Show 30 quoted lines
> David Watson <dwatson@mimvista.com> writes:
>
>> Yes, that's quite true. It took me quite a while to figure that out
>> when I first started using git-svn, and its non-sensicalness nearly
>> put me off using git entirely. My workflow at this point is to use
>> git-cherry-pick -e to pull in any changes from other branches, then
>> delete the git-svn-id line.
>>
>> Essentially, merging using git-svn is almost entirely broken, since
>> an inconsistent tool is worthless - you spend more time figuring out
>> if it's going to break, and working around the breakage, than you
>> save using it.
>
> Full agreement.
>
>> Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping
>> its metadata about which SVN branch it's connected to isn't the best
>> thing, but git-merge is doing exactly what you ask for. Perhaps we
>> need a merge command in git-svn that does the right thing?
>
> Git svn needs to recognize a merge for what it is, and has to ignore
> the branch which has been merged, looking further for git-svn-id lines
> or whatever. Cherrypicking is harder to contain. Basically, I think
> it is a mistake to use something as fragile as the git-svn-id line in
> the log for determining the branch to use for committing. Instead, a
> fixed association of git branches with git-svn should be established.
> Even if one needs to write this manually into some configuration file.
> Before git-svn does not have reliable information, it should refuse to
> commit. One could specify this on the command line, too: that is a
> small price to pay for being sure that one commits where one wants to.
PostScriptum: that is probably all nonsense. git-svn fetch knows what
to fetch, and probably also what to merge (this should be quite
similar to git pull's behavior), and git-svn rebase/dcommit should not
do anything different.
David Kastrup <dak@gnu.org>