Stephen Haberman wrote:
This is the expected behavior and not up for debate.
Cool, thanks for the reply. However, I debate... :-)
---o--o--o--o--o--o <-- origin
\
A'--B' <-- master
Nice. That makes sense in your scenario.
Here is mine:
---A--B--C--D <-- origin/stable
\ |
E--F | <-- origin/topica
\ |
g--h <-- topica
All the upper case commits have been published to origin. Other
devs, etc., know about them, their hashes are in the bug tracking
system.
I'm bringing topica up to date, but with a merge because I have
published history already on topica, so I merge stable and get a
new merge commit: g. And maybe make another change: h.
Why do you merge stable at this point?
If you want the latest and greatest for testing/conflict resolution
purposes, you can simply throw away the merge later and just know
that it works.
If you need some bugfix on stable but not everything else, cherrypick
only that change. Otherwise you're applying a huge patch to fix a
small problem.
Everything's cool...now, with surprising frequency, someone beats
me to moving origin/topica:
---A--B--C--D <-- origin/stable
\ |
E--F---|--I <-- origin/topica
\ |
g--h <-- topica
Pushing h gets rejected as a rewind. Good. I want to pull, which
we had previously always used "--rebase" for, and the desired output
of a pull --rebase, to me, would be:
---A--B--C--D <-- origin/stable
\ \
E--F--I | <-- origin/topica
\|
g'--h' <-- topica
Instead, I get:
---A--B--C--D <-- origin/stable
\
E--F--I <-- origin/topica
\
B'-C'-D'-h'<-- topica
So, yes, linearized history with no merges. However, this leads
to quizzical looks when B'/C'/D' hit the email list, bug tracker, etc.
as new commits.
Currently I just try to pull/merge/push in quick succession, but
it's a manual collaboration hack ("okay, I'm merging now, no
committing...") that would be nice to not have to worry about.
I think you just need to ask yourself *why* you're doing that
first merge of "stable" into your topic. If they aren't really
separate, using a topic-branch doesn't make so much sense. If
they *are* separate, doing the merge doesn't make much sense,
unless you're integration testing a snapshot build, but in that
case you'd want to throw away the merge once it's done and
tested.
I need to investigate the interactive rebase more, but my hesitant
assertion is that it's parent rewriting seems smart enough to handle
this. Perhaps not, and I admit our desired DAG output may not be
attainable without manual intervention.
I apologize--I should have included the example DAGs in my first
post, but since I didn't I felt the need to clarify. So, humoring
me, is the B'/C'/D' from this example really the expected behavior?
Assuming the person who did "h" doesn't have the merge commit, then
yes.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
