threads / discuss / 43267

Re: git fetch --reference?

Subject: Re: git fetch --reference?

## tl;dr

5 messages between Nov 15, 2006 and Nov 15, 2006.

replies: 4people: 3as markdown or json

Michael K. Edwards· Nov 15, 2006, 00:38 UTC · lore

git fetch --reference?

When setting up a working area for kernel integration for a new embedded target, I generally do a "git clone --reference" so that the new area has its own repository (and its own branch structure) but most of the blobs come from a local reference copy. But now that I'm integrating bits from several non-trivially divergent trees (mtd-2.6, netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid re-downloading blobs for these additional remote branches, which are also available in the local reference copy. Is it feasible to implement "git fetch --reference" for this purpose? Or is there a better way to manage this sort of integration effort?

Cheers,
Junio C Hamano· Nov 15, 2006, 01:02 UTC · re: Michael K. Edwards · lore
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
Show 10 quoted lines
> When setting up a working area for kernel integration for a new
> embedded target, I generally do a "git clone --reference" so that the
> new area has its own repository (and its own branch structure) but
> most of the blobs come from a local reference copy.  But now that I'm
> integrating bits from several non-trivially divergent trees (mtd-2.6,
> netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid
> re-downloading blobs for these additional remote branches, which are
> also available in the local reference copy.  Is it feasible to
> implement "git fetch --reference" for this purpose?  Or is there a
> better way to manage this sort of integration effort?

I am somewhat doubtful that this is common enough to warrant adding an extra option to "git fetch", but you could add alternates to these new reference object stores before initiating the fetch.

For example, if you have pristine linux-2.6/ and your work was started by cloning with --reference to it into my-2.6/, you would have something like this:

	$ cd /usr/src
	$ ls -F
        linux-2.6/ linux-2.6.16.y/ netdev-2.6/ my-2.6/
	$ cd my-2.6/
        $ cat .git/objects/info/alternates
	/usr/src/linux-2.6/.git/objects
Then you would (still in my-2.6 repository):
	$ cat >>.git/objects/info/alternates
        /usr/src/linux-2.6.16.y/.git/objects
        /usr/src/netdev-2.6/.git/objects
        $ git pull ../netdev-2.6/ ALL

which would hopefully not download _any_ objects but just gets the ALL branch and makes a merge commit in your working repository.
Michael K. Edwards· Nov 15, 2006, 01:17 UTC · re: Junio C Hamano · lore
On 11/14/06, Junio C Hamano <junkio@cox.net> wrote:
Show 5 quoted lines
> I am somewhat doubtful that this is common enough to warrant
> adding an extra option to "git fetch", but you could add
> alternates to these new reference object stores before
> initiating the fetch.
> ...

Thanks, that's what I was looking for. I can just set up a "tracking" tree where I don't attempt any merges, include it in the alternates for each working tree, and "git fetch" in the tracking tree when it's convenient. Now, will tags from the tracking tree propagate into the working trees?

Cheers,
Junio C Hamano· Nov 15, 2006, 01:49 UTC · re: Michael K. Edwards · lore
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
Show 12 quoted lines
> On 11/14/06, Junio C Hamano <junkio@cox.net> wrote:
>> I am somewhat doubtful that this is common enough to warrant
>> adding an extra option to "git fetch", but you could add
>> alternates to these new reference object stores before
>> initiating the fetch.
>> ...
>
> Thanks, that's what I was looking for.  I can just set up a "tracking"
> tree where I don't attempt any merges, include it in the alternates
> for each working tree, and "git fetch" in the tracking tree when it's
> convenient.  Now, will tags from the tracking tree propagate into the
> working trees?

For the working trees, if you "fetch" from the tracking tree using short-hand, just like you "fetch" from the origin using short-hand, tags will be followed, I think.

Jakub Narebski· Nov 15, 2006, 01:04 UTC · re: Michael K. Edwards · lore
Michael K. Edwards wrote:
Show 10 quoted lines
> When setting up a working area for kernel integration for a new
> embedded target, I generally do a "git clone --reference" so that the
> new area has its own repository (and its own branch structure) but
> most of the blobs come from a local reference copy.  But now that I'm
> integrating bits from several non-trivially divergent trees (mtd-2.6,
> netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid
> re-downloading blobs for these additional remote branches, which are
> also available in the local reference copy.  Is it feasible to
> implement "git fetch --reference" for this purpose?  Or is there a
> better way to manage this sort of integration effort?

All (I think) that --reference does is to create alternates file. You can simply add another alternate before fetch.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

← back to recent threads