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
--
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
