Feature suggestion: git-hist

I've talked about this with Arjen, and he suggested to put it here. Please Cc me too, as I have little time to follow this quite busy list.

Suggestion

	Add a new command: 'git-hist' that will show a blame log of a
	single file with each line `tagged' with the most recent tag
	plus the number of changes since that tag.

Relationale.

	Coming from SCCS, each file `keeps' a version in a keyword like
	%R%.%L% which is included in the file when a release is made.
	The unix command 'what' will show all SCCS id's when used on a
	object, like

	% what probev | head -10
	probev:
		$Revision: 92453-07 linker linker crt0.o B.11.60 070209$
		probev.ic       5.27    [07/11/14]
		Make info: HP-UX B.11.00 9000/800; 14 Jul 2008, 14:52; v04.3.6.04:v82BC anrs.ic 5.5     [07/04/10]
		arsmon.ic       5.19    [08/07/09]
		controle.ic     5.40    [2008-03-18]
		goedmut.ic      5.19    [07/05/16]
		gvh.ic  5.8     [06/06/13]
		inw.ic  5.8     [06/06/12]

	All software has bugs, so has ours, and we ship updates, just as
	git makes updates available to the world. I just updated to the
	most recent 1.5.6.4.

	We make our updates available to our customers, but they
	sometimes wait weeks or months to install the updates, but still
	complain about bugs that already have been fixed and for which
	they already received an update.

	I can ask them what version they have, and I can then check if
	the complaint was already addressed in an update that was
	already released. In SCCS this was easy: they tell me the output
	of the what command, I check if the bug was fixed in a newer
	version and the answer is present. No such luck in git, as the
	stamps are (non-sequitive) SHA id's. As we moved to git, we now
	have to update those id's by hand, as the customers are used to
	it. (At least we can now use readable date formats)

Implementation

	Attached is my perl script git-hist, which is how I currently
	use it, which will show the blame log of a file, with each line
	prefixed with the tag plus changes since. So I can tell that if
	the customer runs release version 0.34, the line in question has
	been added before or after.

	* Tag all releases with a version number like 5.10.0 or
5.10.1-RC2
          (give or take the annoying quircks that git refuses some characters
           in tag names, which changed without warning in the 1.5.x track so
           I had to manually rename all my 'v 0.53' tags to loose the space)
        * Count changes since last tag

# git-hist *pm | perl -ne'63..83 and print' 09d4472 2007-12-06 13:25:58 63: allow_loose_quotes => 0, 09d4472 2007-12-06 13:25:58 64: allow_loose_escapes => 0, 09d4472 2007-12-06 13:25:58 65: allow_whitespace => 0, caf4798 2008-02-19 17:56:36 0.34 + 004 66: blank_is_undef => 0, 09d4472 2007-12-06 13:25:58 67: verbatim => 0, 09d4472 2007-12-06 13:25:58 68: types => undef, 09d4472 2007-12-06 13:25:58 69: 8648db0 2008-03-27 18:37:54 0.37 + 002 70: 09d4472 2007-12-06 13:25:58 71: _EOF => 0, 09d4472 2007-12-06 13:25:58 72: _STATUS => undef, 09d4472 2007-12-06 13:25:58 73: _FIELDS => undef, 09d4472 2007-12-06 13:25:58 74: _FFLAGS => undef, 09d4472 2007-12-06 13:25:58 75: _STRING => undef, 09d4472 2007-12-06 13:25:58 76: _ERROR_INPUT => undef, 2b95026 2008-04-04 11:10:09 0.37 + 006 77: _COLUMN_NAMES => undef, ce53d02 2008-04-06 00:40:26 0.37 + 016 78: _BOUND_COLUMNS => undef, 09d4472 2007-12-06 13:25:58 79: ); caf4798 2008-02-19 17:56:36 0.34 + 004 80: my $last_new_err = ""; 09d4472 2007-12-06 13:25:58 81: 09d4472 2007-12-06 13:25:58 82: sub new 09d4472 2007-12-06 13:25:58 83: {

	Or for a perl file

# git-hist xsutils.c | perl -ne'30..50 and print' 02ca0a6 2005-04-21 17:38:30 perl-5.9.2 + 104 30: PERL_XS_EXPORT_C void XS_attributes_bootstrap(pTHX_ CV *cv); d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 31: d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 32: d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 33: /* d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 34: * Note that only ${pkg}::bootstrap definitions should go here. d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 35: * This helps keep down the start-up time, which is especially d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 36: * relevant for users who don't invoke any features which are d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 37: * (partially) implemented here. d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 38: * d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 39: * The various bootstrap definitions can take care of doing d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 40: * package-specific newXS() calls. Since the layout of the 2136f35 2000-02-04 05:58:57 perl-5.005 + 2832 41: * bundled *.pm files is in a version-specific directory, d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 42: * version checks in these bootstrap calls are optional. d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 43: */ d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 44: 02d011f 2006-05-02 19:46:38 perl-5.9.3 + 950 45: static const char file[] = __FILE__; 02d011f 2006-05-02 19:46:38 perl-5.9.3 + 950 46: d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 47: void d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 48: Perl_boot_core_xsutils(pTHX) d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 49: { d66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 50: newXS("attributes::bootstrap", XS_attributes_bootstrap, file);

On 30 jul 2008, at 13:38, H.Merijn Brand wrote:

You can do something almost similar with a command like:

	git blame -l Makefile | git name-rev --stdin --tags

- Pieter

On Wed, 30 Jul 2008 14:03:59 +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:

Very noisy compared to my script, but it indeed comes close to what I need. This lacks the overview.

* H.Merijn Brand <h.m.brand@xs4all.nl> [08-07-30 13:38]:

Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?

On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski <lars-2008-1@usenet.noschinski.de> wrote:

If you come from a SCCS environment, the developers are used to see the version of a single file, not of the id of a fix. One of the reasons we moved from SCCS to git, is that we now can commit a group of files as a single commit, and later look at the complete picture.

We are not used to working with $SHA's, and IMHO from the end-user pov, a $SHA is less user friendly than a release number or a file version. I can remember a version, but I cannot remember a SHA.

The end user only has the application, which is (or at least should be) able to spit out its release version. That is all we can go by when we dig back into the history to see where we changed things.

One (very) big disadvantage of SCCS is that commits are on a per-file basis, and only in a single directory. This drawback still haunts me in git, as my first attempts to convert were successful in a single folder and git cannot merge folders into a single project.

Say I now have

/work/src/project/.git /work/src/project/module_a/.git /work/src/project/module_b/.git /work/src/project/module_c/.git

Which are all converted repos from SCCS, I'd like to merge the three module_# repos into the top level repo.

On Wed, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:

But a version is never unique in a distributed environment. So a version is useless without at least an abbreviated hash.

If pure hashes are not friendly enough, you can use something like:

git describe $(git rev-list -1 HEAD -- <file>)

to get the _hash_ of the _commit_ (ie. not the version of a file) that touched the file last time.

On Wed, 30 Jul 2008 16:55:34 +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:

Which is exactly what my git-hist does:

# git-hist *pm | perl -ne'63..83 and print' 09d4472 2007-12-06 13:25:58 63: allow_loose_quotes => 0, 09d4472 2007-12-06 13:25:58 64: allow_loose_escapes => 0, 09d4472 2007-12-06 13:25:58 65: allow_whitespace => 0, caf4798 2008-02-19 17:56:36 0.34 + 004 66: blank_is_undef => 0, 09d4472 2007-12-06 13:25:58 67: verbatim => 0, 09d4472 2007-12-06 13:25:58 68: types => undef, 09d4472 2007-12-06 13:25:58 69: 8648db0 2008-03-27 18:37:54 0.37 + 002 70: 09d4472 2007-12-06 13:25:58 71: _EOF => 0, 09d4472 2007-12-06 13:25:58 72: _STATUS => undef, 09d4472 2007-12-06 13:25:58 73: _FIELDS => undef, 09d4472 2007-12-06 13:25:58 74: _FFLAGS => undef, 09d4472 2007-12-06 13:25:58 75: _STRING => undef, 09d4472 2007-12-06 13:25:58 76: _ERROR_INPUT => undef, 2b95026 2008-04-04 11:10:09 0.37 + 006 77: _COLUMN_NAMES => undef, ce53d02 2008-04-06 00:40:26 0.37 + 016 78: _BOUND_COLUMNS => undef, 09d4472 2007-12-06 13:25:58 79: ); caf4798 2008-02-19 17:56:36 0.34 + 004 80: my $last_new_err = ""; 09d4472 2007-12-06 13:25:58 81: 09d4472 2007-12-06 13:25:58 82: sub new 09d4472 2007-12-06 13:25:58 83: {

What do I miss here?

fatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'

My git-hist is just a perl script that collects the combined information of

	git-log --pretty=format:'%h %ct %s'
	git-show-ref --tags
and	git-blame file

I could also make it a reformatting wrapper over several calls to

	git blame -l file | git name-rev --stdin --tags

Which is probably faster for a single file, but slower on multiple files

On Wed, Jul 30, 2008 at 17:03, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:

It cannot be described because there is no annotated tag before this commit. Add --always to show the abbreviated commit as fallback.

Santi

On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:

Or --tags to include non-annotated tags.

Avery

* Avery Pennarun <apenwarr@gmail.com> [08-07-30 18:26]:

For the intended use case, --contains; as the OP wants to know the oldest version, which contains this commit.

On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:

As git itself does:

$ git version git version 1.6.0.rc1.11.g1ce47

I think it is far better to know the version of the entire project, than the version of a single file.

You have, basically, two possibilities:

1) Add the module_# as submodules:
  http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
  http://git.or.cz/gitwiki/GitSubmoduleTutorial
2) Add the submodules as subtrees (as gitk and git-gui in git.git)
  http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Santi

On Wed, 30 Jul 2008 17:18:59 +0200, "Santi Béjar" <sbejar@gmail.com> wrote:

Yes. I agree. We us tags to `mark' the release, but with the repo's of a project (still) scattered around, it is far from ideal.

And as to a single file: I mostly know (when I fixed something) in what file I fixed it, so the first thing I do is to check that file against the revision that the customer runs.

Thanks, I'll start reading ...

On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt <benji@silverinsanity.com> wrote:

All went well
 

So far so good.

$ git merge --no-commit -s ours fnc/master i00f000/master i99f000/master include/master l00m000/master l01f000/master l02f000/master l03f000/master l06f000/master l90z000/master leerpl/master mutbev/master prtabel/master rpt/master tabellen/master zoomen/master Automatic merge went well; stopped before committing as requested

$ git commit --amend fatal: You are in the middle of a merge -- cannot amend. $ git status # On branch master nothing to commit (working directory clean)

When I start git-gui, it still shows a long commit message: Merge commit 'fnc/master'; commit 'i00f000/master'; commit 'i99f000/master'; commit 'include/master'; commit 'l00m000/master'; commit 'l01f000/master'; commit 'l02f000/master'; commit 'l03f000/master'; commit 'l06f000/master'; commit 'l90z000/master'; commit 'leerpl/master'; commit 'mutbev/master'; commit 'prtabel/master'; commit 'rpt/master'; commit 'tabellen/master'; commit 'zoomen/master'

All other areas are clear