threads / discuss / 6784

committing empty diffs

Subject: committing empty diffs

## tl;dr

5 messages between Feb 12, 2007 and Feb 12, 2007.

replies: 4people: 3as markdown or json

Don Zickus· Feb 12, 2007, 19:49 UTC · lore

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

Shawn O. Pearce· Feb 12, 2007, 20:03 UTC · re: Don Zickus · lore

Re: committing empty diffs

Don Zickus <dzickus@gmail.com> wrote:

Show 15 quoted lines

> 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.

Shawn O. Pearce· Feb 12, 2007, 20:10 UTC · re: Shawn O. Pearce · lore

Re: committing empty diffs

"Shawn O. Pearce" <spearce@spearce.org> wrote:

Show 7 quoted lines

> 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.

Don Zickus· Feb 12, 2007, 20:19 UTC · re: Shawn O. Pearce · lore

Re: committing empty diffs

On 2/12/07, Shawn O. Pearce <spearce@spearce.org> wrote:

Show 18 quoted lines

> 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.

Show 6 quoted lines

>
> 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

Linus Torvalds· Feb 12, 2007, 20:10 UTC · re: Don Zickus · lore

Re: committing empty diffs

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