Re: What's in git.git

Junio C Hamano [off-list ref] writes:

 - 'pu' has the shallow clone WIP and a half-finished rewrite of
   git branch in C, both by Johannes.  Both needs a bit more
   polishing and confidence building before going into 'next',
   and given the recent discussion of enhancing branch
   management for pulls/pushes, it might be easier to drop the
   latter for now.

OOPS; sorry but the latter half is entirely untrue.  What's
there is half-done git-shortlog.  Scratch everything about
branch management please.

Hi,

On Sun, 19 Nov 2006, Jakub Narebski wrote:

Johannes Schindelin wrote:

quoted

On Sat, 18 Nov 2006, Junio C Hamano wrote:

IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out 
the built-in mailmap which is totally specific to the Linux kernel 
development.

See the 3 patches I just sent.

If I remember correctly besides having built-in mailmap (at least in Perl
version quite easy modificable, and updateable via Inline::Files), it also
have built-in path shortening. And that part IIRC was not solved (although
there was some proposal).

I do not understand. What paths are handled by git-shortlog?

Ciao,
Dscho

Johannes Schindelin wrote:

I do not understand. What paths are handled by git-shortlog?

I was under (perhaps false) impression that somewhere in git-shortlog 
there is shortening of
  Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
messages, shortening the URL part.

Perhaps this was only other example of hard-coded git-for-Linux-ness.
-- 
Jakub Narebski

Johannes Schindelin wrote:

On Sat, 18 Nov 2006, Junio C Hamano wrote:

quoted

OOPS; sorry but the latter half is entirely untrue.  What's
there is half-done git-shortlog.  Scratch everything about
branch management please.

IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out 
the built-in mailmap which is totally specific to the Linux kernel 
development.

If I remember correctly besides having built-in mailmap (at least in Perl
version quite easy modificable, and updateable via Inline::Files), it also
have built-in path shortening. And that part IIRC was not solved (although
there was some proposal).

The shallow clone work looks promising...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Hi,

On Sat, 18 Nov 2006, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

 - 'pu' has the shallow clone WIP and a half-finished rewrite of
   git branch in C, both by Johannes.  Both needs a bit more
   polishing and confidence building before going into 'next',
   and given the recent discussion of enhancing branch
   management for pulls/pushes, it might be easier to drop the
   latter for now.

OOPS; sorry but the latter half is entirely untrue.  What's
there is half-done git-shortlog.  Scratch everything about
branch management please.

IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out 
the built-in mailmap which is totally specific to the Linux kernel 
development.

As for shallow clone support: I am a bit underwhelmed by the enthusiasm 
to test this thing by the people I thought would be most interested. It 
really could be the case that it is not needed at all.

Just for the record, though: AFAICT the shallow stuff is lacking support 
for at least pushing from/into shallow repos and it should avoid making a 
commit shallow unnecessarily. And quite likely there are a few thinkos in 
it, so it would not hurt having more test cases (notably of things I did 
not think of), and some bad-ass testing with huge amounts of commits and 
files which were added/modified identically in different commits.

Ciao,
Dscho

Hi,

On Sun, 19 Nov 2006, Jakub Narebski wrote:

Johannes Schindelin wrote:

quoted

I do not understand. What paths are handled by git-shortlog?

I was under (perhaps false) impression that somewhere in git-shortlog 
there is shortening of
  Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
messages, shortening the URL part.

Perhaps this was only other example of hard-coded git-for-Linux-ness.

I found it: git-shortlog.perl:28 says

        $desc =~ s#/pub/scm/linux/kernel/git/#/.../#g;

And in builtin-shortlog.c:90 you can read

        const char *dot3 = "/pub/scm/linux/kernel/git/";

and in lines 133--136:

        while ((p = strstr(buffer, dot3)) != NULL) {
                memcpy(p, "...", 3);
                strcpy(p + 2, p + sizeof(dot3) - 1);
        }

So, not only did I forget that git-shortlog has the path shortening, but I 
also forgot that I implemented it in the builtin shortlog, too.

Ciao,
Dscho

On Sun, Nov 19, 2006 at 04:17:17PM CET, Johannes Schindelin wrote:

As for shallow clone support: I am a bit underwhelmed by the enthusiasm 
to test this thing by the people I thought would be most interested. It 
really could be the case that it is not needed at all.

I was underwhelmed all the same by response to my multifetch work.
Perhaps we need some better mechanism to get feedback from the
downstream users which were main requesters of the $feature (I think
that in both cases people can see how it could be useful generically but
there's not too much immediate enthusiasm for playing with it inside the
community). I think the main user of multifetch was xorg while the
primary user of shallow clones would be Mozilla, right?

It would be great if, when wishing for some large feature, they could
say something like "if this ever gets done, please prod $mailinglist and
we'll give it a stab and get you some feedback" (apparently there's
noone from there monitoring the mailing list consistently, which is
understandable though since it's not a too much low-traffic one).

Alp? (xorg) Jon? (mozilla)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."