receive.denyCurrentBranch

(Prompted by the 1.6.2-rc0 announcement.)

Myself, I always thought the obvious way to handle this problem was to detach the HEAD. Is there a reson there's no "detach" option for this?

"George Spelvin" <linux@horizon.com> writes:

Let's first think about why pushing into the current branch with the traditional behaviour is bad.

If you are in control of the remote whose current branch was checked out when push was made, there are two cases:

 (1) You do not know what you are doing.  The first time you do "git diff
     HEAD", or perhaps "git status", you suddenly see a lot of reverts,
     sctach your head and cry for help;

     If you set 'detach' option, this clueless user is not helped; he will
     happily keep working and would make tons of commits on detached HEAD,
     and next time he switches to another branch, will lose all of them.

     In a sense, this is a lot worse than the current behaviour, because
     you will do a lot more damage than just a single commit that has many
     uninteniontal reverts as what currently happens---which can be sorted
     out.

 (2) You know what you are doing.  You'd say:

	: detach HEAD at the commit before the push updated the branch
	$ git checkout @{1}  
	$ work work work
        $ git commit

     to detach the HEAD, finish the work you were doing in the pushed-into
     repository and then:

	: check out the previous branch (i.e. go back)
	$ git checkout @{-1}
	: merge the last commit, i.e. the work you done on detached HEAD
        $ git merge @{1}

    If you allow 'detach' option, then you saved him from typing "git
    checkout @{1}".  Not a big gain, especially if you compare this with
    increased pain you are causing to people in category (1).

The case where the pushed-into repository is not yours was discussed previously by Jeff King in the second thread below.

Previous discussions.

    http://thread.gmane.org/gmane.comp.version-control.git/35770/focus=36291
    http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100731

Hi,

On Sat, 7 Feb 2009, George Spelvin wrote:

It's insane, that's what it is.

You have _no_ business meddling with a remote working directory, _except_ by logging into that machine and working on that working directory _directly_.

If you do not agree, you have not thought about the implications, i.e. what problems you buy.

Ciao, Dscho

On Sun, Feb 8, 2009 at 5:30 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Just by way of providing an additional perspective, I thought I'd illustrate how Mercurial handles this situation:

$ mkdir repoA $ cd repoA repoA$ hg init repoA$ echo foo > foo repoA$ hg add foo repoA$ hg commit -m "added foo" repoA$ cd .. $ hg clone repoA repoB updating working directory 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd repoA repoA$ cat >> .hg/hgrc <<EOF

repoA$ echo bar > bar
repoA$ hg add bar
repoA$ hg commit -m "added bar"
repoA$ hg push
pushing to /Users/jay/repoB
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
repoA$ cd ../repoB
repoB$ hg parents
0   d32c3edefcba   2009-02-08 11:18 -0500   jaysoffian
  added foo

repoB$ hg glog
o  1[tip]   8e0a16e691f4   2009-02-08 11:19 -0500   jaysoffian
|    added bar
|
@  0   d32c3edefcba   2009-02-08 11:18 -0500   jaysoffian
     added foo

repoB$ echo baz > baz
repoB$ hg add baz
repoB$ hg commit -m "added baz"
created new head
repoB$ hg parents
2[tip]:0   8d7db8257fd0   2009-02-08 11:19 -0500   jaysoffian
  added baz

repoB$ hg glog
@  2[tip]:0   8d7db8257fd0   2009-02-08 11:19 -0500   jaysoffian
|    added baz
|
| o  1   8e0a16e691f4   2009-02-08 11:19 -0500   jaysoffian
|/     added bar
|
o  0   d32c3edefcba   2009-02-08 11:18 -0500   jaysoffian
     added foo

Now let's look at what happens if I pull from B, instead of pushing from A:

$ rm -rf repoA repoB
$ mkdir repoA
$ cd repoA
repoA$ hg init
repoA$ echo foo > foo
repoA$ hg add foo
repoA$ hg commit -m "added foo"
repoA$ cd ..
$ hg clone repoA repoB
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd repoA
repoA$ echo bar > bar
repoA$ hg add bar
repoA$ hg commit -m "added bar"
repoA$ cd ../repoB
repoB$ hg pull
pulling from /Users/jay/repoA
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
callisto:~/repoB$ hg parents
0   1adbe0643fb7   2009-02-08 11:22 -0500   jaysoffian
  added foo

repoB$ hg glog
o  1[tip]   66a5c6395cfc   2009-02-08 11:22 -0500   jaysoffian
|    added bar
|
@  0   1adbe0643fb7   2009-02-08 11:22 -0500   jaysoffian
     added foo

repoB$ echo baz > baz
repoB$ hg add baz
repoB$ hg commit -m "added baz"
created new head
repoB$ hg parents
2[tip]:0   cb8f0c639bd4   2009-02-08 11:23 -0500   jaysoffian
  added baz

repoB$ hg glog
@  2[tip]:0   cb8f0c639bd4   2009-02-08 11:23 -0500   jaysoffian
|    added baz
|
| o  1   66a5c6395cfc   2009-02-08 11:22 -0500   jaysoffian
|/     added bar
|
o  0   1adbe0643fb7   2009-02-08 11:22 -0500   jaysoffian
     added foo

What I especially like about Mercurial here is that pushing from A is perfectly symetrical to pulling from B.

With git, cloning sets things up to fetch into a tracking branch, but then the push is not symetric to the fetch. That makes sense if you're cloning from a bare repo, but I think leads to confusion for new users when they clone a non-bare repo they wish to later push into. I dunno, I guess we'll see if the new message helps any.

j.

Hi,

On Sun, 8 Feb 2009, Jay Soffian wrote:

Just to make it clear: if you have merge conflicts on the remote end, you will get into trouble.

I do not know how Mercurial handles this (I am sure you will send a page-long mail illustrating it), but in my humble opinion, there is _no_ way to handle this except if you have shell access to the remote repository/working directory.

No matter if you suggest leaving merge conflict, a detached HEAD, or "read-tree -u -m HEAD" (i.e. trying a simple merge with the working directory): _all_ of them are unsafe.

Ciao, Dscho

On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

No, I will not. Sorry for trying to help. Over and out.

j.

On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I apologize for my prior reply. I understand you find any mention of Mercurial offensive. But if you had paid attention, you would have noticed that Mercurial did not attempt to merge. Rather, it created a new branch head in the remote repository.

The equivalent in git would be for the user to do something like this:

satellite:~/repo (master)$ git push origin
! [remote rejected] master -> master (branch is currently checked out)
satellite:~/repo (master)$ git push origin master:satellite-master
 * [new branch]      master -> satellite-master
satellite:~/repo (master)$ ssh origin
origin$ cd repo
origin:~/repo (master)$ git merge satellite-master

I'm not suggesting any of those things. I was just illustrating what another DVCS does to see if there was anything that might be learned from it.

Clearly users are confused about pushing into a checked-out branch. Maybe making that impossible by default will be enough.

j.

Hi,

On Sun, 8 Feb 2009, Jay Soffian wrote:

So this is the "detached HEAD" idea. Which contradicts the law of the least surprise.

It should be clear that the equivalent of a central repository is a bare repository. And hopefully Junio's strategy will make that clearer, so I think this is the superior approach.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I do not think so. It is "adopting the symmetric mothership-satellite layout, when it suits the user's workflow".

On Sun, Feb 8, 2009 at 6:41 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I agree that a detached HEAD is a bad idea. The closest parallel that I can come up with for git would be for receive-pack to store incoming changes into separate branch hierarchy, NOT for it to detach HEAD. A toy-patch I played around with earlier allowed this on the non-bare upstream repo:

[receive]
     prefix = refs/remotes/incoming

Then a push to refs/heads/master was automatically stored as refs/remotes/incoming/master instead.

And yes, I'm aware the user can use a push refspec on the sending side.

I foresee new user doing this:

laptop:~$ git clone ssh://workstation/~/repo
laptop:~$ cd repo
laptop:~/repo (master)$ echo change >> file && git commit -am change
laptop:~/repo (master)$ git push
...
error: refusing to update checked out branch: refs/heads/master
To ssh://workstation/~/repo
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://workstation/~/repo'

And now new user is stumped.

Perhaps adding something like this to the git-push man page:

---8<---

Non-bare Repositories --------------------- When pushing to a non-bare upstream repository (i.e. an upstream repository with a working copy), changes to the checked out branch are NOT reflected in the upstream index, nor in the working copy. This creates a situation where it is easy to accidentally revert the changes on the next commit in the upstream repository.

e.g. Assume the following history exists in the upstream repository:

A---B master

master is the currently checked out branch, nothing is staged in the index and the working copy is clean.

A single change is made to master downstream and pushed. The upstream repository is now in this state:

A---B---C master

However, the index and working copy reflect the state at commit B. Performing a new commit in the upstream repository would do this:

A---B---C---B' master

B' is a new commit, but reflects the same state as B.

In order to prevent this situation, it is recommended that if you need to push into a non-bare upstream repository, set receive.denyCurrentBranch = true in the upstream repository (this will become the default in git-X.Y). This will prevent the push from occurring. Instead, you can push into an alternate branch, and then merge that branch in the upstream repository. e.g.:

server$ cd ~/repo && git config receive.denyCurrentBranch true

laptop$ git push
...
error: refusing to update checked out branch: refs/heads/master
To ssh://server/~/repo
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://server/~/repo'
laptop$ git push origin master:refs/remotes/laptop/master
laptop$ ssh server
server$ cd ~/repo
server$ git merge laptop/master

Alternatively, you can set receive.denyCurrentBranch = warn in the upstream repo, but then you must remember to perform "git reset --hard" in the upstream repo after pushing to its currently checked out branch. (But be careful, as "git reset --hard" throws away uncommitted changes.)

---8<---

j.

On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote:

What happens when the next person pushes to the same remote repo, and their refs/heads/master push is not a fast-forward merge of the current refs/remotes/incoming/master?

Do you lose the first user's push at that point? Or do you refuse the push?

						- Ted

Hi,

On Mon, 9 Feb 2009, Theodore Tso wrote:

This is meant for non-bare repositories, right? Repositories that do have reflogs...

Ciao, Dscho

P.S.: There _have_ been times when I would have liked an automatic PUSH_HEAD that is always temporary, such as FETCH_HEAD. I _could_ imagine that this is something we could do (opt-in, of course): storing what was already pushed in a PUSH_HEAD, even if the refs could not be updated.

On Mon, Feb 9, 2009 at 6:06 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Absolutely. It would be insane on a bare repository.

Oooh. Interesting idea.

j.

On Mon, Feb 9, 2009 at 12:06 AM, Theodore Tso <tytso@mit.edu> wrote:

The idea initially was to give a place to store the push head for the checked-out branch, but that isn't what HEAD points to. But it seemed confusing to do this for just the checked-out branch, so I was playing with having all incoming pushes go into their own namespace, hence the prefix.

Also, the use case I have in mind here is an individual with a workstation and a laptop, and the repository on the workstation and its clone on the laptop are both non-bare. There are not multiple individuals pushing to the non-bare repo. Someone please correct me if I'm wrong, but it is my impression that these are the users that have motivated the receive.denyCurrentBranch option (and its eventual default changing to refuse) in the first place.

In that case, the work-flow is typically:

server$ mkdir repo && cd repo && git init
server$ ... add, commit, add, commit ...
  [...time passes...]
laptop$ git clone ssh://server/~/repo
laptop$ ... add, commit, add, commit ...
laptop$ git push
laptop$ ssh server
server$ cd repo
server$ git merge incoming/master
server$ git branch -dr incoming/master

But, to answer your question, the non-fast-forward push is rejected, unless the user forces it, unless receive.denyNonFastForwards prevents the force.

j.

Jay Soffian <jaysoffian@gmail.com> writes:

Push _is_ symmetric to fetch; it is not symmetric to pull, and it cannot be. BTW. Mercurial's pull is equivalent to Git's fetch.

That is of course provided that you have the same refspec(s) for push and for fetch. And up to the point: push needs to be via authenticated channel, for obvious reasons.

The fact that default setup is not symmetric reflect the fact that in most cases the situation is not symmetric: you fetch from other remote repository into separate remotes layout, you push into your own public bare publishing repository set up in mirroring mode.