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