Git Questions

Git Questions

[Tom Schinckel]

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

Re: Git Questions

[Jeff King]

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

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

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)

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

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.

> b) Automatically use the default hashed-out bit:

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

Re: Git Questions

[David Kågedal]

Tom Schinckel <gunny01@gmail.com> writes:

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

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

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

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?

> Can I set up Git to:
>
> a) Automatically commit a file to the repository every time it's saved

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

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

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.

-- 
David Kågedal

Re: Git Questions

[Tom Schinckel]

On Mon, 2007-08-20 at 13:23 +0200, David Kågedal wrote:
> Tom Schinckel <gunny01@gmail.com> writes:
> 
> > Hi all,
> >
> > I've just started using git to run a repository on my local machine. I'm
> > wondering about the following questions:
> 
> You seem to have a very strange use case that you need to explain
> better.

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)

> 
> > Is it possible to change the revision numbers from long hashes to normal
> > numbers (i.e, 0001 for first, 0002 for the second)
> 
> 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?
> 

Gotcha.

> > Can I set up Git to:
> >
> > a) Automatically commit a file to the repository every time it's saved
> 
> 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).
> 
> > 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?)
> 
> 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.

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

Re: Git Questions

[Andy Parkins]

On Monday 2007 August 20, Tom Schinckel wrote:

> 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

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
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Git Questions

[Matthieu Moy]

Tom Schinckel <gunny01@gmail.com> writes:

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

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.

-- 
Matthieu

Re: Git Questions

[David Tweed]

> On Monday 2007 August 20, Tom Schinckel wrote:
>
> > 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

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.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee

Re: Git Questions

[David Tweed]

On 8/20/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> OK. AAUI, you're abusing git as a backup system.

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.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee

Re: Git Questions

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On Mon, Aug 20, 2007 at 13:59:41 +0100, David Tweed wrote:
> > On Monday 2007 August 20, Tom Schinckel wrote:
> >
> > > 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
> 
> 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.

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.

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

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]