{"thread":{"id":"17231","subject":"[PATCH] bash: offer to show (un)staged changes","startedAt":"2009-01-18T00:56:24Z","lastAt":"2009-02-03T18:11:21Z","messageCount":22,"participants":["Thomas Rast","Junio C Hamano","Shawn O. Pearce","Martin Langhoff","Mike Hommey","Boyd Stephen Smith Jr.","Tuncer Ayaz"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"100899","messageId":"1232240184-10906-1-git-send-email-trast@student.ethz.ch","threadId":"17231","inReplyTo":null,"subject":"[PATCH] bash: offer to show (un)staged changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-01-18T00:56:24Z","receivedAt":"2009-01-18T00:56:24Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Add a bit of code to __git_ps1 that lets it append '*' to the branch\nname if there are any uncommitted changes, and '+' if there are any\nstaged changes.\n\nSince this is a rather expensive operation and will force a lot of\ndata into the cache whenever you first enter a repository, you have to\nenable it manually by setting GIT_PS1_EXPENSIVE to something nonempty.\n\nSigned-off-by: Thomas Rast \n---\n\nI came up with this after sending two incomplete patches on the same\nnight, and really like it. Perhaps others might find it useful.\n\nOf course it would be brilliant if there were a way to ask the kernel\nif a certain directory is cached, but I couldn't find one, let alone\none accessible from the shell.\n\n\n contrib/completion/git-completion.bash | 21 +++++++++++++++++++--\n 1 files changed, 19 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex f8b845a..36ea528 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -34,6 +34,10 @@\n # are currently in a git repository. The %s token will be\n # the name of the current branch.\n #\n+#\tIn addition, if you set GIT_PS1_EXPENSIVE to a nonempty value,\n+#\tunstaged (*) and staged (+) changes will be shown next to the\n+#\tbranch name.\n+#\n # To submit patches:\n #\n # *) Read Documentation/SubmittingPatches\n@@ -116,10 +120,23 @@ __git_ps1 ()\n \t\t\tfi\n \t\tfi\n \n+\t\tlocal w\n+\t\tlocal i\n+\n+\t\tif test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n+\t\t\tgit update-index --refresh >/dev/null 2>&1 || w=\"*\"\n+\t\t\tif git rev-parse --quiet --verify HEAD >/dev/null; then\n+\t\t\t\tgit diff-index --cached --quiet \\\n+\t\t\t\t\t--ignore-submodules HEAD -- || i=\"+\"\n+\t\t\telse\n+\t\t\t\ti=\"#\"\n+\t\t\tfi\n+\t\tfi\n+\n \t\tif [ -n \"${1-}\" ]; then\n-\t\t\tprintf \"$1\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \"$1\" \"${b##refs/heads/}$w$i$r\"\n \t\telse\n-\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$w$i$r\"\n \t\tfi\n \tfi\n }\n-- \ntg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)\n"},{"id":"100907","messageId":"7vwsct2xd1.fsf@gitster.siamese.dyndns.org","threadId":"17231","inReplyTo":"1232240184-10906-1-git-send-email-trast@student.ethz.ch","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-18T01:53:30Z","receivedAt":"2009-01-18T01:53:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> +\t\tif test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n> +\t\t\tgit update-index --refresh >/dev/null 2>&1 || w=\"*\"\n\nThis makes the feature unavailable for people who care about the stat\ndirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n"},{"id":"100910","messageId":"200901180306.40700.trast@student.ethz.ch","threadId":"17231","inReplyTo":"7vwsct2xd1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-01-18T02:06:38Z","receivedAt":"2009-01-18T02:06:38Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> Thomas Rast writes:\n> \n> > +\t\tif test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n> > +\t\t\tgit update-index --refresh >/dev/null 2>&1 || w=\"*\"\n> \n> This makes the feature unavailable for people who care about the stat\n> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n\nTrue, and I admit I didn't know there was an option to change that.\nOTOH git-diff-files doesn't normally update the index even if the\noption is set. Should I ask 'git diff --exit-code --raw' or some such\ninstead?\n\n(Why would people want to keep the stat info dirty even though there\nmay not have been any changes?)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n\n\n\n"},{"id":"100911","messageId":"7vvdsd1hur.fsf@gitster.siamese.dyndns.org","threadId":"17231","inReplyTo":"1232240184-10906-1-git-send-email-trast@student.ethz.ch","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-18T02:13:48Z","receivedAt":"2009-01-18T02:13:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> I came up with this after sending two incomplete patches on the same\n> night, and really like it. Perhaps others might find it useful.\n\nAny patch worth discussing (on this list at least) would need a nontrivial\ncommit log message that you need to really think while writing. It is\nnatural to assume people would be making them with their editor, not with\n\"commit -m\". These two incomplete patches could have been avoided if you\npaid attention to the status output that is in the commit log message\nbuffer. Perhaps we should make it even louder in some way?\n"},{"id":"100912","messageId":"200901180332.49489.trast@student.ethz.ch","threadId":"17231","inReplyTo":"7vvdsd1hur.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-01-18T02:32:07Z","receivedAt":"2009-01-18T02:32:07Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> Thomas Rast writes:\n> \n> > I came up with this after sending two incomplete patches on the same\n> > night, and really like it. Perhaps others might find it useful.\n> \n> Any patch worth discussing (on this list at least) would need a nontrivial\n> commit log message that you need to really think while writing. It is\n> natural to assume people would be making them with their editor, not with\n> \"commit -m\". These two incomplete patches could have been avoided if you\n> paid attention to the status output that is in the commit log message\n> buffer. Perhaps we should make it even louder in some way?\n\nActually I tend to write the commit (and message) sometime halfway\nthrough, and then amend the commit with fixes, docs and such, possibly\ntweaking the message if I need to. That night I just forgot to amend\nbefore format-patch, and there's no status message at that point which\ncould have reminded me. So the *+ display is just what I needed; it\nshows the status right before I get a chance to format-patch (or\nwhatever else command expects a commit).\n\n[As a side note, this kind of workflow is what will probably prevent\nme from working with any other SCM in the near future. I simply\ncannot imagine going back to a world without add -p, commit --amend\nand rebase -i.]\n\nThat being said, I never look at that status message; so far I've been\ntoo lazy to make my emacs add syntax highlighting there, and without\nit, it's just a big chunk of text. In fact, for most commits the 1-2\nfile names completely drown in the big chunk of surrounding,\ninvariant, instructions. If it becomes even louder in the ASCII\ndimension, that most likely means I'll just have to steer my eye away\nfrom it even harder to see the commit message I'm typing. Perhaps\nsome colours would help, I should really try that.\n\nOf course the real solution would be to hack less and sleep more, but\nwho would want to do that?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n\n"},{"id":"101145","messageId":"20090119172939.GA14053@spearce.org","threadId":"17231","inReplyTo":"7vwsct2xd1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-01-19T17:29:39Z","receivedAt":"2009-01-19T17:29:39Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Thomas Rast writes:\n> \n> > +\t\tif test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n> > +\t\t\tgit update-index --refresh >/dev/null 2>&1 || w=\"*\"\n> \n> This makes the feature unavailable for people who care about the stat\n> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n\nYup, and I'm one of those people who sets autorefresindex to false\nin my ~/.gitconfig, usually before I even have user.{name,email} set.\n\nI do like the idea of what Thomas is trying to do here, but its\nso bloody expensive to compute dirty state on every prompt in\nsome repositories that I'd shoot myself. E.g. WebKit is huge,\ncomputing the dirty state inside of the WebKit repository on each\nprompt would absolutely kill CLI performance to a point of it not\nbeing usuable. But git.git is small enough its OK on pretty much\neverything except Cygwin.\n\nSo as much as I'd like to use this without the update-index --refresh\nbit, I'm not sure its viable in every project out there. If we had\nan inotify sort of daemon to keep the data current so the prompt\ndoesn't have to stat every source file on every display it would\nbe reasonable, but we don't have such a thing yet for Git.\n\n-- \nShawn.\n"},{"id":"101154","messageId":"46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com","threadId":"17231","inReplyTo":"20090119172939.GA14053@spearce.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2009-01-19T18:00:10Z","receivedAt":"2009-01-19T18:00:10Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce wrote:\n> ... If we had\n> an inotify sort of daemon to keep the data current so the prompt\n> doesn't have to stat every source file on every display it would\n> be reasonable, but we don't have such a thing yet for Git.\n\nNote that inotify is not recursive and is a hog if you ask it to\nmonitor lots of dents.\n\nI am not convinced that an inotify-enabled git is a good idea for\nanything but small/mid-sized project. And such don't need it either.\n\nIn other words, the kernel's cache will outperform any userland\nattempting to keep track of the fs via inotify.\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"101157","messageId":"20090119181158.GH14053@spearce.org","threadId":"17231","inReplyTo":"46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-01-19T18:11:58Z","receivedAt":"2009-01-19T18:11:58Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Langhoff wrote:\n> On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce wrote:\n> > ... If we had\n> > an inotify sort of daemon to keep the data current so the prompt\n> > doesn't have to stat every source file on every display it would\n> > be reasonable, but we don't have such a thing yet for Git.\n> \n> Note that inotify is not recursive and is a hog if you ask it to\n> monitor lots of dents.\n> \n> I am not convinced that an inotify-enabled git is a good idea for\n> anything but small/mid-sized project. And such don't need it either.\n> \n> In other words, the kernel's cache will outperform any userland\n> attempting to keep track of the fs via inotify.\n\n*sigh*\n\nI was hoping it would work well for the really huge repository case,\nlike WebKit, where the stats against the work tree just kill the\nuser space application.\n\nBut if its only good for smaller sets of files, then yea, just\ndoing the stats on demand is going to be better than anything an\ninotify daemon might be able to offer.\n\n-- \nShawn.\n"},{"id":"101158","messageId":"20090119182802.GA10914@glandium.org","threadId":"17231","inReplyTo":"20090119181158.GH14053@spearce.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-01-19T18:28:02Z","receivedAt":"2009-01-19T18:28:02Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Jan 19, 2009 at 10:11:58AM -0800, Shawn O. Pearce wrote:\n> Martin Langhoff wrote:\n> > On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce wrote:\n> > > ... If we had\n> > > an inotify sort of daemon to keep the data current so the prompt\n> > > doesn't have to stat every source file on every display it would\n> > > be reasonable, but we don't have such a thing yet for Git.\n> > \n> > Note that inotify is not recursive and is a hog if you ask it to\n> > monitor lots of dents.\n> > \n> > I am not convinced that an inotify-enabled git is a good idea for\n> > anything but small/mid-sized project. And such don't need it either.\n> > \n> > In other words, the kernel's cache will outperform any userland\n> > attempting to keep track of the fs via inotify.\n> \n> *sigh*\n> \n> I was hoping it would work well for the really huge repository case,\n> like WebKit, where the stats against the work tree just kill the\n> user space application.\n\nI was hoping something like that too, especially for cold cache cases,\nafter resuming from hibernation, for instance, in which case the kernel\ncache is empty and inotify tracking will help know if something changed.\n\nMike\n"},{"id":"101160","messageId":"46a038f90901191042o6e47c9f7p188542f78f138317@mail.gmail.com","threadId":"17231","inReplyTo":"20090119181158.GH14053@spearce.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2009-01-19T18:42:28Z","receivedAt":"2009-01-19T18:42:28Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Mon, Jan 19, 2009 at 1:11 PM, Shawn O. Pearce wrote:\n> *sigh*\n>\n> I was hoping it would work well for the really huge repository case,\n> like WebKit, where the stats against the work tree just kill the\n> user space application.\n\nEven hot-cache? My perception is that in hot-cache conditions the perf is good.\n\nIf it is cold-cache, what in the end you are hoping for is \"pegging\"\nsome stuff in the cache. Perhaps there's a way to tell the kernel to\nskew the cache eviction scheme. Still, if the kernel's algorythms are\ngood, the kernel knows more about your fs usage patterns than you\ndo...\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"101159","messageId":"200901191301.49312.bss@iguanasuicide.net","threadId":"17231","inReplyTo":"20090119172939.GA14053@spearce.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-19T19:01:44Z","receivedAt":"2009-01-19T19:01:44Z","isPatch":true,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Monday 2009 January 19 11:29:39 Shawn O. Pearce wrote:\n>E.g. WebKit is huge,\n>computing the dirty state inside of the WebKit repository on each\n>prompt would absolutely kill CLI performance to a point of it not\n>being usuable.\n\nIs the performance any better on other VCSes for this operation? If not, \nmaybe its just a feature that's infeasible for large trees.\n-- \nBoyd Stephen Smith Jr. ,= ,-_-. =. \nbss@iguanasuicide.net ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \nhttp://iguanasuicide.net/ \\_/ \n"},{"id":"101161","messageId":"200901191306.49979.bss@iguanasuicide.net","threadId":"17231","inReplyTo":"46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-19T19:06:49Z","receivedAt":"2009-01-19T19:06:49Z","isPatch":true,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Monday 2009 January 19 12:00:10 Martin Langhoff wrote:\n>On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce \nwrote:\n>> ... If we had\n>> an inotify sort of daemon to keep the data current so the prompt\n>> doesn't have to stat every source file on every display it would\n>> be reasonable, but we don't have such a thing yet for Git.\n>\n>[T]he kernel's cache will outperform any userland\n>attempting to keep track of the fs via inotify.\n\nReally? Why have inotify then? I thought its only purpose is \"to keep track \nof the fs\". If it is never a net win, why even use/provide it?\n-- \nBoyd Stephen Smith Jr. ,= ,-_-. =. \nbss@iguanasuicide.net ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \nhttp://iguanasuicide.net/ \\_/ \n"},{"id":"101162","messageId":"46a038f90901191112p6626c670md219191d6bc46725@mail.gmail.com","threadId":"17231","inReplyTo":"200901191306.49979.bss@iguanasuicide.net","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2009-01-19T19:12:20Z","receivedAt":"2009-01-19T19:12:20Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Mon, Jan 19, 2009 at 2:06 PM, Boyd Stephen Smith Jr.\n wrote:\n> Really? Why have inotify then? I thought its only purpose is \"to keep track\n> of the fs\". If it is never a net win, why even use/provide it?\n\nLots of programs want to monitor _one file_ or _one directory_. Cron\ndaemons monitor /etc/cron.*/ , incron monitors /etc/incron.d/ ,\nprograms that watch mailspool directories can be made more efficient\nthis way too.\n\nYou might find your system today has perhaps a dozen inotify watches.\nJudiciously used, it's great.\n\ncheers\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"101170","messageId":"1232401089-27512-1-git-send-email-trast@student.ethz.ch","threadId":"17231","inReplyTo":"20090119172939.GA14053@spearce.org","subject":"[PATCH v2] bash: offer to show (un)staged changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-01-19T21:38:09Z","receivedAt":"2009-01-19T21:38:09Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Add a bit of code to __git_ps1 that lets it append '*' to the branch\nname if there are any unstaged changes, and '+' if there are any\nstaged changes.\n\nSince this is a rather expensive operation and will force a lot of\ndata into the cache whenever you first enter a repository, you have to\nenable it manually by setting bash.showDirtyState to a true value.\n\nSigned-off-by: Thomas Rast \n\n---\n\nShawn O. Pearce wrote:\n> Junio C Hamano wrote:\n> > This makes the feature unavailable for people who care about the stat\n> > dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n> \n> Yup, and I'm one of those people who sets autorefresindex to false\n> in my ~/.gitconfig, usually before I even have user.{name,email} set.\n\nI tried to alleviate the problem with a combination of diff options\nthat hopefully does the right thing in all cases.\n\n> I do like the idea of what Thomas is trying to do here, but its\n> so bloody expensive to compute dirty state on every prompt in\n> some repositories that I'd shoot myself. E.g. WebKit is huge,\n> computing the dirty state inside of the WebKit repository on each\n> prompt would absolutely kill CLI performance to a point of it not\n> being usuable. But git.git is small enough its OK on pretty much\n> everything except Cygwin.\n> \n> So as much as I'd like to use this without the update-index --refresh\n> bit, I'm not sure its viable in every project out there.\n\nI mostly work on small-ish repos, and while the initial loading is\n_very_ noticeable, it's ok after that. But your point about repos\nbeing different is very good, so I changed the patch to use a\ngit-config variable instead of a shell environment variable. That\nway, you could even configure it to a different setting per-repo.\n\n(Which might end up rather confusing, but at least it's possible.)\n\n\n contrib/completion/git-completion.bash | 22 ++++++++++++++++++++--\n 1 files changed, 20 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex f8b845a..7864ca7 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -34,6 +34,10 @@\n # are currently in a git repository. The %s token will be\n # the name of the current branch.\n #\n+#\tIn addition, if you set bash.showDirtyState to a true value,\n+#\tunstaged (*) and staged (+) changes will be shown next to the\n+#\tbranch name.\n+#\n # To submit patches:\n #\n # *) Read Documentation/SubmittingPatches\n@@ -116,10 +120,24 @@ __git_ps1 ()\n \t\t\tfi\n \t\tfi\n \n+\t\tlocal w\n+\t\tlocal i\n+\n+\t\tif test \"$(git config --bool bash.showDirtyState)\" = \"true\"; then\n+\t\t\tgit diff --no-ext-diff --ignore-submodules \\\n+\t\t\t\t--quiet --exit-code || w=\"*\"\n+\t\t\tif git rev-parse --quiet --verify HEAD >/dev/null; then\n+\t\t\t\tgit diff-index --cached --quiet \\\n+\t\t\t\t\t--ignore-submodules HEAD -- || i=\"+\"\n+\t\t\telse\n+\t\t\t\ti=\"#\"\n+\t\t\tfi\n+\t\tfi\n+\n \t\tif [ -n \"${1-}\" ]; then\n-\t\t\tprintf \"$1\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \"$1\" \"${b##refs/heads/}$w$i$r\"\n \t\telse\n-\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$w$i$r\"\n \t\tfi\n \tfi\n }\n-- \ntg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)\n"},{"id":"102785","messageId":"1233526423-30694-1-git-send-email-trast@student.ethz.ch","threadId":"17231","inReplyTo":"1232401089-27512-1-git-send-email-trast@student.ethz.ch","subject":"[PATCH v2] bash: offer to show (un)staged changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-02-01T22:13:43Z","receivedAt":"2009-02-01T22:13:43Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Add a bit of code to __git_ps1 that lets it append '*' to the branch\nname if there are any unstaged changes, and '+' if there are any\nstaged changes.\n\nSince this is a rather expensive operation and will force a lot of\ndata into the cache whenever you first enter a repository, you have to\nenable it manually by setting bash.showDirtyState to a true value.\n\nSigned-off-by: Thomas Rast \n---\n\nThis got no replies... was there anything wrong with v2?\n\n\n contrib/completion/git-completion.bash | 22 ++++++++++++++++++++--\n 1 files changed, 20 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex f8b845a..7864ca7 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -34,6 +34,10 @@\n # are currently in a git repository. The %s token will be\n # the name of the current branch.\n #\n+#\tIn addition, if you set bash.showDirtyState to a true value,\n+#\tunstaged (*) and staged (+) changes will be shown next to the\n+#\tbranch name.\n+#\n # To submit patches:\n #\n # *) Read Documentation/SubmittingPatches\n@@ -116,10 +120,24 @@ __git_ps1 ()\n \t\t\tfi\n \t\tfi\n \n+\t\tlocal w\n+\t\tlocal i\n+\n+\t\tif test \"$(git config --bool bash.showDirtyState)\" = \"true\"; then\n+\t\t\tgit diff --no-ext-diff --ignore-submodules \\\n+\t\t\t\t--quiet --exit-code || w=\"*\"\n+\t\t\tif git rev-parse --quiet --verify HEAD >/dev/null; then\n+\t\t\t\tgit diff-index --cached --quiet \\\n+\t\t\t\t\t--ignore-submodules HEAD -- || i=\"+\"\n+\t\t\telse\n+\t\t\t\ti=\"#\"\n+\t\t\tfi\n+\t\tfi\n+\n \t\tif [ -n \"${1-}\" ]; then\n-\t\t\tprintf \"$1\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \"$1\" \"${b##refs/heads/}$w$i$r\"\n \t\telse\n-\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$w$i$r\"\n \t\tfi\n \tfi\n }\n-- \ntg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)\n"},{"id":"102787","messageId":"20090201222937.GP26880@spearce.org","threadId":"17231","inReplyTo":"1233526423-30694-1-git-send-email-trast@student.ethz.ch","subject":"Re: [PATCH v2] bash: offer to show (un)staged changes","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-02-01T22:29:37Z","receivedAt":"2009-02-01T22:29:37Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Thomas Rast wrote:\n> Add a bit of code to __git_ps1 that lets it append '*' to the branch\n> name if there are any unstaged changes, and '+' if there are any\n> staged changes.\n> \n> Since this is a rather expensive operation and will force a lot of\n> data into the cache whenever you first enter a repository, you have to\n> enable it manually by setting bash.showDirtyState to a true value.\n> \n> Signed-off-by: Thomas Rast \n> ---\n> \n> This got no replies... was there anything wrong with v2?\n\nDropped on the floor by me. Sorry.\n\nBut I'm a bit worried about the config --bool test in the prompt.\nIts a new fork+exec we weren't doing before. I wonder if we should\nuse a shell variable to consider whether or not this should even\nbe executed and try to shortcut out if not. E.g.:\n\n if test -n \"$GIT_PS1_SHOWDIRTYSTATE\"; then\n ... your new code block ...\n fi\n\nand ask that users at some point set GIT_PS1_SHOWDIRTYSTATE=1 in\ntheir shell startup scripts, and also set bash.showDirtyState true\nin any of the repositories they care about it in.\n\n\n \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index f8b845a..7864ca7 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -34,6 +34,10 @@\n> # are currently in a git repository. The %s token will be\n> # the name of the current branch.\n> #\n> +#\tIn addition, if you set bash.showDirtyState to a true value,\n> +#\tunstaged (*) and staged (+) changes will be shown next to the\n> +#\tbranch name.\n> +#\n> # To submit patches:\n> #\n> # *) Read Documentation/SubmittingPatches\n> @@ -116,10 +120,24 @@ __git_ps1 ()\n> \t\t\tfi\n> \t\tfi\n> \n> +\t\tlocal w\n> +\t\tlocal i\n> +\n> +\t\tif test \"$(git config --bool bash.showDirtyState)\" = \"true\"; then\n> +\t\t\tgit diff --no-ext-diff --ignore-submodules \\\n> +\t\t\t\t--quiet --exit-code || w=\"*\"\n> +\t\t\tif git rev-parse --quiet --verify HEAD >/dev/null; then\n> +\t\t\t\tgit diff-index --cached --quiet \\\n> +\t\t\t\t\t--ignore-submodules HEAD -- || i=\"+\"\n> +\t\t\telse\n> +\t\t\t\ti=\"#\"\n> +\t\t\tfi\n> +\t\tfi\n> +\n> \t\tif [ -n \"${1-}\" ]; then\n> -\t\t\tprintf \"$1\" \"${b##refs/heads/}$r\"\n> +\t\t\tprintf \"$1\" \"${b##refs/heads/}$w$i$r\"\n> \t\telse\n> -\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$r\"\n> +\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$w$i$r\"\n> \t\tfi\n> \tfi\n> }\n\n-- \nShawn.\n"},{"id":"102793","messageId":"4ac8254d0902011448t242e7fcek3ae7fda609648ef0@mail.gmail.com","threadId":"17231","inReplyTo":"20090119172939.GA14053@spearce.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2009-02-01T22:48:30Z","receivedAt":"2009-02-01T22:48:30Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce wrote:\n> Junio C Hamano wrote:\n>> Thomas Rast writes:\n>>\n>> > + if test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n>> > + git update-index --refresh >/dev/null 2>&1 || w=\"*\"\n>>\n>> This makes the feature unavailable for people who care about the stat\n>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n>\n> Yup, and I'm one of those people who sets autorefresindex to false\n> in my ~/.gitconfig, usually before I even have user.{name,email} set.\n>\n> I do like the idea of what Thomas is trying to do here, but its\n> so bloody expensive to compute dirty state on every prompt in\n> some repositories that I'd shoot myself. E.g. WebKit is huge,\n\nI've been thinking about this and wondered\nwhether implementing \"status --mini\" or\n\"status --short\" which prints \"+?*\" in wt-status.c\ncould be made fast enough.\n\nShould we try to implement and profile this\nor do we know it will be slow beforehand?\n\nI am actually using this feature on the bash\nprompt via calls to git commands and parsing\nfor added=+, unknown=? and changed=* as\nothers have done in combination with __git_ps1.\n\n> computing the dirty state inside of the WebKit repository on each\n> prompt would absolutely kill CLI performance to a point of it not\n> being usuable. But git.git is small enough its OK on pretty much\n> everything except Cygwin.\n>\n> So as much as I'd like to use this without the update-index --refresh\n> bit, I'm not sure its viable in every project out there. If we had\n> an inotify sort of daemon to keep the data current so the prompt\n> doesn't have to stat every source file on every display it would\n> be reasonable, but we don't have such a thing yet for Git.\n>\n> --\n> Shawn.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"102798","messageId":"7vwsc9rae9.fsf@gitster.siamese.dyndns.org","threadId":"17231","inReplyTo":"4ac8254d0902011448t242e7fcek3ae7fda609648ef0@mail.gmail.com","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-01T23:43:26Z","receivedAt":"2009-02-01T23:43:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tuncer Ayaz writes:\n\n> On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce wrote:\n>> Junio C Hamano wrote:\n>>> Thomas Rast writes:\n>>>\n>>> > + if test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n>>> > + git update-index --refresh >/dev/null 2>&1 || w=\"*\"\n>>>\n>>> This makes the feature unavailable for people who care about the stat\n>>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n>>\n>> Yup, and I'm one of those people who sets autorefresindex to false\n>> in my ~/.gitconfig, usually before I even have user.{name,email} set.\n>>\n>> I do like the idea of what Thomas is trying to do here, but its\n>> so bloody expensive to compute dirty state on every prompt in\n>> some repositories that I'd shoot myself. E.g. WebKit is huge,\n>\n> I've been thinking about this and wondered\n> whether implementing \"status --mini\" or\n> \"status --short\" which prints \"+?*\" in wt-status.c\n> could be made fast enough.\n>\n> Should we try to implement and profile this\n> or do we know it will be slow beforehand?\n\nI think I've seen a patch to do something like that, soon after Shawn\nannounced his repo tool.\n"},{"id":"102804","messageId":"4ac8254d0902011650g714c5a7cya3c5111a74b8d8ea@mail.gmail.com","threadId":"17231","inReplyTo":"7vwsc9rae9.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2009-02-02T00:50:12Z","receivedAt":"2009-02-02T00:50:12Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Mon, Feb 2, 2009 at 12:43 AM, Junio C Hamano wrote:\n> Tuncer Ayaz writes:\n>\n>> On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce wrote:\n>>> Junio C Hamano wrote:\n>>>> Thomas Rast writes:\n>>>>\n>>>> > + if test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n>>>> > + git update-index --refresh >/dev/null 2>&1 || w=\"*\"\n>>>>\n>>>> This makes the feature unavailable for people who care about the stat\n>>>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n>>>\n>>> Yup, and I'm one of those people who sets autorefresindex to false\n>>> in my ~/.gitconfig, usually before I even have user.{name,email} set.\n>>>\n>>> I do like the idea of what Thomas is trying to do here, but its\n>>> so bloody expensive to compute dirty state on every prompt in\n>>> some repositories that I'd shoot myself. E.g. WebKit is huge,\n>>\n>> I've been thinking about this and wondered\n>> whether implementing \"status --mini\" or\n>> \"status --short\" which prints \"+?*\" in wt-status.c\n>> could be made fast enough.\n>>\n>> Should we try to implement and profile this\n>> or do we know it will be slow beforehand?\n>\n> I think I've seen a patch to do something like that, soon after Shawn\n> announced his repo tool.\n\nThe best I could find is your patch from October 25th 2008\nwhich implements:\n $ ./git-shortstatus\n M Makefile\n R100 COPYING -> RENAMING\n M builtin-commit.c\n M builtin-revert.c\n M builtin.h\n M git.c\n M wt-status.c\n M wt-status.h\n\nIs this what you meant?\n"},{"id":"102883","messageId":"4ac8254d0902021131m24bab3b7md4d981e6ee935686@mail.gmail.com","threadId":"17231","inReplyTo":"4ac8254d0902011650g714c5a7cya3c5111a74b8d8ea@mail.gmail.com","subject":"Re: [PATCH] bash: offer to show (un)staged changes","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2009-02-02T19:31:49Z","receivedAt":"2009-02-02T19:31:49Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Mon, Feb 2, 2009 at 1:50 AM, Tuncer Ayaz wrote:\n> On Mon, Feb 2, 2009 at 12:43 AM, Junio C Hamano wrote:\n>> Tuncer Ayaz writes:\n>>\n>>> On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce wrote:\n>>>> Junio C Hamano wrote:\n>>>>> Thomas Rast writes:\n>>>>>\n>>>>> > + if test ! -z \"$GIT_PS1_EXPENSIVE\"; then\n>>>>> > + git update-index --refresh >/dev/null 2>&1 || w=\"*\"\n>>>>>\n>>>>> This makes the feature unavailable for people who care about the stat\n>>>>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?\n>>>>\n>>>> Yup, and I'm one of those people who sets autorefresindex to false\n>>>> in my ~/.gitconfig, usually before I even have user.{name,email} set.\n>>>>\n>>>> I do like the idea of what Thomas is trying to do here, but its\n>>>> so bloody expensive to compute dirty state on every prompt in\n>>>> some repositories that I'd shoot myself. E.g. WebKit is huge,\n>>>\n>>> I've been thinking about this and wondered\n>>> whether implementing \"status --mini\" or\n>>> \"status --short\" which prints \"+?*\" in wt-status.c\n>>> could be made fast enough.\n>>>\n>>> Should we try to implement and profile this\n>>> or do we know it will be slow beforehand?\n>>\n>> I think I've seen a patch to do something like that, soon after Shawn\n>> announced his repo tool.\n>\n> The best I could find is your patch from October 25th 2008\n> which implements:\n> $ ./git-shortstatus\n> M Makefile\n> R100 COPYING -> RENAMING\n> M builtin-commit.c\n> M builtin-revert.c\n> M builtin.h\n> M git.c\n> M wt-status.c\n> M wt-status.h\n>\n> Is this what you meant?\n\nI am confident that this is the patch Junio referred to\nand as time permits I will give it a try.\n"},{"id":"102942","messageId":"1233652854-29306-1-git-send-email-trast@student.ethz.ch","threadId":"17231","inReplyTo":"20090201222937.GP26880@spearce.org","subject":"[PATCH v3] bash: offer to show (un)staged changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-02-03T09:20:54Z","receivedAt":"2009-02-03T09:20:54Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Add a bit of code to __git_ps1 that lets it append '*' to the branch\nname if there are any unstaged changes, and '+' if there are any\nstaged changes.\n\nSince this is a rather expensive operation and will force a lot of\ndata into the cache whenever you first enter a repository, you have to\nenable it manually by setting GIT_PS1_SHOWDIRTYSTATE to a nonempty\nvalue. The configuration variable bash.showDirtyState can then be\nused to disable it again for some repositories.\n\nSigned-off-by: Thomas Rast \n---\n\nShawn O. Pearce wrote:\n> But I'm a bit worried about the config --bool test in the prompt.\n> Its a new fork+exec we weren't doing before. I wonder if we should\n> use a shell variable to consider whether or not this should even\n> be executed and try to shortcut out if not.\n\nOk, why not. I changed the default of bash.showDirtyState to true\nsince the user already opts in via GIT_PS1_SHOWDIRTYSTATE.\n\n\n contrib/completion/git-completion.bash | 26 ++++++++++++++++++++++++--\n 1 files changed, 24 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex f8b845a..13cae8d 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -34,6 +34,12 @@\n # are currently in a git repository. The %s token will be\n # the name of the current branch.\n #\n+#\tIn addition, if you set GIT_PS1_SHOWDIRTYSTATE to a nonempty\n+#\tvalue, unstaged (*) and staged (+) changes will be shown next\n+#\tto the branch name. You can configure this per-repository\n+#\twith the bash.showDirtyState variable, which defaults to true\n+#\tonce GIT_PS1_SHOWDIRTYSTATE is enabled.\n+#\n # To submit patches:\n #\n # *) Read Documentation/SubmittingPatches\n@@ -116,10 +122,26 @@ __git_ps1 ()\n \t\t\tfi\n \t\tfi\n \n+\t\tlocal w\n+\t\tlocal i\n+\n+\t\tif test -n \"$GIT_PS1_SHOWDIRTYSTATE\"; then\n+\t\t\tif test \"$(git config --bool bash.showDirtyState)\" != \"false\"; then\n+\t\t\t\tgit diff --no-ext-diff --ignore-submodules \\\n+\t\t\t\t\t--quiet --exit-code || w=\"*\"\n+\t\t\t\tif git rev-parse --quiet --verify HEAD >/dev/null; then\n+\t\t\t\t\tgit diff-index --cached --quiet \\\n+\t\t\t\t\t\t--ignore-submodules HEAD -- || i=\"+\"\n+\t\t\t\telse\n+\t\t\t\t\ti=\"#\"\n+\t\t\t\tfi\n+\t\t\tfi\n+\t\tfi\n+\n \t\tif [ -n \"${1-}\" ]; then\n-\t\t\tprintf \"$1\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \"$1\" \"${b##refs/heads/}$w$i$r\"\n \t\telse\n-\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$r\"\n+\t\t\tprintf \" (%s)\" \"${b##refs/heads/}$w$i$r\"\n \t\tfi\n \tfi\n }\n-- \ntg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)\n"},{"id":"103006","messageId":"20090203181121.GY26880@spearce.org","threadId":"17231","inReplyTo":"1233652854-29306-1-git-send-email-trast@student.ethz.ch","subject":"Re: [PATCH v3] bash: offer to show (un)staged changes","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-02-03T18:11:21Z","receivedAt":"2009-02-03T18:11:21Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Thomas Rast wrote:\n> Add a bit of code to __git_ps1 that lets it append '*' to the branch\n> name if there are any unstaged changes, and '+' if there are any\n> staged changes.\n> \n> Since this is a rather expensive operation and will force a lot of\n> data into the cache whenever you first enter a repository, you have to\n> enable it manually by setting GIT_PS1_SHOWDIRTYSTATE to a nonempty\n> value. The configuration variable bash.showDirtyState can then be\n> used to disable it again for some repositories.\n> \n> Signed-off-by: Thomas Rast \n\nAcked-by: Shawn O. Pearce \n\n> Shawn O. Pearce wrote:\n> > But I'm a bit worried about the config --bool test in the prompt.\n> > Its a new fork+exec we weren't doing before. I wonder if we should\n> > use a shell variable to consider whether or not this should even\n> > be executed and try to shortcut out if not.\n> \n> Ok, why not. I changed the default of bash.showDirtyState to true\n> since the user already opts in via GIT_PS1_SHOWDIRTYSTATE.\n\nYea, that seems right.\n\n-- \nShawn.\n"}]}