# git-svn: does anybody care for sub-optimal merge tracking?

1 messages from 2007-01-15 to 2007-01-15. Participants: Eric Wong.
Thread: https://gitlist.dev/t/6387

## Eric Wong, 2007-01-15 06:56

Subject: git-svn: does anybody care for sub-optimal merge tracking?
Message-ID: <20070115065635.GA939@localdomain>
URL: https://gitlist.dev/e/20070115065635.GA939%40localdomain

```
First off, parental information on the creation of new tags and branches
will stay, meaning --follow-parent will remain in git-svn; and will
probably even become the default for fetching.

However... there are some experimental features in git-svn
that I'm considering dropping:

* tree matching: -b/--branch <refname> and -B/--branch-all-refs[1]
* the graft-branches command

Tree matches are usually done at fetch time, and will add parents to an
imported commit if the tree matches the one made in a commit.  I
originated this feature myself, but have not used it often.

Tree matching likely has problems with a dcommit-based
workflow (I haven't heard any complaints, either because nobody is using
it or they're still using set-tree (formerly 'commit').

Tree matching will almost certainly go away unless somebody raises some
very good objections.

graft-branches attempts to do merge-tracking via regexes on log
messages, analyzing parenting information in logs, and also via tree
matching (like -b/-B).  git-svnimport does somewhat the same things
(minus tree matching), but at import time (not after-the-fact with
grafts).

Despite spending a reasonable amount of time creating graft-branches, I
have hardly ever used it on real projects; and the times I did use it I
didn't think it was very useful.  The regex matching on log messages and
parenting information in logs should not be harmful to a dcommit-based
workflow.

[1] - apologies for not documenting -B/--branch-all-refs in
      the manpage, it's basically shorthand for:
      `git-rev-parse --symbolic --all | xargs -n1 echo -b`

-- 
Eric Wong

```