Re: [PATCH 2/3] git-bundle: die if a given ref is not included in bundle

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Mar 10, 2007, 16:14 UTC
Message-ID: <45F2D955.8050800@gmail.com>
In-Reply-To: <Pine.LNX.4.63.0703101637300.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 10 quoted lines

> 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