Re: RFC PATCH: support for default remote in StGIT

Re: RFC PATCH: support for default remote in StGIT

[Catalin Marinas]

On 09/12/06, Pavel Roskin <proski@gnu.org> wrote:
> Sorry, I was unlucky to pick your address from setup.py, where it's
> incorrect (gmail.org, not gmail.com), so I'm sending you another copy.

Thanks for spotting this.

> One approach is to leave the default remote selection completely to git.
> The downside is that StGIT prints the remote it's pulling from.  Now
> StGIT will have to print common words that it's pulling something.  Or
> maybe it shouldn't print anything?

Yann started a thread on this but I didn't find the time to look at
this properly. He's idea was to store the remote branch information in
the StGIT metadata but I'd like to leave this for GIT to deal with.

The StGIT UI can probably be modified to display something useful but
I don't see a problem if it doesn't.

> The other approach is to calculate the default remote in StGIT.  This
> would allow StGIT to tell the user where it's pulling from.
>
> However, I had to introduce a function that ignores errors except there
> is any output on stderr.  This is because git-repo-config returns error
> code 1 if it cannot find the key.  Maybe git-repo-config should have an
> option not to fail in this case?  Perhaps a default value to return?

With the recent changes, StGIT shares the config files with GIT and it
has direct access to git settings without the need to use
git-repo-config. Just use "config.has_key" and "config.get_option".

Maybe a combination of your two options - StGIT could try to get the
default branch and, if there isn't any in the config files, just
invoke git-pull without any argument (and display something like
"pulling from default").

-- 

[PATCH] Check git pull remote before defaulting to 'origin'

[Pavel Roskin]

Check git pull remote before defaulting to 'origin'

Signed-off-by: Pavel Roskin <proski@gnu.org>
---

 stgit/commands/pull.py |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 227249e..7c5db22 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -50,10 +50,16 @@ def func(parser, options, args):
     if len(args) > 2:
         parser.error('incorrect number of arguments')
 
-    repository = 'origin'
-    refspec = None
     if len(args) >= 1:
         repository = args[0]
+    else:
+        section = 'branch "%s"' % git.get_head_file()
+        if config.has_option(section, 'remote'):
+            repository = config.get(section, 'remote')
+        else:
+            repository = 'origin'
+
+    refspec = None
     if len(args) == 2:
         refspec = args[1]
 

-- 
Regards,
Pavel Roskin

Re: [PATCH] Check git pull remote before defaulting to 'origin'

[Catalin Marinas]

On 09/01/07, Pavel Roskin <proski@gnu.org> wrote:
> Check git pull remote before defaulting to 'origin'

Thanks. Applied.

-- 
Catalin

RFC PATCH: support for default remote in StGIT

[Pavel Roskin]

Hello, Catalin!

It's very important for me to have default remote support in StGIT.  I'm
trying to track different Linux branches, and I don't want to remember
what branch I'm on when I run "stg pull".

I have tried two approaches, and both work, but I'm not particular fond
of either of them, so I think I'll just send both, and maybe we'll come
to a satisfactory solution.

One approach is to leave the default remote selection completely to git.
The downside is that StGIT prints the remote it's pulling from.  Now
StGIT will have to print common words that it's pulling something.  Or
maybe it shouldn't print anything?

Also, git-pull doesn't allow to specify the refspec without the remote.
This limitation seems artificial to me, but we have to pass this
limitation to the StGIT users.

The positive side if that StGIT is completely unaware of the word
"origin", and any changes in git handling of the default remote will
propagate to StGIT immediately.


diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 227249e..3ef582e 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -50,7 +50,7 @@ def func(parser, options, args):
     if len(args) > 2:
         parser.error('incorrect number of arguments')
 
-    repository = 'origin'
+    repository = None
     refspec = None
     if len(args) >= 1:
         repository = args[0]
@@ -73,7 +73,11 @@ def func(parser, options, args):
         print 'done'
 
     # pull the remote changes
-    print 'Pulling from "%s"...' % repository
+    if repository:
+        print 'Pulling from "%s"...' % repository
+    else:
+        print 'Pulling from the default repository'
+
     git.pull(repository, refspec)
     print 'done'
 
diff --git a/stgit/git.py b/stgit/git.py
index eb8da4e..7aed357 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -790,14 +790,20 @@ def reset(files = None, tree_id = None, check_out = True):
     if not files:
         __set_head(tree_id)
 
-def pull(repository = 'origin', refspec = None):
+def pull(repository = None, refspec = None):
     """Pull changes from the remote repository. At the moment, just
     use the 'git-pull' command
     """
     # 'git-pull' updates the HEAD
     __clear_head_cache()
 
-    args = [repository]
+    if repository:
+        args = [repository]
+    else:
+	if refspec:
+            raise GitException, 'git-pull requires repository with refspec'
+        args = []
+
     if refspec:
         args.append(refspec)
 

The other approach is to calculate the default remote in StGIT.  This
would allow StGIT to tell the user where it's pulling from.

However, I had to introduce a function that ignores errors except there
is any output on stderr.  This is because git-repo-config returns error
code 1 if it cannot find the key.  Maybe git-repo-config should have an
option not to fail in this case?  Perhaps a default value to return?


diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 227249e..7824dc3 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -54,6 +54,9 @@ def func(parser, options, args):
     refspec = None
     if len(args) >= 1:
         repository = args[0]
+    else:
+        repository = git.get_default_remote()
+
     if len(args) == 2:
         refspec = args[1]
 
diff --git a/stgit/git.py b/stgit/git.py
index eb8da4e..ed08d7d 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -186,6 +186,20 @@ def _output_one_line(cmd, file_desc = None):
                                                 p.childerr.read().strip())
     return output
 
+def _output_one_line_try(cmd, file_desc = None):
+    """ Read one line of cmd output, fail only on stderr messages
+    """
+    p=popen2.Popen3(cmd, True)
+    if file_desc != None:
+        for line in file_desc:
+            p.tochild.write(line)
+        p.tochild.close()
+    output = p.fromchild.readline().strip()
+    errors = p.childerr.read().strip()
+    if errors:
+        raise GitException, '%s failed (%s)' % (str(cmd), errors)
+    return output
+
 def _output_lines(cmd):
     p=popen2.Popen3(cmd, True)
     lines = p.fromchild.readlines()
@@ -285,6 +299,20 @@ def get_head_file():
     return strip_prefix('refs/heads/',
                         _output_one_line('git-symbolic-ref HEAD'))
 
+def get_default_remote():
+    """Returns default remote to pull
+    """
+    branch = get_head_file()
+
+    repository = _output_one_line_try(['git-repo-config', '--get',
+                                       'branch.%s.remote' % branch])
+
+    if not repository:
+        repository = 'origin'
+
+    return repository
+
+
 def set_head_file(ref):
     """Resets HEAD to point to a new ref
     """


-- 
Regards,

Re: RFC PATCH: support for default remote in StGIT

[Yann Dirson]

Hi Pavel,

This is quite related to the subject of the "Handling of branches in
stgit" thread I launched recently (Nov 30th).

On Sat, Dec 09, 2006 at 04:23:25AM -0500, Pavel Roskin wrote:
> It's very important for me to have default remote support in StGIT.  I'm
> trying to track different Linux branches, and I don't want to remember
> what branch I'm on when I run "stg pull".

Right, that's the main problem with the current implementation.

> One approach is to leave the default remote selection completely to git.
> The downside is that StGIT prints the remote it's pulling from.  Now
> StGIT will have to print common words that it's pulling something.  Or
> maybe it shouldn't print anything?

It could just print a generic message and let GIT print out
the details.

> Also, git-pull doesn't allow to specify the refspec without the remote.
> This limitation seems artificial to me, but we have to pass this
> limitation to the StGIT users.

In which situtation do you need to pass a refspec ?  I thought all
necessary refspecs should already be part of a remote's definition.

> The positive side if that StGIT is completely unaware of the word
> "origin", and any changes in git handling of the default remote will
> propagate to StGIT immediately.

Indeed.


> The other approach is to calculate the default remote in StGIT.  This
> would allow StGIT to tell the user where it's pulling from.

Doing so would probably require to teach StGIT about every new way of
fetching a branch (we already have 3 ways, as outlined in my initial
mail).  OTOH, it may be the only way to present the user with a
uniform way of working, independently of the way we update the parent
branch.


Indeed, we may just want to distinguish whether the parent branch is a
remote one or not.  Then if it's a remote one, git-fetch already has
enough info to do its work updating the parent branch (whether using
.git/remotes or .git/branches).  If it's not a remote branch, there's
just nothing to do at this step.

Then, we just have to "pop -a" and move the stack base, without
relying on "pull".  That would also transparently give support for
branching off a non-forwarding branch (like git's "next" and "pu", or
like any stgit managed branch).  Would anyone miss the "git-pull" call ?

Best regards,
--