* Re: v1.5.4 plans
From: Johannes Schindelin @ 2007-12-11 12:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99999.0712102249180.555@xanadu.home>
Hi,
On Mon, 10 Dec 2007, Nicolas Pitre wrote:
> On Mon, 10 Dec 2007, Junio C Hamano wrote:
>
> > There are outstanding issues that need to be resolved:
> >
> > * We need to do something about "gc --aggressive". The documentation
> > removal patch from Linus, if it ever materializes, would be better
> > than nothing, but I have this nagging suspicion that the explosion is
> > merely a bad interation between -A and -f option to the repack, which
> > are not meant to be used together.
>
> Well, with the gcc repo, simply using 'git repack -a -f' with current
> default window size does produce a 2.1GB pack, while changing the window
> size to 100 (keeping default delta depth) produces a 400MB pack for me.
>
> So this is really a matter of not having a sufficiently large window for
> some data sets.
So my dumb patch to simply default to window and depth 250 with
aggressive was not _that_ dumb after all?
Ciao,
Dscho
^ permalink raw reply
* Re: v1.5.4 plans
From: Jeff King @ 2007-12-11 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzmqhvgq.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 10, 2007 at 05:27:17PM -0800, Junio C Hamano wrote:
> Thanks for a reminder. Anything else?
This bugfix has been sitting in my repo for a few weeks. When it last
appeared, you asked if the other code paths needed a similar fix, and I
verified that they did not, so I think it is complete as-is.
-- >8 --
git-clone: print an error message when trying to clone empty repo
Previously, cloning an empty repository looked like this:
$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org
Now we at least report that the clone was not successful.
Signed-off-by: Jeff King <peff@peff.net>
---
git-clone.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index ecf9d89..96a356d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -297,7 +297,8 @@ yes)
find objects -type f -print | sed -e 1q)
# objects directory should not be empty because
# we are cloning!
- test -f "$repo/$sample_file" || exit
+ test -f "$repo/$sample_file" ||
+ die "fatal: cannot clone empty repository"
if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
then
rm -f "$GIT_DIR/objects/sample"
--
1.5.3.7.2224.ge4a5
^ permalink raw reply related
* [RFH] leading dots in manpages
From: Jeff King @ 2007-12-11 12:42 UTC (permalink / raw)
To: git
The git-shortlog manpage has a "files" section that mentions ".mailmap".
Asciidoc correctly renders this in the HTML version, but in the manpage,
the line that should say ".mailmap" is omitted. This seems to be caused
by the line
.mailmap::
being misinterpreted somewhere (though the .xml file looks reasonable).
It looks like the same problem as 7c8b5eaf, but we just dodged the
problem there. Is there an actual fix?
-Peff
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Jeff King @ 2007-12-11 12:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pierre Habouzit, Jakub Narebski, Ingo Molnar, Christian Couder,
git
In-Reply-To: <20071211122539.GA13945@sigill.intra.peff.net>
On Tue, Dec 11, 2007 at 07:25:39AM -0500, Jeff King wrote:
> $ git show 4602c17d
> commit 4602c17d8911e14d537f6f87db02faab6e3f5d69
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Fri Dec 7 17:19:31 2007 -0800
>
> git-shortlog -e: show e-mail address as well
>
> This option shows the author's email address next to the name.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
And here is a matching documentation patch. I know, it's not a v1.5.4
bugfix, but hopefully it should be easy to review. ;)
-- >8 --
shortlog: document -e option
This was added in 4602c17d.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-shortlog.txt | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 2220ef6..e14720b 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output
SYNOPSIS
--------
[verse]
-git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s]
-git-shortlog [-n|--numbered] [-s|--summary] [<committish>...]
+git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e]
+git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [<committish>...]
DESCRIPTION
-----------
@@ -32,6 +32,9 @@ OPTIONS
-s, \--summary::
Suppress commit description and provide a commit count summary only.
+-e, \--email::
+ Show the email address of each author.
+
FILES
-----
--
1.5.3.7.2224.ge4a5
^ permalink raw reply related
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Jeff King @ 2007-12-11 12:25 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Jakub Narebski, Ingo Molnar, Christian Couder, git,
Junio C Hamano
In-Reply-To: <20071211115914.GJ30948@artemis.madism.org>
On Tue, Dec 11, 2007 at 12:59:14PM +0100, Pierre Habouzit wrote:
> > Not exactly, as it does not give us email address.
>
> maybe it should be "fixed" so that it does, not to mention that other
> concerns ingo raised look legit to me.
Perhaps Junio is a time-traveller.
$ git show 4602c17d
commit 4602c17d8911e14d537f6f87db02faab6e3f5d69
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Dec 7 17:19:31 2007 -0800
git-shortlog -e: show e-mail address as well
This option shows the author's email address next to the name.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: Something is broken in repack
From: David Kastrup @ 2007-12-11 12:18 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Nicolas Pitre, Junio C Hamano, Jon Smirl, Git Mailing List
In-Reply-To: <20071211120851.GK30948@artemis.madism.org>
Pierre Habouzit <madcoder@artemis.madism.org> writes:
> On Tue, Dec 11, 2007 at 11:08:47AM +0000, David Kastrup wrote:
>
>> Maybe address space fragmentation is involved here? malloc/free for
>> large areas works using mmap in glibc. There must be enough
>> _contiguous_ space for a new allocation to succeed.
>
> Note that I find your explanation unlikely: glibc uses mmap for
> sizes over 128k by default (IIRC), and as soon as you use mmaps,
> that's the kernel that deals with the address space, and it's not
> necessarily contiguous, that's only true for the heap.
Every single allocation needs to be contiguous in virtual address space
and must not collide with existing virtual address space allocations.
So fragmentation is at least a logistical issue.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Something is broken in repack
From: Pierre Habouzit @ 2007-12-11 12:08 UTC (permalink / raw)
To: David Kastrup; +Cc: Nicolas Pitre, Junio C Hamano, Jon Smirl, Git Mailing List
In-Reply-To: <85bq8xlc8w.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Tue, Dec 11, 2007 at 11:08:47AM +0000, David Kastrup wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Mon, 10 Dec 2007, Junio C Hamano wrote:
> >
> >> "Jon Smirl" <jonsmirl@gmail.com> writes:
> >>
> >> > 95% 530 2.8G - 1,420 total to here, previous was 1,983
> >> > 100% 1390 2.85G
> >> > During the writing phase RAM fell to 1.6G
> >> > What is being freed in the writing phase??
> >>
> >> entry->delta_data is the only thing I can think of that are freed
> >> in the function that have been allocated much earlier before entering
> >> the function.
> >
> > Yet all ->delta-data instances are limited to 256MB according to Jon's
> > config.
>
> Maybe address space fragmentation is involved here? malloc/free for
> large areas works using mmap in glibc. There must be enough
> _contiguous_ space for a new allocation to succeed.
Well, that's interesting, but there is a way to know for sure instead
of taking bets. Just use valgrind --tool=massif and look at the pretty
picture, it'll tell what was going on very accurately.
Note that I find your explanation unlikely: glibc uses mmap for sizes
over 128k by default (IIRC), and as soon as you use mmaps, that's the
kernel that deals with the address space, and it's not necessarily
contiguous, that's only true for the heap.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Pierre Habouzit @ 2007-12-11 11:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ingo Molnar, Christian Couder, git, Junio C Hamano
In-Reply-To: <m3ve75sfn3.fsf@roke.D-201>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Tue, Dec 11, 2007 at 10:13:45AM +0000, Jakub Narebski wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote:
> > > ---------{ git-authors }--------->
> > > #!/bin/bash
> > >
> > > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n
> >
> > You mean:
> > git shortlog -n -s HEAD -- "$@"
> > to do exactly the same right ? :)
>
> Not exactly, as it does not give us email address.
maybe it should be "fixed" so that it does, not to mention that other
concerns ingo raised look legit to me.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix clone not to ignore depth when performing a local clone
From: Johannes Schindelin @ 2007-12-11 11:54 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20071211064731.GA30525@hashpling.org>
Hi,
On Tue, 11 Dec 2007, Charles Bailey wrote:
> @@ -205,7 +205,10 @@ fi
> # it is local
> if base=$(get_repo_base "$repo"); then
> repo="$base"
> - local=yes
> + if test -z "$depth"
> + then
> + local=yes
> + fi
> fi
Or shorter:
- local=yes
+ test -z "$depth" && local=yes
Ciao,
Dscho
^ permalink raw reply
* Re: [Misfeature] cloning without configuration fails and returns 0
From: Benoit Sigoure @ 2007-12-11 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzlwktzzb.fsf@gitster.siamese.dyndns.org>
On Dec 9, 2007, at 2:32 AM, Junio C Hamano wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> on a new machine I have access to, I fetched tonight's git master
>> (git
>> version 1.5.3.7.g9758e) and installed it on my account in order to
>> clone one of my projects. I did not setup anything in my git config
>> and stumbled on the following misfeature:
>
> This is not a misfeature but an outright bug in an earlier fix to
> 13208572fbe8838fd8835548d7502202d1f7b21d (builtin-commit: fix --
> signoff)
>
> Can you try this and see if it works for you?
Yes, thank you.
>
> -- >8 --
> Re-fix "builtin-commit: fix --signoff"
>
> An earlier fix to the said commit was incomplete; it mixed up the
> meaning of the flag parameter passed to the internal fmt_ident()
> function, so this corrects it.
>
[...]
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> builtin-commit-tree.c | 4 ++--
> builtin-commit.c | 4 ++--
> builtin-log.c | 4 ++--
> builtin-tag.c | 4 ++--
> cache.h | 3 +++
> ident.c | 30 ++++++++++++------------------
> refs.c | 2 +-
> var.c | 4 ++--
> 8 files changed, 26 insertions(+), 29 deletions(-)
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Re: Something is broken in repack
From: David Kastrup @ 2007-12-11 11:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Jon Smirl, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712102225240.555@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 10 Dec 2007, Junio C Hamano wrote:
>
>> "Jon Smirl" <jonsmirl@gmail.com> writes:
>>
>> > 95% 530 2.8G - 1,420 total to here, previous was 1,983
>> > 100% 1390 2.85G
>> > During the writing phase RAM fell to 1.6G
>> > What is being freed in the writing phase??
>>
>> entry->delta_data is the only thing I can think of that are freed
>> in the function that have been allocated much earlier before entering
>> the function.
>
> Yet all ->delta-data instances are limited to 256MB according to Jon's
> config.
Maybe address space fragmentation is involved here? malloc/free for
large areas works using mmap in glibc. There must be enough
_contiguous_ space for a new allocation to succeed.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Sixt @ 2007-12-11 11:01 UTC (permalink / raw)
To: H.Merijn Brand
Cc: Junio C Hamano, Johannes Schindelin, Andreas Ericsson, git,
Sam Vilain
In-Reply-To: <20071211114251.78ae357a@pc09.procura.nl>
H.Merijn Brand schrieb:
> On Tue, 11 Dec 2007 10:20:55 +0100, Johannes Sixt <j.sixt@viscovery.net>
> wrote:
>
>> Junio C Hamano schrieb:
>>> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>>>> 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
>>>> at least does not conform to the expectations in the GNU world,
>>>> but chickening out like the way strbuf_addf () does is maybe a
>>>> bit too rude, so I forced a minimum of 64bytes available. That
>>>> fixes a lot!
>>>>
>>>> but it still breaks t4013 :(
>>> I think Shawn had something similar for Solaris, and if it is a small
>>> cost to help portability, it does not feel so bad.
>> Windows's vsnprintf() is broken in two regards: (1) It returns -1 if the
>> buffer is too small; (2) the size parameter is not the size of the buffer,
>> but the max. number of chars to write (i.e. does not count the NUL). How
>> broken is HP-UX's?
>
> Do you have a simple test program to show how `broken' it is?
> I have 10.20, 11.00, 11.11, 11.23/PA and 11.23/IPF and both
> HP C-ANSI-C and gcc
Sorry, no. vsnprintf's behavior on Windows is actually documented, so to be
fair it is not "broken", but "unwanted".
-- Hannes
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-11 10:42 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Johannes Schindelin, Andreas Ericsson, git,
Sam Vilain
In-Reply-To: <475E5677.9090507@viscovery.net>
On Tue, 11 Dec 2007 10:20:55 +0100, Johannes Sixt <j.sixt@viscovery.net>
wrote:
> Junio C Hamano schrieb:
> > "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> >> 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
> >> at least does not conform to the expectations in the GNU world,
> >> but chickening out like the way strbuf_addf () does is maybe a
> >> bit too rude, so I forced a minimum of 64bytes available. That
> >> fixes a lot!
> >>
> >> but it still breaks t4013 :(
> >
> > I think Shawn had something similar for Solaris, and if it is a small
> > cost to help portability, it does not feel so bad.
>
> Windows's vsnprintf() is broken in two regards: (1) It returns -1 if the
> buffer is too small; (2) the size parameter is not the size of the buffer,
> but the max. number of chars to write (i.e. does not count the NUL). How
> broken is HP-UX's?
Do you have a simple test program to show how `broken' it is?
I have 10.20, 11.00, 11.11, 11.23/PA and 11.23/IPF and both
HP C-ANSI-C and gcc
> Maybe we can share the implementation? See:
>
> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=5fd41ffacdef5454acbe51f5e23a97eb5158226d
> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e88aa8cbe816526bb0a7d37eaf2f5eb40ff36ae1
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: backups with git and inotify
From: Luciano Rocha @ 2007-12-11 10:25 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071210215746.GA3022@atjola.homenet>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
On Mon, Dec 10, 2007 at 10:57:46PM +0100, Björn Steinbrink wrote:
> On 2007.12.10 20:29:11 +0000, Luciano Rocha wrote:
<snip>
> > So, please, suggest.
>
> I posted an extremely simple bash script here:
> http://lkml.org/lkml/2007/12/7/279
That thread was what motivated me to write the program, but I must've
missed your post.
>
> It just employs inotifywait to do all watching and just needs to
> translate the events to the different git command. Did just glance over
> your code, but it seems to do basically the same thing, just that it's a
> lot shorter. The overhead of being a shell script is probably neglible,
> as the amount of git calls are likely dominating anyway.
Yes, being a shell script isn't a problem. I wasn't aware of
inotify-tools, so I wrote my own. Still, the inotify-tools programs miss
a check for ignoring directories with predetermined contents (I want to
ignore sub-directories with their own git repository).
I think I'll contribute to inotify-tools a switch for that, and switch
to perl. That will simplify the development and allow for coalescing
events, so that updates with temporary files would be a simple update.
> Feel free to ignore my comments on why I think that that is crap anyway
> and do whatever you want with the script.
FWIW, I also think that trying to keep a coherent stat with automatic
commits isn't possible. As for the temporary, unneeded files, a
exclusion pattern will suffice, and using .git directly, instead of a
(FUSE) filesystem, will allow permanent storage of those temporary
files, until explicitly removed.
Thanks,
Luciano Rocha
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-11 10:17 UTC (permalink / raw)
To: Pierre Habouzit, Christian Couder, git, Junio C Hamano
In-Reply-To: <20071211092916.GF30948@artemis.madism.org>
* Pierre Habouzit <madcoder@debian.org> wrote:
> On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote:
> > ---------{ git-authors }--------->
> > #!/bin/bash
> >
> > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n
>
> You mean:
> git shortlog -n -s HEAD -- "$@"
> to do exactly the same right ? :)
didnt know about that - i guess i wrote git-authors before even
git-shortlog existed ;-)
but i still prefer this format:
2 Serge E. Hallyn <serue@us.ibm.com>
10 Eric W. Biederman <ebiederm@xmission.com>
10 Pavel Emelyanov <xemul@openvz.org>
10 Sukadev Bhattiprolu <sukadev@us.ibm.com>
because i'm not just interested in the stats, i'm also interested in an
email address to pick. Also, the number should be the first column and
aligned, it's easier to read for humans that way. (and this summary
output is for humans.)
Ingo
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Jakub Narebski @ 2007-12-11 10:13 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Ingo Molnar, Christian Couder, git, Junio C Hamano
In-Reply-To: <20071211092916.GF30948@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote:
> > ---------{ git-authors }--------->
> > #!/bin/bash
> >
> > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n
>
> You mean:
> git shortlog -n -s HEAD -- "$@"
> to do exactly the same right ? :)
Not exactly, as it does not give us email address.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Pierre Habouzit @ 2007-12-11 9:29 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Christian Couder, git, Junio C Hamano
In-Reply-To: <20071211092446.GA4703@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote:
> ---------{ git-authors }--------->
> #!/bin/bash
>
> git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n
You mean:
git shortlog -n -s HEAD -- "$@"
to do exactly the same right ? :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-11 9:24 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano
In-Reply-To: <200712080636.12982.chriscool@tuxfamily.org>
* Christian Couder <chriscool@tuxfamily.org> wrote:
> Tell us if you have other scripts or suggestions related to
> git-bisect.
not strictly git-bisect related, but i've got the git-authors oneliner
script below that i find very useful when figuring out whom to mail to
related to a bug in any given kernel subsystem. For example when i see
some USB problem i can do:
git-authors v2.6.23.. drivers/usb/
which gives me the most active (and hence most relevant) developers in
an area:
9 Pete Zaitcev <zaitcev@redhat.com>
10 Inaky Perez-Gonzalez <inaky@linux.intel.com>
12 David Brownell <david-b@pacbell.net>
12 Oliver Neukum <oliver@neukum.org>
23 Alan Cox <alan@lxorguk.ukuu.org.uk>
49 Alan Stern <stern@rowland.harvard.edu>
with an email to pick up. In terms of accuracy this beats the
MAINTAINERS file most of the time. And even when MAINTAINERS is accurate
- in this particular case there are 48 'USB' related entries in the
MAINTAINERS file - totally hard to sort out for a newbie.
git-authors is also much easier and more natural to use - when i find
problems it's usually related to a file, and i can run this:
$ git-authors v2.6.23.. kernel/pid.c
1 Eric W. Biederman <ebiederm@xmission.com>
1 Pavel Emelianov <xemul@openvz.org>
1 Serge E. Hallyn <serue@us.ibm.com>
3 Sukadev Bhattiprolu <sukadev@us.ibm.com>
10 Pavel Emelyanov <xemul@openvz.org>
which works on a very finegrained level and gives a better "overview"
than a pure git-log. Perhaps this could be a --authorstats option of
git-log perhaps?
Ingo
---------{ git-authors }--------->
#!/bin/bash
git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n
^ permalink raw reply
* [PATCH] Add a makefile rule to regenerate .gitignore from the make variables.
From: Pierre Habouzit @ 2007-12-11 9:24 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20071211092101.GD30948@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]
This allow that the commands that moved away, were renamed, or the new
commands gets added in a simple fashion.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
This is an alternative patch that aims at solving the problem at once,
running "make ignore" or "make .gitignore" will regenerate the list of
commands and test programs and add it in a sorted way at the end.
.gitignore | 60 +++++++++++++++++++++++++++---------------------------------
Makefile | 7 +++++++
2 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/.gitignore b/.gitignore
index 5eaba41..52cb353 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,28 @@
GIT-CFLAGS
GIT-GUI-VARS
GIT-VERSION-FILE
+git-core-*/?*
+gitk-wish
+common-cmds.h
+*.tar.gz
+*.dsc
+*.deb
+git.spec
+*.exe
+*.[aos]
+*.py[co]
+config.mak
+autom4te.cache
+config.cache
+config.log
+config.status
+config.mak.autogen
+config.mak.append
+configure
+tags
+TAGS
+cscope*
+### Automatic ignore list
git
git-add
git-add--interactive
@@ -31,18 +53,17 @@ git-cvsexportcommit
git-cvsimport
git-cvsserver
git-daemon
+git-describe
git-diff
git-diff-files
git-diff-index
git-diff-tree
-git-describe
git-fast-export
git-fast-import
git-fetch
git-fetch--tool
git-fetch-pack
git-filter-branch
-git-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
@@ -59,7 +80,6 @@ git-index-pack
git-init
git-init-db
git-instaweb
-git-local-fetch
git-log
git-lost-found
git-ls-files
@@ -69,9 +89,8 @@ git-mailinfo
git-mailsplit
git-merge
git-merge-base
-git-merge-index
git-merge-file
-git-merge-tree
+git-merge-index
git-merge-octopus
git-merge-one-file
git-merge-ours
@@ -79,13 +98,14 @@ git-merge-recursive
git-merge-resolve
git-merge-stupid
git-merge-subtree
+git-merge-tree
git-mergetool
git-mktag
git-mktree
-git-name-rev
git-mv
-git-pack-redundant
+git-name-rev
git-pack-objects
+git-pack-redundant
git-pack-refs
git-parse-remote
git-patch-id
@@ -120,10 +140,6 @@ git-show
git-show-branch
git-show-index
git-show-ref
-git-ssh-fetch
-git-ssh-pull
-git-ssh-push
-git-ssh-upload
git-stash
git-status
git-stripspace
@@ -144,34 +160,12 @@ git-verify-pack
git-verify-tag
git-whatchanged
git-write-tree
-git-core-*/?*
-gitk-wish
gitweb/gitweb.cgi
test-absolute-path
test-chmtime
test-date
test-delta
-test-dump-cache-tree
test-genrandom
test-match-trees
test-parse-options
test-sha1
-common-cmds.h
-*.tar.gz
-*.dsc
-*.deb
-git.spec
-*.exe
-*.[aos]
-*.py[co]
-config.mak
-autom4te.cache
-config.cache
-config.log
-config.status
-config.mak.autogen
-config.mak.append
-configure
-tags
-TAGS
-cscope*
diff --git a/Makefile b/Makefile
index ccc9f3c..50c8b9a 100644
--- a/Makefile
+++ b/Makefile
@@ -946,6 +946,13 @@ $(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
$(XDIFF_LIB): $(XDIFF_OBJS)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)
+.gitignore: Makefile
+ $(QUIET_GEN)$(RM) $@+ && ( \
+ sed -e '/^### Automatic ignore list$$/q' $@ \
+ $(foreach p,$(sort $(OTHER_PROGRAMS) $(ALL_PROGRAMS) $(BUILT_INS)),&& echo $p) \
+ $(foreach t,$(sort $(TEST_PROGRAMS)),&& echo $t) \
+ ) > $@+ && mv $@+ $@
+ignore: .gitignore
doc:
$(MAKE) -C Documentation all
--
1.5.3.7.2224.gb695b
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [PATCH] add git-browse-help to the ignore list
From: Pierre Habouzit @ 2007-12-11 9:21 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Here is a missing new command in the ignore list. See next patch for
an alternative solution to the problem ;)
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index bac60ce..5eaba41 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ git-archive
git-bisect
git-blame
git-branch
+git-browse-help
git-bundle
git-cat-file
git-check-attr
--
1.5.3.7.2224.gb695b
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Sixt @ 2007-12-11 9:20 UTC (permalink / raw)
To: H.Merijn Brand
Cc: Junio C Hamano, Johannes Schindelin, Andreas Ericsson, git,
Sam Vilain
In-Reply-To: <7vfxy9fxh3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>> 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
>> at least does not conform to the expectations in the GNU world,
>> but chickening out like the way strbuf_addf () does is maybe a
>> bit too rude, so I forced a minimum of 64bytes available. That
>> fixes a lot!
>>
>> but it still breaks t4013 :(
>
> I think Shawn had something similar for Solaris, and if it is a small
> cost to help portability, it does not feel so bad.
Windows's vsnprintf() is broken in two regards: (1) It returns -1 if the
buffer is too small; (2) the size parameter is not the size of the buffer,
but the max. number of chars to write (i.e. does not count the NUL). How
broken is HP-UX's? Maybe we can share the implementation? See:
http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=5fd41ffacdef5454acbe51f5e23a97eb5158226d
http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e88aa8cbe816526bb0a7d37eaf2f5eb40ff36ae1
-- Hannes
^ permalink raw reply
* Re: git help -t <topic>: list the help of the commands in a given topic
From: Santi Béjar @ 2007-12-11 9:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7ijmjayl.fsf@gitster.siamese.dyndns.org>
On Dec 11, 2007 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Santi Béjar <sbejar@gmail.com> writes:
>
> > With 'git help -t' lists the available topics.
> >
> > Show a hint to get a longer list when listing the common commands.
>
> I like the idea of making the categorized command list in git(7)
> available, and agree with you that renaming common_cmds[] to cmd_list[]
> and place everything in there would be the way to go.
>
> However, I doubt about your presentation. Who are the intended
> audience and what is the expected way this is used?
The main reason for this was to be able to show a longer list in git
help. But at the end I did this topic thing. The intented audience was
the newbies looking at the "git help" output, for them to have a
longer list. Then the topic part was intended for intermidiate user
looking for even more powerfull commands.
>
> I highly suspect that it would be much easier to use if you add a mode
> to "git help" that runs the pager over the categoized command list part
> of git(7) manual page, without taking "show me list of topics" nor "show
> commands only in this topic" parameters. It is highly unlikely that a
> user knows which category an obscure command whose name he wants to
> recall is in, or can guess which category it would be classified in
> after seeing the "category list". It would be much more likely that he
> finds it easier to scan (perhaps with "/<string>") the command list with
> one line description in the pager.
OK, this makes sense. But I still think that having a longer list in
"git help -l?" with the main porcelain commands makes sense. I'll try
to do it.
Best regards,
Santi
>
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Shawn O. Pearce @ 2007-12-11 8:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: H.Merijn Brand, Johannes Schindelin, Andreas Ericsson, git,
Sam Vilain
In-Reply-To: <7vfxy9fxh3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
> > at least does not conform to the expectations in the GNU world,
> > but chickening out like the way strbuf_addf () does is maybe a
> > bit too rude, so I forced a minimum of 64bytes available. That
> > fixes a lot!
> >
> > but it still breaks t4013 :(
>
> I think Shawn had something similar for Solaris, and if it is a small
> cost to help portability, it does not feel so bad.
My Solaris change is already in your tree; on Solaris vnsprintf
will return -1 if the input buffer we gave it had a length of 0.
This can happen at odd times, depending on what is already in the
strbuf and how its buffer is. :)
The fix for Solaris turned out to be just make sure there is at
least 1 byte in the buffer before calling vsnprintf().
> > + git-index-pack -o tmp.idx test-2-7f8ead892057e78576c0329a70cc83afb113f117.pack
> > fatal: serious inflate inconsistency
>
> That sounds like a broken zlib X-<.
I think this is actually a broken pread(). Its been reported
multiple times by different people on HP-UX. Compiling with
NO_PREAD=1 resolves the issues for everyone who has tried it.
Jakub asked me for an autoconf test to look for this sort of
breakage in pread(), I have yet to come up with a theory for
what sort of breakage HP-UX is showing us here, let alone write
a test for it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] autoconf: Check autoconf version (ASCIIDOC8)
From: Jakub Narebski @ 2007-12-11 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciqhqnd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Subject: Re: [PATCH] autoconf: Check autoconf version (ASCIIDOC8)
>
> That's "Check asciidoc version".
Yep. Sorry for mistake (autoconf <-> asciidoc).
> > Check for asciidoc, and if it exists check asciidoc version, setting
> > ASCIIDOC8 when needed. Currently it just runs asciidoc in asciidoc7
> > compatibility mode (see: Documentation/Makefile).
> >
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > diff --git a/config.mak.in b/config.mak.in
> > index 7d5df9b..759470a 100644
> > --- a/config.mak.in
> > +++ b/config.mak.in
> > @@ -7,6 +7,7 @@ AR = @AR@
> > TAR = @TAR@
> > #INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
> > TCLTK_PATH = @TCLTK_PATH@
> > +ASCIIDOC=@ASCIIDOC@
>
> And this is "ASCIIDOC8=@ASCIIDOC8@", I think.
Nope. ASCIIDOC8=@ASCIIDOC8@ is in chunk below, this is for [future]
detecting asciidoc binary (so you can drop this chunk).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Junio C Hamano @ 2007-12-11 8:26 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Johannes Schindelin, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071210145123.7c34af6d@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> Summary of the changes:
>
> 1 Added a section for HP-UX in the Makefile. Note that this will
> cover most of HP-UX, but might need several changes for both
> newer HP-UX versions and 64bit environments. Will come to that
> once I've got it all running
>
> 2 HP-UX does not have <sys/select.h>. I mentioned this before
Unfortunate. It is even in POSIX.
But nothing "make -DNO_SYS_SELECT=Unfortunately" cannot fix.
> 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
> at least does not conform to the expectations in the GNU world,
> but chickening out like the way strbuf_addf () does is maybe a
> bit too rude, so I forced a minimum of 64bytes available. That
> fixes a lot!
>
> but it still breaks t4013 :(
I think Shawn had something similar for Solaris, and if it is a small
cost to help portability, it does not feel so bad.
> 4 'tr' doesn't like '\0', but wants '\000' instead.
> 5 'tr' cannot deal with character classes
Ok, that's odd (and not old fashioned, which makes even odder), but
"\000" is not too bad (unless we have to do that million places).
> 6 I don't know how to attack another HP specific problem: HP has
> a system command called 'patch' and it is *very* incompatible
> with GNU patch. Very.
I do not think there is any reason for us to rely on "GNU patch"
anymore. 4109 can have precomputed test vector instead of comparing our
output with what GNU patch of the day happens to do.
> 7 What do you expect for LOCALE's?
I am not opposed to a change that makes these tests to conditionally
skip on systems (not necessarily "platforms" but individual
"installations") that do not have locales necessary to run tests
installed, just like cvs or svn tests are skipped when they are not
installed. Especially you are not using iconv...
> + git-index-pack -o tmp.idx test-2-7f8ead892057e78576c0329a70cc83afb113f117.pack
> fatal: serious inflate inconsistency
That sounds like a broken zlib X-<.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox