On Fri, Nov 09, 2012 at 08:42:33AM +1300, Nathan Broadbent wrote:
> It sounds like we want a tool that combines the functionality of 'git add
> --patch', 'git checkout --patch', and other features, so that we can
> perform various actions on 'hunks' without switching context. What do you
> think about naming this command 'git patch'?
I think it would be a slightly confusing name, given that it is not
related to the usual Unix "patch" command (git's analog to that is "git
apply").
I was thinking something like "git organize" because it is about
organizing muddled changes. Duy mentioned my earlier "git put", which is
based around the same ideas. This could be thought of as "git put
--patch", I suppose.
> I'm not sure how dropping hunks into 'buckets' would work, but the main
> idea is to be able to stage, discard or edit hunks in a single pass.
Buckets are really just patches you are building up from hunks. So I
think you are dealing with two buckets either way: a to-stage bucket and
a to-discard bucket. Adding more buckets isn't hard; you just turn the
to-stage bucket into an array of buckets.
The tricky part is figuring out how to keep the state persistent across
multiple invocations. The simplest program flow for the 2-bucket case
would be something like:
for h in hunks
do
show hunk to user
ask user what they want to do
if they want to stage
append to to-stage patch
else if they want to discard
append to to-discard patch
else
ignore the hunk
done
feed to-stage patch to "git apply --cached"
feed to-discard patch to "git apply -R"
Modifying the loop to have more buckets is easy. But the end is probably
something like:
feed to-discard patch to "git apply -R"
feed bucket[0] to "git apply --cached"
save bucket[1..n] somewhere
exit
Then the user gets control back, builds, tests, commits, whatever, and
then runs "git organize --continue" to apply bucket[1], and so on. And
since we don't know what the user did in between, we have to be ready
for conflicts in applying the buckets. Hmm, this is sounding a lot like
how "rebase --interactive" works.
One way to implement this would be to store each bucket as a commit
against HEAD (i.e., stage it into a temporary index, then run "git
write-tree" and "git commit-tree"), and then make a "rebase -i"
instruction sheet like:
pick $sha1_of_bucket_1_commit
edit
pick $sha1_of_bucket_2_commit
edit
and so forth, except that we would not want our picks to actually commit
(just pull the changes into the working tree and/or index).
That's just me thinking off the top of my head. Obviously what you are
proposing is way simpler, and it is probably sane to start with the
simple thing, and then build the more complex thing on top. But it might
be worth keeping in mind the complex case when building out the
infrastructure for the simple case.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
