On 18/06/10 17:10, Junio C Hamano wrote:
>
> But doesn't all of the above suggest the decision should be per branch?
> It is not too implausible to have a branch that is actively interacting
> with SVN upstream and another branch whose upstream has migrated from SVN
> and now managed by git. Say you and your pal are working with a project
> that is managed by SVN, and you use one of your branches to interact
> directly with SVN upstream. Your pal has a branch forked from the same
> SVN upstream, and one of your other branches is building on top of her
> work. When you are on the former branch, you would want to know how your
> work diverged from the SVN upstream; when you are on the latter branch,
> you would want to know how your work diverged from your pal's git branch
> that you are using as its upstream. No?
>
It sounds like you're asking for git-svn to set
git.<branch>.{remote|upstream}, and for this script to ditch the
SVN-specific workarounds. I have no problem with such a solution, but I
also have no idea where to begin with it. Is there some reason we don't
do this already?
A simpler 90% solution would be to switch the defaults around, so you
always use @{upstream} if defined, or otherwise search for the SVN
upstream. This enables every use case except noMetadata, and I suspect
any solution to that one would be at least as complex as setting
git.<branch>.{remote|upstream}.
>>> If you "tr" to trash "\0" anyway, do you need to run "config -z"?
>>
>> The `tr` is there to work around issues like this:
>>
>> git config bash.showUpstream $'svn\nlegacy'
>> git config bash.showUpstream | tr '\0\n' '\n '
>
> Is that even an issue? Why should there be a LF in the value? I thought
> you defined it as a string with space separated magic tokens... Perhaps I
> am missing something?
My concern was more with the robustness principle than anything - LFs
aren't part of the format defined in the docs, and I can't think of a
reason why people would need them, but there's no mechanical way to stop
people putting them in there. If you're saying that git users can be
trusted not to do anything so stupid (and/or that it's their problem if
they do), then I'm happy to get rid of this.
- Andrew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html