On 05/05/2011 10:09 PM, mark florisson wrote:
On 5 May 2011 21:52, Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no> wrote:
There was just a messup in git history: Mark's OpenMP pull request got
merged twice; all commits show up two times.
It doesn't matter, since the two openmp branches with the same changes
merged OK, but we shouldn't make this a habit. For instance, the openMP
commits also show up as part of vitja's pull request, which is confusing.
In Mercurial speak: The openmp branch was used like you would use a
Mercurial "patch queue" in one case, and as a branch in another case. In git
they are the same technically and you rely on conventions to make sure you
don't treat a "queue" as a "branch".
OPTION A) Either i) only branch from master, or ii) make sure you agree with
whoever you're branching from that this is a "branch", not a "patch queue",
so that it isn't rebased under your feet.
We could also, say, prepend all patch queues with an underscore (its
private).
OPTION B) Stop rebasing. I'd have a very hard time doing that myself, but
nobody are pulling from dagss/cython these days anyway.
Opinions?
FYI,
The workflow me and Mark is currently using is:
a) Fork off a feature branch from master (with master I'll always refer to
cython/master)
b) When one gets in sync with master, do NOT merge master, but rather
rebase on top of it:
git pull --rebase origin master
c) Continue rebasing, and eventually .
The advantage of this approach is that ugly merges disappear from history,
since commits are rewritten. And the history graph looks very nice and is
easy to follow.
BUT, if the result is duplication, we should avoid this practice, and rather
always merge.
Dag Sverre
>
I think the rebasing is pretty elegant, so I'm +1 on that, as long as
everyone agrees because those duplicated commits are nasty. I'm
surprised git didn't issue an error to prevent this.
Going OT:
I guess a principle of git is to be as dumb as possible, so that you can
predict what it does.
When you rebase, you really get entirely new versions of all your
commits. There's no way to link the old commits with the new commits,
except to compare the commit message. And not even that, since you can
change commit messages during rebases.
Git doesn't even store commits by their diff, it stores each commit by
the resulting full tree contents, so even if the patch is the exact
same, git couldn't really know (without going through your entire
history and check for "similar changes"...ugh)
What I wish they did was to add a simple "rebased-from" header field on
commits, which could be trivially checked on merges to issue a warning.
I guess the reason it is not there is because usually you're about to
(automatically) throw away the commits, so the only purpose it would
have would be sort of pedagogical.
Dag Sverre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
