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

> В Sat, 11 May 2013 08:57:14 -0500
> Felipe Contreras <felipe.contreras@gmail.com> пишет:
> 
> > On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov <arvidjaar@gmail.com> 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?
> > 
> > Indeed, this is the way it currently works, and it's not easy to fix.
> > We would need some way to make fast-export wait until we know the exit
> > status of the remote helper, and then tell it when it failed, so the
> > marks are not updated.
> > 
> 
> Hmm ... actually as far as I understand transport-helper keeps track of
> which revisions to push in "remote helper ref" (for the lack of better
> word). This makes use of marks as tracking means rather redundant.
> 
> What about the idea below? This relies on transport helper to provide
> correct revisions and uses marks exclusively as cross-reference between
> GIT and remote SCM. It is on top of next branch.