Re: Cannot push anything via export transport helper after push fails.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



В Sat, 11 May 2013 13:36:26 +0100
John Keeping <john@xxxxxxxxxxxxx> пишет:

> On Sat, May 11, 2013 at 04:29:36PM +0400, Andrey Borzenkov wrote:
> > I noticed that using git-remote-bzr, but as far as I can tell this is
> > generic for all transport helpers using fast-export.
> > 
> > 
> > 
> > What happened was "git push" failed due to merge conflict. So far so
> > good - but from now on git assumes everything is up to date.
> > 
> > bor@opensuse:/tmp/test/git> git push origin master
> > To bzr::bzr+ssh://bor@localhost/tmp/test/bzr
> >  ! [rejected]        master -> master (non-fast-forward)
> > error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'
> > hint: Updates were rejected because the tip of your current branch is behind
> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
> > hint: before pushing again.
> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> > bor@opensuse:/tmp/test/git> git push origin master
> > Everything up-to-date
> > bor@opensuse:/tmp/test/git> 
> > 
> > The problem seems to be that git fast-export updates marks
> > unconditionally, whether export actually applied or not. So next time
> > it assumes everything is already exported and does nothing.
> > 
> > Is it expected behavior?
> 
> What version of Git are you using?
> 

bor@opensuse:~/src/git> rpm -q git
git-1.8.1.4-1.1.1.x86_64

> This sounds similar to the regression fixed by commit 126aac5
> (transport-helper: fix remote helper namespace regression, 2013-05-10)
> but that was only introduced in commit 664059f (transport-helper: update
> remote helper namespace, 2013-04-17) which isn't in any released
> versions of Git.

Yes, it sounds similar, but likely the different issue. This can be
demonstrated without any transport-helper involved.

bor@opensuse:/tmp/test/git> cat .git/bzr/origin/marks-git 
:4 7ee7c98504aa12cb82a18978ebef37900b3a5dfb
:2 91fc7db33a662ae294699945631239365eb12880
bor@opensuse:/tmp/test/git> git rev-list HEAD
7ee7c98504aa12cb82a18978ebef37900b3a5dfb
91fc7db33a662ae294699945631239365eb12880
bor@opensuse:/tmp/test/git> git fast-export --import-marks=.git/bzr/origin/marks-git HEAD
bor@opensuse:/tmp/test/git> git rev-list master...origin/master
7ee7c98504aa12cb82a18978ebef37900b3a5dfb
bor@opensuse:/tmp/test/git> git rev-list master...bzr/origin/heads/master
7ee7c98504aa12cb82a18978ebef37900b3a5dfb
bor@opensuse:/tmp/test/git> git fast-export --import-marks=.git/bzr/origin/marks-git HEAD...bzr/origin/heads/master
bor@opensuse:/tmp/test/git> git fast-export --import-marks=.git/bzr/origin/marks-git master...bzr/origin/heads/master
bor@opensuse:/tmp/test/git> 

So in this particular case the problem is in git-fast-export. Actually
this behavior seems to documented:

           Any commits that have already been marked will not be exported
           again.

May be the right thing would be to write only those marks that had
been confirmed by remote helper. But that as far as I understand
requires some interaction between remote helper and git-fast-export. 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]