From: Mark Levedahl Date: Sat, 10 Mar 2007 16:14:13 GMT Subject: Re: [PATCH 2/3] git-bundle: die if a given ref is not included in bundle Message-ID: <45F2D955.8050800@gmail.com> In-Reply-To: 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 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