{"thread":{"id":"43380","subject":"bash completion in backticks partially broken","startedAt":"2006-11-05T09:05:40Z","lastAt":"2006-11-05T10:26:35Z","messageCount":3,"participants":["Shawn Pearce","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294565","messageId":"20061105090540.GA4843@spearce.org","threadId":"43380","inReplyTo":null,"subject":"bash completion in backticks partially broken","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-05T09:05:40Z","receivedAt":"2006-11-05T09:05:40Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"So an annoying feature of bash appears to be that it won't really\nprovide completion on backtick'd commands.\n\nFor example I can complete \"git merge-base ma\" just fine as is, but\nif I toss it into backticks say \"git update-ref M `git merge-base ma\"\nthen I can't complete \"ma\" out to \"master\" anymore.\n\nA little bit of debugging appears to show that bash is invoking the\ncompletion hook for the outermost command; that is we are looking\nfor parameters for update-ref and not merge-base.\n\nI think I could rewrite a good part of git-completion.bash to\nsupport this use.  But it won't work for \"echo `git merge-base ma\"\nas the outermost command is echo and we don't have a Git completion\nhook registered for that command.\n\nThis is really annoying when it comes to less contrived examples.\nI find myself forming odd pipelines with commit-tree, update-ref,\nmktree, lstree, sed, rev-list, etc. and always keep bumping up on\nthe limitations of git-completion.bash.\n\nAny suggestions?  How often do bash users try to use backticks to\ncall Git commands, only to find bash isn't being as helpful as it\nshould be?\n\n-- \n"},{"id":"296591","messageId":"7vpsc2teb0.fsf@assigned-by-dhcp.cox.net","threadId":"43380","inReplyTo":"20061105090540.GA4843@spearce.org","subject":"Re: bash completion in backticks partially broken","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-05T09:48:03Z","receivedAt":"2006-11-05T09:48:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> This is really annoying when it comes to less contrived examples.\n> I find myself forming odd pipelines with commit-tree, update-ref,\n> mktree, lstree, sed, rev-list, etc. and always keep bumping up on\n> the limitations of git-completion.bash.\n>\n> Any suggestions?\n\nI am more interested in why you would even need to use\ncombinations of such low-level commands in day-to-day workflow.\n\nIf they are often-needed patterns, you would have scripted them\nalready, so completion would not be an issue for you.  So I am\nassuming these are ad-hoc one-shot needs.\n\nWhile it is satisfying to know that things you would want to do\ncan be scripted even for one-shot use (which is how git is\ndesigned to, and it shows that the design goal has been\nachieved), maybe it's a sign that we are giving you too much\nflexibility?  Under less capable/flexible system that puts you\nin a straightjacket, you would not even be tempted to do oddball\nthings to begin with...\n\n\n"},{"id":"294691","messageId":"20061105102635.GB4843@spearce.org","threadId":"43380","inReplyTo":"7vpsc2teb0.fsf@assigned-by-dhcp.cox.net","subject":"Re: bash completion in backticks partially broken","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-05T10:26:35Z","receivedAt":"2006-11-05T10:26:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > This is really annoying when it comes to less contrived examples.\n> > I find myself forming odd pipelines with commit-tree, update-ref,\n> > mktree, lstree, sed, rev-list, etc. and always keep bumping up on\n> > the limitations of git-completion.bash.\n> >\n> > Any suggestions?\n> \n> I am more interested in why you would even need to use\n> combinations of such low-level commands in day-to-day workflow.\n> \n> If they are often-needed patterns, you would have scripted them\n> already, so completion would not be an issue for you.  So I am\n> assuming these are ad-hoc one-shot needs.\n\nYes, that's correct.\n \n> While it is satisfying to know that things you would want to do\n> can be scripted even for one-shot use (which is how git is\n> designed to, and it shows that the design goal has been\n> achieved), maybe it's a sign that we are giving you too much\n> flexibility?  Under less capable/flexible system that puts you\n> in a straightjacket, you would not even be tempted to do oddball\n> things to begin with...\n\nA few recent examples come to mind:\n\n  *) We're mostly on Windows (*sigh*) which as you know is a case\n     insensitive file system.  Someone managed to delete a file\n\t called 'Myfoo' and recreate it as 'MyFoo' on two different\n\t branches.\n\n\t We have a specialized merge driver which we are running on\n\t certain merges.  This merge driver made the bad assumption\n\t that both 'Myfoo' and 'MyFoo' should stick around after\n\t merging those two branches together.  No, merge-recursive\n\t doesn't implement the type of bastard merge we need,\n\t so don't ask.\tThis merge strategy is also probably not\n\t useful to anyone else, which is why I haven't posted a\n\t patch to include it.\n\n\t A quick hack with mktree/commit-tree/update-ref removed\n\t the wrong 'Myfoo' leaving 'MyFoo' in place.  And before\n\t you ask, yes I did check that was sane, 'Myfoo' and 'MyFoo'\n\t had the exact same SHA1.  ;-)\n\n  *) A new user branched off a highly experimental branch then\n     proceeded to merge that straight into the mainline.  We found\n\t his mistake 100 commits later on the mainline and couldn't\n\t rewind it.\n\n\t Because of the way that mainline is flushed into the\n\t testing environment, and because it had a lot of history on\n\t it that we wanted to keep valid in git-blame, I reverted\n\t ~36 commits in one large squash commit onto the mainline,\n\t flushed that into testing, then squash cherry-picked all\n\t ~36 commits back ontop of that, then merged that into the\n\t prior experimental branch.  Yuck.\n\n\t The upside is that both git-blame and git-pickaxe report\n\t back to the original commits.\t:)\n\n\t I'm sure I abused git-write-tree and git-commit-tree during\n\t that as both are faster than waiting for git-commit.  Yes,\n\t it takes me less time to type out and execute commit-tree\n\t pipeline than to wait for git-commit on my system.  :-(\n\n\t I also know I spent a lot of time with gitk and\n\t git-merge-base trying to find the correct set of 36 commits\n\t which had to be worked on.  It wasn't a trivial rev-list/log\n\t type operation due to the sheer number of commits and merges\n\t involved.  Our commit graph is much uglier than git.git.\n\n  *) Being the moron that I am I pulled another (but slightly\n     less) experimental branch into the highly experimental branch\n     mentioned above.  3 weeks later we concluded that was a bad idea\n\t as not all of the stuff in the slightly less experimental\n\t branch was good.  But I had also done a number of bug fixes\n\t onto that highly experimental branch and those needed to\n\t get saved.\n\n\t This turned out to be mostly a format-patch | am pipeline,\n\t so it wasn't really that awkward.\n\n  *) At least twice I've had an aweful merge of over 1000 files\n     conflicting heavily between two branches.\tYet in both cases\n\t I *know without a doubt* that one of those two branches is\n\t completely correct for 15 of say 20 top level directories,\n\t such that those 15 directories cover about 995 files.\n\n\t To resolve these I've often just reverted those directories\n\t en-mass to the version in the merge-base of the two branches\n\t by way of ls-tree/vi/mktree, then let merge-recursive do\n\t its thing.  As the correct side differs but the wrong side\n\t was reverted, the correct side pops out of the merge. :-)\n\n\t Its somewhat lying in the history because Git now thinks\n\t that one branch modified 995 files, then suddenly threw them\n\t all back to the version at the merge-base.  But honestly\n\t reverting them back to the merge-base and then immediately\n\t doing a merge which replaces them with the correct versions\n\t is about the same as resolving the 995 conflicts during\n\t the merge with the ones from the other branch.\n\n\t Its also *much* faster on Cygwin.  That 1000 file merge\n\t would probably have taken my system 15 minutes just to\n\t invoke 'merge' on each file and still leave me with a mess\n\t to cleanup.  Yet the bastard approach above with mktree\n\t took me like 5 minutes (total).\n\nNow on UNIX systems I never do stupid things like the above; nor\ndo I work with such new users...  Hmm...  I wonder what that says...\n\n-- \n"}]}