bash completion in backticks partially broken

bash completion in backticks partially broken

[Shawn Pearce]

So an annoying feature of bash appears to be that it won't really
provide completion on backtick'd commands.

For example I can complete "git merge-base ma" just fine as is, but
if I toss it into backticks say "git update-ref M `git merge-base ma"
then I can't complete "ma" out to "master" anymore.

A little bit of debugging appears to show that bash is invoking the
completion hook for the outermost command; that is we are looking
for parameters for update-ref and not merge-base.

I think I could rewrite a good part of git-completion.bash to
support this use.  But it won't work for "echo `git merge-base ma"
as the outermost command is echo and we don't have a Git completion
hook registered for that command.

This is really annoying when it comes to less contrived examples.
I find myself forming odd pipelines with commit-tree, update-ref,
mktree, lstree, sed, rev-list, etc. and always keep bumping up on
the limitations of git-completion.bash.

Any suggestions?  How often do bash users try to use backticks to
call Git commands, only to find bash isn't being as helpful as it
should be?

-- 

Re: bash completion in backticks partially broken

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> This is really annoying when it comes to less contrived examples.
> I find myself forming odd pipelines with commit-tree, update-ref,
> mktree, lstree, sed, rev-list, etc. and always keep bumping up on
> the limitations of git-completion.bash.
>
> Any suggestions?

I am more interested in why you would even need to use
combinations of such low-level commands in day-to-day workflow.

If they are often-needed patterns, you would have scripted them
already, so completion would not be an issue for you.  So I am
assuming these are ad-hoc one-shot needs.

While it is satisfying to know that things you would want to do
can be scripted even for one-shot use (which is how git is
designed to, and it shows that the design goal has been
achieved), maybe it's a sign that we are giving you too much
flexibility?  Under less capable/flexible system that puts you
in a straightjacket, you would not even be tempted to do oddball
things to begin with...

Re: bash completion in backticks partially broken

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > This is really annoying when it comes to less contrived examples.
> > I find myself forming odd pipelines with commit-tree, update-ref,
> > mktree, lstree, sed, rev-list, etc. and always keep bumping up on
> > the limitations of git-completion.bash.
> >
> > Any suggestions?
> 
> I am more interested in why you would even need to use
> combinations of such low-level commands in day-to-day workflow.
> 
> If they are often-needed patterns, you would have scripted them
> already, so completion would not be an issue for you.  So I am
> assuming these are ad-hoc one-shot needs.

Yes, that's correct.
 
> While it is satisfying to know that things you would want to do
> can be scripted even for one-shot use (which is how git is
> designed to, and it shows that the design goal has been
> achieved), maybe it's a sign that we are giving you too much
> flexibility?  Under less capable/flexible system that puts you
> in a straightjacket, you would not even be tempted to do oddball
> things to begin with...

A few recent examples come to mind:

  *) We're mostly on Windows (*sigh*) which as you know is a case
     insensitive file system.  Someone managed to delete a file
	 called 'Myfoo' and recreate it as 'MyFoo' on two different
	 branches.

	 We have a specialized merge driver which we are running on
	 certain merges.  This merge driver made the bad assumption
	 that both 'Myfoo' and 'MyFoo' should stick around after
	 merging those two branches together.  No, merge-recursive
	 doesn't implement the type of bastard merge we need,
	 so don't ask.	This merge strategy is also probably not
	 useful to anyone else, which is why I haven't posted a
	 patch to include it.

	 A quick hack with mktree/commit-tree/update-ref removed
	 the wrong 'Myfoo' leaving 'MyFoo' in place.  And before
	 you ask, yes I did check that was sane, 'Myfoo' and 'MyFoo'
	 had the exact same SHA1.  ;-)

  *) A new user branched off a highly experimental branch then
     proceeded to merge that straight into the mainline.  We found
	 his mistake 100 commits later on the mainline and couldn't
	 rewind it.

	 Because of the way that mainline is flushed into the
	 testing environment, and because it had a lot of history on
	 it that we wanted to keep valid in git-blame, I reverted
	 ~36 commits in one large squash commit onto the mainline,
	 flushed that into testing, then squash cherry-picked all
	 ~36 commits back ontop of that, then merged that into the
	 prior experimental branch.  Yuck.

	 The upside is that both git-blame and git-pickaxe report
	 back to the original commits.	:)

	 I'm sure I abused git-write-tree and git-commit-tree during
	 that as both are faster than waiting for git-commit.  Yes,
	 it takes me less time to type out and execute commit-tree
	 pipeline than to wait for git-commit on my system.  :-(

	 I also know I spent a lot of time with gitk and
	 git-merge-base trying to find the correct set of 36 commits
	 which had to be worked on.  It wasn't a trivial rev-list/log
	 type operation due to the sheer number of commits and merges
	 involved.  Our commit graph is much uglier than git.git.

  *) Being the moron that I am I pulled another (but slightly
     less) experimental branch into the highly experimental branch
     mentioned above.  3 weeks later we concluded that was a bad idea
	 as not all of the stuff in the slightly less experimental
	 branch was good.  But I had also done a number of bug fixes
	 onto that highly experimental branch and those needed to
	 get saved.

	 This turned out to be mostly a format-patch | am pipeline,
	 so it wasn't really that awkward.

  *) At least twice I've had an aweful merge of over 1000 files
     conflicting heavily between two branches.	Yet in both cases
	 I *know without a doubt* that one of those two branches is
	 completely correct for 15 of say 20 top level directories,
	 such that those 15 directories cover about 995 files.

	 To resolve these I've often just reverted those directories
	 en-mass to the version in the merge-base of the two branches
	 by way of ls-tree/vi/mktree, then let merge-recursive do
	 its thing.  As the correct side differs but the wrong side
	 was reverted, the correct side pops out of the merge. :-)

	 Its somewhat lying in the history because Git now thinks
	 that one branch modified 995 files, then suddenly threw them
	 all back to the version at the merge-base.  But honestly
	 reverting them back to the merge-base and then immediately
	 doing a merge which replaces them with the correct versions
	 is about the same as resolving the 995 conflicts during
	 the merge with the ones from the other branch.

	 Its also *much* faster on Cygwin.  That 1000 file merge
	 would probably have taken my system 15 minutes just to
	 invoke 'merge' on each file and still leave me with a mess
	 to cleanup.  Yet the bastard approach above with mktree
	 took me like 5 minutes (total).

Now on UNIX systems I never do stupid things like the above; nor
do I work with such new users...  Hmm...  I wonder what that says...

--