Junio C Hamano <junkio@xxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> 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...
--
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html