{"thread":{"id":"30389","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","startedAt":"2012-05-02T02:58:46Z","lastAt":"2012-05-03T02:06:29Z","messageCount":9,"participants":["Linus Torvalds","Stephen Rothwell","Junio C Hamano","Steven Rostedt","Jakub Narebski","Nguyen Thai Ngoc Duy"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"190516","messageId":"CA+55aFy02d13HkfwY-TEGwu=2cd8en+_rnrnwcwixGKRmdJRtA@mail.gmail.com","threadId":"30389","inReplyTo":"20120502004439.965120020@goodmis.org","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2012-05-02T02:58:46Z","receivedAt":"2012-05-02T02:58:46Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, May 1, 2012 at 5:44 PM, Steven Rostedt wrote:\n>\n> Is git set up to not fast forward by default? (I need to give it another try)\n\nGit will fast-forward by default if you do a pull and there is no\ndevelopment of your own in your tree.\n\nThere are two exceptions:\n\n - you explicitly say that you don't want to fast-forward (--no-ff or\n\"[merge] ff=false\" in the git config file)\n\n - if you pull a signed tag with a modern version of git.\n\nThat second case may be what you hit.\n\nIf you do a\n\n git pull linus v3.4-rc5\n\nin order to just update to the state of my latest tag, then git will\nassume you want to do a new commit (and thus a non-fast-forward) just\nso that git can record the tag signature in the commit.\n\nThe sad part is that I don't think you can even override the second\ncase. IOW, I think even \"git pull --ff linus v3.4-rc5\" will still do a\nnon-fast-forward merge.\n\nThat's inconvenient, and an unintended consequence of the behavior I\nwanted as a top-level maintainer. But I really do think it's wrong for\nnormal developers who might validly just want to update to some\nparticular tagged release.\n\nJunio? Any ideas?\n\n Linus\n"},{"id":"190517","messageId":"20120502133023.07e16a8681b8924afc47e4e0@canb.auug.org.au","threadId":"30389","inReplyTo":"CA+55aFy02d13HkfwY-TEGwu=2cd8en+_rnrnwcwixGKRmdJRtA@mail.gmail.com","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Stephen Rothwell","fromEmail":"sfr@canb.auug.org.au","sentAt":"2012-05-02T03:30:23Z","receivedAt":"2012-05-02T03:30:23Z","isPatch":true,"sender":{"key":"sfr@canb.auug.org.au","avatar":null},"body":"Hi Linus,\n\nOn Tue, 1 May 2012 19:58:46 -0700 Linus Torvalds wrote:\n>\n> The sad part is that I don't think you can even override the second\n> case. IOW, I think even \"git pull --ff linus v3.4-rc5\" will still do a\n> non-fast-forward merge.\n\ngit merge v3.4-rc5^{commit}\n\nworks, but that doesn't work for \"git pull\" :-( I tend to \"fetch and\nmerge\" rather than pull ...\n\n-- \nCheers,\nStephen Rothwell sfr@canb.auug.org.au\nhttp://www.canb.auug.org.au/~sfr/\n"},{"id":"190518","messageId":"7v62cf6y3d.fsf@alter.siamese.dyndns.org","threadId":"30389","inReplyTo":"CA+55aFy02d13HkfwY-TEGwu=2cd8en+_rnrnwcwixGKRmdJRtA@mail.gmail.com","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-02T03:49:58Z","receivedAt":"2012-05-02T03:49:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> If you do a\n>\n> git pull linus v3.4-rc5\n>\n> in order to just update to the state of my latest tag, then git will\n> assume you want to do a new commit (and thus a non-fast-forward) just\n> so that git can record the tag signature in the commit.\n>\n> The sad part is that I don't think you can even override the second\n> case.\n> ...\n> That's inconvenient, and an unintended consequence of the behavior I\n> wanted as a top-level maintainer. But I really do think it's wrong for\n> normal developers who might validly just want to update to some\n> particular tagged release.\n>\n> Junio? Any ideas?\n\n\"Ideas\" meaning \"recipe to do with deployed binaries\"?\n\nWhen a normal developer wants to _reset to_ a particular tagged release,\nin order to _start_ new work, she wouldn't be doing even the above \"git\npull linus v3.4-rc5\". That will contaminate the result with whatever\nrandom stuff she happened to have on the current branch. A more natural\nsequence would be \"git fetch --tags linus\" followed by either\n\n git checkout v3.4-rc5 ;# to detach\n\nor\n\n git checkout -b mywork v3.4-rc5 ;# to start\n\nSo the case to \"reset to\" is not very interesting.\n\nBut when a normal developer wants to _sync to_ a particular tagged\nrelease, in order to _continue_ working on her topic, she would need to\nhave a merge (unless she does not have _anything_ herself), and at that\npoint, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a\ndifference. If she absolutely detests the \"mergetag\" header, she could do\na \"git fetch --tags linus\" followed by\n\n\tgit merge v3.4-rc5^0\n\nwhich admittedly is two more letters than she used to type.\n\nIf you mean by \"Ideas\" for additional features, obviously the last step\ncould be enhanced to use a more intuitive command line that requires the\nuser to type even more, i.e.\n\n\tgit merge --ff v3.4-rc5\n\nOnce that is done, \"git pull --ff linus v3.4-rc5\" would fall out as a\nlogical consequence.\n\nBut obviously these two would need new code ;-)\n"},{"id":"190550","messageId":"1335966292.14207.40.camel@gandalf.stny.rr.com","threadId":"30389","inReplyTo":"7v62cf6y3d.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2012-05-02T13:44:52Z","receivedAt":"2012-05-02T13:44:52Z","isPatch":true,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n\n> When a normal developer wants to _reset to_ a particular tagged release,\n> in order to _start_ new work, she wouldn't be doing even the above \"git\n> pull linus v3.4-rc5\". That will contaminate the result with whatever\n> random stuff she happened to have on the current branch. A more natural\n> sequence would be \"git fetch --tags linus\" followed by either\n> \n> git checkout v3.4-rc5 ;# to detach\n\nThe problem is, I like to know what has been pulled into mainline. I\nhave patches in quilt (for ktest only, not for my other work) and will\nstart adding them on a \"clean\" release. By doing a git pull (or fetch\nand merge), I like to see the fast forward to know if everything that's\nin my current branch has been pulled. If it hasn't, then something may\nhave been missed.\n\n> \n> or\n> \n> git checkout -b mywork v3.4-rc5 ;# to start\n\nBut then I would end up with several branches that would require\ndeleting. One way I could see myself in handling this case would be to\ndelete the current branch and start again (thinking that everything was\nalready pulled). But by doing that, if something wasn't pulled in, then\nI would have lost those changes without ever knowing.\n\n> \n> So the case to \"reset to\" is not very interesting.\n> \n> But when a normal developer wants to _sync to_ a particular tagged\n> release, in order to _continue_ working on her topic, she would need to\n> have a merge (unless she does not have _anything_ herself), and at that\n> point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a\n> difference. If she absolutely detests the \"mergetag\" header, she could do\n> a \"git fetch --tags linus\" followed by\n> \n> \tgit merge v3.4-rc5^0\n> \n> which admittedly is two more letters than she used to type.\n\nThis would fit into my workflow. Thus I could use this.\n\n> \n> If you mean by \"Ideas\" for additional features, obviously the last step\n> could be enhanced to use a more intuitive command line that requires the\n> user to type even more, i.e.\n> \n> \tgit merge --ff v3.4-rc5\n> \n> Once that is done, \"git pull --ff linus v3.4-rc5\" would fall out as a\n> logical consequence.\n> \n> But obviously these two would need new code ;-)\n\nThe -ff would make sense as it seems to be the logical thing a user\nwould want. If they specify the fast-forward flag, then the user would\nexpect the merge to be a fast forward if possible.\n\nBTW, is there a git compare type option. That is, I like to compare two\nseparate branches with the result that one currently gets with git when\na branch is following another branch. When you check out that branch, it\ngives you an update on how those two branches are related (is one a fast\nforward of the other, are they off by different commits?). It would be\nnice if git could do this with any two branches. I wrote a script to do\nthis for me (attached) but it would be nice if git had it natively.\n\n$ git-branch-status v3.0.4 v3.0.5 \nBranch v3.0.4 can be fast forward to v3.0.5 in 240 commits\n\n$ git-branch-status v3.0.4 v3.1 \nBranch v3.0.4 and v3.1\ndiffer by 257 and 9380 commit(s) respectively\n\n\n-- Steve\n"},{"id":"190596","messageId":"7vsjfigx23.fsf@alter.siamese.dyndns.org","threadId":"30389","inReplyTo":"1335966292.14207.40.camel@gandalf.stny.rr.com","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-02T20:14:28Z","receivedAt":"2012-05-02T20:14:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Rostedt writes:\n\n> On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:\n>> Linus Torvalds writes:\n>> \n>\n>> When a normal developer wants to _reset to_ a particular tagged release,...\n>\n> The problem is,...\n> But then I would end up with ...\n\n[comments on the part I declared \"uninteresting\" snipped]\n\n>> So the case to \"reset to\" is not very interesting.\n\n>> But when a normal developer wants to _sync to_ a particular tagged\n>> release, in order to _continue_ working on her topic, she would need to\n>> have a merge (unless she does not have _anything_ herself), and at that\n>> point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a\n>> difference. If she absolutely detests the \"mergetag\" header, she could do\n>> a \"git fetch --tags linus\" followed by\n>> \n>> \tgit merge v3.4-rc5^0\n>> \n>> which admittedly is two more letters than she used to type.\n>\n> This would fit into my workflow. Thus I could use this.\n\nOK.\n\n>> If you mean by \"Ideas\" for additional features, obviously the last step\n>> could be enhanced to use a more intuitive command line that requires the\n>> user to type even more, i.e.\n>> \n>> \tgit merge --ff v3.4-rc5\n>> \n>> Once that is done, \"git pull --ff linus v3.4-rc5\" would fall out as a\n>> logical consequence.\n>> \n>> But obviously these two would need new code ;-)\n>\n> The -ff would make sense as it seems to be the logical thing a user\n> would want. If they specify the fast-forward flag, then the user would\n> expect the merge to be a fast forward if possible.\n\nOK. Sounds like a good janitor project we could try to find a volunteer\non ;-).\n\n> BTW, is there a git compare type option. That is, I like to compare two\n> separate branches with the result that one currently gets with git when\n> a branch is following another branch. When you check out that branch, it\n> gives you an update on how those two branches are related (is one a fast\n> forward of the other, are they off by different commits?). It would be\n> nice if git could do this with any two branches. I wrote a script to do\n> this for me (attached) but it would be nice if git had it natively.\n>\n> $ git-branch-status v3.0.4 v3.0.5 \n> Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits\n>\n> $ git-branch-status v3.0.4 v3.1 \n> Branch v3.0.4 and v3.1\n> differ by 257 and 9380 commit(s) respectively\n\nI personally do not think \"257 and 9380\" vs \"15 and 400\" totally\nuninteresting, in the sense that the absolute numbers do not matter much,\nand the only question that matter is \"Is everything in this one included\nin the other?\" and I just say \"git lgf master..topic\" (where I have in my\n$HOME/.gitconfig \"[alias] lgf = log --oneline --boundary --first-parent\"\ndefined) to see the list of commits on a topic, with the indication of\nwhere the topic forked from. Obviously it takes the \"never merge mainline\ninto topics\" discipline for it to be useful.\n\nI also use \"git show-branch $A $B $C...\" for something like this but that\nis only useful when these branches are known to have only a handful of\ncommits on their own, and its output is not very suited if they have\nhundreds of commits.\n"},{"id":"190607","messageId":"1336003655.14207.71.camel@gandalf.stny.rr.com","threadId":"30389","inReplyTo":"7vsjfigx23.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2012-05-03T00:07:35Z","receivedAt":"2012-05-03T00:07:35Z","isPatch":true,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"On Wed, 2012-05-02 at 13:14 -0700, Junio C Hamano wrote:\n> Steven Rostedt writes:\n> \n> > On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:\n> >> Linus Torvalds writes:\n> >> \n> >\n> >> When a normal developer wants to _reset to_ a particular tagged release,...\n> >\n> > The problem is,...\n> > But then I would end up with ...\n> \n> [comments on the part I declared \"uninteresting\" snipped]\n\nJust have to snip it, you don't need to declare it uninteresting.\n\n\n> > $ git-branch-status v3.0.4 v3.0.5 \n> > Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits\n> >\n> > $ git-branch-status v3.0.4 v3.1 \n> > Branch v3.0.4 and v3.1\n> > differ by 257 and 9380 commit(s) respectively\n> \n> I personally do not think \"257 and 9380\" vs \"15 and 400\" totally\n> uninteresting, in the sense that the absolute numbers do not matter much,\n\nI disagree here. Maybe it's because of the example I used. Here's a more\nappropriate one:\n\nI usually work against the tip.git tree for my kernel work (not ktest),\nand I have several branches for different things I work on. I\nperiodically rebase against the latest tip branch to make sure\neverything works (these development branches are only local to my own\nmachines, not public). Sometimes I forget what I pushed forward and\nwhere I left off. I'll make a branch off of another branch's commit and\npush that, and continue developing. But I rebase the new stuff and test\nit before pushing it again. So I have something like this:\n\n$ git-branch-status tip/perf/core\nBranch HEAD and tip/perf/core\ndiffer by 15 and 644 commit(s) respectively\n\nHere it shows that this branch has 15 patches that are pending. I'll\nusually rebase against tip/perf/core, run a bunch of tests, and then\npush it out when ready.\n\nI'll continue to work on this branch and add more patches. But because\nother people may add things to tip/perf/core that affect me, I need to\nrebase once in a while. But I also check to see if the previous push was\nin, and I use my script git-branch-status on a daily basis. Lets me know\nwhat patches I need to look at. Maybe it's not that important, but I\nfind it useful in my everyday workflow.\n\n> and the only question that matter is \"Is everything in this one included\n> in the other?\" and I just say \"git lgf master..topic\" (where I have in my\n> $HOME/.gitconfig \"[alias] lgf = log --oneline --boundary --first-parent\"\n> defined) to see the list of commits on a topic, with the indication of\n> where the topic forked from. Obviously it takes the \"never merge mainline\n> into topics\" discipline for it to be useful.\n> \n> I also use \"git show-branch $A $B $C...\" for something like this but that\n> is only useful when these branches are known to have only a handful of\n> commits on their own, and its output is not very suited if they have\n> hundreds of commits.\n\n\nIf I'm the only one that finds this feature useful, then I'm happy with\njust using my script. It works well and I have it on all my boxes. I\njust wanted to show others in case I'm not the only one that finds this\ninformation useful.\n\nI just thought it would be easy to implement as git already does this\ncheck. I liked what I saw from git that I based my output of this script\non it. In fact, I just saw it today:\n\n$ git checkout trace/rfc/tracing/fentry\nSwitched to branch 'trace/rfc/tracing/fentry'\nYour branch and 'ftrace/rfc/tracing/fentry' have diverged,\nand have 65913 and 4 different commit(s) each, respectively.\n\n\nI'll throw in one more feature request, that you can take or leave (I\nhave another script for it ;-), something that does a listing of\nbranches in order of date. I have over a hundred branches in my repo,\nand I forget which branch was the last one I was working on. So I\ncreated a script called git-ls (attached).\n\nHere's what the output looks like:\n\n$ git-ls | tail\n681d1c4 2012-04-19 trace/tip/perf/urgent tracing: Fix stacktrace of latency tracers (irqsoff and friends)\n59cfede 2012-04-19 trace/rfc/iolatency tracing: Add iolatency tracer\n61463fa 2012-04-24 trace/tip/perf/core ftrace/x86: Remove the complex ftrace NMI handling code\ne201738 2012-04-26 trace/tip/perf/core-2 ftrace/x86: Remove the complex ftrace NMI handling code\n053cef1 2012-04-27 trace/rfc/tracing/fentry ftrace/x86: Add support for -mfentry to x86_64\n4a6d70c 2012-04-27 trace/tip/perf/core-3 ftrace/x86: Remove the complex ftrace NMI handling code\na76c3eb 2012-04-30 trace/rfc/kprobes/ftrace ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer\n6e1b77e 2012-05-02 trace/rfc/kprobes/ftrace-v2 kprobes: Update header for ftrace optimization\na4cc5f1 2012-05-02 trace/tip/perf/next-2 ftrace/x86: Add separate function to save regs\n9bd8569 2012-05-02 trace/tip/perf/next trace: Make removal of ring buffer pages atomic\n\nIt lists the branches in order of date of last commit.\n\nAgain, just showing some things that I find useful. If no one else finds\nthese interesting, then just ignore it. I have my scripts :-)\n\n-- Steve\n\n"},{"id":"190608","messageId":"m3havyqf17.fsf@localhost.localdomain","threadId":"30389","inReplyTo":"1336003655.14207.71.camel@gandalf.stny.rr.com","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-05-03T00:33:44Z","receivedAt":"2012-05-03T00:33:44Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Rostedt writes:\n\n> I'll throw in one more feature request, that you can take or leave (I\n> have another script for it ;-), something that does a listing of\n> branches in order of date. I have over a hundred branches in my repo,\n> and I forget which branch was the last one I was working on. So I\n> created a script called git-ls (attached).\n> \n> Here's what the output looks like:\n> \n> $ git-ls | tail\n> 681d1c4 2012-04-19 trace/tip/perf/urgent tracing: Fix stacktrace of latency tracers (irqsoff and friends)\n> 59cfede 2012-04-19 trace/rfc/iolatency tracing: Add iolatency tracer\n> 61463fa 2012-04-24 trace/tip/perf/core ftrace/x86: Remove the complex ftrace NMI handling code\n> e201738 2012-04-26 trace/tip/perf/core-2 ftrace/x86: Remove the complex ftrace NMI handling code\n> 053cef1 2012-04-27 trace/rfc/tracing/fentry ftrace/x86: Add support for -mfentry to x86_64\n> 4a6d70c 2012-04-27 trace/tip/perf/core-3 ftrace/x86: Remove the complex ftrace NMI handling code\n> a76c3eb 2012-04-30 trace/rfc/kprobes/ftrace ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer\n> 6e1b77e 2012-05-02 trace/rfc/kprobes/ftrace-v2 kprobes: Update header for ftrace optimization\n> a4cc5f1 2012-05-02 trace/tip/perf/next-2 ftrace/x86: Add separate function to save regs\n> 9bd8569 2012-05-02 trace/tip/perf/next trace: Make removal of ring buffer pages atomic\n> \n> It lists the branches in order of date of last commit.\n> \n> Again, just showing some things that I find useful. If no one else finds\n> these interesting, then just ignore it. I have my scripts :-)\n\nWell, there is \"git branch -v -v\":\n\n $ git branch -v -v\n [...]\n gsoc2012-wiki 0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '\"Published\" and \"secret\" commits' project\n html 8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c\n i18n-po.pl aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations\n maint bf50515 Git 1.7.10.1\n [...]\n t/doc-config-extraction 451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages\n test b77178e gitweb: Separate features with no project specific override\n todo 10c7888 Meta/dodoc: assign default values\n user-manual 4c22f3d Comments to user-manual (WIP)\n\n\nI guess that git-for-each-ref could be extended with behind / ahead\ninformation, perhaps as modifiers to existing %(upstream) field...\n\nP.S. I would associate \"git ls\" with listing worktree files.\n\n-- \nJakub Narebski\n"},{"id":"190614","messageId":"1336009944.14207.74.camel@gandalf.stny.rr.com","threadId":"30389","inReplyTo":"m3havyqf17.fsf@localhost.localdomain","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2012-05-03T01:52:24Z","receivedAt":"2012-05-03T01:52:24Z","isPatch":true,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"On Wed, 2012-05-02 at 17:33 -0700, Jakub Narebski wrote:\n> Steven Rostedt writes:\n\n> Well, there is \"git branch -v -v\":\n> \n> $ git branch -v -v\n> [...]\n> gsoc2012-wiki 0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '\"Published\" and \"secret\" commits' project\n> html 8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c\n> i18n-po.pl aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations\n> maint bf50515 Git 1.7.10.1\n> [...]\n> t/doc-config-extraction 451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages\n> test b77178e gitweb: Separate features with no project specific override\n> todo 10c7888 Meta/dodoc: assign default values\n> user-manual 4c22f3d Comments to user-manual (WIP)\n> \n> \n> I guess that git-for-each-ref could be extended with behind / ahead\n> information, perhaps as modifiers to existing %(upstream) field...\n\nWould that list them in order then? Also, having the date printed is\nuseful, as I sometimes remember the approximate date a I worked on\nsomething.\n\n\n> \n> P.S. I would associate \"git ls\" with listing worktree files.\n> \n\nYeah, I agree. I just wanted a script that had a short and easy name ;-)\n\ngit branch-sort\n\nwould probably be a better name.\n"},{"id":"190620","messageId":"CACsJy8Dd-Nwcet+jZ6bPwNoOVXgRqTPOvOLswqAa_eO5tBDxGQ@mail.gmail.com","threadId":"30389","inReplyTo":"m3havyqf17.fsf@localhost.localdomain","subject":"Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-05-03T02:06:29Z","receivedAt":"2012-05-03T02:06:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 3, 2012 at 7:33 AM, Jakub Narebski wrote:\n> Steven Rostedt writes:\n>\n>> I'll throw in one more feature request, that you can take or leave (I\n>> have another script for it ;-), something that does a listing of\n>> branches in order of date. I have over a hundred branches in my repo,\n>> and I forget which branch was the last one I was working on. So I\n>> created a script called git-ls (attached).\n>>\n>> Here's what the output looks like:\n>>\n>> $ git-ls | tail\n>> 681d1c4    2012-04-19    trace/tip/perf/urgent                         tracing: Fix stacktrace of latency tracers (irqsoff and friends)\n>> 59cfede    2012-04-19    trace/rfc/iolatency                           tracing: Add iolatency tracer\n>> 61463fa    2012-04-24    trace/tip/perf/core                           ftrace/x86: Remove the complex ftrace NMI handling code\n>> e201738    2012-04-26    trace/tip/perf/core-2                         ftrace/x86: Remove the complex ftrace NMI handling code\n>> 053cef1    2012-04-27    trace/rfc/tracing/fentry                      ftrace/x86: Add support for -mfentry to x86_64\n>> 4a6d70c    2012-04-27    trace/tip/perf/core-3                         ftrace/x86: Remove the complex ftrace NMI handling code\n>> a76c3eb    2012-04-30    trace/rfc/kprobes/ftrace                      ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer\n>> 6e1b77e    2012-05-02    trace/rfc/kprobes/ftrace-v2                   kprobes: Update header for ftrace optimization\n>> a4cc5f1    2012-05-02    trace/tip/perf/next-2                         ftrace/x86: Add separate function to save regs\n>> 9bd8569    2012-05-02    trace/tip/perf/next                           trace: Make removal of ring buffer pages atomic\n>>\n>> It lists the branches in order of date of last commit.\n>>\n>> Again, just showing some things that I find useful. If no one else finds\n>> these interesting, then just ignore it. I have my scripts :-)\n>\n> Well, there is \"git branch -v -v\":\n>\n>  $ git branch -v -v\n>  [...]\n>    gsoc2012-wiki                  0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '\"Published\" and \"secret\" commits' project\n>    html                           8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c\n>    i18n-po.pl                     aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations\n>    maint                          bf50515 Git 1.7.10.1\n>  [...]\n>    t/doc-config-extraction        451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages\n>    test                           b77178e gitweb: Separate features with no project specific override\n>    todo                           10c7888 Meta/dodoc: assign default values\n>    user-manual                    4c22f3d Comments to user-manual (WIP)\n>\n>\n> I guess that git-for-each-ref could be extended with behind / ahead\n> information, perhaps as modifiers to existing %(upstream) field...\n\nThere's also a patch that adds sorting support to \"git branch\":\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/188705\n-- \nDuy\n"}]}