Re: selective git-update-index per diff(1) chunks

Pretty often I end up with a file with two simple orthogonal fixes in it. git-diff shows me both, that's OK.

Now I want to commit them as two separate commits. So far, it's
* getting full diff
* cp(1)
* hand-edit both diffs
* commit first
* commit second

Has anyone thought about aggregating this into git-update-index or somewhere?

    git-update-index -C1,3    #chunks 1, 3
    git commit
    git-update-index -C1,3    # chunks 2,5 in original numbering
    git commit

On 2006-12-01, Alexey Dobriyan <adobriyan@gmail.com> wrote:

I don't think it belongs in the plumbing, the git-update-index but I think something like this would be very usefull.

AFAIR darcs has this functionality. It selectively ask for each hunk if it should be commited. This would be awfull to have in git.

-Peter

Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> writes:

I concur, on both counts. My own now-defunct Porcelain had the darcs style interactive hunk selection because it felt so useful (and sometimes it was).

On Fri, 01 Dec 2006 03:38:13 -0800, Junio C Hamano wrote:

Is there a good receipe on how to do this? Everytime I do it, I try a different method; since I'm testing out my understanding of things.

It'd nice to have some of these "advanced receipes" that people often do noted down somewhere.

Sometimes I feel git is kind of like the Emacs of VCS ... there is always more to learn, even when you think you have a good handle on things.

Cheers, Anand

Hi,

On Fri, 1 Dec 2006, Anand Kumria wrote:

Can't say anything about advanced recipes, but I use a poor-man's workflow:

$ git diff > a1.patch
$ vi a1.patch
  <edit out what I want to _keep_>
$ git apply -R < a1.patch
  <test & commit>
$ git apply < a1.patch

Of course, you could write a little wrapper around it, even one which asks you which hunks you want to edit out. Should not be that hard...

Note that this is independent of the SCM you are using.

Ciao, Dscho

Peter Baumann wrote:

I made a patch to 'cg-commit -p' to do this, check the archives.

darcs and SVK both have this "interactive commit".

darcs also does something very useful with this; what amounts to automatically making topic branches. Currently there is no easy way to manage that, either.

Sam.

On Fri, 1 Dec 2006, Alexey Dobriyan wrote:

You can already do it, but it's called something else.

Instead of updating a certain hunk (which is fundamentally wrong, since it depends on "diff" even working on that file), you can tell git-update-index to update a certain _state_ for an arbitrary number of files. Namely:

	git-update-index [--cacheinfo <mode> <object> <file>]*

However, that obviously is very much a _plumbing_ command, and you need to have some higher-level GUI on top of it to actually pick out the chunks (if that is what you want) and generate the object(s) associated with the file(s) with only those chunks and then do the above "install this state into the index/staging area/whatever".

In other words, git already supports this on a _technical_ level, but does not have the high-level interfaces for it, and quite frankly "git-update-index" _shouldn't_ have the high-level interfaces for it. It's designed to be the low-level technology, not the actual interface.

I think it's more appropriate for a GUI front-end, frankly, but you could script it fairly easily with whatever your favourite patch editing tool:

 (a) Generate the "result" file you want in /tmp or something, using patch 
     editing tools to extract a partial patch and apply it to the original 
     file.

 (b) Use "git-hash-object" to create the backing store object, and get the 
     SHA1 for that file.

 (c) Use "git-update-index --cacheinfo <mode> <sha1> <filename>" to 
     populate that new entry of yours into the index.

 (d) Do (a)-(c) as many times as you like to handle all the files you 
     want to commit, and then just call "git commit"

iow, it's not hard, but no, git on its own is _not_ a patch-based system, and doesn't do things hunk-for-hunk. You need that "hunk selector" interface on top of it.

On Fri, Dec 01, 2006 at 02:23:14PM +0300, Alexey Dobriyan wrote:

Paul Mackerras modified his dirdiff tool to do something like this. I have a couple of patches on top of his version from way back at http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary

I don't know if he has continued working on this.

Sven Verdoolaege wrote:

If this has support for git, could you add it to GitWiki:
  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
And perhaps also update related page
  http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist

Thanks in advance.

Sven Verdoolaege wrote:

If it is GPL, you can post it anyway. As I understand from log you have added git interface, isn't it? You are then perfectly in the right to post info at GitWiki about this tool.

On Mon, Dec 04, 2006 at 09:46:06PM +0100, Jakub Narebski wrote:

I think Paul added the ability to compare a git tree to a (set of) directory trees, while I add a primitive way of committing partial changes to a git branch. It's been over a year, though, so I may be mistaken.

I feel like I should check first that it hasn't been obsoleted by some other tool already and I currently don't have the time to investigate.

Sven Verdoolaege wrote:

Logs are there... ;-)
 

It doesn't look like this.