RE: Fetch and -t
[Sorry for the top-posting. I *hate* Outlook.] I will need to check why my system is showing old man pages. I am running something compiled from the git tree on kernel.org. Thanks! -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Monday, February 11, 2013 6:25 PM To: Olsen, Alan R Cc: git@vger.kernel.org Subject: Re: Fetch and -t Olsen, Alan R alan.r.ol...@intel.com writes: I have found that if I add a remote and do a git fetch -t -f remote_name that it *only* pulls tags. Reading the man page it seems like it should pull all the remotes and all the tags and the commits only reachable by tags. This is what appears in the documentation we ship these days. -t:: --tags:: This is a short-hand for giving refs/tags/*:refs/tags/* refspec from the command line, to ask all tags to be fetched and stored locally. Because this acts as an explicit refspec, the default refspecs (configured with the remote.$name.fetch variable) are overridden and not used. http://git-htmldocs.googlecode.com/git/git-fetch.html Previous discussion: http://thread.gmane.org/gmane.comp.version-control.git/180636 A more recent one: http://thread.gmane.org/gmane.comp.version-control.git/211439/focus=211464 -- 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: Interesting git-format-patch bug
[Sorry for the top posting. Outlook is crap.] You are correct. I should only get one copy of the patch on branch A. Branch B was modified after the merge and git-format-patch includes the original patch from the merge and a duplicate copy with the changed comments. Note that this patch only has different comments. The body of the patch is exactly the same. How gerrit mangles things is out of my control. I would prefer that they cherry-pick instead of merges. I have to live with the bad choices of both gerrit and developers in this case. I guess I will have to diagram out a better example of what is happening here. -Original Message- From: Perry Hutchison [mailto:per...@pluto.rain.com] Sent: Monday, November 26, 2012 8:15 PM To: gits...@pobox.com Cc: git@vger.kernel.org; Olsen, Alan R Subject: Re: Interesting git-format-patch bug Junio C Hamano gits...@pobox.com wrote: Olsen, Alan R alan.r.ol...@intel.com writes: I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) As you literally have patches that do essentially the same or similar things on two branches that was merged, you cannot expect to export each individual commit into a patch and not have conflicts among them. So I do not think there is no answer than don't do that. To me, this seems to miss Alan's point: only one patch was merged to branch A, so git-format-patch applied to branch A should find only one patch. It can be argued either way whether that one-patch report should include the gerrit annotations, but surely the application of gerrit on branch B, _after the merge to branch A has already been performed_, should not cause an additional patch to magically appear on branch A. -- 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
Interesting git-format-patch bug
I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) This is should be one of those rare corner case don't do that occurrences. Unfortunately it does happen once in a while on our branches and it screws up some of the automated processes we rely on. Is there a way around that (other than don't) or can this be fixed? -- 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
