Re: [RFC/PATCH] git-svn: add support for --first-parent

From: David Kastrup <dak@gnu.org>
Date: Sep 6, 2007, 08:05 UTC
Message-ID: <85ejhcfccp.fsf@lola.goethe.zz>
In-Reply-To: <20070906075104.GA10192@hand.yhbt.net>

Eric Wong <normalperson@yhbt.net> writes:

Show 24 quoted lines

> Lars Hjemli <hjemli@gmail.com> wrote:
>> On 9/5/07, Eric Wong <normalperson@yhbt.net> wrote:
>> > Lars Hjemli <hjemli@gmail.com> wrote:
>> > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
>> > > messages, it can get confused when local history contains merges with
>> > > other git-svn branches. But if --first-parent is supplied to git-log,
>> > > working_head_info() will only see 'branch-local' commits and thus the
>> > > first commit containing a 'git-svn-id' line should refer to the correct
>> > > subversion branch.
>> >
>> > Ideally, we'd probably stop, say something and give the user the choice
>> > of branches if multiple parents available.
>> 
>> Could you elaborate? (I don't understand how following the first
>> parent of a merge could end up at the wrong svn branch)
>
> Well, if the user didn't know about --first-parent (like me yesterday
> :), they could still end up miscommitting to any branch.  That's been a
> complaint of users for a while now.  Thinking more about it,
> --first-parent should probably be the default.
>
> But, if they want to commit a different branch instead of the one they
> merged into (so the second/third/fourth parent), --first-parent would
> never give them that chance.

If they want to commit to a different branch, they can b****y well check out that branch and merge to _that_. That is the way all the rest of git works and nobody whines that this is a restriction.

Quite the opposite: that git-svn does not feel constrained to actually commit to the base of the checked-out branch is a complete nuisance. _Why_ would anybody want to dcommit to a Subversion branch not associated with the current branch?

Just yesterday, I _again_ had git-svn dcommit to a nonsensical branch (this time, the commit was to branch instead of the trunk, while more often the catastrophes happen the other way round). And it is not like git-svn gives you a chance to override this bad decision: you have to rebase -i all of your commit messages from potential cherrypicks or whatever else and remove the git-svn taglines manually for every commit before git-svn will deign to dcommit to the same branch as before.

Eric, this is not "flexibility". This is madness. If you think that it is essential to dcommit to a branch unrelated to the current HEAD, then create a sane command line interface for it that takes effect at the time of dcommit. But the current interface is just throwing dice as far as the user is concerned, since the addition of git-svn tags to commit messages happens behind his back, and any merge or cherrypick or rebase 5 revisions back might come to bite you.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum