Re: ! [rejected] master -> master (non-fast forward)

["Jon Smirl" <jonsmirl@gmail.com>]

On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > What's causing this? I'm using stgit on the master branch.
> > I'm fixing it each time on the remote server by deleting the ref to master.
> >
> > jonsmirl@terra:~/ds$ git push digispeaker
> > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> >  ! [rejected]        master -> master (non-fast forward)
> > error: failed to push to
> > 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'
> > jonsmirl@terra:~/ds$
>
> A "non-fast forward" means that you had this history earlier:
>
>          o---o---A
>         /
>     ---o
>
> pushed "A" to the remote's 'master', then built this history:
>
>          o---o---A
>         /
>     ---o---o---o---o---A'
>
> by rewinding and rebuilding, and the tip of the branch now
> points at A', which you tried to push to the remote.

stgit must be doing this when I rebase. It pops all of it's patches,
moves to head of linus/master and then rebases them.

I'm the only person with write access to the repo.

> Which often causes troubles for people who are fetching from the
> branch you are pushing into, and forbidden by default as a
> safety measure.

What is the right way to share repositories using stgit? I have a set
of patches which I am working on for kernel inclusion. I have them
applied as a stgit stack on top of linus/master. I need to share this
patch stack with other developers. These developers may want to change
one of my patches. Right now they are emailing me deltas and I apply
them to the appropriate stgit patch. I have seventeen patches in my
stack currently.

I am starting to see why several people have made comments about
integrating stgit into git. When other developers clone my repo the
stgit setup doesn't come with it. It would be great it we could use
git to push the stgit patches around and work on them.

> As long as the people who fetch from the branch knows that you
> will regularly rewinding the tip of the branch, there is no
> confusion, and you can "force" a non-fast forward update.  There
> are two independent safety mechanisms:
>
>  - the sending end safety can be overriden by "git push --force"
>    and/or by using a refspec prefixed with a '+');
>
>  - the receiving end safety can be overriden by the config
>    variable receive.denynonfastworwards of the repository you
>    are pushing into.
>
> The latter defaults to "unsafe", but if the safety is activated
> in the repository, forcing from the sending side will not
> deactivate it.  IOW, both ends need to agree to allow the unsafe
> behaviour.
>
> > On the server I have:
> > [core]
> >         repositoryformatversion = 0
> >         filemode = true
> >         bare = true
> >         logallrefupdates = true
> >
> > bare was set false, I just flipped it to true. The server repo was
> > originally created via a clone from kernel.org and then renamed to be
> > a bare repo. Why do we need a 'bare' attribute?
>
> There are a few things that change behaviour depending on the
> bareness of the repository.  One example is that "git fetch"
> that updates to the current branch (i.e. what HEAD points at) by
> having it as the RHS of a refspec is accepted only for bare
> repositories (for non-bare repositories such a fetch would make
> the HEAD and the work tree go out-of-sync).
>


-- 
Jon Smirl
jonsmirl@gmail.com