committing empty diffs

committing empty diffs

[Don Zickus]

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

Re: committing empty diffs

[Shawn O. Pearce]

Don Zickus <dzickus@gmail.com> 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.

Re: committing empty diffs

[Linus Torvalds]

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

Re: committing empty diffs

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Don Zickus <dzickus@gmail.com> 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

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.

Re: committing empty diffs

[Don Zickus]

On 2/12/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Don Zickus <dzickus@gmail.com> 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.

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