Re: Two ideas for improving git's user interface

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 4048 bytes --]

On Wed, 1 Feb 2006 17:23:38 -0800 (PST), Linus Torvalds wrote:
>
> I tend to have a certain fairly constant set of changes in my working 
> tree, namely every time a release is getting closer, I always tend to have 
> the "Makefile" already updated for the new version (but not checked in: I 
> do that just before I actually tag it, so that the tag will match the 
> commit that actually changes the version).

OK. That use case I understand just fine.

> However, if the question was an even stricter "do you ever commit 
> _changes_ to a particular file where the last HEAD, the index _and_ the 
> working tree are all different", then the answer is actually "Yes" to that 
> too.

Yes, this is the question I was trying to ask. Thanks for pretending
that I had actually asked it, and then answering it as well.

> What has happened is that I have had merges that have content conflicts 
> that I fix up by hand, but exactly _because_ I fix them up by hand, I 
> actually want to re-compile the kernel and test my fixups.

OK. I hadn't anticipated this use case, but I am interested in
exploring it more fully.

> And in that case, I will actually re-apply my manual Makefile change, even 
> if that file was part of the merge changes (in which case I had had to 
> first un-apply the change in order to do the merge).

Are the un-apply and re-apply operations here primarily manual? or
does git help you much with those (beyond alerting you that the merge
cannot take place before you un-apply things)?

> The thing is, once you get used to the git "index" as a staging place, 
> it's really really powerful.

I believe that the staging operations you perform are quite desirable,
but I wonder if existing primitives in git might not provide a more
powerful basis for the kinds of operation you're performing.

For example, in the case of the not-quite-ready-to-be-committed
changes that you want to carry along, couldn't you get additional
benefits if those changes could live on their own branch? I suppose
there may be a missing operator needed to allow you to easily merge
*and* unmerge that branch if needed. Would that seem at all feasible?

If so, could your not-ready changes be implemented as some branch that
is automatically unmerged prior to commit and then re-merged
afterwards? Or something like that?

I guess the feeling I get is that staging into the index feels
conceptually similar to a commit to a branch, but it's a uniquely weak
branch (only one revision per file). And this uniqueness also
introduces complexity (the various diff operations), as well as
possibilities of confusion when committing. Meanwhile the response to
the commit confusion seems to be to add yet more complexity to commit
which doesn't seem like an improvement to me.

[I'm maybe too far out on a limb at this point, since you've
definitely identified a use case for staging in the index, and all
I've offered as an alternative is hand-waving about "branches should
be able to do that". But if nothing else, I'm floating some ideas out
loud, and next I'll try experimenting more with possibilities for
non-index staging.]

I'm already having a lot of fun with git. It's a very impressive tool,
with a surprisingly simple/powerful core.

> Actually, we do exactly that. Right now we expressly limit the "preview" 
> to just the filenames, but we literally do run
> 
> 	git-diff-index -M --cached --name-status --diff-filter=MDTCRA HEAD
>
> as part of "git status", and the eventual end result is what we will 
> populate the commit message file with for your editing pleasure.

Yes, that's a good thing to do. In my personal workflow, a
pre-populated commit message is a bit late, since I want to review and
convince myself I like things before I type the magic word "commit".

And I'm not claiming that a preview patch is impossible to generate,
I'm just saying that it's currently rather hard to figure what the correct
correspondence for arguments to diff and arguments to commit, (see
more on this point in another branch of this thread).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]