threads / discuss / 24487

Replacing a Remote Branch

Subject: Replacing a Remote Branch

## tl;dr

7 messages between Jul 23, 2010 and Jul 24, 2010.

replies: 6people: 3as markdown or json

Eric James Michael Ritz· Jul 23, 2010, 20:14 UTC · lore

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone. I have a question about pushing branches that I hope a more experienced user could help me with.

Commonly I run into this situation:

  1. I have pushed a topic branch out to a repo where other developers
  on my team push their work until its ready to be merged.

  2. I realized I need to perform some ‘destructive’ action like
  ‘rebase -i’ or amend the last commit to fix a typo in the message.

  3. Then I want to push the changed branch as a replacement.

Currently I deal with this by running

    $ git push origin :foo && git push origin foo

to replace `foo`. But is there a shorter way to do this? I thought that writing something like

    $ git push origin +foo:foo

may have the intended effect, but I still get a rejection due to a non-fast-forward, so I am likely misunderstanding the purpose of `+`.

If there is any short-cut for this, I would greatly appreciate it. And if not, writing a simple script is not a huge hassle :)

- --
Eric James Michael Ritz
Cyber Sprocket Labs
(843) 225-3830
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMSfg7AAoJEEHUZXw5hMWshwAIALOnsArQIWoxXNmOVNvi3ptd oXpUXbfX2ZgMnhOQAYmJXYjkqc/fKFh+MultDP1PRgQwPdPCEUfK/n5TEJXB66Jf nsgnGWIHk7nULuKJmCb9BrDd+xVI4tvbhI3gZYXrypoWdrfUat9rlUL52+eiAXp7 CG/FQrSoFRydREGUuAi1UNtTPt9UG2MT65dEx/S8wqRn8phpJHZI94mKOVZ58lI1 oQDfx+Ox6p2RJG/HRrX7/jWOiGzMk3Ix/cToAaltBWWp7MgvDq31pjrN0TZJfUu+ +vcgafAqseXDDuStlEGd8O5WT+uRYjn9/K3YHf55MKsMvKVzNxgS8IHQGzC+Yk4= =/0uY -----END PGP SIGNATURE-----

Thomas Rast· Jul 23, 2010, 20:48 UTC · re: Eric James Michael Ritz · lore

Re: Replacing a Remote Branch

Eric James Michael Ritz wrote:

>   2. I realized I need to perform some ‘destructive’ action like
>   ‘rebase -i’ or amend the last commit to fix a typo in the message.
> 
>   3. Then I want to push the changed branch as a replacement.

[...]

Show 9 quoted lines

>     $ git push origin :foo && git push origin foo
> 
> to replace `foo`.  But is there a shorter way to do this?  I thought
> that writing something like
> 
>     $ git push origin +foo:foo
> 
> may have the intended effect, but I still get a rejection due to a
> non-fast-forward, so I am likely misunderstanding the purpose of `+`.

Since + overrides the non-ff check, this means that the remote side has receive.denyNonFastForwards (see man git-config) enabled (or a hook to the same effect). Deleting and pushing the new branch merely defeats this refusal because it is no longer a branch *update*.

You should probably check why and by who receive.denyNonFastForwards was set. Git itself sets it if you use 'git init --shared', so that may be one reason.

Note that non-ff updates are generally a bad thing for everyone who has work based on the affected branch.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Eric James Michael Ritz· Jul 23, 2010, 20:52 UTC · re: Thomas Rast · lore

Re: Replacing a Remote Branch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/23/2010 04:48 PM, Thomas Rast wrote:

Show 24 quoted lines

> Eric James Michael Ritz wrote:
>>   2. I realized I need to perform some ‘destructive’ action like
>>   ‘rebase -i’ or amend the last commit to fix a typo in the message.
>>
>>   3. Then I want to push the changed branch as a replacement.
> [...]
>>     $ git push origin :foo && git push origin foo
>>
>> to replace `foo`.  But is there a shorter way to do this?  I thought
>> that writing something like
>>
>>     $ git push origin +foo:foo
>>
>> may have the intended effect, but I still get a rejection due to a
>> non-fast-forward, so I am likely misunderstanding the purpose of `+`.
>
> Since + overrides the non-ff check, this means that the remote side
> has receive.denyNonFastForwards (see man git-config) enabled (or a
> hook to the same effect).  Deleting and pushing the new branch merely
> defeats this refusal because it is no longer a branch *update*.
>
> You should probably check why and by who receive.denyNonFastForwards
> was set.  Git itself sets it if you use 'git init --shared', so that
> may be one reason.

That’s the reason then, `--shared` was used.

> Note that non-ff updates are generally a bad thing for everyone who
> has work based on the affected branch.

We make it a policy to never base work off individual developer’s branches precisely for this reason, because we’re often making cleanups via rebase and such.

Thank you for the answer.

- --
Eric James Michael Ritz
Cyber Sprocket Labs
(843) 225-3830
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMSgEVAAoJEEHUZXw5hMWsu1wIANwTnswKzd0pKub3zms1y2wv ouv2TRvxvpQhKvVO2r+CjDohdH2BQQIa2FWa8g/bG7fQVvGby1xQkWNJYxypebrh GHHX3Q4uF6mNIqD+yC4AQNQdEywCDXL4lBqh0Q7Bo+6ZGhUtQIEp1vyWHQeHTLuZ 8NhWd4PwE4z5ssGGKTzzvg2FgkWxtKrNaCVXfPTHpeh51J/Slt0Jfhw/i/zXNlGU BN0Jlnavhvr5IDbODCNB96KJQue1xLZv+mNNrINlY+TlHwNVyKlq2ui8zvG0vC0K OwwbOh6HlGV1sPReFfbObu6F9oxz6DMcmdHqNtedQPiAmm38EIuFFTa4H1CiYlM= =P2Zr -----END PGP SIGNATURE-----

bill lam· Jul 24, 2010, 01:17 UTC · re: Thomas Rast · lore

Re: Replacing a Remote Branch

Птн, 23 Июл 2010, Thomas Rast писал(а):

> Since + overrides the non-ff check, this means that the remote side
> has receive.denyNonFastForwards (see man git-config) enabled (or a
> hook to the same effect).  Deleting and pushing the new branch merely

I also scratched my head why push --force failed to push an amend/rebase branch to assembla. IMO it would be nice to mention this receive.denyNonFastForwards inside man git-push.

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Thomas Rast· Jul 24, 2010, 16:03 UTC · re: bill lam · lore

[PATCH 1/2] Document receive.denyDeleteCurrent

This option was introduced by 747ca24 (receive-pack: receive.denyDeleteCurrent, 2009-02-08) but never documented.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 Documentation/config.txt |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e75434b..fdb90c0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1558,6 +1558,10 @@ receive.denyDeletes::
 	If set to true, git-receive-pack will deny a ref update that deletes
 	the ref. Use this to prevent such a ref deletion via a push.
 
+receive.denyDeleteCurrent::
+	If set to true, git-receive,pack will deny a ref update that
+	deletes the currently checked out branch of a non-bare repository.
+
 receive.denyCurrentBranch::
 	If set to true or "refuse", git-receive-pack will deny a ref update
 	to the currently checked out branch of a non-bare repository.

-- 
1.7.2.278.g76edd.dirty

Thomas Rast· Jul 24, 2010, 16:03 UTC · re: Thomas Rast · lore

[PATCH 2/2] Documentation/git-push: Explain status output in more detail

Mention the effects of the receive.deny* family of options for the "remote rejected" case. While there, also split up the explanation into an easier-to-parse list format.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

I considered instead patching receive-pack to have more verbose messages, but decided not to, because it's already very verbose (by git standards anyway) and because a doc update has the advantage of immediately showing up in the kernel.org-hosted copies instead of appearing in two years when hosting providers update their gits.

 Documentation/git-push.txt |   33 +++++++++++++++++++++++----------
 1 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index b68abff..658ff2f 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -200,16 +200,29 @@ summary::
 	For a successfully pushed ref, the summary shows the old and new
 	values of the ref in a form suitable for using as an argument to
 	`git log` (this is `<old>..<new>` in most cases, and
-	`<old>...<new>` for forced non-fast-forward updates). For a
-	failed update, more details are given for the failure.
-	The string `rejected` indicates that git did not try to send the
-	ref at all (typically because it is not a fast-forward). The
-	string `remote rejected` indicates that the remote end refused
-	the update; this rejection is typically caused by a hook on the
-	remote side. The string `remote failure` indicates that the
-	remote end did not report the successful update of the ref
-	(perhaps because of a temporary error on the remote side, a
-	break in the network connection, or other transient error).
+	`<old>...<new>` for forced non-fast-forward updates).
++
+For a failed update, more details are given:
++
+--
+rejected::
+	Git did not try to send the ref at all, typically because it
+	is not a fast-forward and you did not force the update.
+
+remote rejected::
+	The remote end refused the update.  Usually caused by a hook
+	on the remote side, or because the remote repository has one
+	of the following safety options in effect:
+	`receive.denyCurrentBranch` (for pushes to the checked out
+	branch), `receive.denyNonFastForwards` (for forced
+	non-fast-forward updates), `receive.denyDeletes` or
+	`receive.denyDeleteCurrent`.  See linkgit:git-config[1].
+
+remote failure::
+	The remote end did not report the successful update of the ref,
+	perhaps because of a temporary error on the remote side, a
+	break in the network connection, or other transient error.
+--
 
 from::
 	The name of the local ref being pushed, minus its

-- 
1.7.2.278.g76edd.dirty

Thomas Rast· Jul 24, 2010, 16:07 UTC · re: Thomas Rast · lore

[PATCH v1.1 1/2] Document receive.denyDeleteCurrent

This option was introduced by 747ca24 (receive-pack: receive.denyDeleteCurrent, 2009-02-08) but never documented.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Argh, there was a typo ("receive,pack") in the first version. Why do I only notice them on the 4th reading. Sorry for the noise.

 Documentation/config.txt |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e75434b..fdb90c0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1558,6 +1558,10 @@ receive.denyDeletes::
 	If set to true, git-receive-pack will deny a ref update that deletes
 	the ref. Use this to prevent such a ref deletion via a push.
 
+receive.denyDeleteCurrent::
+	If set to true, git-receive-pack will deny a ref update that
+	deletes the currently checked out branch of a non-bare repository.
+
 receive.denyCurrentBranch::
 	If set to true or "refuse", git-receive-pack will deny a ref update
 	to the currently checked out branch of a non-bare repository.

-- 
1.7.2.278.g76edd.dirty