Replacing a Remote Branch

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

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.

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

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


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

Eric James Michael Ritz wrote:

quoted

  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.

[...]

quoted

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

Птн, 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

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

Signed-off-by: Thomas Rast <redacted>
---
 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

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

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

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

Signed-off-by: Thomas Rast <redacted>
---

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