Re: Git Questions

["David Kågedal" <davidk@lysator.liu.se>]

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