Re: git-commit: select which files to commit while editing the commit message

Pazu [off-list ref] writes:

# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# On branch refs/heads/next
# Updated but not checked in:
#   (will commit)
#
#	modified:   perl/Makefile
#	modified:   var.c

Here's where the magic would happen. Removing the line "modified: var.c" would
remove var.c from this commit. Of course, the template message should be
modified to tell the user he can do that.

So, what do you think about this?

Personally, I would refuse to use such a modified git, because
often the first thing I would do in the commit log buffer is
check the listed files and remove the '# ...' lines while
typing.  I do not want that to affect the set of changes I
staged in any way.

But maybe that is just me.

--- Jakub Narebski <jnareb@gmail.com> wrote:

Junio C Hamano wrote:

quoted

Pazu [off-list ref] writes:

quoted

# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# On branch refs/heads/next
# Updated but not checked in:
#   (will commit)
#
#    modified:   perl/Makefile
#    modified:   var.c

Here's where the magic would happen. Removing the line "modified: var.c" would
remove var.c from this commit. Of course, the template message should be
modified to tell the user he can do that.

So, what do you think about this?

Personally, I would refuse to use such a modified git, because
often the first thing I would do in the commit log buffer is
check the listed files and remove the '# ...' lines while
typing.  I do not want that to affect the set of changes I
staged in any way.

But maybe that is just me.

I was to raise the same objection. 

But this can be solved by using magic _only_ if the template with exception
of "modified:" lines matches, and if there is at least one file
in "modified:" section.

I raise the same objection as Junio.

This is how perforce does it*, and while it is useful, git is NOT perforce,
and I agree with Junio and Jakub.

If you want to commit only few files, update the index for only
the ones you want to commit.  If you did update the index for all
of them, "git-read-tree -m -i HEAD" is your friend.

    Luben

* The reason being is that there is no "index-cache" and the commit
message needs to be scanned to determine which of the edited files
you actually intend to commit to the server at this time.

On Friday 08 December 2006 21:45, Luben Tuikov wrote:

This is how perforce does it*, and while it is useful, git is NOT perforce,
and I agree with Junio and Jakub.

However, the idea itself is not bad. AFAIK, cogito does it this way.
It could be done as separate command, e.g. "git add --interactive",
and would only update the index.

Junio C Hamano wrote:

Pazu [off-list ref] writes:

quoted

# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# On branch refs/heads/next
# Updated but not checked in:
#   (will commit)
#
#    modified:   perl/Makefile
#    modified:   var.c

Here's where the magic would happen. Removing the line "modified: var.c" would
remove var.c from this commit. Of course, the template message should be
modified to tell the user he can do that.

So, what do you think about this?

Personally, I would refuse to use such a modified git, because
often the first thing I would do in the commit log buffer is
check the listed files and remove the '# ...' lines while
typing.  I do not want that to affect the set of changes I
staged in any way.

But maybe that is just me.

I was to raise the same objection. 

But this can be solved by using magic _only_ if the template with exception
of "modified:" lines matches, and if there is at least one file
in "modified:" section.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Fri, 08 Dec 2006 11:18:16 -0800
Junio C Hamano [off-list ref] wrote:

Personally, I would refuse to use such a modified git, because
often the first thing I would do in the commit log buffer is
check the listed files and remove the '# ...' lines while
typing.  I do not want that to affect the set of changes I
staged in any way.

Your usage should not affected at all by the addition of this
feature.  One of the comment lines could be magic, in that if
it is missing the feature is disabled.  Something like:

#  *** Editable Commit List ***

Or some such at the top of the list, where if it is missing after
commit message editing, the post processing of the file list
will be completely disabled.  Another alternative would be to
just enable the feature with an  -A  or some other commit command
line option, so that those uninterested in such a feature don't
have to even see it.

It would be interesting to hear from Pasky on how this feature
has worked out in practice for Cogito users and whether he thinks
it would be a good addition to Git.