Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle

[Mark Levedahl <mlevedahl@gmail.com>]

Adam Brewster wrote:
> Hi Mark,
>
> Thank you for your help, and I'm sorry I didn't get back to you sooner.
>
> That's a good way to do things.  I tend to like my system better
> because it's a little more flexible and it doesn't pollute git-branch
> -a and gitk --all, also as I said before I like the bundle creation
> and the basis update to be separated.
>
> How do you deal with the case where you want to include remote refs in
> the bundle?  Don't they get saved as
> refs/remotes/remote/remotes/somewhere-else/master?
>
> Adam
>
>   
My script is based upon experience with breakage from keeping the basis 
separate: absent keeping the refs in the git repo, there is nothing to 
guarantee that the referenced commits continue to exist. We make 
extensive use of short lived topic branches that are often rebased 
multiple times before being incorporated into a stable branch, so an 
externally stored basis would frequently have invalid commits. The 
solutions to this are to 1) filter them out, one by one, with a "git 
rev-parse $commit" or some such, or 2) keep the refs in tree so git will 
not remove the objects.

I'm using this for sneaker-netting, so I know the bundles are being 
applied - clearly the create bundle and update in-tree basis steps could 
be separated, but I don't use this for cases where I'm not sure the 
bundle will be applied. In the latter case, I just use a basis 
containing only previous stable branches.

You are correct in the name for a remote in the pushed bundle, the names 
do get convoluted, but then I'm not sure what the "correct" syntax would 
be to refer to a remote repo's idea of a remote branch.

Mark