committing empty diffs

I was toying around with the idea of keeping track of scripts or
config files in my home directory.  Most of the time my commits would
include a change to the file I was tracking.  However, there are a
couple of cases where I wanted to commit empty diffs.  For example,
ideas or todos about that particular file that I didn't want to embed
in the file itself nor write it in yet another file labeled ideas or
todos.  I thought it would be easier to just to run a 'git log' on the
file and see my whole thought process.

Considering git-commit doesn't allow this (probably for good reason),
is it technically safe to do the following sequence of events?

tree=$(git-write-tree)  #basically the same tree HEAD points to
commit=$(echo $IDEAS | git-commit-tree $tree -p HEAD)
git-update-ref HEAD $commit HEAD

I figured all a commit is doing is taking a snapshot of a particular
tree at a moment in time.  And taking multiple snapshots at that same
moment and stringing them together (pointed to by HEAD) wouldn't be a
big deal.

Am I going to wind up shooting myself in the foot later or will this
work?  Light testing didn't show any issues.  Thought I would ask the
experts.  Thanks.

Cheers,
Don

Don Zickus [off-list ref] wrote:

Considering git-commit doesn't allow this (probably for good reason),
is it technically safe to do the following sequence of events?

tree=$(git-write-tree)  #basically the same tree HEAD points to
commit=$(echo $IDEAS | git-commit-tree $tree -p HEAD)
git-update-ref HEAD $commit HEAD

I figured all a commit is doing is taking a snapshot of a particular
tree at a moment in time.  And taking multiple snapshots at that same
moment and stringing them together (pointed to by HEAD) wouldn't be a
big deal.

Am I going to wind up shooting myself in the foot later or will this
work?  Light testing didn't show any issues.  Thought I would ask the
experts.  Thanks.

No, it won't break anything.

I do that empty commit myself for a different reason.  I wouldn't
recommend that you do that with public history, and since the file
didn't change in that commit you cannot do `git log -- foo.c` to
see which notes you wrote about foo.c.  But `git log` will still
show you the messages.

-- 
Shawn.

On Mon, 12 Feb 2007, Don Zickus wrote:

Considering git-commit doesn't allow this (probably for good reason),
is it technically safe to do the following sequence of events?

Yes. There's nothing *technically* wrong with an empty commit. The reason 
"git commit" doesn't do it is that it's just almost always a mistake.

tree=$(git-write-tree)  #basically the same tree HEAD points to
commit=$(echo $IDEAS | git-commit-tree $tree -p HEAD)
git-update-ref HEAD $commit HEAD

If you know ahead-of-time that the tree is HEAD, there's no reason to do 
the "git-write-tree". You can just use "HEAD^{tree}" instead (and in 
fact, I think git-commit-tree will happily just take HEAD directly).

And please give a log messages for "git-update-ref"

Please do make sure to do some of the other sanity checks that "git 
commit" does, though. It is a good idea to at least verify that the commit 
message isn't empty etc.

		Linus

"Shawn O. Pearce" [off-list ref] wrote:

Don Zickus [off-list ref] wrote:

quoted

Considering git-commit doesn't allow this (probably for good reason),
is it technically safe to do the following sequence of events?

tree=$(git-write-tree)  #basically the same tree HEAD points to
commit=$(echo $IDEAS | git-commit-tree $tree -p HEAD)
git-update-ref HEAD $commit HEAD

This can also be written shorter, and safer:

	head=$(git-rev-parse --verify HEAD^0)
	commit=$(echo $IDEAS | git-commit-tree $head^{tree} -p $head)
	git-update-ref HEAD $commit $head

The reason you do it like this is it prevents a HEAD which was
modified between the time you did git-commit-tree and git-update-ref
from being lost.

And the write-tree is completely unnecessary, and might actually
write out a dirty-index, which would make your ideas commit actually
modifying files - not what you wanted.

-- 
Shawn.

On 2/12/07, Shawn O. Pearce [off-list ref] wrote:

Don Zickus [off-list ref] wrote:

quoted

Considering git-commit doesn't allow this (probably for good reason),
is it technically safe to do the following sequence of events?

tree=$(git-write-tree)  #basically the same tree HEAD points to
commit=$(echo $IDEAS | git-commit-tree $tree -p HEAD)
git-update-ref HEAD $commit HEAD

I figured all a commit is doing is taking a snapshot of a particular
tree at a moment in time.  And taking multiple snapshots at that same
moment and stringing them together (pointed to by HEAD) wouldn't be a
big deal.

Am I going to wind up shooting myself in the foot later or will this
work?  Light testing didn't show any issues.  Thought I would ask the
experts.  Thanks.

No, it won't break anything.

Great.

I do that empty commit myself for a different reason.  I wouldn't
recommend that you do that with public history, and since the file
didn't change in that commit you cannot do `git log -- foo.c` to
see which notes you wrote about foo.c.  But `git log` will still
show you the messages.

Hmm.  Good point.

Cheers,
Don