{"thread":{"id":"687","subject":"cogito - how do I ???","startedAt":"2005-05-21T21:47:00Z","lastAt":"2005-05-24T03:05:24Z","messageCount":13,"participants":["Sam Ravnborg","Sean","Linus Torvalds","Frank Sorenson","Thomas Glanzmann","Junio C Hamano","Herbert Xu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3722","messageId":"20050521214700.GA18676@mars.ravnborg.org","threadId":"687","inReplyTo":null,"subject":"cogito - how do I ???","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-05-21T21:47:00Z","receivedAt":"2005-05-21T21:47:00Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"Hi all.\n\nWhile trying to get up to speed on cogito/git I stumbled across\na few things that I at least did not find available in cogito.\n\n1) Something similar to \"bk changes -R\". I use this to see what has\nhappened upstream - to see if I really want to merge stuff.\n\n2) Export of individual patches. \"bk export -tpatch -r1.2345\"\nI have nu public git repository yet so I have to feed changes as\nplain patches. Browsing cg-* I did not find the command to do this.\n\nI do try to avoid having to develop my little army of shell scripts,\nand due to this I have avoided the git- commands for now.\n\nAny help appreciated,\n\tSam\n"},{"id":"3724","messageId":"2765.10.10.10.24.1116713164.squirrel@linux1","threadId":"687","inReplyTo":"20050521214700.GA18676@mars.ravnborg.org","subject":"Re: cogito - how do I ???","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-21T22:06:04Z","receivedAt":"2005-05-21T22:06:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:\n> Hi all.\n>\n> While trying to get up to speed on cogito/git I stumbled across\n> a few things that I at least did not find available in cogito.\n>\n> 1) Something similar to \"bk changes -R\". I use this to see what has\n> happened upstream - to see if I really want to merge stuff.\n\nNot sure what bk did here, but you can do something like:\n\ncg-pull origin\ncg-log -c -r origin\n\nTo see what is at the head of the unmerged objects you just pulled down,\nand if you want to merge then \"cg-merge origin\".  Although as far as I\nknow there's no way to have the log stop automatically at the proper spot.\n\n> 2) Export of individual patches. \"bk export -tpatch -r1.2345\"\n> I have nu public git repository yet so I have to feed changes as\n> plain patches. Browsing cg-* I did not find the command to do this.\n\ncg-diff -p -r SHA1\n\nWhich asks for the diff from the parent (-p) to the revision (-r).\n\nSean\n\n\n"},{"id":"3733","messageId":"Pine.LNX.4.58.0505211635440.2206@ppc970.osdl.org","threadId":"687","inReplyTo":"2765.10.10.10.24.1116713164.squirrel@linux1","subject":"Re: cogito - how do I ???","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-21T23:41:24Z","receivedAt":"2005-05-21T23:41:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 May 2005, Sean wrote:\n\n> On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:\n> > Hi all.\n> >\n> > While trying to get up to speed on cogito/git I stumbled across\n> > a few things that I at least did not find available in cogito.\n> >\n> > 1) Something similar to \"bk changes -R\". I use this to see what has\n> > happened upstream - to see if I really want to merge stuff.\n> \n> Not sure what bk did here, but you can do something like:\n> \n> cg-pull origin\n> cg-log -c -r origin\n\nIn the raw git interfaces, you'd basically have to do the same thing that\n\"git-pull-script\" does, except that _instead_ of calling the\ngit-resolve-script thing, you'd do\n\n\tgit-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin\n\nto show what is in the downloaded MERGE_HEAD but not in HEAD.\n\n> > 2) Export of individual patches. \"bk export -tpatch -r1.2345\"\n> > I have nu public git repository yet so I have to feed changes as\n> > plain patches. Browsing cg-* I did not find the command to do this.\n> \n> cg-diff -p -r SHA1\n\nAnd again, without the porcelain this is:\n\n\tgit-diff-tree -v -p <name>\n\n(Basically, you can do _anything_ with \"git-diff-tree\". For example, you \nwant \"cg log\"? Do\n\n\tgit-rev-list HEAD | git-diff-tree --stdin -v -m -s\n\nwhich is basically what \"git-whatchanged\" does).\n\n\t\tLinus\n"},{"id":"3737","messageId":"42901840.5080002@tuxrocks.com","threadId":"687","inReplyTo":"2765.10.10.10.24.1116713164.squirrel@linux1","subject":"Re: cogito - how do I ???","fromName":"Frank Sorenson","fromEmail":"frank@tuxrocks.com","sentAt":"2005-05-22T05:27:28Z","receivedAt":"2005-05-22T05:27:28Z","isPatch":false,"sender":{"key":"frank@tuxrocks.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nSean wrote:\n> On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:\n> \n>>Hi all.\n>>\n>>While trying to get up to speed on cogito/git I stumbled across\n>>a few things that I at least did not find available in cogito.\n>>\n>>1) Something similar to \"bk changes -R\". I use this to see what has\n>>happened upstream - to see if I really want to merge stuff.\n> \n> \n> Not sure what bk did here, but you can do something like:\n> \n> cg-pull origin\n> cg-log -c -r origin\n> \n> To see what is at the head of the unmerged objects you just pulled down,\n> and if you want to merge then \"cg-merge origin\".  Although as far as I\n> know there's no way to have the log stop automatically at the proper spot.\n\nHere's what I use:\n\ncg-log -c -f -r :origin\n\n- -c = colorize the output\n- -f = list files affected\n- -r :origin = only display this range (equivalent to \"-r HEAD:origin\")\n\nFrank\n- --\nFrank Sorenson - KD7TZK\nSystems Manager, Computer Science Department\nBrigham Young University\nfrank@tuxrocks.com\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.6 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFCkBhAaI0dwg4A47wRAtrdAJ9Hy/H4BNurGd+Ukjtz+0+6sUDIkgCdHJIr\nKnponX5ITXEDe/r+0dAOmqc=\n=jaNR\n-----END PGP SIGNATURE-----\n"},{"id":"3742","messageId":"20050522071435.GA10681@mars.ravnborg.org","threadId":"687","inReplyTo":"Pine.LNX.4.58.0505211635440.2206@ppc970.osdl.org","subject":"Re: cogito - how do I ???","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-05-22T07:14:35Z","receivedAt":"2005-05-22T07:14:35Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> > > 1) Something similar to \"bk changes -R\". I use this to see what has\n> > > happened upstream - to see if I really want to merge stuff.\n> > \n> > Not sure what bk did here, but you can do something like:\n> > \n> > cg-pull origin\n> > cg-log -c -r origin\n> \n> In the raw git interfaces, you'd basically have to do the same thing that\n> \"git-pull-script\" does, except that _instead_ of calling the\n> git-resolve-script thing, you'd do\n> \n> \tgit-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin\nThat looks ... long.\nI can teach my fingers to use: cg-log, but the above is just too much \nto type/remeber do a daily operation.\n\nIn bk the usage pattern was to check what was in mainline _before_\nfetching and merging. So it seems that with git/cogoto one\nhas to fetch the chages, inspect them, and then decide to apply or not.\n\nWhen the fetches changes stay in MERGE_HEAD I assume my work when\ncommitted will be based on top of HEAD - so I do not have to know\nif I have fetched some (unmerged) updates.\n\n> to show what is in the downloaded MERGE_HEAD but not in HEAD.\n> \n> > > 2) Export of individual patches. \"bk export -tpatch -r1.2345\"\n> > > I have nu public git repository yet so I have to feed changes as\n> > > plain patches. Browsing cg-* I did not find the command to do this.\n> > \n> > cg-diff -p -r SHA1\n> \n> And again, without the porcelain this is:\n> \n> \tgit-diff-tree -v -p <name>\n\nThe key here is the SHA1. I hoped to avoid specifying SHA1's with\ncogito, I so often miss one character when doing copy'n'paste.\n\n\nThanks all for the replies. Now I feel a bit more confident in this.\n\n\n\tSam\n"},{"id":"3749","messageId":"Pine.LNX.4.58.0505220908290.2307@ppc970.osdl.org","threadId":"687","inReplyTo":"20050522071435.GA10681@mars.ravnborg.org","subject":"Re: cogito - how do I ???","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-22T16:23:30Z","receivedAt":"2005-05-22T16:23:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 22 May 2005, Sam Ravnborg wrote:\n>\n> > > > 1) Something similar to \"bk changes -R\". I use this to see what has\n> > > > happened upstream - to see if I really want to merge stuff.\n> > > \n> > > Not sure what bk did here, but you can do something like:\n> > > \n> > > cg-pull origin\n> > > cg-log -c -r origin\n> > \n> > In the raw git interfaces, you'd basically have to do the same thing that\n> > \"git-pull-script\" does, except that _instead_ of calling the\n> > git-resolve-script thing, you'd do\n> > \n> > \tgit-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin\n> That looks ... long.\n\nThat's why people don't generally use git natively. \n\nI want teach people what the \"raw\" interfaces are not because you're \nsupposed to use them, but because I expect that the raw ones are useful \nfor scripting.\n\n> In bk the usage pattern was to check what was in mainline _before_\n> fetching and merging.\n\nIn git (and cogito, although it's less obvious), the \"fetching\" is totally \nseparate from the \"merging\". In BK, the two were the same - you couldn't \nmerge without fetching, and you couldn't fetch without merging.\n\n> So it seems that with git/cogoto one has to fetch the chages, inspect\n> them, and then decide to apply or not.\n\nWell, that's really what you ended up largely doing in BK too, since even\nif it _looks_ like you first inspect them with \"bk changes -R\", the fact\nis, in order to do that, you do have to _fetch_ the data first. It's just\nthat BK (a) fetched just the changeset changes (I think) and (b) then\nthrew the data away.\n\nWith git, you can also do the \"fetch just the changeset changes\", since if \nyou use \"git-http-pull\" you can instruct it to first _only_ fetch the \nactual commits, and forget about the actual data. But since git considers \n\"fetching\" and \"merging\" totally separate phases, it's up to your scripts \nwhether they leave the objects around or not afterwards. The normal \noperaion is to leave everything around, since that means that if/when you \ndo decide to merge, you already have the data, and you don't need to \nre-fetch.\n\nIf you decide to throw it away, you first remove the reference to the\nstuff you pulled, and then use \"git-prune-script\" to get rid of the\nobjects you used. Right now that is admittedly quite expensive, it's\nconsidered a \"rare\" thing to do (sicne even if you decide not to merge,\nthe extra objects never hurt - you can prune things once a week if you\ncare).\n\n> When the fetches changes stay in MERGE_HEAD I assume my work when\n> committed will be based on top of HEAD - so I do not have to know\n> if I have fetched some (unmerged) updates.\n\nYes. Note that MERGE_HEAD ends up being just a totally temporary reference\nto the top (that you decided not to merge). It has no meaning for git\nitself, and the naming and meaning is purely as a git-pull-script (and\ngit-resolve-script) internal temporary thing.\n\n> > And again, without the porcelain this is:\n> > \n> > \tgit-diff-tree -v -p <name>\n> \n> The key here is the SHA1. I hoped to avoid specifying SHA1's with\n> cogito, I so often miss one character when doing copy'n'paste.\n\nYou don't have to use the raw SHA1. git understands tags and references, \nso for example, if you take the \"fetch\" part of git-pull-script (I really \nshould split it up into \"git-fetch-script\"), then you can, for example, do\n\n\tgit-diff-tree -v -p MERGE_HEAD\n\nto see the top of the (unmerged) thing. Similarly, doing a\n\n\tgit-rev-list MERGE_HEAD | git-diff-tree --stdin -v -s\n\nwill give you the changelog for the unmerged side. No SHA1's necessary.\n\nOf course, if you don't have a reference to the thing you want to look at, \nyou do need to figure out the SHA1 some way. But for example, gitk will \nwork fine for the unmerged stuff too - ie you can do\n\n\tgitk MERGE_HEAD ^HEAD\n\n_before_ you merge, and get all the nice graphical tools to inspect what \nthe hell there is that is new there..\n\nNotice how this \"fetch is independent of merge\" thing thus means that you \ncan do a lot _more_ than \"bk changes -R\" ever did. But yes, it's a bit \nmore complex too (so normally you'd probably only use the porcelain \nlayer).\n\n\t\tLinus\n"},{"id":"3796","messageId":"20050523071919.GG23388@cip.informatik.uni-erlangen.de","threadId":"687","inReplyTo":"Pine.LNX.4.58.0505211635440.2206@ppc970.osdl.org","subject":"Re: cogito - how do I ???","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-23T07:19:19Z","receivedAt":"2005-05-23T07:19:19Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello Linus,\n\n> \tgit-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin\n\nThis doesn't work for me:\n\n(faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97\n1116799695 2cb45e95438c113871fbbea5b4f629f9463034e7:1 09d74b3b5ac634495e17b92b2b785fa996ffce97:3\n(faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97 | git-diff-tree -v -m -s --stdin\n(faui00u) [~/work/git/git]\n\nBit this does:\n\n(faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97 | awk '{print $2'} | sed 's#:.*##' | git-diff-tree -v -m -s --stdin\n\nwas that a typo or is git-diff-tree supposed to handle the output of\ngit-rev-tree as well and it is a bug?\n\n\tThomas\n"},{"id":"3800","messageId":"7v64xa75l3.fsf@assigned-by-dhcp.cox.net","threadId":"687","inReplyTo":"20050523071919.GG23388@cip.informatik.uni-erlangen.de","subject":"Re: cogito - how do I ???","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-23T07:40:40Z","receivedAt":"2005-05-23T07:40:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"TG\" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:\n\n>> git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin\n\nTG> This doesn't work for me:\n\nIt should not.  \"diff-tree --stdin\" expects the line to begin\nwith an SHA1 and it either takes (1) one SHA1 followed by one\nspace followed by another SHA1 potentially followed by garbage\ntil the newline, or (2) one SHA1 potentially followed by garbage\ntil the newline.  rev-tree has the timestamp at the beginning\nwhich does not match either of them.  What you are doing with\nawk should work, so should this:\n\n  git-rev-tree MH ^H | sed -e 's/^[0-9]* //' | git-diff-tree --stdin ...\n\n\n"},{"id":"3802","messageId":"20050523080222.GH23388@cip.informatik.uni-erlangen.de","threadId":"687","inReplyTo":"7v64xa75l3.fsf@assigned-by-dhcp.cox.net","subject":"Re: cogito - how do I ???","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-23T08:02:22Z","receivedAt":"2005-05-23T08:02:22Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> It should not.  \"diff-tree --stdin\" expects the line to begin\n> with an SHA1 and it either takes (1) one SHA1 followed by one\n> space followed by another SHA1 potentially followed by garbage\n> til the newline, or (2) one SHA1 potentially followed by garbage\n> til the newline.  rev-tree has the timestamp at the beginning\n> which does not match either of them.  What you are doing with\n> awk should work, so should this:\n\nthanks for the clarification.\n\n>   git-rev-tree MH ^H | sed -e 's/^[0-9]* //' | git-diff-tree --stdin ...\n\nThis is very usefull with a 'pull only' mode.\n\nThanks,\n\tThomas\n"},{"id":"3805","messageId":"Pine.LNX.4.58.0505230731430.2307@ppc970.osdl.org","threadId":"687","inReplyTo":"20050523071919.GG23388@cip.informatik.uni-erlangen.de","subject":"Re: cogito - how do I ???","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-23T14:35:47Z","receivedAt":"2005-05-23T14:35:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 May 2005, Thomas Glanzmann wrote:\n> \n> > \tgit-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin\n> \n> This doesn't work for me:\n\nYeah, I'm an idiot.\n\n> Bit this does:\n> \n> (faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97 | awk '{print $2'} | sed 's#:.*##' | git-diff-tree -v -m -s --stdin\n> \n> was that a typo or is git-diff-tree supposed to handle the output of\n> git-rev-tree as well and it is a bug?\n\nIt was me just forgetting about the time thing in rev-tree, forcing you to\nhave a second phase there (I usually use just \"cut -d' ' -f2\" - the input\n_can_ have the \":n\" flag thing that rev-tree outputs, and git-diff-tree\nwill just ignore it).\n\nI actually suspect that whole time thing was a mistake, it seemed sensible \nback when we didn't have any other way of ordering the changesets well, \nbut it's really a bad ordering anyway to do it by time (ie add a \"sort \n-rn\" in there), and we can (and probably should) order rev-tree output \nwith some topological sort based on the commit tree.\n\n\t\tLinus\n"},{"id":"3807","messageId":"7v1x7x7vf4.fsf@assigned-by-dhcp.cox.net","threadId":"687","inReplyTo":"Pine.LNX.4.58.0505230731430.2307@ppc970.osdl.org","subject":"Re: cogito - how do I ???","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-23T16:34:55Z","receivedAt":"2005-05-23T16:34:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds <torvalds@osdl.org> writes:\n\nLT> ..., and we can (and probably should) order rev-tree output \nLT> with some topological sort based on the commit tree.\n\nSeconded.\n\n"},{"id":"3837","messageId":"E1DaP7k-0007ar-00@gondolin.me.apana.org.au","threadId":"687","inReplyTo":"Pine.LNX.4.58.0505230731430.2307@ppc970.osdl.org","subject":"Re: cogito - how do I ???","fromName":"Herbert Xu","fromEmail":"herbert@gondor.apana.org.au","sentAt":"2005-05-24T02:26:28Z","receivedAt":"2005-05-24T02:26:28Z","isPatch":false,"sender":{"key":"herbert@gondor.apana.org.au","avatar":null},"body":"Linus Torvalds <torvalds@osdl.org> wrote:\n> \n> I actually suspect that whole time thing was a mistake, it seemed sensible \n> back when we didn't have any other way of ordering the changesets well, \n> but it's really a bad ordering anyway to do it by time (ie add a \"sort \n> -rn\" in there), and we can (and probably should) order rev-tree output \n> with some topological sort based on the commit tree.\n\nYes please.  Can we also have a rev-* command that outputs parent\nrelations instead of a simple list? That is,\n\n<tree-1> <parent-1>\n<tree-1> <parent-2>\n<tree-2> <parent-3>\n...\n\nThen you could just run tsort for rev-tree, plus you could use this\nfor other things like finding merges.\n\nCheers,\n-- \nVisit Openswan at http://www.openswan.org/\nEmail: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>\nHome Page: http://gondor.apana.org.au/~herbert/\nPGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt\n"},{"id":"3838","messageId":"Pine.LNX.4.58.0505232000400.2307@ppc970.osdl.org","threadId":"687","inReplyTo":"E1DaP7k-0007ar-00@gondolin.me.apana.org.au","subject":"Re: cogito - how do I ???","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-24T03:05:24Z","receivedAt":"2005-05-24T03:05:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 May 2005, Herbert Xu wrote:\n> \n> Yes please.  Can we also have a rev-* command that outputs parent\n> relations instead of a simple list? That is,\n> \n> <tree-1> <parent-1>\n> <tree-1> <parent-2>\n> <tree-2> <parent-3>\n\nThat's not <tree-n>, it's <commit-n>.\n\nI think that would be \"git-rev-list --parents\" or something - that \nwouldn't impact any existing users.\n\nPatches welcome.\n\nAs to git-rev-tree, that's likely used by scripts in various places \n(cogito, gitk, gitweb etc), so changing that is nastier, but at least the \noutput could be _sorted_ better.\n\nOf course, I really think that the bigger problem with git-rev-tree\ncurrently is that global reachability analysis, which is just not\nacceptable performance-wise.\n\n\t\tLinus\n"}]}