[PATCH] git push --track

Hi,

I'd like a feature to automatically "transform" a non-tracking local  
branch into a tracking branch on push. A patch to do that is attached.

Usage:

git branch mybranch
git checkout mybranch
...
git push --track origin mybranch:mybranch

will not just perform the push, but also write a block

[branch "mybranch"]
         remote = origin
         merge = refs/heads/mybranch

to the git configuration so the branch becomes tracking.

This should be a simpler alternative to the otherwise usual procedure

git push origin mybranch:mybranch
git config branch.mybranch.remote origin
git config branch.mybranch.merge refs/heads/mybranch

Are there any chances for this getting added to official git - or an  
alternate convenient way convert a local to a tracking branch?

Best regards,

Rudolf

On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:

Hi,

I'd like a feature to automatically "transform" a non-tracking local
branch into a tracking branch on push. A patch to do that is
attached.

The patches should be sent inline, together with commit messages
(unless you are asked to resend as attachment because of whitespace
mangling). Attached patches are very hard to comment on.

Are there any chances for this getting added to official git - or an
alternate convenient way convert a local to a tracking branch?

This is missing sign-off. It can't be included without it.

Also couple comments:

- Some lines look way too long (~160 chars, should be max 80 unles
it would linebreak error message).
- Should the tracking be set up even if only part of ref update suceeded
(for those that succeeded), not requiring all to succeed?
- Is --track the best name for this?

-Ilari

On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara  
[off-list ref] wrote:

On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:

quoted

Hi,

I'd like a feature to automatically "transform" a non-tracking local
branch into a tracking branch on push. A patch to do that is
attached.

The patches should be sent inline, together with commit messages
(unless you are asked to resend as attachment because of whitespace
mangling). Attached patches are very hard to comment on.

quoted

Are there any chances for this getting added to official git - or an
alternate convenient way convert a local to a tracking branch?

This is missing sign-off. It can't be included without it.

Of course, but I assume the sign-off would not be by me, but by some of  
the git developers, and would depend on whether they actually want this  
feature.

Also couple comments:

- Some lines look way too long (~160 chars, should be max 80 unles
it would linebreak error message).

Yes, also I got told that I used the wrong braces style... well, fixed  
that.

- Should the tracking be set up even if only part of ref update suceeded
(for those that succeeded), not requiring all to succeed?

Good point, but I simply see no clean way to set it up for the succeeded  
refs. Would be a nice idea for improvement of this.

- Is --track the best name for this?

I am assuming this, because this is what git-checkout and git-branch use  
for the same thing.

As I am absolutely not sure if with Opera I can include the file as is, I  
also provided it on http://nopaste.linux-dev.org/?6248 this time.

Best regards,

Rudolf


 From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001
From: Rudolf Polzer <redacted>
Date: Wed, 13 Jan 2010 16:42:04 +0100
Subject: [PATCH 1/2] Add a feature "git push --track" to automatically  
make the pushed branches tracking

---
  builtin-push.c |   33 +++++++++++++++++++++++++++++++++
  transport.h    |    1 +
  2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/builtin-push.c b/builtin-push.c
index 28a26e7..e5b66a3 100644
--- a/builtin-push.c
+++ b/builtin-push.c

@@ -7,6 +7,7 @@
  #include "builtin.h"
  #include "remote.h"
  #include "transport.h"
+#include "branch.h"
  #include "parse-options.h"

  static const char * const push_usage[] = {

@@ -115,6 +116,36 @@ static int push_with_options(struct transport  

*transport, int flags)
  		fprintf(stderr, "Pushing to %s\n", transport->url);
  	err = transport_push(transport, refspec_nr, refspec, flags,
  			     &nonfastforward);
+	if (err == 0 && flags & TRANSPORT_PUSH_TRACK) {
+		struct ref *remote_refs =
+			transport->get_refs_list(transport, 1);
+		struct ref *local_refs = get_local_heads();
+		int match_flags = 0;
+		if (flags & TRANSPORT_PUSH_ALL)
+			match_flags |= MATCH_REFS_ALL;
+		if (flags & TRANSPORT_PUSH_MIRROR)
+			match_flags |= MATCH_REFS_MIRROR;
+		if(!(flags & TRANSPORT_PUSH_DRY_RUN))
+		if(!match_refs(local_refs, &remote_refs, refspec_nr, refspec,
+					match_flags)) {
+			struct ref *next = remote_refs;
+			while(next) {
+				if(next->peer_ref && *next->peer_ref->name &&
+						*next->name &&
+						next->peer_ref->new_sha1 &&
+						!is_null_sha1(next->peer_ref->new_sha1))
+				{
+					if (!prefixcmp(next->peer_ref->name,
+								"refs/heads/"))
+						install_branch_config(BRANCH_CONFIG_VERBOSE,
+								next->peer_ref->name + 11,
+								transport->remote->name,
+								next->name);
+				}
+				next = next->next;
+			}
+		}
+	}
  	if (err != 0)
  		error("failed to push some refs to '%s'", transport->url);

@@ -218,6 +249,8 @@ int cmd_push(int argc, const char **argv, const char  

*prefix)
  		OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
  		OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive  
pack program"),
  		OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack  
program"),
+		OPT_BIT('t', "track",  &flags, "set up tracking mode (see git-pull(1))",
+			TRANSPORT_PUSH_TRACK),
  		OPT_END()
  	};

diff --git a/transport.h b/transport.h
index 9e74406..8a9c776 100644
--- a/transport.h
+++ b/transport.h

@@ -74,6 +74,7 @@ struct transport {
  #define TRANSPORT_PUSH_VERBOSE 16
  #define TRANSPORT_PUSH_PORCELAIN 32
  #define TRANSPORT_PUSH_QUIET 64
+#define TRANSPORT_PUSH_TRACK 128

  /* Returns a transport suitable for the url */
  struct transport *transport_get(struct remote *, const char *);

-- 
1.6.3.3


 From bbdd185ac43fb789f35d0177697486457af87fd0 Mon Sep 17 00:00:00 2001
From: Rudolf Polzer <divVerent@alientrap.org>
Date: Wed, 13 Jan 2010 16:47:24 +0100
Subject: [PATCH 2/2] tracking into Docs

---
  Documentation/git-push.txt |    8 ++++++++
  1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index e3eb1e8..ebaa67b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -82,6 +82,14 @@ nor in any Push line of the corresponding remotes  
file---see below).
  	if the configuration option `remote.<remote>.mirror` is
  	set.

+-t::
+--track::
+	When pushing, set up "upstream" configuration. See
+	"--track" in linkgit:git-branch[1] for details. All
+	refspecs that have a branch as source ref will be turned
+	into tracking branches if they are not already, and in any case
+	adjusted to track the given remote and ref on the remote side.
+
  -n::
  --dry-run::
  	Do everything except actually send the updates.
-- 
1.6.3.3

On Wed, Jan 13, 2010 at 04:55:20PM +0100, Rudolf Polzer wrote:

On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara
[off-list ref] wrote:

quoted

On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:

quoted

Hi,

Of course, but I assume the sign-off would not be by me, but by some
of the git developers, and would depend on whether they actually
want this feature.

It would need sign-off by you. Even if you took the code from somewhere
(and then it would need theirs as well) and passed it along.
 

quoted

- Should the tracking be set up even if only part of ref update suceeded
(for those that succeeded), not requiring all to succeed?

Good point, but I simply see no clean way to set it up for the
succeeded refs. Would be a nice idea for improvement of this.

Ah, that is only known in transport_push and what it calls (and transport_push
is last point to insert common functionality)...
 

Linewrap damage.

-Ilari

Hi,

On Wed, Jan 13, 2010 at 11:12 PM, Rudolf Polzer [off-list ref] wrote:

Hi,

I'd like a feature to automatically "transform" a non-tracking local branch
into a tracking branch on push. A patch to do that is attached.

Usage:

git branch mybranch
git checkout mybranch
...
git push --track origin mybranch:mybranch

will not just perform the push, but also write a block

[branch "mybranch"]
       remote = origin
       merge = refs/heads/mybranch

to the git configuration so the branch becomes tracking.

This should be a simpler alternative to the otherwise usual procedure

git push origin mybranch:mybranch
git config branch.mybranch.remote origin
git config branch.mybranch.merge refs/heads/mybranch

Are there any chances for this getting added to official git - or an
alternate convenient way convert a local to a tracking branch?

before I put up my comments on the patch, I wonder if git-push is the
best place to add this feature, as git-push usually deals with
"pushing" data to another repo.

I think git-branch would be a better place to do this.

-- 
Cheers,
Ray Chuan

Hi,

generally, it would be better if you could add some tests for this.

If I'm not wrong, the place to put it would be t5516-fetch-push.sh.

On Wed, Jan 13, 2010 at 11:55 PM, Rudolf Polzer [off-list ref] wrote:

On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara
[off-list ref] wrote:

please don't drop people from the Cc list - especially when you're
replying to somebody!

From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001
From: Rudolf Polzer <redacted>
Date: Wed, 13 Jan 2010 16:42:04 +0100
Subject: [PATCH 1/2] Add a feature "git push --track" to automatically make
the pushed branches tracking

Each patch should be sent out in its own mail. (As Matthieu has
recommended, you should check out Documentation/SubmittingPatches.)

It would be better if you can move this to
transport.c::transport_push(). It repeats what's already there, so you
don't have to configure match_flags, nor call match_refs, etc.

+                       struct ref *next = remote_refs;
+                       while(next) {
[snip]
+                               next = next->next;

In most places, this is done like this:

  struct ref* ref;
  for (ref = remote_refs; ref; ref = ref->next) {
    ...
  }

-- 
Cheers,
Ray Chuan

Quoting Rudolf Polzer [off-list ref]

I'd like a feature to automatically "transform" a non-tracking local
branch into a tracking branch on push. A patch to do that is attached.

How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
  http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

On Thu, Jan 14, 2010 at 03:41:54PM +0900, Nanako Shiraishi wrote:

Quoting Rudolf Polzer [off-list ref]

quoted

I'd like a feature to automatically "transform" a non-tracking local
branch into a tracking branch on push. A patch to do that is attached.

How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
  http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390

I don't really think this has much to do with the other. git branch
--will-track still means one needs to know it at branch setup time, and git
pull --remember still means one needs to type way more stuff than with a simple
push --track.

But well, given the discussion here I see the feature is essentially rejected,
and already was rejected a previous time. Will probably forget about this and
make a shell script that does for ME what I want.

Best regards,

Rudolf

On Wed, Jan 13, 2010 at 04:55:20PM +0100, Rudolf Polzer wrote:

quoted

- Should the tracking be set up even if only part of ref update suceeded
(for those that succeeded), not requiring all to succeed?

Good point, but I simply see no clean way to set it up for the
succeeded refs. Would be a nice idea for improvement of this.

I don't think it's that hard. In fact, I did a preliminary patch for it
about a year ago:

  http://article.gmane.org/gmane.comp.version-control.git/107750

That patch was held up because there were a lot of cleanups needed in
transport.c before it would make sense (read the whole thread for
details). I think most of those cleanups have happened in the meantime,
so it would be pretty straightforward to use the same setup_tracking()
function and just call it from the right spot in transport.c. But I
haven't actually looked at this topic since the above-referenced thread.

-Peff

On Thu, Jan 14, 2010 at 09:27:26AM +0800, Tay Ray Chuan wrote:

before I put up my comments on the patch, I wonder if git-push is the
best place to add this feature, as git-push usually deals with
"pushing" data to another repo.

I think git-branch would be a better place to do this.

I think git-branch can already do this: after pushing, you can do git branch -f
--track origin/mybranch.

But the goal of this is to postponing the decision to track to the push time,
and adding as little as possible extra commands/options to do this.

On Thu, Jan 14, 2010 at 01:21:17PM +0800, Tay Ray Chuan wrote:

Hi,

generally, it would be better if you could add some tests for this.

If I'm not wrong, the place to put it would be t5516-fetch-push.sh.

Can add that, but it seems like it won't go in anyway from the discussion here,
so it's probably not worth working on it. Sad.

On Wed, Jan 13, 2010 at 11:55 PM, Rudolf Polzer [off-list ref] wrote:

quoted

On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara
[off-list ref] wrote:

please don't drop people from the Cc list - especially when you're
replying to somebody!

I did not drop anyone, but simply replied from my newsreader. I really don't
want to subscribe to a mailing list and then get hundreds of emails a day.

quoted

From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001
From: Rudolf Polzer <redacted>
Date: Wed, 13 Jan 2010 16:42:04 +0100
Subject: [PATCH 1/2] Add a feature "git push --track" to automatically make
the pushed branches tracking

Each patch should be sent out in its own mail. (As Matthieu has
recommended, you should check out Documentation/SubmittingPatches.)

So, using a newsreader is not accepted practice? Why is the mailing list on a
newsgroup then?

quoted

 static const char * const push_usage[] = {

@@ -115,6 +116,36 @@ static int push_with_options(struct transport

*transport, int flags)
               fprintf(stderr, "Pushing to %s\n", transport->url);
       err = transport_push(transport, refspec_nr, refspec, flags,
                            &nonfastforward);
+       if (err == 0 && flags & TRANSPORT_PUSH_TRACK) {
+               struct ref *remote_refs =
+                       transport->get_refs_list(transport, 1);
+               struct ref *local_refs = get_local_heads();
+               int match_flags = 0;
+               if (flags & TRANSPORT_PUSH_ALL)
+                       match_flags |= MATCH_REFS_ALL;
+               if (flags & TRANSPORT_PUSH_MIRROR)
+                       match_flags |= MATCH_REFS_MIRROR;
+               if(!(flags & TRANSPORT_PUSH_DRY_RUN))
+               if(!match_refs(local_refs, &remote_refs, refspec_nr,
refspec,
+                                       match_flags)) {

It would be better if you can move this to
transport.c::transport_push(). It repeats what's already there, so you
don't have to configure match_flags, nor call match_refs, etc.

Then I have to duplicate it in the rsync specific push code too. Otherwise,
agreed.

quoted

+                       struct ref *next = remote_refs;
+                       while(next) {
[snip]
+                               next = next->next;

In most places, this is done like this:

  struct ref* ref;
  for (ref = remote_refs; ref; ref = ref->next) {
    ...
  }

Sure, could do that too, I got this loop from the loop that frees a ref list.

Best regards,

Rudolf

Hi,

On Thu, 14 Jan 2010, Nanako Shiraishi wrote:

Quoting Rudolf Polzer [off-list ref]

quoted

I'd like a feature to automatically "transform" a non-tracking local
branch into a tracking branch on push. A patch to do that is attached.

How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
  http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390

Thank you for looking up that reference.

Do you remember what the outcome was?  (Peff mentioned that there was some 
talk about putting this code into transport.c and some needed 
restructurings, but I do not remember the details, and I did not have time 
to follow the development of that file in the recent months.)

Ciao,
Dscho

Quoting Johannes Schindelin [off-list ref]

On Thu, 14 Jan 2010, Nanako Shiraishi wrote:

quoted

Quoting Rudolf Polzer [off-list ref]

quoted

I'd like a feature to automatically "transform" a non-tracking local
branch into a tracking branch on push. A patch to do that is attached.

How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
  http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390

Thank you for looking up that reference.

Do you remember what the outcome was?

I summarized it when I reminded Junio on this topic last time and it is in the same discussion thread: http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=136216

Here is an extended version.

'git branch --will-track origin/topic topic origin/master' was proposed as a way to fork a topic branch at origin's master. Later 'git pull' will merge topic from origin to topic.

This is bad in two ways. It will force users to decide when the branch is created. It will not allow users to configure branch.topic.rebase variable.

'git push --track' was suggested as a way to let users delay that decision.

'git branch --configure' to update the same information for an existing branch was suggested as an alternative UI. An added benefit is that this approach will allow the same option to be used when creating a branch.

'git pull --remember' that remembers the options used from the command line was suggested as a solution in addition to 'git branch --reconfigure'. Users can postpone the decision even more than 'git push --track', and it naturally supports setting branch.topic.rebase with 'git pull --rebase --remember'.  It also has two additional benefits. 'push --track' configures what happens when you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change the setting used by 'pull' (much more natural). Also it does not add the confusing word 'track' to the interface (for a more detailed discussion on 'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Rudolf Polzer [off-list ref] writes:

quoted

Each patch should be sent out in its own mail. (As Matthieu has
recommended, you should check out Documentation/SubmittingPatches.)

So, using a newsreader is not accepted practice? Why is the mailing list on a
newsgroup then?

I do read this list in a newsreader.  When I say "reply" or "follow-up",
the response is sent out to the list via e-mail.  Your newsreader should
be configurable in a similar way, I think.

On Fri, Jan 15, 2010 at 07:27:41AM +0900, Nanako Shiraishi wrote:

'git push --track' was suggested as a way to let users delay that decision.

'git branch --configure' to update the same information for an existing
branch was suggested as an alternative UI. An added benefit is that this
approach will allow the same option to be used when creating a branch.

'git pull --remember' that remembers the options used from the command line
was suggested as a solution in addition to 'git branch --reconfigure'. Users
can postpone the decision even more than 'git push --track', and it naturally
supports setting branch.topic.rebase with 'git pull --rebase --remember'.  It
also has two additional benefits. 'push --track' configures what happens when
you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change
the setting used by 'pull' (much more natural). Also it does not add the
confusing word 'track' to the interface (for a more detailed discussion on
'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).

Still requires you to specify the remote and the branch name twice.

So the workflow would be:

git push origin localbranch:remotebranch
...
git pull --remember origin remotebranch:localbranch

instead of

git push --track origin localbranch:remotebranch
...
git pull

The one thing I want to avoid, is specifying the "origin
localbranch:remotebranch" stuff twice.

Doesn't make git pull --remember a bad idea, it's good in many other cases. But
in my specific use case, git push --track is the most useful one.

Rudolf

Hi,

On Fri, 15 Jan 2010, Rudolf Polzer wrote:

On Fri, Jan 15, 2010 at 07:27:41AM +0900, Nanako Shiraishi wrote:

quoted

'git push --track' was suggested as a way to let users delay that decision.

'git branch --configure' to update the same information for an existing
branch was suggested as an alternative UI. An added benefit is that this
approach will allow the same option to be used when creating a branch.

'git pull --remember' that remembers the options used from the command line
was suggested as a solution in addition to 'git branch --reconfigure'. Users
can postpone the decision even more than 'git push --track', and it naturally
supports setting branch.topic.rebase with 'git pull --rebase --remember'.  It
also has two additional benefits. 'push --track' configures what happens when
you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change
the setting used by 'pull' (much more natural). Also it does not add the
confusing word 'track' to the interface (for a more detailed discussion on
'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).

Thanks for the very nice summary!

Still requires you to specify the remote and the branch name twice.

So the workflow would be:

git push origin localbranch:remotebranch
...
git pull --remember origin remotebranch:localbranch

instead of

git push --track origin localbranch:remotebranch
...
git pull

The one thing I want to avoid, is specifying the "origin
localbranch:remotebranch" stuff twice.

Doesn't make git pull --remember a bad idea, it's good in many other 
cases. But in my specific use case, git push --track is the most useful 
one.

The thing is: done right, the three can share the major part of the code.

Ciao,
Dscho