[Prbl: pushing does not work]

[Simon King]

On Mon, Feb 1, 2016 at 4:24 PM, Uwe Brauer <oub at mat.ucm.es> wrote:

> >>> "Simon" == Simon King <simon at simonking.org.uk> writes:
>
>     > On Mon, Feb 1, 2016 at 1:52 PM, Uwe Brauer <oub at mat.ucm.es> wrote:
>     >>>> "Arne" == Arne Babenhauserheide <arne_bab at web.de> writes:
>
>
>     > By default, git doesn't like you pushing to a repository that has a
>     > working copy associated with it, because the working copy is normally
>     > associated with a symbolic branch name, and when you push to that
>     > repository, you'd be advancing the branch but not updating the
>     > working copy.
>
>     > The normal way to avoid this is to make the git repository "bare",
>     > which I think is done by using the "--bare" flag to "git init" or
>     > "git clone".
>
>     > Hope that helps,
>
>
> Thanks, it worked  for my small experiment, I mentioned in my earlier
> message.
>
> But I turned now to something more serious. I cloned the auctex
> development repo (which is under git), via
>
> git clone
>
> to a local directory (that would be my repo-bridge)
>
> $HOME/Git/auctex
>
> I then run
>
>  hg clone to  a hg directory, namely $HOME/Git/Hg
>  cd $HOME/Git/Hg
>  hg clone $HOME/Git/auctex.
>
> Now in that cloned hg repo, I edited some files, committed and tried to
> push.
>
> The original conf file of auctex is this.
>
> [core]
>         repositoryformatversion = 0
>         filemode = true
>         bare = false
>         logallrefupdates = true
> [remote "origin"]
>         fetch = +refs/heads/*:refs/remotes/origin/*
>         url = git://git.savannah.gnu.org/auctex.git
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
>
> Now I couldn't push, but when I changed to
>
>    bare =true
>
> I could push (to $HOME/Git/auctex) . *However* when I run
>
>  git checkout master -f
>
> In the $HOME/Git/auctex
>
> I obtained
>
>
> fatal: This operation must be run in a work tree
>
> So one option was to switch back to
>
>      bare =false.
>
> In the  config file.
> However I found another solution which I already posted, I leave the
> bare option untouched, but add
>
> [receive]
>         denyCurrentBranch = ignore
>
> That also seems to work. I would, however, appreciate comments from
> people who are  familiar with the git-hg plugin, in order to see that I
> don't screw things up with this setting.
>
>
This doesn't really have anything to do with hg or hg-git any more - this
is purely about how git handles pushes to non-bare repositories, so a
discussion on the mercurial-users mailing list is not really the best place
for it. However, I'll give it a go:

By setting "denyCurrentBranch = ignore" in your auctex repository, you are
telling *git* that it is OK for changes to be pushed to the branch that is
currently checked out in that repository. When you first cloned that
repository, it presumably checked out the "master" branch, which would have
been a particular revision. Then, you cloned that repository (it doesn't
matter that you used hg-git, the same would happen if you used git itself),
made some changes on that master branch, and pushed them back.

The repository is now in a funny state. The "master" branch has moved on to
a new commit, but the working directory is still pointing at an older
commit. If you run "git status" in it, I think you'll see some unexpected
output (I just tried it, and I got inconsistent results between "git
status" and "git diff", so I'm not going to attempt to explain exactly what
state it is in, since I don't understand it)

Unless you *really* *really* need to, I would recommend sticking with a
*proper* bare repository as your bridge repository. That is, one created
with "git clone --bare". Not one where you started with a working copy and
then edited the config file.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20160201/4c8c6d3d/attachment-0002.html>