also sprach Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> [2011.08.03.0125 +0200]:
> >> For my first mentioned problem, I think a new 'system' needs to be
> >> 'rebase' based, not merge based like TopGit.
> >
> > The problem with rebasing is that you cannot publish the branches.
>
> That doesn't hold you back to publish them. But the other side need to
> know how to deal with them.
>
> Saying that doesn't mean I know a good way to deal with them. I mostly
> end up using plumbing commands to deal with this.
Let me address this in terms of patch queue branches. Obviously, you
are talking topic branches, but wrt rebase-publish, the two are
identical. Patch queue branches are essentially quilt imports, e.g.
one-commit-one-patch, usually edited with git rebase -i (which some
people consider to be the better quilt).
The problem that led me away from patch queue branches is that
— albeit unlikely in our context (distro packaging) — it is possible
that you and I both rewrite the patch queue at the same time. The
first one to push will then have his changes overwritten by the
second push — in order to push the rebased ref,
receive.denyNonFastForwards needs to be off.
Unfortunately, I can't see a remedy to this, apart from tagging each
and every patch queue branch, but that does not solve the problem of
having to merge changes made simultaneously. It could go something
like this:
1. ensure that noone has pushed an updated ref since you last
fetched.
2. if a new ref is found, download it and rebase your own patch
queue on top of it, consolidating the changes.
3. tag and push your new ref.
But there's a race condition in this, and so we're back to square
one.
--
martin | http://madduck.net/ | http://two.sentenc.es/
uʍop ǝpısdn sı ɹoʇıuoɯ ɹnoʎ
spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)