Re: Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?

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

 



Hi,

On 15 September 2012 18:21, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> David Chanters <david.chanters@xxxxxxxxxxxxxx> writes:
>> 2.  If I do publish it, are there any caveats with that?  i.e.,
>> because the replace data will likely point to a repo which in my
>> working checkout I added with "git-remote", is that going to be a
>> problem?
>
> That is between you and other project participants.  They may not
> want to see replacement in their project in the first place.
>
> Assuming that they do, pushing the replacement ref makes the
> replacing object available in the pushed-into repository, so
> they will *not* rely on your repository.

This makes sense.  But it is more the mechanics of what happens with
needing to update the "fetch" line for the remote in .git/config I am
more puzzled by.

For example, if I have two repos -- repoA and repoB, where repoA
contains the replace refs for repoB -- if I clone both repos with the
intent of wanting to look at the two histories, what must I do in
repoA to fetch the replace refs in the first place?

I've tried:

[remote "origin"]
        fetch =
+refs/replace/*:+refs/heads/*:refs/remotes/origin/*:refs/replace/*

But this results in:

% git pull
fatal: Invalid refspec
'+refs/replace/*:+refs/heads/*:refs/remotes/origin/*:refs/replace/*'

So I'm clearly not understanding something here, and even then, I'm
assuming that I can manipulate the correct "fetch" line via "git
config", it's just that I'm not sure which one to use.

I keep meaning to read up on refspec stuff because it looks so useful.

Kindly,

David
--
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]