Re: [PATCH] submodule recursion in git-archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26 Nov 2013, at 14:38, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote:

> Hi,
> 
> I like where this is going.
> 
> On Tue, Nov 26, 2013 at 04:17:43PM +0100, René Scharfe wrote:
>> Am 26.11.2013 01:04, schrieb Nick Townsend:
>>> +		strbuf_addstr(&dotgit, work_tree);
>>> +		strbuf_addch(&dotgit, '/');
>>> +		if (args->treepath) {
>>> +			  strbuf_addstr(&dotgit, args->treepath);
>>> +			  strbuf_addch(&dotgit, '/');
>>> +		}
>>> +		strbuf_add(&dotgit, path_without_prefix,strlen(path_without_prefix)-1);
>>> +		if (add_submodule_odb(dotgit.buf))
>>> +			  die("Can't add submodule: %s", dotgit.buf);
>> 
>> Hmm, I wonder if we can traverse the tree and load all submodule object
>> databases before traversing it again to actually write file contents.
>> That would spare the user from getting half of an archive together with
>> that error message.
> 
> I am not sure whether we should die here. What about submodules that
> have not been initialized and or cloned? I think that is a quite regular
> use case for example for libraries that not everyone needs or big media
> submodules which only the design team uses. How about skipping them (maybe
> issuing a warning) by returning 0 here and proceeding?
> 
> Cheers Heiko

I agree that issuing a warning and continuing is best. If the submodule hasn’t been setup
then we should respect that and keep the current behaviour (just archive the directory entry).
There is some further debate to be had about the extent to which this should work with
un-initialized submodules which I’ll discuss in other replies.

Thanks
Nick--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]