[PATCH 0/3] Update to stgit parent tracking

[PATCH 0/3] Update to stgit parent tracking

[Yann Dirson]

The following series brings a couple of improvements to parent- and
remote-handling stuff, including addressing the FIXME you pointed to
in your reply.

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

[PATCH 1/3] The user does not want to mess with the refspecs.

[Yann Dirson]

The only use I know of for this parameter is 'stg pull . <branch>',
for which 'stg rebase <branch>' should be used instead.

Signed-off-by: Yann Dirson <ydirson@altern.org>
---

 stgit/commands/pull.py |   13 ++++---------
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 0608fb6..f837fd4 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -24,7 +24,7 @@ from stgit import stack, git
 
 
 help = 'pull the changes from the remote repository'
-usage = """%prog [options] [<repository>] [<refspec>]
+usage = """%prog [options] [<repository>]
 
 Pull the latest changes from the given repository (defaulting to
 'origin'). This command works by popping all the patches from the
@@ -34,8 +34,7 @@ of the stack to the latest parent HEAD and pushing the patches back
 there are conflicts. They need to be resolved and the patch pushed
 again.
 
-Check the 'git pull' documentation for the <repository> and <refspec>
-format."""
+Check the 'git pull' documentation for the <repository> format."""
 
 options = [make_option('-n', '--nopush',
                        help = 'do not push the patches back after pulling',
@@ -47,7 +46,7 @@ options = [make_option('-n', '--nopush',
 def func(parser, options, args):
     """Pull the changes from a remote repository
     """
-    if len(args) > 2:
+    if len(args) > 1:
         parser.error('incorrect number of arguments')
 
     if len(args) >= 1:
@@ -55,10 +54,6 @@ def func(parser, options, args):
     else:
         repository = crt_series.get_parent_remote()
 
-    refspec = None
-    if len(args) == 2:
-        refspec = args[1]
-
     if crt_series.get_protected():
         raise CmdException, 'This branch is protected. Pulls are not permitted'
 
@@ -76,7 +71,7 @@ def func(parser, options, args):
 
     # pull the remote changes
     print 'Pulling from "%s"...' % repository
-    git.pull(repository, refspec)
+    git.pull(repository)
     print 'done'
 
     # push the patches back

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

[Yann Dirson]

Previously we were just assuming that the remote from which we
just failed defined a local branch whose name was the same as the
remote def, and that this branch was the parent.  While this is true
for the most common case (branch "origin" from remote "origin"), it is
quite an unflexible assumption.

Also move the rebasing from git.pull to commands.pull.func since that
is clearly stgit-level stuff, and rename git.pull() to git.fetch() to
match default behaviour.

Signed-off-by: Yann Dirson <ydirson@altern.org>
---

 stgit/commands/pull.py |   20 +++++++++++---------
 stgit/git.py           |   10 +++-------
 2 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index f837fd4..15bbed6 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -26,15 +26,15 @@ from stgit import stack, git
 help = 'pull the changes from the remote repository'
 usage = """%prog [options] [<repository>]
 
-Pull the latest changes from the given repository (defaulting to
-'origin'). This command works by popping all the patches from the
-stack, pulling the changes in the parent repository, setting the base
-of the stack to the latest parent HEAD and pushing the patches back
-(unless '--nopush' is specified). The 'push' operation can fail if
-there are conflicts. They need to be resolved and the patch pushed
-again.
+Pull the latest changes from the given remote repository (defaulting
+to branch.<name>.remote, or 'origin' if not set). This command works
+by popping all the patches from the stack, pulling the changes in the
+parent repository, setting the base of the stack to the latest parent
+HEAD and pushing the patches back (unless '--nopush' is specified).
+The 'push' operation can fail if there are conflicts. They need to be
+resolved and the patch pushed again.
 
-Check the 'git pull' documentation for the <repository> format."""
+Check the 'git fetch' documentation for the <repository> format."""
 
 options = [make_option('-n', '--nopush',
                        help = 'do not push the patches back after pulling',
@@ -71,7 +71,9 @@ def func(parser, options, args):
 
     # pull the remote changes
     print 'Pulling from "%s"...' % repository
-    git.pull(repository)
+    git.fetch(repository)
+    if (config.get('stgit.pull-does-rebase')):
+        git.reset(tree_id = git.rev_parse(crt_series.get_parent_branch()))
     print 'done'
 
     # push the patches back
diff --git a/stgit/git.py b/stgit/git.py
index e30b959..49ebae1 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -807,9 +807,9 @@ def reset(files = None, tree_id = None, check_out = True):
     if not files:
         __set_head(tree_id)
 
-def pull(repository = 'origin', refspec = None):
-    """Pull changes from the remote repository. Uses 'git-fetch'
-    and moves the stack base.
+def fetch(repository = 'origin', refspec = None):
+    """Fetches changes from the remote repository, using 'git-fetch'
+    by default.
     """
     # we update the HEAD
     __clear_head_cache()
@@ -822,10 +822,6 @@ def pull(repository = 'origin', refspec = None):
     if __run(command, args) != 0:
         raise GitException, 'Failed "%s %s"' % (command, repository)
 
-    if (config.get('stgit.pull-does-rebase')):
-        # FIXME!
-        reset(tree_id = rev_parse(repository))
-
 def repack():
     """Repack all objects into a single pack
     """

[PATCH 3/3] Do not return 'origin' as parent remote when there is no such remote.

[Yann Dirson]

Signed-off-by: Yann Dirson <ydirson@altern.org>
---

 stgit/stack.py |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/stgit/stack.py b/stgit/stack.py
index dbdda01..729b77e 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -408,7 +408,15 @@ class Series(StgitObject):
         self._set_field('description', line)
 
     def get_parent_remote(self):
-        return config.get('branch.%s.remote' % self.__name) or 'origin'
+        value = config.get('branch.%s.remote' % self.__name)
+        if value:
+            return value
+        elif 'origin' in git.remotes_list():
+            # FIXME: this is for compatibility only.  Should be
+            # dropped when all relevant commands record this info.
+            return 'origin'
+        else:
+            raise StackException, 'Cannot find a parent remote for "%s"' % self.__name
 
     def __set_parent_remote(self, remote):
         value = config.set('branch.%s.remote' % self.__name, remote)
@@ -418,6 +426,8 @@ class Series(StgitObject):
         if value:
             return value
         elif git.rev_parse('heads/origin'):
+            # FIXME: this is for compatibility only.  Should be
+            # dropped when all relevant commands record this info.
             return 'heads/origin'
         else:
             raise StackException, 'Cannot find a parent branch for "%s"' % self.__name

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

[Catalin Marinas]

On 01/02/07, Yann Dirson <ydirson@altern.org> wrote:
> Previously we were just assuming that the remote from which we
> just failed defined a local branch whose name was the same as the
> remote def, and that this branch was the parent.  While this is true
> for the most common case (branch "origin" from remote "origin"), it is
> quite an unflexible assumption.

The t1200-push-modified.sh test fails after applying this patch. It
looks like the 3rd test fails to pull the changes from 'foo' into
'bar'.

Thanks.

-- 
Catalin

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

[Yann Dirson]

On Fri, Feb 02, 2007 at 09:58:06AM +0000, Catalin Marinas wrote:
> On 01/02/07, Yann Dirson <ydirson@altern.org> wrote:
> >Previously we were just assuming that the remote from which we
> >just failed defined a local branch whose name was the same as the
> >remote def, and that this branch was the parent.  While this is true
> >for the most common case (branch "origin" from remote "origin"), it is
> >quite an unflexible assumption.
> 
> The t1200-push-modified.sh test fails after applying this patch. It
> looks like the 3rd test fails to pull the changes from 'foo' into
> 'bar'.

Strange, it passes here, even after pulling you latest commits
(HEAD=fba895f5f12a652c248b0fd02b7c41f8342cfbdc).

Best regards,
-- 
Yann.

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

[Yann Dirson]

On Fri, Feb 02, 2007 at 07:07:06PM +0100, Yann Dirson wrote:
> > The t1200-push-modified.sh test fails after applying this patch. It
> > looks like the 3rd test fails to pull the changes from 'foo' into
> > 'bar'.
> 
> Strange, it passes here, even after pulling you latest commits
> (HEAD=fba895f5f12a652c248b0fd02b7c41f8342cfbdc).

Wondering which GIT version you are using, I tried to run the
testsuite with current GIT HEAD, and it fails much earlier (t1001).
We'll have some work here :)

Best regards,
-- 
Yann.

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

[Catalin Marinas]

On 02/02/07, Yann Dirson <ydirson@altern.org> wrote:
> On Fri, Feb 02, 2007 at 07:07:06PM +0100, Yann Dirson wrote:
> > > The t1200-push-modified.sh test fails after applying this patch. It
> > > looks like the 3rd test fails to pull the changes from 'foo' into
> > > 'bar'.
> >
> > Strange, it passes here, even after pulling you latest commits
> > (HEAD=fba895f5f12a652c248b0fd02b7c41f8342cfbdc).
>
> Wondering which GIT version you are using, I tried to run the
> testsuite with current GIT HEAD, and it fails much earlier (t1001).
> We'll have some work here :)

I tried the latest GIT and it only fails at t1200. I think I got a
t1001 failure but I fixed it. Do you want me to push the snapshot I
have and you can see whether it fails on your system? I tried it with
both Python 2.4 and 2.3 but what's strange is that 'pull' run manually
(not from the test script) seems to work.

-- 
Catalin

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

[Catalin Marinas]

On 02/02/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> I tried the latest GIT and it only fails at t1200. I think I got a
> t1001 failure but I fixed it. Do you want me to push the snapshot I
> have and you can see whether it fails on your system? I tried it with
> both Python 2.4 and 2.3 but what's strange is that 'pull' run manually
> (not from the test script) seems to work.

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.

I already committed the patches I have (and pushed them to the public
repo) so that we know whether you have additional changes.

Thanks.

-- 
Catalin

git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".)

[Yann Dirson]

On Fri, Feb 02, 2007 at 07:07:06PM +0100, Yann Dirson wrote:
> On Fri, Feb 02, 2007 at 09:58:06AM +0000, Catalin Marinas wrote:
> > On 01/02/07, Yann Dirson <ydirson@altern.org> wrote:
> > >Previously we were just assuming that the remote from which we
> > >just failed defined a local branch whose name was the same as the
> > >remote def, and that this branch was the parent.  While this is true
> > >for the most common case (branch "origin" from remote "origin"), it is
> > >quite an unflexible assumption.
> > 
> > The t1200-push-modified.sh test fails after applying this patch. It
> > looks like the 3rd test fails to pull the changes from 'foo' into
> > 'bar'.

With current GIT HEAD, plain git-clone creates the following config
(when cloning a repo with HEAD pointing to branch "downstream":


[remote "origin"]
        url = /export/work/yann/git/stgit/tmp/.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "downstream"]
        remote = origin
        merge = refs/heads/downstream
                ^^^^^^^^^^^^^^^^^^^^^

I would have expected "merge = remotes/origin/downstream" instead, and
this setting confuses the rebase-after-pull logic, causing it to
rebase the stack onto its own base (no-op).

Isn't that a git-clone bug ?

Now, it looks like without this patch, the post-fetch rebasing only
worked by chance, even more than I thought.

Best regards, 
-- 
Yann.

Re: git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".)

[Yann Dirson]

On Sat, Feb 03, 2007 at 12:56:55AM +0100, Yann Dirson wrote:
> With current GIT HEAD, plain git-clone creates the following config
> (when cloning a repo with HEAD pointing to branch "downstream":
> 
> 
> [remote "origin"]
>         url = /export/work/yann/git/stgit/tmp/.git
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "downstream"]
>         remote = origin
>         merge = refs/heads/downstream
>                 ^^^^^^^^^^^^^^^^^^^^^
> 
> I would have expected "merge = remotes/origin/downstream" instead, and
> this setting confuses the rebase-after-pull logic, causing it to
> rebase the stack onto its own base (no-op).

Hm, I see I was confused about the branch.*.merge meaning.  The config
doc does document it to be the remote part of the refspec.

But what does that mean - why using the remote part here ?  I cannot
see that, although I can see arguments why using the local part here:

- When we come to finding the branch to merge, we have already fetched
all remote branches into local ones, so why would we need to find a
local branch matching this remote name ?

- How are we supposed to handle the case where a single remote ref is
mapped to several local ones ?  Although I cannot see a use for this
situation, it would seem to be a valid one, whereas having several
fetch lines for a single local ref in a single remote would clearly
be invalid: using a local ref would avoid a possible ambiguity.

Best regards,
-- 
Yann.

Re: git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".)

[Jakub Narebski]

Yann Dirson wrote:

> With current GIT HEAD, plain git-clone creates the following config
> (when cloning a repo with HEAD pointing to branch "downstream":
> 
> 
> [remote "origin"]
>         url = /export/work/yann/git/stgit/tmp/.git
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "downstream"]
>         remote = origin
>         merge = refs/heads/downstream
>                 ^^^^^^^^^^^^^^^^^^^^^
> 
> I would have expected "merge = remotes/origin/downstream" instead, and
> this setting confuses the rebase-after-pull logic, causing it to
> rebase the stack onto its own base (no-op).
> 
> Isn't that a git-clone bug ?

No, it is a feature. branch.<name>.merge is usually _remote_ head,
to allow pulling without local tracking branch. IIRC there was
patch to allow to use local head, if it is ambiguous.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".)

[Catalin Marinas]

Yann,

On 02/02/07, Yann Dirson <ydirson@altern.org> wrote:
> On Fri, Feb 02, 2007 at 07:07:06PM +0100, Yann Dirson wrote:
> > On Fri, Feb 02, 2007 at 09:58:06AM +0000, Catalin Marinas wrote:
> > > On 01/02/07, Yann Dirson <ydirson@altern.org> wrote:
> > > >Previously we were just assuming that the remote from which we
> > > >just failed defined a local branch whose name was the same as the
> > > >remote def, and that this branch was the parent.  While this is true
> > > >for the most common case (branch "origin" from remote "origin"), it is
> > > >quite an unflexible assumption.
> > >
> > > The t1200-push-modified.sh test fails after applying this patch. It
> > > looks like the 3rd test fails to pull the changes from 'foo' into
> > > 'bar'.
>
> With current GIT HEAD, plain git-clone creates the following config
> (when cloning a repo with HEAD pointing to branch "downstream":

As I haven't followed the GIT latest developments in this area, I
can't comment. Regarding StGIT, I'd like it to work with earlier
stable versions of GIT and not just with the current HEAD. I (and
probably many others) already have repositories cloned some (long)
time ago and their gitconfig might not have the cloning information.

The (interim) solution I see is for StGIT pull command to default to
using git-pull and people can configure it to git-fetch and the
automatic rebase if they need it. I'd like to release 0.12 this
weekend but 'pull' doesn't currently work. Are you OK with my solution
(for backward compatibility with older repositories and GIT versions)?

Thanks.

-- 
Catalin

Re: git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".)

[Yann Dirson]

On Sat, Feb 03, 2007 at 12:16:47PM +0000, Catalin Marinas wrote:
> Yann,
> 
> On 02/02/07, Yann Dirson <ydirson@altern.org> wrote:
> >On Fri, Feb 02, 2007 at 07:07:06PM +0100, Yann Dirson wrote:
> >> On Fri, Feb 02, 2007 at 09:58:06AM +0000, Catalin Marinas wrote:
> >> > On 01/02/07, Yann Dirson <ydirson@altern.org> wrote:
> >> > >Previously we were just assuming that the remote from which we
> >> > >just failed defined a local branch whose name was the same as the
> >> > >remote def, and that this branch was the parent.  While this is true
> >> > >for the most common case (branch "origin" from remote "origin"), it is
> >> > >quite an unflexible assumption.
> >> >
> >> > The t1200-push-modified.sh test fails after applying this patch. It
> >> > looks like the 3rd test fails to pull the changes from 'foo' into
> >> > 'bar'.
> >
> >With current GIT HEAD, plain git-clone creates the following config
> >(when cloning a repo with HEAD pointing to branch "downstream":
> 
> As I haven't followed the GIT latest developments in this area, I
> can't comment.

As noted elsewhere, I have misinterpreted the branch.*.merge
parameter; I'm trying to get things right.

> Regarding StGIT, I'd like it to work with earlier
> stable versions of GIT and not just with the current HEAD. I (and
> probably many others) already have repositories cloned some (long)
> time ago and their gitconfig might not have the cloning information.

There are 2 issues there:

- support for running atop previous releases of Git. For this we
should select a policy like "we support the current stable branch (or
to-be-published, like 1.5.0), and the previous (ie. 1.4.4.x or
1.4.x)", and document that in the release notes so packagers can
update their dependencies.

- and continue to work with repos created with old releases.  For the
"pull" change, what's needed (or should be, modulo bugs such as this
one), is to tell people they need to "git config" the missing info
when it's not there.  I have tried to keep the old behaviour as much
as possible (ie. relying on the user to pass the info on command-line)
instead of insisting on the user providing the info in the config
file, but this work is probably not 100% finished.


> The (interim) solution I see is for StGIT pull command to default to
> using git-pull and people can configure it to git-fetch and the
> automatic rebase if they need it. I'd like to release 0.12 this
> weekend but

Right, it is reasonable to keep the old behaviour the default for now.


> 'pull' doesn't currently work.

I'll still try to make it work nevertheless before the release :)

Best regards,
-- 
Yann.

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

[Yann Dirson]

On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:
> 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.

1. I guess we can continue to store local refs for those branches when
they mirror a remote one, but if we store something there without
storing a branch.*.remote to '.', git-fetch could confuse this local
ref with a ref from remote 'origin', since that's still the default.

2. branch.*.merge is not where we should read a parent branch from.
Even if we store that info there, the user could have put a remote ref
name there.  So if we want to keep a get_parent_branch() method we'll
have to store that info somewhere else, eg. branch.*.stgit.parentbranch.

3. we need get_parent_branch() to implement parent branch as default
arg to "stg rebase"

So (please correct me if necessary):

- always store local parent branch to branch.*.stgit.parentbranch
- never set branch.*.merge without setting branch.*.remote
- set them, with remote as '.' when dealing with local branch

Best regards,
-- 
Yann.

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

[Junio C Hamano]

Yann Dirson <ydirson@altern.org> writes:

> On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:
>> 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.

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

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Yann Dirson <ydirson@altern.org> writes:
> ...
>> 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 <junkio@cox.net>
---
 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

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

[Yann Dirson]

On Sat, Feb 03, 2007 at 03:01:59PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
> 
> > On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:
> >> 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.

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

[Jeff King]

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

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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 actually was re-reading that exact post (and more importantly,
messages 35810 and 36374 in the thread) before I sent the
message you are replying to.

While I think branch.*.merge, which was invented for the use of
git-pull -> git-merge callchain, should consistently use the
remote branch name, after re-reading your messages, especially
36374, I see why you wanted a mechanism to talk about
relationships between two (or more) local branches.

I do not think it is wrong to have a separate mechanism (and it
might end up being called as "mergelocal" which you said might
be a terrible name) for that.  I just think it is probably a
wrong thing to do to use branch.*.merge for that. As you said,
operations you are interested in like format-patch (and perhaps
rebase) of a local branch relative to another locally available
ref (be it another branch or a tracking branch) do not involve
fetching (hence pulling) necessarily.

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

[Jeff King]

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

> I do not think it is wrong to have a separate mechanism (and it
> might end up being called as "mergelocal" which you said might
> be a terrible name) for that.  I just think it is probably a
> wrong thing to do to use branch.*.merge for that. As you said,
> operations you are interested in like format-patch (and perhaps
> rebase) of a local branch relative to another locally available
> ref (be it another branch or a tracking branch) do not involve
> fetching (hence pulling) necessarily.

Good, it looks like we are mostly agreeing on this then (the feature
might have some use, but it should _not_ be tacked onto branch.*.merge).
I will give it some thought until v1.5.0 has settled, and then hopefully
submit some patches.

-Peff