Re: git-send-pack SIGSEGV..

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> writes:

>> I suspect this has an side effect of allowing
>> 
>> 	fetch = refs/heads/*
>> 
>> to mean the same thing as
>> 
>> 	fetch = refs/heads/*:refs/heads/*
>> 
>> which is suitable for a bare mirroring repository, but I do not
>> think of any downside, so it might be Ok.
>> 
>> But that is something from a person who was under anesthesia a
>> few hours ago, so you should take it with a big grain of salt ;-)
>
> Yeah, that's not right; "push = refs/heads/*" works like that, but 
> "fetch = refs/heads/*" puts them in MERGE_HEAD without storing them 
> anywhere, unlike "fetch = refs/heads/*:refs/heads/*".

While I appreciate the proper fix, I have to say "Wait a minute".

First of all, do you really mean MERGE_HEAD in the above?  My
fix would obviously change the way how "git fetch" would STORE
what was fetched when you have "fetch = refs/heads/*" line in
the configuration file, which is what I already said in my
message.  However, using or not using tracking branches to store
the result should never affect if the fetched object is used in
MERGE_HEAD, so the fix you are responding to should not affect
what goes there at all.  If it does, then there is something
wrong in the current code.

I did not even realize that "push/fetch = $prefix/*" was
allowed.  IIRC, it has always been "$prefix1/*:$prefix2/*" form,
and "$prefix/*" was illegal.  Somehow a change in sematics
sneaked in without me knowing that makes it legal, and the
updated semantics is that for push "$prefix/*" is the same as
listing every ref under the prefix (without any colon, so it
pushes to the same name), and for fetch "$prefix/*" is the same
as $prefix/$x: (i.e. with colon and empty RHS) for all refs
under $prefix.

Now, I am not opposed to _having_ enhanced semantics.  Earlier,
"$prefix/*" was illegal, so it is not like you have introduced
any incompatibility.  On the push side, I do not think of any
sane interpretation for it other than treating it exactly as
"$prefix/*:$prefix/*".  On the fetch side, however, I am not
sure not to use any tracking _and_ grabbing everything is a sane
semantics.  You fetch everything under $prefix/ and list them in
FETCH_HEAD --- now what?  On the other handl, treating it as if
the user wrote "$prefix/*:$prefix/*" makes some sense.  It is a
natural operation to keep a bare mirroring repository up to
date.

But I am somewhat upset about us having the enhanced semantics
without me knowing.  I see two possible reasons for it: (1) I
was not being extra careful when I accepted your patches, and
(2) the change in the semantics were not documented, either in
the log nor Documentation/.

We obviously cannot fix (1) overnight, but could you please at
least fix (2)?  git-push.txt and pull-fetch-param.txt would be
the two places that talk about "$prefix1/*:$prefix2/*", and they
should talk about the new "$prefix/*" syntax as well.

I think "fetch = refs/heads/*" syntax, if it just fetches
without storing, does not make much sense.  In a separate-remote
repository, "[remote "foo"] fetch = refs/heads/*" would probably
be useful if we treated it as "refs/heads/*:refs/remotes/foo/*".
In a bare repository used for mirrors, it would be useful if it
stood for "refs/heads/*:refs/heads/*".