[IPython-dev] Pull request workflow...

[Hans Meine]

Hi Fernando,

I did not get into the discussion so far, since I am very new to Git.  
However, I have a lot of experience with Mercurial, and I spent a lot of time 
thinking about equivalent problems with hg.

AFAICS, I am more with Brian than with your original proposal here; I also do 
believe that the DVCS should capture the original development process.

Op den Dingsdag 12 Oktober 2010 Klock 04:01:55 hett Fernando Perez schreven:
> Those are valid points.  Let me try to clarify my perspective and why
> I suggested the rebasing.  Compare the two screenshots:
> 
> - http://imgur.com/nBZI2: merged branch where I rebased right before
> pushing - http://imgur.com/7bNOy: merged branch (yellow) where I did NOT
> rebase before pushing.
> 
> I find the former much easier to follow than the latter, because all
> related commits are topologically together.

My opinion here is that one should separate the data (commits) and 
presentation (above graphs).  IMO it is the task of the commit log viewer to 
present a graph as nice as possible - many of your complaints do not actually 
concern the graph itself, but its linearized view, no?

Actually, I would even say that repeated merges should be fine and being 
presented in a much nicer manner, but I also see that we need to live with the 
tools we got.

The current state of Git GUIs and graph viewers is not clear to me at all, but 
the "bad" example you posted looks really stupid to me.  I seem to recall a 
discussion concerning grouped changesets in some HG repo viewer, but a quick 
test showed that the same zig-zag effect is presented (at least by default) by 
the hg tools I am using (Logilab's hgview, TortoiseHG, and hg serve's HTML).

> I also don't think the rebased verion is a much less clear reflection
> of the original history, as all commits in the rebased version retain
> their original message and timestamp, so one can easily see when
> things happened.

It would even be possible to re-order the changesets without changing their 
topology or ID at all (in hg I would know how to do that), but obviously the 
log viewers all present the exact linear order of changesets found in the 
local repo storage. :-(

Have a nice day,
  Hans

PS: I used these commands to produce an example hg repository for testing:

mkdir foo
cd foo
hg init
echo hello > world
hg add world
hg ci -m "first"
echo first > extra
hg add extra
hg ci -m "created extra (topic branch)"
hg up 0
echo second.2 >> world
hg ci -m "second"
hg up 1
echo second >> extra
hg ci -m "expanded extra (topic branch)"
hg up 2
echo third.2 >> world
hg ci -m "third"
hg merge
hg ci -m "merged topic branch"