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

Mark Levedahl [off-list ref] writes:

git>git bundle create t.bdl master --not master
Generating pack...
Done counting 0 objects.
Writing 0 objects.
Total 0 (delta 0), reused 0 (delta 0)
git>git ls-remote t.bdl
git>

e.g, an empty bundle is created without any error or warning. This is
the one case I believe an error should result: there is no use to
sending (or even creating) an empty bundle.

I agree that erroring on an empty output is a sensible _option_
just like pack-objects has --no-empty option.

The above is actually an interesting example in a different
sense.  When somebody did the following, what should be output?

	$ edit; git commit -a ;# on master
        $ git checkout -b side
        $ edit; git commit -a ;# on side
        $ git bundle create foo.bdl master side ^master
	$ git bundle verify foo.bdl

My answer is that it should list master and side as the
available heads and master itself as also a prerequisite (which
is not what the current code does).  

I think unbundling foo.bdl should be the moral equivalent of
fetching from the originating repository by somebody who has its
prerequisites as tips of some branches.  So I think foo.bdl
should list refs/heads/master as one of the available heads to
fetch/pull from, while requiring the same commit as prerequisite
of the bundle.  It is as if you tried "git fetch" and found out
that you are up to date.  Listing where the 'master' tip is,
even though you did not have to include any commits from that
branch, gives you a useful bit of information ("I am up to date
with respect to that branch").

So I think if you did this instead in the above sequence: 

	$ git bundle create foo.bdl master ^master

it would be sensible to have an option to error out because of
empty pack, but at the same time it would equally be sensible to
have an option to still create a bundle with an empty pack
contents.  In either case, the head and prerequisite section
should include the tip of the master.  Earlier, I said we should
error out if we do not find 'master' in the list of shown
objects, but I think it is more sensible to add it to both the
list of head _and_ prerequisites.

Junio C Hamano wrote:

My answer is that it should list master and side as the
available heads and master itself as also a prerequisite (which
is not what the current code does).
  

So, practically speaking the proposal is that for each ref where 
git-bundle currently issues a warning, instead the ref should be added 
to the prerequisites list, and that all refs given on the command line 
are in the bundle's defined refs.

Sounds reasonable to me.

Mark

Hi,

On Fri, 9 Mar 2007, Junio C Hamano wrote:

Mark Levedahl [off-list ref] writes:

quoted

git>git bundle create t.bdl master --not master
Generating pack...
Done counting 0 objects.
Writing 0 objects.
Total 0 (delta 0), reused 0 (delta 0)
git>git ls-remote t.bdl
git>

e.g, an empty bundle is created without any error or warning. This is
the one case I believe an error should result: there is no use to
sending (or even creating) an empty bundle.

I agree that erroring on an empty output is a sensible _option_
just like pack-objects has --no-empty option.

The above is actually an interesting example in a different
sense.  When somebody did the following, what should be output?

	$ edit; git commit -a ;# on master
        $ git checkout -b side
        $ edit; git commit -a ;# on side
        $ git bundle create foo.bdl master side ^master

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

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

Hi,

On Sat, 10 Mar 2007, Mark Levedahl wrote:

Johannes Schindelin wrote:

quoted

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.

[...]

As long as the lists are syntactically acceptable (all exist), we should 
just create the bundle with the given refs and prerequisites.

So, what do you do if some of your users do, and some others do not, have 
the "blue-sky" branch? If you say "git bundle create new.bundle --all 
-10", your bundle will list "blue-sky" as a prerequisite.

Boom.

Some of your users -- those without "blue-sky" -- will _not_ be able 
to fetch _anything_ from the bundle. They are lacking the prerequisites.

The semantics of git-bundle used to be so clear and sensible, since they 
exactly reflected what git-pack-objects would do.

Now they are no longer?

Ciao,
Dscho

Johannes Schindelin wrote:

Hi,
  
So, what do you do if some of your users do, and some others do not, have 
the "blue-sky" branch? If you say "git bundle create new.bundle --all 
-10", your bundle will list "blue-sky" as a prerequisite.

Boom.

Some of your users -- those without "blue-sky" -- will _not_ be able 
to fetch _anything_ from the bundle. They are lacking the prerequisites.
  

Those who have the prerequisites can apply the bundle. Those who do not, 
cannot. This is unchanged, and completely unrelated to whether the 
bundle defines 0 objects or 10,000. If you do not have the 
prerequisites, you need a different bundle.

Mark

Hi,

On Sat, 10 Mar 2007, Mark Levedahl wrote:

Johannes Schindelin wrote:

quoted

So, what do you do if some of your users do, and some others do not, 
have the "blue-sky" branch? If you say "git bundle create new.bundle 
--all -10", your bundle will list "blue-sky" as a prerequisite.

Boom.

Some of your users -- those without "blue-sky" -- will _not_ be able 
to fetch _anything_ from the bundle. They are lacking the 
prerequisites.

Those who have the prerequisites can apply the bundle. Those who do not, 
cannot. This is unchanged, and completely unrelated to whether the 
bundle defines 0 objects or 10,000. If you do not have the 
prerequisites, you need a different bundle.

Only that I suspect that you want to stick more than one ref into the 
bundle. And at some point you -- or any other user -- will expect the 
bundle to work _with several refs_, even if different recipients will pick 
_only one_ of them.

Basically, I am saying that this whole bundle concept is not thought 
through, that it is too loosely defined, and that it will result in unmet 
expectations sooner or later. (Which usually means sooner.)

So, either we have to rethink how to handle prerequisites (so that only 
those are checked which are strictly necessary for _the one_ ref you are 
updating), or we have to make it _very_ obvious to (human) users of 
git-bundle that you should _not_ bundle two unrelated -- or only remotely 
related -- refs into one bundle.

Ciao,
Dscho