Andrew Sayers <andrew-git@xxxxxxxxxxxxxxx> writes:
>>> +# You can
>>> +# override the value of GIT_PS1_SHOWUPSTREAM on a per-repository
>>> +# basis by setting the bash.showUpstream config variable.
>>
>> That's totally backwards from it should be, isn't it?
>>
>> Usually configuration variables are used to give you the default, and
>> you use environment variables to override them.
>
> I basically agree with Thomas here.
Ok.
> ... If someone had e.g. imported their old
> SVN history into a git project, or did clever git tricks on a branch
> they regularly merged into SVN, they would want to override the default
> behaviour. This is probably quite rare now I think about it, and I've
> rejigged the documentation a bit to reflect that.
Yeah, I see.
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?
Which led me to this expectation:
>>> + svn-remote.*.url)
>>> + svn_remote[ $((${#svn_remote[@]} + 1)) ]="$value"
>>> + svn_url_pattern+="\\|$value"
>>> + upstream=svn # default upstream is SVN if available
>>> + ;;
>>
>> I expected that (1) when on a branch that is a fork of a svn upstream, you
>> would use the svn magic; (2) otherwise when on a branch that is a fork of
>> a git upstream, you would use "@{upstream}". That way, the users do not
>> even have to say "git" or "svn" in GIT_PS1_SHOWUPSTREAM at all, no?
I wonder if looking for "git-svn-id:" in the past log is the best you can
do to see if a branch is forked from a remote that is managed by git-svn;
for one thing, that would not work for "noMetadata" setting.
>> 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?
--
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