On Tue, Jun 07, 2011 at 07:32:22PM +0200, Sverre Rabbelier wrote: > On Tue, Jun 7, 2011 at 19:21, Jeff King <peff@xxxxxxxx> wrote: > > When a remote helper exports to a non-local git repo, the > > steps are roughly: > > > > Â1. fast-export into a local staging area; the set of > > Â Â interesting refs is defined by what is in the fast-export > > Â Â stream > > > > Â2. git push from the staging area to the non-local repo > > > > In the second step, we should explicitly push all refs, not > > just matching ones. This will let us push refs that do not > > yet exist in the remote repo. > > That repo is re-used though. Wouldn't this break for: > > $ git push branch-a > $ # make commits on branch-a that shouldn't be pushed yet > $ git push branch-b No, because our fast-export from git will not include branch-a, and this is about pushing from the exported staging area. If the remote rewound their branch-a, we would actually fast-forward it back again. This is no different than the current behavior, though, which uses matching[1]. It would also update branch-a because it exists upstream. A related problem is branch deletion. I don't know that I can delete via a fast-export stream. So once a branch exists in the staging area, it will never go away. So I think the right solution is really that the "export" command needs to communicate the ref pairs to the remote helper so that it can do the right thing (which would include renaming or deleting). -Peff [1] Actually, isn't the default push behavior due to change soon? That would further break the existing code. -- 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