On Tuesday 12 December 2006 22:51, Junio C Hamano wrote: > I've updated my "git add --interactive" in 'pu' and it now knows > how to split a hunk into smaller pieces and recounting the diff > offsets before applying Nice. Yes, this seems to be a missing piece in this hunk-wise staging. > To make it easier, one possibility might be to add a subcommand > to "git add --interactive" that lets you edit what is currently > staged in the index by opening a temporary copy in your favorite > editor, and stage the result of your edit in the index. Yes. Sounds interesting. Another would be to open the editor with the diff of this hunk. > But I > feel quite uneasy to introduce ways to update the index with > something _wildly_ different from what you ever had in your > working tree as a whole. Hmm... yes. Is this not a general problem with staging, of course to a lesser degree if you work at file granularity, because the probability of dependence of changes in multiple files, which could lead to a wrong commit, is less. > I think it is wrong to commit partially, purely from the index, > when you are building a series that has complex changes that > come during the series but go away at the end. The user should > be able to verify all the steps in the middle in such a complex > series, but it is not easy if you have it only in the index. What you really want is to test the commit afterwards. If you did it wrong, you always can do "git reset --mixed HEAD^" or "git commit --amend". However, testing a commit with a dirty working tree is not possible. For this to work, you would want that "git-checkout --store" can store away a dirty working state when going to another revision, e.g. store it into a temporary ref "<current branch>.dirtywork". You would need a "git-checkout --restore" which would restore the dirty state of the branch you are switching too. Then, to check the commit of staged things, it should be enough to do "git-checkout --store", check the commit, and do a "git-checkout --restore" afterwards to get the dirty state back. > You could do > > $ git checkout-index --prefix=testarea/ -f -q -u -a > > and run your tests there, but that takes a discipline, and is > cumbersome to do. IMHO that is too tricky for the average git user. > So in short, I think per-hunk update-index is a cute hack and > may be useful in a narrow simple cases, but it would not be so > useful in the real life. No. It currently is starting to get useful. With the ability to temporarily store away a dirty state of the working directory, it really could become very good. > > Just as a sidenote: after deciding to not apply hunks, you > > lose them in this WIP, as you will find nothing in "unstaged" mode > > afterwards :-( > > I do not understand this part. You can 'revert' to match the > index to HEAD and run 'patch' to pick what you want again. Hmmm... I lost my changes in the working directory; there was nothing to pick again any more. Perhaps I did something wrong. Josef - 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