Re: Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?
David Chanters writes: > I've tried: > > [remote "origin"] > fetch = > +refs/replace/*:+refs/heads/*:refs/remotes/origin/*:refs/replace/* Read the documentation and learn about instead of blindly guessing. [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/replace/*:refs/replace/* would be syntactically more correct. That would blindly fetch each and every replace refs from the other side and apply the replacement. It is questionable if it is a sensible thing to do, though. "Git cabal" has been discussing a plan to make this easier but it is not quite ready to outline here yet. Perhaps after I return from my vacation post 1.8.0 release ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?
Hi, On Sat, Sep 15, 2012 at 11:49 PM, David Chanters wrote: > Hi, > > On 15 September 2012 18:21, Junio C Hamano wrote: > >> 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/* Could you try the following: [remote "origin"] fetch = +refs/replace/*:refs/replace/* fetch = +refs/heads/*:refs/remotes/origin/* > But this results in: > > % git pull > fatal: Invalid refspec > '+refs/replace/*:+refs/heads/*:refs/remotes/origin/*:refs/replace/*' Best, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?
Hi, On 15 September 2012 18:21, Junio C Hamano wrote: > David Chanters 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using git-replace in place of grafts -- and publishing .git/refs/replace between repos?
David Chanters writes: > 1. I thought the replace data in .git/refs/replace was published when > I did "git push" so that others could use this information as a > base-point, yet it seems not to be the case. How do I publish this? If you don't tell it what to push, the command will just update the branches. You can tell "git push" what you want to push explicitly, e.g. $ git replace -l ;# to learn what replacement I want to send 77d5ba8477eb90509e79dbcf63814a3dfdefb906 $ git push origin refs/replace/77d5ba8477eb90509e79dbcf63814a3dfdefb906 > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
