Re: [PATCHv5 0/2] bash completion: Support "divergence from upstream" messages in __git_ps1

Andrew Sayers [off-list ref] writes:

quoted

quoted

+#       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:

quoted

quoted

+			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.

quoted

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?

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}.

quoted

quoted

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