Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
- From
Mark Levedahl <mlevedahl@gmail.com>
- Date
- Jul 4, 2008, 13:14 UTC
- Message-ID
- <486E2245.6040404@gmail.com>
- In-Reply-To
- <c376da900807031613pc63639du356946f8daeabb29@mail.gmail.com>
Adam Brewster wrote:
Show 16 quoted lines
> 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