Re: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".

Yann Dirson [off-list ref] writes:

On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:

quoted

OK, tried again and 'stg pull' doesn't update the base with the last
patch in the series ('stg rebase origin' updates it). I don't have
anything set up in my gitconfig in this area.

So now that this particular problem has a fix, let's fix everything
related.

Since branch.*.merge accept local ref names, there is probably far
more to change that what I initially feared.

If that is the case maybe we should fix branch.*.merge not to
match the local tracking branch name.  Matching it with local
tracking branch name when the remote name does not match was
werely a fallback to help broken configurations confused people
might create by hand, and has never been the part of sane
practice at all.

Junio C Hamano [off-list ref] writes:

Yann Dirson [off-list ref] writes:
...

quoted

Since branch.*.merge accept local ref names, there is probably far
more to change that what I initially feared.

If that is the case maybe we should fix branch.*.merge not to
match the local tracking branch name.  Matching it with local
tracking branch name when the remote name does not match was
werely a fallback to help broken configurations confused people
might create by hand, and has never been the part of sane
practice at all.

That is, I suspect that reverting 80c79776 would make things a
lot more consistent.

-- >8 --
[PATCH] Revert "Allow branch.*.merge to talk about remote tracking branches."

This reverts commit 80c797764a6b6a373f0f1f47d7f56b0d950418a9.

Back when I committed this, it seemed to be a good idea.  People
who always use remote tracking branches can optionally use the
local name they happen to use to specify what to merge, which meant
that I did not have to teach them why we use the name at the remote
side every time they are confused.

But allowing it seems to break other people's scripts.  The real
solution is not to allow more ways to express the same thing, but
to educate people to use the right syntax.

Signed-off-by: Junio C Hamano <redacted>
---
 git-parse-remote.sh |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 3e783b7..5208ee6 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh

@@ -174,12 +174,8 @@ canon_refs_list_for_fetch () {
 		else
 			for merge_branch in $merge_branches
 			do
-			    if	test "$remote" = "$merge_branch" ||
-				test "$local" = "$merge_branch"
-			    then
-				    dot_prefix=
-				    break
-			    fi
+			    [ "$remote" = "$merge_branch" ] &&
+			    dot_prefix= && break
 			done
 		fi
 		case "$remote" in

-- 
1.5.0.rc3.24.g2391

On Sat, Feb 03, 2007 at 03:01:59PM -0800, Junio C Hamano wrote:

Yann Dirson [off-list ref] writes:

quoted

On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:

quoted

OK, tried again and 'stg pull' doesn't update the base with the last
patch in the series ('stg rebase origin' updates it). I don't have
anything set up in my gitconfig in this area.

So now that this particular problem has a fix, let's fix everything
related.

Since branch.*.merge accept local ref names, there is probably far
more to change that what I initially feared.

If that is the case maybe we should fix branch.*.merge not to
match the local tracking branch name.  Matching it with local
tracking branch name when the remote name does not match was
werely a fallback to help broken configurations confused people
might create by hand, and has never been the part of sane
practice at all.

Oh, sorry, I indeed meant "less to change" :>

Since git-fetch alone makes the decisions (so no algorithm has to get
duplicated into stgit), and since the only remote refs possibly
confused for local ones are the old non-separate ones, and since in
that case usually the remote branches are mapped to the same name, the
odds for a problem are low, and will get lower.

Making branch.*.merge not understand local refs, OTOH, would require
stgit to resolve a local branch to its remote name.  Note that I
already had to do the job to guess which remote a branch was pulled
from (and thus, to decide whether a branch was local or remote).

Fortunately, all of this is going to be unnecessary on newer repos
since git-clone now fills all the fields - we only have to deal with
the upgrade of older repos.

Best regards,
-- 
Yann.

On Sat, Feb 03, 2007 at 03:01:59PM -0800, Junio C Hamano wrote:

quoted

Since branch.*.merge accept local ref names, there is probably far
more to change that what I initially feared.

If that is the case maybe we should fix branch.*.merge not to
match the local tracking branch name.  Matching it with local
tracking branch name when the remote name does not match was
werely a fallback to help broken configurations confused people
might create by hand, and has never been the part of sane
practice at all.

I was one of the major pushers of this feature in December; however, I
think it actually can create some confusing results. See:
  http://article.gmane.org/gmane.comp.version-control.git/35789

I still think it is worth pursuing, but I have been waiting for v1.5.0
to happen before stirring up more trouble. Regardless, I think this
implementation is not the right way to go about it, and you should
revert 80c79776.

-Peff