git rebase question

[Colin Macdonald]

[replying to maillist instead of issue tracker]

> I've noticed that you rebase a lot. Rebasing after code is "public" is not a great
> habit to get into. Check our dev workflow ...

Thanks for this.  From the dev workflow doc:

> The only time when it is recommended to rebase instead of merge is when you
> need to edit your commit messages, or **remove unnecessary commits**.

Would this latter case include cleaning up a (sordid) history that has approaches
tried but latter reverted?  For example in pr #7824, I had some low-level changes
to superclasses that are later reverted.  Otherwise, strikes me as messy to have
that sort of thing in the history of master...

thanks,
Colin

[Jason Moore]

The issue with rebasing is that if you release code publicly, other people can clone it, then the rebase changes the history but the history isn't changed on everyone else's clone so things get harry. Rebasing changes the history, so it should only be done when you are the only person who's "seen" the history. It also screws up all the comments in the Github PR because they can no longer link to an existing diff. But if you are the *only* person working on a branch/pr that you've push publicly then rebasing a bunch of small commits into fewer nicely packaged commits is fine to do before merging to master. Just beware that once you start working on a branch with commits by more than one author headaches will likely be introduced by rebasing.

Jason
moorepants.info
+01 530-601-9791

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c94ed790-6016-4e26-a562-e778cb70d412%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sergey Kirpichev]

On Thursday, October 2, 2014 12:46:25 AM UTC+4, Colin Macdonald wrote:

[replying to maillist instead of issue tracker]

Would this latter case include cleaning up a (sordid) history that has approaches
tried but latter reverted?

It's ok, but only as a last resort, after the review was 1) done and 2) is positive.

[Joachim Durchholz]

Am 01.10.2014 um 22:46 schrieb Colin Macdonald:
> Would this latter case include cleaning up a (sordid) history that has
> approaches
> tried but latter reverted? For example in pr #7824, I had some low-level
> changes
> to superclasses that are later reverted. Otherwise, strikes me as messy to
> have
> that sort of thing in the history of master...

Things get messy for others if they merge your work into their own
changes - they will need to rebase their work, too.

As long as you put up your updates with an explicit "don't merge" tag,
it's fine (except that github discussions will get lost, which is
not-so-nice; you should summarize these discussions in comments in the
rebased code, but this still isn't *that* optimal).

A messy history isn't *that* much of an issue. We mostly need it for
bisecting, and possibly to trace back a decision (in which case we'll
want to look at the discussions again).

HTH
Jo