[haiku-commits] Re: haiku: hrev43263 - in src/apps/debugger: files user_interface/gui/team_window

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 14 Nov 2011 12:10:28 +0100

On 2011-11-14 at 02:36:06 [+0100], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> On Sun, Nov 13, 2011 at 8:29 PM, Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> > Is there by any chance an easy way to prune commits like this prior to
> > pushing back to master?
> >

I know geist has answered this on IRC, but not knowing what exactly he has 
suggested, here's my take:

If you have applied your local changes directly to master (i.e. you have 
not done an explicit merge), you can use 'git pull --rebase' to rebase 
those local changes to the top of the updated master. You can even do this 
repeatedly if someone has pushed while you were busy solving rebase 
conflicts.

However, if you have been working on a branch and merged that into master 
(which I think was the case here) and then failed to push, doing 'git pull 
--rebase' has unwanted effects: basically, it will throw away the merge 
commit for your local branch onto master, which in turn will yield 
duplicate changesets. In order to avoid that, one has to use 'git rebase -p 
remote/origin/master' to explicitly rebase your local master on the remote 
master, while preserving your merge commit.

You can (and should) of course always pull on master, then rebase your 
local branch, merge it into master and the push, but there's always a 
possibility of someone sneaking in commits in the meantime. So the 
situation can't really be avoided at all times.

You can find a much more elaborate description of the problem here:

        http://notes.envato.com/developers/rebasing-merge-commits-in-git/

If this sounds a bit complicated, it is because rebasing is a powerful, but 
somewhat dangerous operation. 

Concerning the "clean history": actually there are two different versions 
of that:

- people that prefer rebase aim for a "structurally clean" history, with
  a linear line of changesets

- people that prefer merges aim for a "chronologically clean" history, where
  the structure of changesets represents the chronological structure of the 
  development (i.e. changesets that were developed at the same time sit next
  to each other, in (potentially anonymous) branches.

I'm a bit torn on the topic of which kind of "clean" history we should aim 
for: I can see the point of rebasing, but I don't think it's really 
important to try to maintain a linear history in our master. 
After all, doing your local work on branches (instead of doing them 
directly on master) is encouraged and when merging those, you will create 
merge commits anyway.

What we *should* definitely avoid, though, is the degenerate case described 
in the article above, with duplicate commits and dangling branches. So: 
rebasing on master is ok if you know what you're doing. If not, please 
learn to live with those merge commits.

cheers,
        Oliver

Other related posts: