Re: [PATCHv5 0/2] bash completion: Support "divergence from upstream" messages in __git_ps1
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 18, 2010, 16:10 UTC
- Message-ID
- <7vljacxqwc.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4C1A9442.7080304@pileofstuff.org>
Andrew Sayers <andrew-git@pileofstuff.org> writes:
Show 10 quoted lines
>>> +# 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.
Show 5 quoted lines
> ... 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:
Show 10 quoted lines
>>> + 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.
Show 6 quoted lines
>> 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?