Re: [PATCHv5 0/2] bash completion: Support "divergence from upstream" messages in __git_ps1
- From
- Andrew Sayers <andrew-git@pileofstuff.org>
- Date
- Jun 18, 2010, 21:02 UTC
- Message-ID
- <4C1BDED3.2090002@pileofstuff.org>
- In-Reply-To
- <7vljacxqwc.fsf@alter.siamese.dyndns.org>
On 18/06/10 17:10, Junio C Hamano wrote:
Show 13 quoted lines
> > 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}.
Show 10 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?
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