Johannes Schindelin wrote:
Hi,
IMHO saying "master ^master" should blow into the user's face. If she says
"I want it" _and_ "I don't want it", she should sorta expect it not to
work.
Ciao,
Dscho
The command
git-bundle create foo next ^master
is legitimate, even if next points to the same commit as master. The
current logic would reject this, and should not as we might want to push
out the base of a new development branch in this manner. Consider that
git-fetch <url> would happily update next in this case, git bundle /
git-fetch should as well.
I think we should think of the git-bundle command as accepting two lists
of rev-args
1 - the list of heads to define in the bundle (possibly --all, should
also accept refs/heads/*)
2 - the list of commits to require as prerequisites for applying the
bundle (possibly defined as --since=, possibly defined as a list of
commits, etc).
As long as the lists are syntactically acceptable (all exist), we should
just create the bundle with the given refs and prerequisites. The
resulting bundle will apply cleanly and conforms to general git
semantics. So, I think git-bundle should error out only if a ref does
not exist or if no refs are defined. An empty pack file is legitimate.
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