Re: receive.denyCurrentBranch

From: Jay Soffian <jaysoffian@gmail.com>
Date: Feb 8, 2009, 17:50 UTC
Message-ID: <76718490902080950r798ca02es4e560da35e499046@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0902081128420.10279@pacific.mpi-cbg.de>

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

Show 8 quoted lines

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

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

> [paths]
> default = ../repoB
> 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.