Git Questions

Hi all,

I've just started using git to run a repository on my local machine. I'm wondering about the following questions:

Is it possible to change the revision numbers from long hashes to normal numbers (i.e, 0001 for first, 0002 for the second)

Can I set up Git to:

a) Automatically commit a file to the repository every time it's saved

b) Automatically use the default hashed-out bit:

	# Please enter the commit message for your changes.
	# (Comment lines starting with '#' will not be included)
	# Updated but not checked in:
	#   (will commit)
	#
	#       modified:   TOK/bce.abw
	#
	# Untracked files:
	#   (use "git add" to add to commit)
	#
	#       TOK/bce.abw.bak~

as the commit message? (i.e, remove the hash signs and not bring up vim in the first place?)

Thanks for any help.

tom

On Mon, Aug 20, 2007 at 07:25:48PM +0930, Tom Schinckel wrote:

No, they are a fundamental part of the way git works. However, there are a few ways you can avoid using the hashes:

 - tag your commits with readable names
 - use git's syntax for relative commits (e.g., "git-show HEAD~20") will
   show you 20 commits back from the current commit (where back is
   defined by following the first parent of each commit)

If you want git to notice when files are changed and commit them, then no. You can probably configure your editor (or whatever is saving the file) to trigger a 'git-add && git-commit'. But keep in mind this will produce a lot of commits with lousy commit messages.

There isn't an argument to git-commit to do this, but you can get the same message from git-status. So you could do something like:

git-status | sed 's/^# //' | git-commit -F -

-Peff

Tom Schinckel <gunny01@gmail.com> writes:

You seem to have a very strange use case that you need to explain better.

There are no "revision numbers" in git. There is only content. The history of commits is created by having one commit point to its "parent" commit. And in git, everything is addressed by its content, by using hashes. So the long hash is a universal identifier for what it refers to. It is not a revision number in your repository, it is something that can be used by someone else who hasn't even heard of yo to refer to exactly the same thing.

So, no you can't change that. But there might be something else that you can do if you explain what you're actually after?

Probably, but remember that git doesn't track individual files. It tracks the whole tree, so you would be creating a new revision of the whole tree every time you saved that single file. Which would not create a very nice history if you are using git for something it usually is used for (tracking source code etc).

Why on earth would you want to do that? That comment doesn't contain any information about what change you committed? The list of files that were modified by the commit is already in git.

On Mon, 2007-08-20 at 13:23 +0200, David Kågedal wrote:

What I'm using it for is to essentially create a history of various documents and other files that I'm creating. So if I accidently delete something or want to make a major change in the direction of an essay or the like.

(If anyone reads Linux Format, there was an article about a year ago about "Subverting your Home Directory". I'm doing a similar thing, but with git)

Gotcha.

The reason I want to do that is so I can set up blind commits that I can add in a anacron job or something. The information about the files isn't really important

Thanks for the help: I'm using git in a uncoventional way. 

tom

On Monday 2007 August 20, Tom Schinckel wrote:

The point still stands though - what you are asking is to put information the commit message that is available outside of the commit message anyway - so why bother? If you really don't care about a commit message, then just use

 git commit -a -m ""

This commits all (-a) changed files and uses an empty commit message (-m "").

Then later, if you wanted to see a summary of a particular commit

 git show --stat <commit hash>

For example, in my currently checked out git repository:

$ git show --stat HEAD
commit 83b3df7d582429d9036f34d2c95abfff7bf0ab24
Author: Junio C Hamano <gitster@pobox.com>
Date:   Fri Jul 27 23:51:45 2007 -0700

    git-stash apply --index: optimize postprocessing
    
    Originally, "apply --index" codepath was bolted on to the
    "update working tree files and index, but then revert the
    changes we make to the index except for added files so that we
    do not forget about them" codepath, almost as an afterthought.
    Because "apply --index" first prepares the final index state
    upfront, "revert except the added paths" postprocessing does not
    have to be done.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

 git-stash.sh |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

In particular note the summary at the bottom - that's not stored in the commit message, but git is perfectly capably of telling you all about what files changed. No need to put git-status in the log message as well.

Andy

Regarding your basic intention, I've worked on something _similar_ using git and put it up on the web (although not got around to editing the git wiki) at

http://www.personal.rdg.ac.uk/~sis05dst/chronoversion.htm

(with a minor update is going to go up when 1.5.3 gets released & I test it works.) There are two important differences with what you want to do:

1. As I recall someone else saying when talking about using SCM
on their home directory (Joey Hess?), if you blanket record
everything you then end up being careful about, eg, piping a
grep search into a temporary file for some purpose, etc. So
chronoversion takes a python function that decides if a file
is "worth recording" (which can be by suffix or more general
analysis).

2. As I've got a nervous tick of saving every couple of minutes
(in case the editor or network I'm on dies), recording on save
is too fine a granularity for me, so the script is designed to
run from a cron job (I have it at once an hour) and not make
a commit if it finds nothing has changed.

As I say, not exactly what you're looking for but it might be in the right direction.

On Mon, Aug 20, 2007 at 13:59:41 +0100, David Tweed wrote:

There's inotify interface in recent Linux and there is an incron (http://inotify.aiken.cz/) tool to run action when a file changes. I didn't actually use that tool, but from description of the Debian package it looks like it could be used to run git whenever you save something.

Tom Schinckel <gunny01@gmail.com> writes:

OK. AAUI, you're abusing git as a backup system.

That's definitely not what git (and other VCS) is meant for. What git is good at is to create clean "changesets" (i.e. _you_ tell git when you have something worth recording in history), and merging. But since git is fast and disk-efficient (if you run git-gc from time to time), it can probably be a good backup tool too.

If you want to run "git commit" each time you save a file, you can probably program your editor to do so, or use something like fam/inotify. But it's probably not reasonable, you'll quickly end-up with thousands of file revisions (imagine the result if you run a script like "for i in $(whatever big thing); do echo $i >> file; done"). If I were you, I'd set up a cron job to do the commit once every (few) minute(s). If the project is not too big, it will take less than a second, and commit will fail silently if you have no modification to commit.

You'll want git to automatically add any new file, so you'll run something like

git add .

# Remove deleted files. # There's probably a better way, but I don't find it. git-ls-files --deleted -z | git-update-index --remove -z --stdin

git commit -m backup

I don't think your idea of taking the output of git-status as a commit message is necessarily relevant: this information is anyway in the commit, git-show and friends will show it. I'd say the commit message is irrelevant, and you can provide a dummy one. Otherwise, someone answered in the thread.

On 8/20/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

Just as a point, I think a better word is "archive system". (Backups are more for replicating current state in the event of a system failure. Clearly _if_ you're working on a well defined project, careful repository management is a good idea. (One of the key things you lose from automatic commits is the ability to reliably bisect stuff.)

However, not all the work one does on a computer is so focussed and well-demarcated, so in other cases keeping a history so you can, eg, look at what you're research codebase looked like when you generated the results you pasted into a paper on July 12 2005 is a useful ability, even if that sort of "looseness" wouldn't be appropriate in "product" based development.

The nice thing about git is that it's so efficient at the low levels it can be used for both "proper" SCM and archival storage.