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

[Mark Levedahl <mlevedahl@gmail.com>]

Johannes Schindelin wrote:
> I am not convinced.  This sort of feature belongs into git-bundle.  It 
> certainly does not deserve being blessed by yet-another git-* command, 
> when we are constantly being bashed for having _way_ too many _already_.
>
> Ciao,
> Dscho
>
>   
Actually, I would like to see "normal" interface for git-bundle handled 
by git-push, git-fetch, and git-remote. We fixed the retrieve side to 
use git-fetch before first integration, but didn't understand the 
semantics for creation well-enough to put into git-push. Right now, we 
can do "git remote add bundle-nick <path-to-bundle>" and set up the remote.

We should have "git push bundle-nick"  create the new bundle, updating 
the basis refs kept somewhere in refs/* (possibly refs/remotes, possibly 
refs/bundles?).

However, we need two helpers to maintain the basis refs, both I believe 
should be sub-commands of git-remote:

- a "rewind" function to roll the refs back to a previous state because 
the bundle didn't get applied, whatever. This is well supported by 
reflogs, is "expire anything *newer* than time", and for convenience 
should apply to all refs for the given remote so the user doesn't have 
to invoke per branch on the remote. e.g., "git remote rewind bundle-nick 
3.days.ago".

- a "prune" function to remove any branch for the remote that is not 
known to the local refs/heads/* hierarchy. This is needed to support 
cleaning up pruned topic branches. Could be a special behavior of "git 
remote prune" triggered by the remote being a bundle, but that might be 
confusing a perhaps need a new sub-command name. Perhaps, "git remote 
prune-non-local bundle-nick"

If we did the above, then git-bundle can be relegated to plumbing and 
bundles become better integrated to the porcelain.

Mark