Feature suggestion: git-hist

Feature suggestion: git-hist

[H.Merijn Brand]

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

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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: git-hist --]
[-- Type: application/octet-stream, Size: 1102 bytes --]

#!/pro/bin/perl

# git-hist file ...
# (c) 2008 H.Merijn Brand for PROCURA B.V.

use strict;
use warnings;

sub pr_time
{
    my @d = @_;
    sprintf "%4d-%02d-%02d %02d:%02d:%02d", 1900 + $d[5], ++$d[4], @d[3,2,1,0];
    } # pr_time

my @hsh;
my %log;
{   local @ARGV = ("git-log --pretty=format:'%h %ct %s' |");
    while (<>) {
	my ($hsh, $time, $text) = (m/^(\S+)\s+([0-9]+)\s+(.*)/);
	push @hsh, $hsh;
	$log{$hsh} = [ "", $text, pr_time localtime $time ];
	}
    }

{   local @ARGV = ("git-show-ref --tags |");
    while (<>) {
	m{(\S{7}).*/(.*)} or next;
	$log{$1}[0] = $2;
	}
    }

{   my $tag = "";
    my $inc;
    foreach my $hsh (reverse @hsh) {
	if ($log{$hsh}[0]) {
	    $tag = $log{$hsh}[0];
	    $inc = "001";
	    }
	elsif ($tag) {
	    $log{$hsh}[0] = sprintf "%-13s + %s", $tag, $inc++;
	    }
	}
    }

foreach my $file (@ARGV) {
    open my $blame, "-|", "git-blame $file" or next;
    while (<$blame>) {
	my ($hsh, $lnr, $txt) =
	    m/^\^?([0-9a-f]{7}).*?\s+([0-9]+)\)(.*)/ or next;
	printf "%.7s %s %-20s %5d:%s\n",
	    $hsh, $log{$hsh}[2], $log{$hsh}[0], $lnr, $txt;
	}
    }

Re: Feature suggestion: git-hist

[Pieter de Bie]

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

Re: Feature suggestion: git-hist

[H.Merijn Brand]

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

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

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

-- 
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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Feature suggestion: git-hist

[Lars Noschinski]

* H.Merijn Brand <h.m.brand@xs4all.nl> [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"?

Re: Feature suggestion: git-hist

[H.Merijn Brand]

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

> * H.Merijn Brand <h.m.brand@xs4all.nl> [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"?

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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Feature suggestion: git-hist

[Miklos Vajna]

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

On Wed, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> 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.

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

Re: Feature suggestion: git-hist

[H.Merijn Brand]

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

> On Wed, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> 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.

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: {

> If pure hashes are not friendly enough, you can use something like:
> 
> git describe $(git rev-list -1 HEAD -- <file>)

What do I miss here?

> git describe $(git rev-list -1 HEAD -- *pm)
fatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'

> 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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Feature suggestion: git-hist

[Santi Béjar]

On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
> <lars-2008-1@usenet.noschinski.de> wrote:
>
>> * H.Merijn Brand <h.m.brand@xs4all.nl> [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"?
>
> 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.

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

Re: Feature suggestion: git-hist

[Santi Béjar]

On Wed, Jul 30, 2008 at 17:03, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Wed, 30 Jul 2008 16:55:34 +0200, Miklos Vajna
> <vmiklos@frugalware.org> wrote:
>
>> If pure hashes are not friendly enough, you can use something like:
>>
>> git describe $(git rev-list -1 HEAD -- <file>)
>
> What do I miss here?
>
>> git describe $(git rev-list -1 HEAD -- *pm)
> fatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'
>

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

Santi

Re: Feature suggestion: git-hist

[H.Merijn Brand]

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

> On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
> > <lars-2008-1@usenet.noschinski.de> wrote:
> >
> >> * H.Merijn Brand <h.m.brand@xs4all.nl> [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"?
> >
> > 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.

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.

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

Thanks, I'll start reading ...

-- 
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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Feature suggestion: git-hist

[Avery Pennarun]

On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:
> It cannot be described because there is no annotated tag before this
> commit. Add --always to show the abbreviated commit as fallback.

Or --tags to include non-annotated tags.

Avery

Re: Merging submodules (was Re: Feature suggestion: git-hist)

[H.Merijn Brand]

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

> 
> On Jul 30, 2008, at 9:58 AM, H.Merijn Brand wrote:
> 
> > 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.
> 
> Following the example of Linus, the following is completely untested.
> 
> First you fetch all of the heads/tags/etc into the superproject with  
> commands like
> 
> git fetch module_a refs/heads/*:refs/remotes/module_a/*
> git fetch module_b refs/heads/*:refs/remotes/module_b/*
> git fetch module_c refs/heads/*:refs/remotes/module_c/*

All went well
 
> Then you do something like:
> 
> rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> git add module_a module_b module_c
> git commit # Needed because '-s ours' uses current HEAD, not index

So far so good.

> git merge --no-commit -s ours module_a/master module_b/master module_c/master

$ 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

$ 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

> From this point on, the project repository has a merged history of  
> the sub-projects, and if anyone doesn't catch up and still makes a  
> commit on a subproject you can use "git merge -s subtree" to merge it  
> in anyway.
> 
> You may need to "git rm --cached" some files after the "git add" step  
> if your .gitignore files aren't perfect.

-- 
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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Feature suggestion: git-hist

[Lars Noschinski]

* Avery Pennarun <apenwarr@gmail.com> [08-07-30 18:26]:
>On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:
>> It cannot be described because there is no annotated tag before this
>> commit. Add --always to show the abbreviated commit as fallback.
>
>Or --tags to include non-annotated tags.

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

Re: Merging submodules (was Re: Feature suggestion: git-hist)

[Brian Gernhardt]

This message got eaten by a syntax error somewhere.  This is a re-send, sorry for any duplicate messages.

On Jul 30, 2008, at 12:26 PM, H.Merijn Brand wrote:

> On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
> <benji@silverinsanity.com> wrote:
> 
> > Then you do something like:
> > 
> > rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> > git add module_a module_b module_c
> > git commit # Needed because '-s ours' uses current HEAD, not index
> 
> So far so good.
> 
> > git merge --no-commit -s ours module_a/master module_b/master module_c/master
> 
> $ 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
> 
> $ git commit --amend
> fatal: You are in the middle of a merge -- cannot amend.

Hm.  I did mention this was completely untested, yes?  The problem comes
from the fact that '-s ours' wants to use HEAD, not the index.  But you
can't amend a normal commit into a merge, apparently.  And I don't think
you want a commit that adds the files and a commit that "does the merge"
as two separate steps.

Well, I don't know how to make the porcelain do this then. But the
plumbing can definitely do it.  Hopefully someone more used to doing
strange things like this can give a simpler recipe, but this should
work.

# First reset to the commit you made with all the modules added.
vim commit-message # Create a merge message
commit=$(git commit-tree HEAD: -p HEAD^ -p module_a/master -p
		module_b/master -p module_c/master < commit-message)
git update-ref HEAD $commit  # Update your current ref

~~ Brian

Re: Merging submodules (was Re: Feature suggestion: git-hist)

[H.Merijn Brand]

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

On Wed, 30 Jul 2008 19:03:37 -0400, Brian Gernhardt
<benji@silverinsanity.com> wrote:

> This message got eaten by a syntax error somewhere.  This is a re-send, sorry for any duplicate messages.
> 
> On Jul 30, 2008, at 12:26 PM, H.Merijn Brand wrote:
> 
> > On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
> > <benji@silverinsanity.com> wrote:
> > 
> > > Then you do something like:
> > > 
> > > rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> > > git add module_a module_b module_c
> > > git commit # Needed because '-s ours' uses current HEAD, not index
> > 
> > So far so good.
> > 
> > > git merge --no-commit -s ours module_a/master module_b/master module_c/master
> > 
> > $ 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
> > 
> > $ git commit --amend
> > fatal: You are in the middle of a merge -- cannot amend.
> 
> Hm.  I did mention this was completely untested, yes?  The problem comes
> from the fact that '-s ours' wants to use HEAD, not the index.  But you
> can't amend a normal commit into a merge, apparently.  And I don't think
> you want a commit that adds the files and a commit that "does the merge"
> as two separate steps.
> 
> Well, I don't know how to make the porcelain do this then. But the
> plumbing can definitely do it.  Hopefully someone more used to doing
> strange things like this can give a simpler recipe, but this should
> work.
> 
> # First reset to the commit you made with all the modules added.
> vim commit-message # Create a merge message
> commit=$(git commit-tree HEAD: -p HEAD^ -p module_a/master -p
                                 ^^^^^^^^
had to remove that part

> 		module_b/master -p module_c/master < commit-message)
> git update-ref HEAD $commit  # Update your current ref

Some history
---
I'm aware I started at the wrong end of being a git user. I had to move
from SCCS to `something better', and at that point only git, svn, and
hq seemed to be likely candidates.

hq being python, and our company not using python, but perl, made that
an easy drop. I gave up compiling svn on HP-UX in 64bit mode after
about a week, mainly because it depended on way too many things, and
the new VCS has to run on this platform, as it is our main development
system. I got git up and running in two days (compile in less than two
hours, but then I got to chase HP-UX and 64bit oddities).

By the I knew a lot about the git source code, make files, and test
scripts, but still had no idea about the whole plumbing/porcelain
approach. The plan was to make that someone else's job.

Once it was up and running, I had to create a way to convert all our
SCCS repo's to git, so we could get started and test if it met our
needs. That part went smooth, and with a little help from Sam Villain
to get some speed into the conversions using git-fast-import, it is now
available to the public on CPAN as VCS::SCCS, with git2sccs in the
examples folder.

Using git-gui and gitk my users were enthousiastic, and they saw all
the advantages of using git over SCCS. Of course, with every change
there are a few (serious) drawbacks, but we have to live with those.

Being a perl5 porter/maintainer, I was used to p4v (perforce) and still
wonder why there are two GUI's instead of just one, and why they don't
offer the functionality I love in p4v. Not that I think perforce is
better than git, but their GUI certainly is.
---

So, back to this merging issue. Now you might understand why I have all
those `silly' questions and have (still) no good idea of what all these
commands do. (The person that were to do all that never came into the
picture). I'm learning.

I'm VERY happy and thankful for the help I get from you here, and I get
the impression that my feedback on getting git running in our somewhat
different environment to you is also appreciated.

I had to cut down my number of modules to merge, as I got an error that
the maximum number of merges was 16. I had 18.

I will now be playing with the results a bit. I have attached the
script, in case you might want to use it in documentation or examples.
For now, all the mods are hardcoded. No arguments and so on.

Again, Thanks!

$ bash git-merge-mods.sh
Re-initialize GIT repo
Initialized empty Git repository in /work/lep/4gl/.git/
Recovering original module repo's
Fetching for i00f000
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 24 (delta 9), reused 24 (delta 9)
Unpacking objects: 100% (24/24), done.
From i00f000
 * [new branch]      master     -> i00f000/master
Fetching for i99f000
:
:
Receiving objects: 100% (356/356), 139.05 KiB, done.
Resolving deltas: 100% (180/180), done.
From rpt
 * [new branch]      master     -> rpt/master
Removing module repo's
Adding modules
Commit
Merge
Automatic merge went well; stopped before committing as requested
Commit
=========
53229f046c5d85d11bbd500cf04b468fd3f62c08
=========
Update
$




-- 
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.org      http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: git-merge-mods.sh --]
[-- Type: application/x-shellscript, Size: 1057 bytes --]