[Prbl: pushing does not work] (was: hg-git plugin, and git-fast export)
Simon King
simon at simonking.org.uk
Mon Feb 1 14:36:48 UTC 2016
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:
>
> > Am Freitag, 22. Januar 2016, 12:25:15 schrieb Uwe Brauer:
> >> But what's about the hg-git plugin, could it, say, work with some of
> the
> >> lisp projects which reside in github using that plugin and *not*
> screw
> >> up things for the other git users? Does anybody has experience with
> that
> >> plugin used in that way?
>
> > I’m using hg-git almost daily for contributing to Freenet (on github,
> > sadly). It’s not as convenient as contributing to a hg project (mostly
> > clone, push and pull are quite a bit slower), but it works — and hg
> > with hg-git is easier to use than git.
>
> > As a hint: Create a bridge repository which is responsible for all
> > interaction with git repos. Then clone your work repository from that.
>
> > repo-bridge/ ⇔ git
> > repo-work/ ⇔ repo-bridge
>
> > Just code in the work repo, create bookmarks and push them to the
> bridge.
>
> > hg boo what-git-will-see-as-branch -r REV
> > hg push -B what-git-will-see-as-branch; hg -R ~/repo-bridge push -r
> what-git-will-see-as-branch
>
> > and pull
>
> > hg -R ~/repo-bridge pull; hg pull
>
>
> Hm it does not work for me as I will describe below, but I also would like
> to know: what is the -R option?
>
> Here is a test case I run, just concerning the bridge-repo
>
> $HOME: mkdir Git-Hg
> cd Git-Hg
> mkdir Git
> cd Git
> git init
> generate a file, add text, commit 2 times.
>
> cd $HOME/Git-Hg
> mkdir Hg
> cd Hg
> hg clone $HOME/Git-Hg/Git (succesful)
> (hg clone of that git repo is now in $HOME/Git-Hg/Hg/Git)
> cd Git
> hg log
>
> ,----
> | changeset: 1:853a02fe291d
> | bookmark: master
> | tag: tip
> | user: oub <oub at Gilgamesch.(none)>
> | date: Mon Feb 01 13:41:00 2016 +0000
> | summary: 3
> |
> | changeset: 0:07d46e13ed2c
> | user: oub <oub at Gilgamesch.(none)>
> | date: Mon Feb 01 13:40:47 2016 +0000
> | summary: 2
> `----
>
> hg bookmarks
> * master 1:853a02fe291d
> edit the file various times, commit once with hg
> now push
> hg push $HOME/Git-Hg/Git
>
> I obtain an error.
> ,----
> | pushing to /home/oub/Git-Hg/Git/
> | searching for changes
> | adding objects
> | Unpacking objects: 100% (3/3), done.
> | remote: error: refusing to update checked out branch: refs/heads/master
> | remote:
> | remote: error: By default, updating the current branch in a non-bare
> repository
> | remote:
> | remote: error: is denied, because it will make the index and work tree
> inconsistent
> | remote:
> | remote: error: with what you pushed, and will require 'git reset --hard'
> to match
> | remote:
> | remote: error: the work tree to HEAD.
> | remote:
> | remote: error:
> | remote:
> | remote: error: You can set 'receive.denyCurrentBranch' configuration
> variable to
> | remote:
> | remote: error: 'ignore' or 'warn' in the remote repository to allow
> pushing into
> | remote:
> | remote: error: its current branch; however, this is not recommended
> unless you
> | remote:
> | remote: error: arranged to update its work tree to match what you pushed
> in some
> | remote:
> | remote: error: other way.
> | remote:
> | remote: error:
> | remote:
> | remote: error: To squelch this message and still keep the default
> behaviour, set
> | remote:
> | remote: error: 'receive.denyCurrentBranch' configuration variable to
> 'refuse'.
> | remote:
> | abort: git remote error: refs/heads/master failed to update
> |
> |
> |
> `----
>
> Could it be my hg version (3.01) or my git version (1.7.0.4)
>
> Any help would be appreciated, because if that simple case does not
> work, no change for me to consider a repo at github.
>
>
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,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20160201/fa8af75a/attachment-0002.html>
More information about the Mercurial
mailing list