* Re: pseudo initial empty commit and tag for git-log and git-describe?
From: Linus Torvalds @ 2006-09-20 15:12 UTC (permalink / raw)
To: Nguyá»n Thái Ngá»c Duy; +Cc: git
In-Reply-To: <fcaeb9bf0609200658p3f04df7oe91ddb971787bd70@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1106 bytes --]
On Wed, 20 Sep 2006, Nguyá»n Thái Ngá»c Duy wrote:
>
> I'm still uncomfortable with git-log -p unable to show the first
> commit (git-whatchanged too).
Both of those work fine with "--root". That option tells git: "I'm
interested in the root patch too".
It might make sense to have "--root" be the default, but the problem is
that for projects like the Linux kernel where the first commit is a big
import, showing it as a patch simply doesn't make sense.
So it would have to be a per-repository decision, depending on whether the
repo considers the first commit to be an import or not. Maybe a git-config
option?
> Also git-describe refuses to work without any tag.
Now, that's arguably a real bug. You should be able to describe any
commit, and if there's no tag that is reachable from it, the "description"
should probably just be the SHA1 of the commit.
(Side issue: we should probably also accept the output of "git describe"
as a revision name, since it's a bit silly that you can ask git to
"describe" a revision, but then git can't actually use the description
itself ;)
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Linus Torvalds @ 2006-09-20 15:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060920105133.GL8259@pasky.or.cz>
On Wed, 20 Sep 2006, Petr Baudis wrote:
> Dear diary, on Wed, Sep 20, 2006 at 05:35:02AM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
> >
> > When I click "summary" for the glibc-cvs.git tree, I get just a
> >
> > <div class="title"> </div>
> > -------------------^
> >
> > thing back.
> >
> > Broken gitweb?
>
> That's the start of the summary table. Did you wait long enough here? It
> takes a while before the refs are processed and your browser might not
> show you the data received meanwhile.
It's _definitely_ broken for me. But it looks like that may be a firefox
on ppc issue (even if other sites work fine), because I don't have the
same problem on my Mac Mini. Strange.
Maybe it's a "yum install" that upgraded firefox while it was running or
something.
Linus
^ permalink raw reply
* git pull for update of netdev fails.
From: Stephen Hemminger @ 2006-09-20 15:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
Jeff, you use branches on the netdev tree, but GIT doesn't seem to like
to sync these up properly. My normal method is to keep a clone'd version
of the netdev tree and use pull to resync it. I don't do any changes
to that tree.
This doesn't work with all the branches for some reason. Is this a git
bug?
$ git pull
Generating pack...
Done counting 666 objects.
Result has 400 objects.
Deltifying 400 objects.
100% (400/400) done
Unpacking 400 objects
Total 400, written 400 (delta 324), reused 0 (delta 0)
100% (400/400) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
from f04b92e97d21b1921c91ec1d6d5e8bbf8606b77a to e478bec0ba0a83a48a0f6982934b6de079e7e6b3
* refs/heads/e100-sbit: does not fast forward to branch 'e100-sbit' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6;
not updating.
A temporary workaround is to prune the offending branches locally
first, but that seems like a hack.
^ permalink raw reply
* Re: [PATCH] gitweb: Support for custom per-project owner string
From: Junio C Hamano @ 2006-09-20 15:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060919225522.GB13132@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Also, ideally this would be in the configfile but calling repoconfig for
> each repository in the index would slow things down way too much.
Hmph. I wonder why. We do read description already from a file
so maybe we would want a faster way to access the config file to
grab gitweb.* variables in a single call?
In any case, I like where this patch is going and agree that
file owner should be overridable with something like this.
^ permalink raw reply
* Re: pseudo initial empty commit and tag for git-log and git-describe?
From: Matthias Kestenholz @ 2006-09-20 14:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0609200658p3f04df7oe91ddb971787bd70@mail.gmail.com>
hello
On Wed, 2006-09-20 at 20:58 +0700, Nguyễn Thái Ngọc Duy wrote:
> I'm still uncomfortable with git-log -p unable to show the first
> commit (git-whatchanged too). Also git-describe refuses to work
> without any tag. I'm thinking about adding a pseudo empty commit
> together with a tag so that these commands work. The commit and tag
> will be created at runtime. They do not actually exist in the object
> database. I haven't thought about how to implement it yet.
> Any other ideas?
you can use git log -p --root to also display the root commit.
Matthias
^ permalink raw reply
* pseudo initial empty commit and tag for git-log and git-describe?
From: Nguyễn Thái Ngọc Duy @ 2006-09-20 13:58 UTC (permalink / raw)
To: git
I'm still uncomfortable with git-log -p unable to show the first
commit (git-whatchanged too). Also git-describe refuses to work
without any tag. I'm thinking about adding a pseudo empty commit
together with a tag so that these commands work. The commit and tag
will be created at runtime. They do not actually exist in the object
database. I haven't thought about how to implement it yet.
Any other ideas?
--
Duy
^ permalink raw reply
* Re: [OT] What do you use to find message on git mailing list with given Message-Id?
From: Jakub Narebski @ 2006-09-20 12:09 UTC (permalink / raw)
To: git
In-Reply-To: <20060920114412.GM8259@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Sep 20, 2006 at 01:11:02PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> What do you use to find message on git mailing list (or LKML) with given
>> Message-Id? Do you use some mailing list archive? Is there a way to find
>> URL pointing to archived version of email given by Message-Id?
>
> Unfortunately I haven't found any either. I use /~i <messageid> in
> mutt.
I have found two places for git mailing list. I was hoping for something
more universal, but alas, no such luck (and most probably not possible)
Example Message-ID:
Message-ID: <200609200739.48732.alan@chandlerfamily.org.uk>
Links to git mailing list archive: MARC and GMane (out of MARC, GMane,
Gelato, Spinics, mail-archive)
http://marc.theaimsgroup.com/?i=200609200739.48732.alan%20()%20chandlerfamily%20!%20org%20!%20uk
http://news.gmane.org/find-root.php?message_id=<200609200739.48732.alan@chandlerfamily.org.uk>
As you can see, MARC needs some munging.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [OT] What do you use to find message on git mailing list with given Message-Id?
From: Petr Baudis @ 2006-09-20 11:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eer7k5$poj$1@sea.gmane.org>
Dear diary, on Wed, Sep 20, 2006 at 01:11:02PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> What do you use to find message on git mailing list (or LKML) with given
> Message-Id? Do you use some mailing list archive? Is there a way to find
> URL pointing to archived version of email given by Message-Id?
Unfortunately I haven't found any either. I use /~i <messageid> in
mutt.
> I thought that link to message with given Message-ID would be useful both on
> GitWiki, and as example committag.
I concur, Message-ID is IMHO underused in general.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [OT] What do you use to find message on git mailing list with given Message-Id?
From: Jakub Narebski @ 2006-09-20 11:11 UTC (permalink / raw)
To: git
What do you use to find message on git mailing list (or LKML) with given
Message-Id? Do you use some mailing list archive? Is there a way to find
URL pointing to archived version of email given by Message-Id?
I thought that link to message with given Message-ID would be useful both on
GitWiki, and as example committag.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Jakub Narebski @ 2006-09-20 11:00 UTC (permalink / raw)
To: git; +Cc: Andy Whitcroft
In-Reply-To: <4511173D.7020702@shadowen.org>
Andy Whitcroft wrote:
> Jakub Narebski wrote:
> > Andy Whitcroft wrote:
> >
> >> + open(H, "git-for-each-ref --format='%(objectname) %(refname)'|") or
> >
> > By the way, this is equivalent to using "git-show-ref" introduced by Linus.
> > But if you want commit timestamp
> >
> >> cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
> >> out the sha1's in order to work out what time the last commit on
> >> that branch was made (in CVS) thus allowing incremental updates.
> >
> > you can use it in --format as well.
>
> Unfortuantly, for-each-ref only offers us the textual version of this
> information not the numeric offset from the epoch which is what
> cvsimport is after.
>
> I guess we could teach for-each-ref to output this as well? Perhaps
> something like authorstamp?
Or authorepoch.
I thought about following rpm idea of format modifiers, like
authorepoch:date for strftime(3) "%c" format or
commiterepoch:day for strftime(3) "%a %b %d %Y" format.
Feel free to provide patches ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Petr Baudis @ 2006-09-20 10:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609192033050.4388@g5.osdl.org>
Dear diary, on Wed, Sep 20, 2006 at 05:35:02AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
>
>
> On Wed, 20 Sep 2006, Petr Baudis wrote:
> >
> > It's running at
> >
> > http://repo.or.cz/
>
> Well, "running" may be putting it a bit strongly.
>
> When I click "summary" for the glibc-cvs.git tree, I get just a
>
> <div class="title"> </div>
> -------------------^
>
> thing back.
>
> Broken gitweb?
That's the start of the summary table. Did you wait long enough here? It
takes a while before the refs are processed and your browser might not
show you the data received meanwhile.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [PATCH 2/2] cvsimport move over to using git for each ref to read refs V2
From: Andy Whitcroft @ 2006-09-20 10:31 UTC (permalink / raw)
To: git
In-Reply-To: <4511173D.7020702@shadowen.org>
cvsimport: move over to using git-for-each-ref to read refs V2
cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
out the sha1's in order to work out what time the last commit on
that branch was made (in CVS) thus allowing incremental updates.
However, this takes no account of hierachical refs naming producing
the following error for each directory in $GIT_DIR/refs:
Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 503.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-cvsimport line 505.
usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
Take advantage of the new packed refs work to use the new
for-each-ref iterator to get this information. Use the format
specifier to ensure we are neutral to changes in default.
[Junio: although although for-each-ref offers a --perl quoting mode
this patch does not use it as it seems only to make parsing the
output harder in perl. If there is a neat trick for handling this
'perl' form please educate me. Here, rely on sha1's and refnames
to contain no spaces.]
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e5a00a1..5b13c23 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -495,22 +495,17 @@ unless(-d $git_dir) {
$tip_at_start = `git-rev-parse --verify HEAD`;
# Get the last import timestamps
- opendir(D,"$git_dir/refs/heads");
- while(defined(my $head = readdir(D))) {
- next if $head =~ /^\./;
- open(F,"$git_dir/refs/heads/$head")
- or die "Bad head branch: $head: $!\n";
- chomp(my $ftag = <F>);
- close(F);
- open(F,"git-cat-file commit $ftag |");
- while(<F>) {
- next unless /^author\s.*\s(\d+)\s[-+]\d{4}$/;
- $branch_date{$head} = $1;
- last;
- }
- close(F);
+ open(H, "git-for-each-ref --format='%(objectname) %(refname) %(authorstamp)'|") or
+ die "Cannot run git-for-each-ref: $!\n";
+ while(defined(my $entry = <H>)) {
+ chomp($entry);
+ my ($ftag, $name, $stamp, $zone) = split(/ /, $entry, 4);
+ next if ($name !~ m@^refs/heads/(.*)$@);
+ my ($head) = ($1);
+
+ $branch_date{$head} = $stamp;
}
- closedir(D);
+ close(H);
}
-d $git_dir
^ permalink raw reply related
* [PATCH 1/2] for each ref add a raw timestamp field type
From: Andy Whitcroft @ 2006-09-20 10:31 UTC (permalink / raw)
To: git
In-Reply-To: <4511173D.7020702@shadowen.org>
for-each-ref: add a raw timestamp field type
cvsimport is interested in the raw time stamps (in seconds since
the epoch) to do its time comparisons. Export the raw timestamp under
{author,committer,tagger}stamp.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 698618b..9d6c4f0 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -51,14 +51,17 @@ static struct {
{ "authorname" },
{ "authoremail" },
{ "authordate", FIELD_TIME },
+ { "authorstamp", FIELD_TIME },
{ "committer" },
{ "committername" },
{ "committeremail" },
{ "committerdate", FIELD_TIME },
+ { "committerstamp", FIELD_TIME },
{ "tagger" },
{ "taggername" },
{ "taggeremail" },
{ "taggerdate", FIELD_TIME },
+ { "taggerstamp", FIELD_TIME },
{ "subject" },
{ "body" },
{ "contents" },
@@ -344,9 +347,10 @@ static char *copy_email(const char *buf)
return line;
}
-static void grab_date(const char *buf, struct atom_value *v)
+static void grab_date(const char *buf, struct atom_value *v, int raw)
{
const char *eoemail = strstr(buf, "> ");
+ const char *eol = strchr(buf, '\n');
char *zone;
unsigned long timestamp;
long tz;
@@ -359,7 +363,15 @@ static void grab_date(const char *buf, s
tz = strtol(zone, NULL, 10);
if ((tz == LONG_MIN || tz == LONG_MAX) && errno == ERANGE)
goto bad;
- v->s = xstrdup(show_date(timestamp, tz, 0));
+ if (raw) {
+ int len = (eol - eoemail - 2);
+ char *stamp = xmalloc(len + 1);
+
+ memcpy(stamp, eoemail + 2, len);
+ stamp[len] = 0;
+ v->s = stamp;
+ } else
+ v->s = xstrdup(show_date(timestamp, tz, 0));
v->ul = timestamp;
return;
bad:
@@ -386,7 +398,8 @@ static void grab_person(const char *who,
if (name[wholen] != 0 &&
strcmp(name + wholen, "name") &&
strcmp(name + wholen, "email") &&
- strcmp(name + wholen, "date"))
+ strcmp(name + wholen, "date") &&
+ strcmp(name + wholen, "stamp"))
continue;
if (!wholine)
wholine = find_wholine(who, wholen, buf, sz);
@@ -399,7 +412,9 @@ static void grab_person(const char *who,
else if (!strcmp(name + wholen, "email"))
v->s = copy_email(wholine);
else if (!strcmp(name + wholen, "date"))
- grab_date(wholine, v);
+ grab_date(wholine, v, 0);
+ else if (!strcmp(name + wholen, "stamp"))
+ grab_date(wholine, v, 1);
}
}
^ permalink raw reply related
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Andy Whitcroft @ 2006-09-20 10:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eer19l$6hm$1@sea.gmane.org>
Jakub Narebski wrote:
> Andy Whitcroft wrote:
>
>> + open(H, "git-for-each-ref --format='%(objectname) %(refname)'|") or
>
> By the way, this is equivalent to using "git-show-ref" introduced by Linus.
> But if you want commit timestamp
>
>> cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
>> out the sha1's in order to work out what time the last commit on
>> that branch was made (in CVS) thus allowing incremental updates.
>
> you can use it in --format as well.
Unfortuantly, for-each-ref only offers us the textual version of this
information not the numeric offset from the epoch which is what
cvsimport is after.
I guess we could teach for-each-ref to output this as well? Perhaps
something like authorstamp?
-apw
^ permalink raw reply
* [PATCH] gitk(1): mention --all
From: Jonas Fonseca @ 2006-09-20 10:23 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/gitk.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
Someone on #git asked for --all and it probably deserves to be mentioned
in gitk(1).
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 23be005..f1aeb07 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -37,6 +37,10 @@ frequently used options.
Show commits older than a specific date.
+--all::
+
+ Show all branches.
+
<revs>::
Limit the revisions to show. This can be either a single revision
@@ -63,6 +67,11 @@ gitk --since="2 weeks ago" \-- gitk::
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
+gitk --max-count=100 --all -- Makefile::
+
+ Show at most 100 changes made to the file 'Makefile'. Instead of only
+ looking for changes in the current branch look in all branches.
+
See Also
--------
'qgit(1)'::
--
1.4.2.1.gca4e
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Fix trivial typos and inconsistencies in hooks documentation
From: Jonas Fonseca @ 2006-09-20 10:15 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200609200739.48732.alan@chandlerfamily.org.uk>
Pointed out by Alan Chandler.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/hooks.txt | 56 ++++++++++++++++++++++++-----------------------
1 files changed, 28 insertions(+), 28 deletions(-)
Alan Chandler <alan@chandlerfamily.org.uk> wrote Wed, Sep 20, 2006:
> I don't have the source of git on my machine as I am just working from the
> debian packages, so I don't have a patch. However there is a trivial type on
> the hooks.html documentation that I gues comes from the Documentation
> directory
>
> The first sentence for both "update" and "post-update" hooks has an
> extra "is", marked in capitals below
>
> "This hook is invoked by git-receive-pack on the remote repository, which IS
> happens when a git push is done on a local repository."
I fixed those and a few AsciiDoc markup problems, and tried to generally
make it more consistent in its markup.
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index 898b4aa..517f49b 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -5,8 +5,7 @@ Hooks are little scripts you can place i
directory to trigger action at certain points. When
`git-init-db` is run, a handful example hooks are copied in the
`hooks` directory of the new repository, but by default they are
-all disabled. To enable a hook, make it executable with `chmod
-+x`.
+all disabled. To enable a hook, make it executable with `chmod +x`.
This document describes the currently defined hooks.
@@ -16,16 +15,16 @@ applypatch-msg
This hook is invoked by `git-applypatch` script, which is
typically invoked by `git-applymbox`. It takes a single
parameter, the name of the file that holds the proposed commit
-log message. Exiting with non-zero status causes the
-'git-applypatch' to abort before applying the patch.
+log message. Exiting with non-zero status causes
+`git-applypatch` to abort before applying the patch.
The hook is allowed to edit the message file in place, and can
be used to normalize the message into some project standard
format (if the project has one). It can also be used to refuse
the commit after inspecting the message file.
-The default applypatch-msg hook, when enabled, runs the
-commit-msg hook, if the latter is enabled.
+The default 'applypatch-msg' hook, when enabled, runs the
+'commit-msg' hook, if the latter is enabled.
pre-applypatch
--------------
@@ -39,8 +38,8 @@ after application of the patch not commi
It can be used to inspect the current working tree and refuse to
make a commit if it does not pass certain test.
-The default pre-applypatch hook, when enabled, runs the
-pre-commit hook, if the latter is enabled.
+The default 'pre-applypatch' hook, when enabled, runs the
+'pre-commit' hook, if the latter is enabled.
post-applypatch
---------------
@@ -61,9 +60,9 @@ invoked before obtaining the proposed co
making a commit. Exiting with non-zero status from this script
causes the `git-commit` to abort.
-The default pre-commit hook, when enabled, catches introduction
+The default 'pre-commit' hook, when enabled, catches introduction
of lines with trailing whitespaces and aborts the commit when
-a such line is found.
+such a line is found.
commit-msg
----------
@@ -79,8 +78,8 @@ be used to normalize the message into so
format (if the project has one). It can also be used to refuse
the commit after inspecting the message file.
-The default commit-msg hook, when enabled, detects duplicate
-Signed-off-by: lines, and aborts the commit when one is found.
+The default 'commit-msg' hook, when enabled, detects duplicate
+"Signed-off-by" lines, and aborts the commit if one is found.
post-commit
-----------
@@ -91,23 +90,24 @@ parameter, and is invoked after a commit
This hook is meant primarily for notification, and cannot affect
the outcome of `git-commit`.
-The default post-commit hook, when enabled, demonstrates how to
+The default 'post-commit' hook, when enabled, demonstrates how to
send out a commit notification e-mail.
update
------
This hook is invoked by `git-receive-pack` on the remote repository,
-which is happens when a `git push` is done on a local repository.
+which happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
is invoked. Its exit status determines the success or failure of
the ref update.
The hook executes once for each ref to be updated, and takes
three parameters:
- - the name of the ref being updated,
- - the old object name stored in the ref,
- - and the new objectname to be stored in the ref.
+
+ - the name of the ref being updated,
+ - the old object name stored in the ref,
+ - and the new objectname to be stored in the ref.
A zero exit from the update hook allows the ref to be updated.
Exiting with a non-zero status prevents `git-receive-pack`
@@ -126,16 +126,16 @@ Another use suggested on the mailing lis
implement access control which is finer grained than the one
based on filesystem group.
-The standard output of this hook is sent to /dev/null; if you
-want to report something to the git-send-pack on the other end,
-you can redirect your output to your stderr.
+The standard output of this hook is sent to `/dev/null`; if you
+want to report something to the `git-send-pack` on the other end,
+you can redirect your output to your `stderr`.
post-update
-----------
This hook is invoked by `git-receive-pack` on the remote repository,
-which is happens when a `git push` is done on a local repository.
+which happens when a `git push` is done on a local repository.
It executes on the remote repository once after all the refs have
been updated.
@@ -145,16 +145,16 @@ name of ref that was actually updated.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-receive-pack`.
-The post-update hook can tell what are the heads that were pushed,
+The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
so it is a poor place to do log old..new.
-The default post-update hook, when enabled, runs
+When enabled, the default 'post-update' hook runs
`git-update-server-info` to keep the information used by dumb
-transports (e.g., http) up-to-date. If you are publishing
-a git repository that is accessible via http, you should
+transports (e.g., HTTP) up-to-date. If you are publishing
+a git repository that is accessible via HTTP, you should
probably enable this hook.
-The standard output of this hook is sent to /dev/null; if you
-want to report something to the git-send-pack on the other end,
-you can redirect your output to your stderr.
+The standard output of this hook is sent to `/dev/null`; if you
+want to report something to the `git-send-pack` on the other end,
+you can redirect your output to your `stderr`.
--
1.4.2.1.gca4e
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Jakub Narebski @ 2006-09-20 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <20060920085200.GA21865@shadowen.org>
Andy Whitcroft wrote:
> + open(H, "git-for-each-ref --format='%(objectname) %(refname)'|") or
By the way, this is equivalent to using "git-show-ref" introduced by Linus.
But if you want commit timestamp
> cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
> out the sha1's in order to work out what time the last commit on
> that branch was made (in CVS) thus allowing incremental updates.
you can use it in --format as well.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] cvsimport move over to using git for each ref to read refs
From: Andy Whitcroft @ 2006-09-20 8:52 UTC (permalink / raw)
To: git
cvsimport: move over to using git-for-each-ref to read refs
cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
out the sha1's in order to work out what time the last commit on
that branch was made (in CVS) thus allowing incremental updates.
However, this takes no account of hierachical refs naming producing
the following error for each directory in $GIT_DIR/refs:
Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 503.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-cvsimport line 505.
usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
Take advantage of the new packed refs work to use the new
for-each-ref iterator to get this information. Use the format
specifier to ensure we are neutral to changes in default.
[Junio: although although for-each-ref offers a --perl quoting mode
this patch does not use it as it seems only to make parsing the
output harder in perl. If there is a neat trick for handling this
'perl' form please educate me. Here, rely on sha1's to contain
no spaces.]
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e5a00a1..1a62afa 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -495,13 +495,14 @@ unless(-d $git_dir) {
$tip_at_start = `git-rev-parse --verify HEAD`;
# Get the last import timestamps
- opendir(D,"$git_dir/refs/heads");
- while(defined(my $head = readdir(D))) {
- next if $head =~ /^\./;
- open(F,"$git_dir/refs/heads/$head")
- or die "Bad head branch: $head: $!\n";
- chomp(my $ftag = <F>);
- close(F);
+ open(H, "git-for-each-ref --format='%(objectname) %(refname)'|") or
+ die "Cannot run git-for-each-ref: $!\n";
+ while(defined(my $entry = <H>)) {
+ chomp($entry);
+ my ($ftag, $name) = split(' ', $entry, 2);
+ next if ($name !~ m@^refs/heads/(.*)$@);
+ my ($head) = ($1);
+
open(F,"git-cat-file commit $ftag |");
while(<F>) {
next unless /^author\s.*\s(\d+)\s[-+]\d{4}$/;
@@ -510,7 +511,7 @@ unless(-d $git_dir) {
}
close(F);
}
- closedir(D);
+ close(H);
}
-d $git_dir
^ permalink raw reply related
* Re: Subversion-style incrementing revision numbers
From: Junio C Hamano @ 2006-09-20 7:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: Joel Dice, git, Linus Torvalds
In-Reply-To: <20060919220604.GE8259@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes, responding to Linus:
>> You're going to hit a few confusing issues if you really want to call
>> things "r1.x.y.z"
>
> Noone does, that indeed would be horrible. But having the commits
> numbered inside a repository would indeed make for simple usage if you
> need to type in commit ids frequently, and could make Git a bit
> friendlier to newcomers.
SVN increments the number every time anything changes in the
whole-tree. Typically (1) when you make a commit, anywhere, in
the tree or (2) when you tag or branch. An interesting property
of SVN version number is that you can say "at revision 1423,
frotz and nitfol branches existed (filfre branch did not exist
back then) and their states were such and such".
So if Pasky wants to help Joel to emulate it in git, it is not
sufficient to number commits because there are fast-forwards and
it happens rather often in reality. A closer emulation at the
conceptual level is to run pack-refs every time you change any
ref in your repository and version control the resulting
packed-ref file with serial number.
Then when people talk about git.git repository at kernel.org
people can say "the repository at revision 144 had master at
019ba86 and next at 832e76a; tag v1.4.3 did not exist back
then."
Is it useful? In general I think it is useful only as a local
matter, just like ref-log is useful locally. In fact, I think
it is a natural extension of the ref-log (and it can even
capture where the tags were, which I sometimes find sorely
lacking in the current ref-log scheme -- anybody want to update
git-tag.sh to have it use ref-log? hint hint...).
But I am not sure how you would propagate it sanely in the
distributed environment.
I do not often pull from others, but I occasionally pull from
Paul's gitk tree. When I see gitk's tip advance and I pull from
him, I may end up getting a string of two commits. In other
words, in Joel's serial numbered revision scheme (emulated by
packed-ref snapshots versioned serially), there are two gitk
commits between my rN and r(N+1).
Somebody who hasn't thought about merges might be tempted to say
that we should use 2 revision numbers when a pull ends up
integrating 2 commits from outside, but that is not really
feasible. When you make a merge, it is not like you are
cherry-picking individual commits from somebody else one by one.
In state rN, I did not have either of these two commits, and in
state r(N+1) I now have both, and that is the only definition of
rN that makes any sense.
Side note: SVN does not have this "one state change but with
multiple revisions" uneasiness problem, because it does not
have a merge in distributed SCM's sense. What it has is a
convenient way to side-port changes that happened elsewhere
to your state and create a new commit (so it is not that
different from "cvs update -j"). After a "merge" happens
you are just one commit ahead from previous state, just like
a normal commit.
The difference from that and us is that "log ORIG_HEAD.."
will say we got new two commits integrated with the merge
which makes us wonder why there are multiple events between
two states, while SVN does not record what got cherry-picked
from the side so you cannot even worry about it if you
wanted to ;-).
But that definition stops making sense immediately when you look
at things from Paul's point of view. He had these two commits
done separately, and in his repository they are recorded as two
separate events, even under Joel's serial numbered revision
scheme. So for this serially numbered revisioning scheme to
make any sense to you, you have to refuse the everybody-is-equal
distributed model of git, and instead treat one repository
(mine) as more important than all others. If that central
repository says these two commits did not exist in rN and they
appeared in r(N+1), that's the reality as far as you are
concerned, and what Paul says does not count to you at all.
That makes Paul unhappy.
In the same sense, you have to realize that the number "144"
above that came from kernel.org would mean absolutely nothing to
me. I work on one commit at a time unless applying sequence of
patches, and typically ref-log knows that the last time _my_ tip
of "master" and "next" advanced were more than 30 minutes apart.
But I push four branches (maint/master/next/pu) out at the same
time to kernel.org, so between revision 143 and revision 144
four refs would have changed at kernel.org. But in the
repository I do the real work with ref-log knows that that is
not the way how these branches advanced at all. So it is not a
convenient number to work with from my point of view either.
^ permalink raw reply
* Re: [PATCH] Add branch test case: create "j/k" when "j" has been deleted.
From: Junio C Hamano @ 2006-09-20 7:39 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20060920070350.29039f28.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Linus wrote:
> "Somebody should add this test-case
>
> git branch test
> git branch -d test
> git branch test/first
>
> which should work."
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
If you add this, please add its dual test as well, otherwise we
will certainly forget.
^ permalink raw reply
* Trivial Typo in hooks documentation
From: Alan Chandler @ 2006-09-20 6:39 UTC (permalink / raw)
To: git
I don't have the source of git on my machine as I am just working from the
debian packages, so I don't have a patch. However there is a trivial type on
the hooks.html documentation that I gues comes from the Documentation
directory
The first sentence for both "update" and "post-update" hooks has an
extra "is", marked in capitals below
"This hook is invoked by git-receive-pack on the remote repository, which IS
happens when a git push is done on a local repository."
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* [PATCH] Add branch test case: create "j/k" when "j" has been deleted.
From: Christian Couder @ 2006-09-20 5:03 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Linus wrote:
"Somebody should add this test-case
git branch test
git branch -d test
git branch test/first
which should work."
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t3200-branch.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 5b04efc..d863498 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -61,4 +61,11 @@ test_expect_success \
test -f .git/logs/refs/heads/g/h/i &&
diff expect .git/logs/refs/heads/g/h/i'
+test_expect_success \
+ 'git branch j/k should work after branch j has been deleted' \
+ 'git-branch j &&
+ git-branch -d j &&
+ git-branch j/k'
+
+
test_done
--
1.4.2.1.g251a
^ permalink raw reply related
* [PATCH] Fix show-ref usage for --dereference.
From: Christian Couder @ 2006-09-20 4:21 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-show-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index 577d934..fab359b 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -3,7 +3,7 @@ #include "refs.h"
#include "object.h"
#include "tag.h"
-static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--deref] [-s|--hash] [--tags] [--heads] [--] [pattern*]";
+static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash] [--tags] [--heads] [--] [pattern*]";
static int deref_tags = 0, show_head = 0, tags_only = 0, heads_only = 0,
found_match = 0, verify = 0, quiet = 0, hash_only = 0;
--
1.4.2.1.g4251-dirty
^ permalink raw reply related
* [PATCH] Document git-show-ref [-s|--hash] option.
From: Christian Couder @ 2006-09-20 4:14 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
In-Reply-To: <20060918123241.GA8238@diku.dk>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-show-ref.txt | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 529ea17..b724d83 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
- [--tags] [--heads] [--] <pattern>...
+ [-s|--hash] [--tags] [--heads] [--] <pattern>...
DESCRIPTION
-----------
@@ -40,6 +40,12 @@ OPTIONS
Dereference tags into object IDs. They will be shown with "^{}"
appended.
+-s, --hash::
+
+ Only show the SHA1 hash, not the reference name. When also using
+ --dereference the dereferenced tag will still be shown after the SHA1,
+ this maybe a bug.
+
--verify::
Enable stricter reference checking by requiring an exact ref path.
@@ -72,6 +78,16 @@ The output is in the format: '<SHA-1 ID>
...
-----------------------------------------------------------------------------
+When using --hash (and not --dereference) the output format is: '<SHA-1 ID>'
+
+-----------------------------------------------------------------------------
+$ git show-ref --heads --hash
+2e3ba0114a1f52b47df29743d6915d056be13278
+185008ae97960c8d551adcd9e23565194651b5d1
+03adf42c988195b50e1a1935ba5fcbc39b2b029b
+...
+-----------------------------------------------------------------------------
+
EXAMPLE
-------
--
1.4.2.1.g4251-dirty
^ permalink raw reply related
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Linus Torvalds @ 2006-09-20 3:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060920004828.GI8259@pasky.or.cz>
On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> It's running at
>
> http://repo.or.cz/
Well, "running" may be putting it a bit strongly.
When I click "summary" for the glibc-cvs.git tree, I get just a
<div class="title"> </div>
-------------------^
thing back.
Broken gitweb?
Linus
^ 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