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

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`