[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orion-dev] git rebase by default
|
Thanks John,
I've been learning a lot about git since getting on orion.
So far I've been mostly one of those 'naive' users who should stick to using merge.
I think I'm starting to understand when rebases are more appropriate and when they are not :-)
> - 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.
I'm guessing that was a typo... and you meant to say the default in git is *merge*.
Anyhow, it sounds like you guys know what you are doing :-)
I just wanted to make sure you spent some thought on the 'naive' users who may get themselves (and others they work with) into trouble with bad use of rebase.
Kris
----- Original Message -----
> 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
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev