[IPython-dev] Pull request workflow...
hans_meine at gmx.net
Tue Oct 12 05:14:15 EDT 2010
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,
PS: I used these commands to produce an example hg repository for testing:
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 ci -m "merged topic branch"
More information about the IPython-dev