{"thread":{"id":"1182","subject":"Converting commits to patch files? HEAD vs HEAD^","startedAt":"2005-07-09T01:38:59Z","lastAt":"2005-07-09T11:10:26Z","messageCount":4,"participants":["Marc Singer","Linus Torvalds","Junio C Hamano","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5846","messageId":"20050709013859.GA11947@buici.com","threadId":"1182","inReplyTo":null,"subject":"Converting commits to patch files? HEAD vs HEAD^","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-09T01:38:59Z","receivedAt":"2005-07-09T01:38:59Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"Jeff Garzik's guide doesn't appear to explain how to get patches back\nout of the system.  \n\nI've successfully commited a set of changes.\n\n # git diff HEAD^ HEAD\n\nThis command will produce a diff of the changes I've made.  What is\nthe HEAD^?  Does it refer to the commit before the last one made?\n\nIf I've made several commits, I'd like to be able to gather several\ntogether and produce a patch file.  Better still, I'd like to be able\nto pick a set of discontiguous commits an bundle them into a single\npatch.  Ought I be using tags?\n\nFinally, given that the upstream repository is git, what is the way to\npush commits upstream?\n"},{"id":"5849","messageId":"Pine.LNX.4.58.0507081846020.17536@g5.osdl.org","threadId":"1182","inReplyTo":"20050709013859.GA11947@buici.com","subject":"Re: Converting commits to patch files? HEAD vs HEAD^","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-09T01:52:07Z","receivedAt":"2005-07-09T01:52:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 8 Jul 2005, Marc Singer wrote:\n>\n>  # git diff HEAD^ HEAD\n> \n> This command will produce a diff of the changes I've made.  What is\n> the HEAD^?  Does it refer to the commit before the last one made?\n\nYes. The core tools don't understand this syntax, but most of the helper \nscripts use \"git-rev-parse\" to parse arguments, and then you have the \n\"extended syntax\" which allows short SHA1 names and \"parenting\".\n\nHEAD^ is the \"first parent of HEAD\". You could also have written it\n\"HEAD^1\", although the number is really only relevant if you have a merge,\nand you want to specify the _other_ side, ie \"HEAD^2\" is the \"second\nparent of HEAD\".\n\nIf you want to have the parent of the parent, write HEAD^^.\n\nNow, to confuse things, a \"^\" at the _beginning_ of the name means \nsomething else: it means \"not\", and it used to do ranges.\n\n> If I've made several commits, I'd like to be able to gather several\n> together and produce a patch file.  Better still, I'd like to be able\n> to pick a set of discontiguous commits an bundle them into a single\n> patch.  Ought I be using tags?\n\nYou can use tags, but you can just do\n\n\tgit log\n\nand pick out the commit ID's from there and use those too.\n\n\"git-whatchanged -p\" is also useful to see what's been going on. And \n\"gitk\", of course.\n\n> Finally, given that the upstream repository is git, what is the way to\n> push commits upstream?\n\nYou can do\n\n\tgit push destination\n\n(which I just added today), which is just the same thing as\n\"git-send-pack\".\n\nBUT NOTE! It only works for destinations that _you_ control, though. You\ncan't push to others - you can only push to your own repositories, and\nthen wait for others to pull from them. Ie, the normal reason to use\n\"git-send-pack\" or \"git push\" is because you do the work on a private\nmachine, and then you want to push it out to a public one (still yours),\nand send an email to people saying \"please pull from so-and-so\".\n\n\t\tLinus\n"},{"id":"5851","messageId":"7vvf3k1z28.fsf@assigned-by-dhcp.cox.net","threadId":"1182","inReplyTo":"20050709013859.GA11947@buici.com","subject":"Re: Converting commits to patch files? HEAD vs HEAD^","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-09T02:41:03Z","receivedAt":"2005-07-09T02:41:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"MS\" == Marc Singer <elf@buici.com> writes:\n\nMS> If I've made several commits, I'd like to be able to gather several\nMS> together and produce a patch file.  Better still, I'd like to be able\nMS> to pick a set of discontiguous commits an bundle them into a single\nMS> patch.  Ought I be using tags?\n\n    You ought to be using ...\n\nOh, I want to say it because the above is what I do all the time\nusing my Porcelain on GIT, but on the other hand, officially I\nam _not_ working on any Porcelain, so... I am in a dilemma.  I\nwon't talk about that tool I use myself.\n\nAlthough I have not looked at it myself, you may want to take a\nlook at StGIT.\n\n\"Keeping patches, tracking upstream by primarily updating,\nforward porting and e-mail submitting patches\" is often the\ndevelopment model taken by \"individual developers\", while\n\"making commits primarily by accepting patches, merging with\nrepos of other people who have similar aggregator role\" is often\nthe model used by \"project leads\".\n\nThe core GIT (and \"git\" barebone Porcelain) is geared towards\n\"project lead\" use, and I suspect Cogito would be so to a\ncertain extent.  By judging only from its description, StGIT,\nwith its attitude ancestry of quilt, may be more comfortable to\nuse with \"individual developers\" mode of operation.\n\nWell, I'd say what I use anyway, and quickly duck ;-)\n\n    You ought to be using ... JIT.\n"},{"id":"5862","messageId":"tnxhdf48cbh.fsf@arm.com","threadId":"1182","inReplyTo":"7vvf3k1z28.fsf@assigned-by-dhcp.cox.net","subject":"Re: Converting commits to patch files? HEAD vs HEAD^","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-09T11:10:26Z","receivedAt":"2005-07-09T11:10:26Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n>>>>>> \"MS\" == Marc Singer <elf@buici.com> writes:\n> MS> If I've made several commits, I'd like to be able to gather several\n> MS> together and produce a patch file.  Better still, I'd like to be able\n> MS> to pick a set of discontiguous commits an bundle them into a single\n> MS> patch.  Ought I be using tags?\n>\n> Although I have not looked at it myself, you may want to take a\n> look at StGIT.\n\nI still haven't found time to write a tutorial for StGIT (it has a\nREADME but I haven't updated it for some time) but I will try to give\na short description. People familiar with Quilt should not have any\nproblem with using this tool (it is safer than quilt).\n\nStGIT is well suited for working on trees you do not control (you send\npatches and wait for them to be merged and eventually get them from\nthe remote repository when pulling the latest changes). The advantage\nover quilt is that it uses three-way merging and also informs you when\nyour local patch is empty (i.e., after the patch was fully merged\nupstream, quilt just failing to push the patch in this case because of\nconflicts).\n\nIn general, you clone a repository (Linus' for example) and run\n'stg init' to initialise the StGIT specific files.\n\nThere is no 'commit' command in StGIT. To make changes, create a patch\nwith 'stg new <name>' and add some description (can be modified at any\ntime with the 'refresh --edit' command). You make changes to the files\n(or add/rm files) and save them (can be done for an indefinite number\nof times) into the current patch with 'stg refresh'. This last command\ncreates a GIT commit object for the changes between the working tree\nand the bottom of the patch (which can be the upstream HEAD if this is\nthe first patch).\n\nYou can create several patches with 'stg new'. A 'git log' command\nwould show the patches as individual commits. The advantage over a\nnormal SCM is that you can modify the patch and replace the commit\nobject with a new one.\n\nTo work on a given patch, make it current via the 'stg push/pop'\ncommands. Note that 'stg push' also allows patch re-ordering.\n\nTo pull the latest changes from the upstream respository, do a 'stg\npop -a' (at this point the tree is the same as the one when you last\npulled the remote changes), 'git pull', 'stg push -a'. You can get\nconflicts for the latter command if there are overlapping changes or\nthe patch was modified by the gatekeeper before being merged. Fix the\nconflicts, run 'stg resolved/stg refresh' and re-run 'stg push -a' for\nthe rest of the patches. The 'push' and the 'series' commands notify\nyou if the patch is empty so that it can safely be removed ('stg\ndelete <name>').\n\nTo send patches upstream (the 'mail' command is not available yet),\nyou can export the patches with 'stg export' and e-mail manually. You\ncan create your own template for the exported patch (to include\ndescription, diffstats etc.). An temlate example is given in the\narchive, just copy it to the .git/ directory.\n\nAnother way to send patches is to ask the gatekeeper to pull from your\ntree. Run 'stg push' for all the patches you want to be merged and the\nHEAD of your tree would contain the commit objects.\n\n-- \nCatalin\n"}]}