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

Eric Wong [off-list ref] writes:

Lars Hjemli [off-list ref] wrote:

quoted

On 9/5/07, Eric Wong [off-list ref] wrote:

quoted

Lars Hjemli [off-list ref] wrote:

quoted

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