Re: [orion-dev] git rebase by default

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

You're right that in general the choice
between merge and rebase is more complex. Rebase is mainly useful for commits
that you have never pushed to a remote. In particular this very common
workflow:

- Pull from origin/master
- Do some work, make a commit
- Attempt to push -> fails because
someone else has pushed to origin/master in the meantime
- Rebase your commit on origin/master
and now you can push

In this case rebase avoids the extra
merge commits appearing in master. These merges don't add any interesting
information on the overall branch history - they contain the same changes
from one or more previous commits, applied to a different parent commit.
They just add clutter and they are confusing to look at - the author attribute
on such a commit won't match the person who actually made the changes it
contains (they just authored the "merge" where they caught up
to someone else's changes).

The dangerous kind of rebase is rewriting
history that has already been pushed to a remote clone. This destroys existing
commit hashes, which will also destroy any tags that were against those
commits. This is the kind of rebase people are talking about when they
refer to "rebase is dangerous". At eclipse.org that kind of rebase
is completely disallowed using a git configuration settings (receive.denyNonFastForward).
So in our Eclipse world, only "safe" rebase operations on your
local branches are permitted.

But it's a good point that not all Orion
users are eclipse.org Git repository users. Someone could be using Orion
with a repository at github or elsewhere where history-destroying rebases
are allowed, and we need to be careful in Orion not to make it too easy
for a novice Git user to lose data. I think the changes we have been talking
about here are just:

- Make sure the option to rebase is
available in all places where merge is available (such as git status page)
- Make it easier to configure the policy
setting that controls whether "git pull" does a merge or rebase.
By default in Git this is rebase, which I don't think we should globally
change. But we could make it very easy to set the policy to rebase for
people who want that (which includes just about all eclipse.org committers
users I would imagine). I could also imagine a user profile setting to
the effect of "use rebase policy for all local branches I create".

John

Kris De Volder <kdvolder@xxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

02/13/2012 01:52 PM

Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	Re: [orion-dev] git rebase by default

It seems like a complex issue to me... Though
I don't think I quite understand all the issues here.
My feeling is that what default is sensible would probably depend on your
workflow (and on personal
preference). I've seen some opinions out there that 'rebase is evil'. 

E.g: http://changelog.complete.org/archives/586-rebase-considered-harmful

I'm not expert, but the gist of it seems that issues with rebase arise
if you rebase a branch that is shared with other people. It would be fine
to rebase a branch that only exists in your local clone on your own personal
machine.

Here's another opionion arguing for use of both rebase and merge depending
on what you are doing:
http://gitguru.com/2009/02/03/rebase-v-merge-in-git/

He seems to argue for a workflow doing rebases for 'spin-off branches'
and merges to bring in changes back into 'master'. (That incidentally does
seem to
Jive with making rebase default for new branches... assuming you won't
actually push those branches and share them with anyone else).

Finally, from what I've read here and there (sorry can't find a link right
now)... it seems that merge is the best default unless people really understand
what they are doing with rebase.

I think it is great to have the option to choose your strategy when you
create a new branch, but I'm not so sure that rebase would be the right
default for everyone and for every workflow.

Since rebase seems to be considered 'dangerous' and 'harmfull' by some,
I would be a little worried to pick that as a blanket default for any new
branch.
Maybe it makes more sense to choose 'merge' as default. And if you consider
yourself an expert, you can then somehow and easily override that to use
rebase when appropriate.

Kris

---

See also 370735: Improvements to the
Add Branch action (https://bugs.eclipse.org/bugs/show_bug.cgi?id=370735)
One of the goals is to choose the pull strategy for newly created branches.
Rebase strategy could be the default.
--
Szymon 



From:        John
J Barton <johnjbarton@xxxxxxxxxxxxxxx>
To:        Orion
developer discussions <orion-dev@xxxxxxxxxxx>
Date:        2012-02-10
18:45 
Subject:        [orion-dev]
git rebase by default 
Sent by:        orion-dev-bounces@xxxxxxxxxxx

---

I sense that git mavens believe that the default workflow for git
should be rebase rather than merge:

http://d.strelau.net/post/47338904/git-pull-rebase-by-default

If true, then it would be great if Orion can make this default easy to
use.

jjb
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev



_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev