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);
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/http://qa.perl.orghttp://www.goldmark.org/jeff/stupid-disclaimers/
From: Pieter de Bie <hidden> Date: 2016-06-15 22:45:04
On 30 jul 2008, at 13:38, H.Merijn Brand wrote:
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.
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 [off-list ref]
wrote:
On 30 jul 2008, at 13:38, H.Merijn Brand wrote:
quoted
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.
You can do something almost similar with a command like:
git blame -l Makefile | git name-rev --stdin --tags
From: Lars Noschinski <hidden> Date: 2016-06-15 22:45:04
* H.Merijn Brand [off-list ref] [08-07-30 13:38]:
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)
Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
[off-list ref] wrote:
* H.Merijn Brand [off-list ref] [08-07-30 13:38]:
quoted
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)
Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
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.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/http://qa.perl.orghttp://www.goldmark.org/jeff/stupid-disclaimers/
On Wed, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" [off-list ref] wrote:
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.
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, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" [off-list ref] wrote:
quoted
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.
But a version is never unique in a distributed environment. So a version
is useless without at least an abbreviated hash.
to get the _hash_ of the _commit_ (ie. not the version of a file) that
touched the file last time.
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
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/http://qa.perl.orghttp://www.goldmark.org/jeff/stupid-disclaimers/
On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand [off-list ref] wrote:
On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
[off-list ref] wrote:
quoted
* H.Merijn Brand [off-list ref] [08-07-30 13:38]:
quoted
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)
Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
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.
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.
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 15:58, H.Merijn Brand [off-list ref] wrote:
quoted
On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
[off-list ref] wrote:
quoted
* H.Merijn Brand [off-list ref] [08-07-30 13:38]:
quoted
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)
Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
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.
quoted
The end user only has the application, which is (or at least should be)
able to spit out its release version.
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.
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.
quoted
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.