* Re: [PATCH] Improve git-prune -n output
From: Jakub Narebski @ 2006-10-28 14:00 UTC (permalink / raw)
To: git
In-Reply-To: <200610270937.11368.andyparkins@gmail.com>
Andy Parkins wrote:
> prune_object() in show_only mode would previously just show the path to the
> object that would be deleted. The path the object is stored in shouldn't be
> shown to users, they only know about sha1 identifiers so show that instead.
This allowed to 'rm -f' [some] of what git-prune -n shows.
Did anybody used that? I don't know...
> Further, the sha1 alone isn't that useful for examining what is going to be
> deleted. This patch also adds the object type to the output, which makes it
> easy to pick out, say, the commits and use git-show to display them.
Well, you can always use git-lost-found. Perhaps it would be better to add
-n option to git-lost-found to not create refs in $GIT_DIR/lost-found/
directory.
Sorry for being late with that suggestion.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Creating new repos
From: Jakub Narebski @ 2006-10-28 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <200610271708.k9RH8thM022812@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> Dear diary, on Fri, Oct 27, 2006 at 02:29:10PM CEST, I got a letter
>> where "Horst H. von Brand" <vonbrand@inf.utfsm.cl> said that...
>>> git://git-server/user/Test.git
>>> ssh+git://git-server/var/scm/user/Test.git
>>>
>>> Is this intentional?
>>
>> git+ssh has nothing to do with git-daemon, it's executing other git
>> commands remotely.
>
> OK. But from an UI POW it is confusing.
You can use ssh:// instead of ssh+git:// if you like. ssh+git:// is to note
that you should use git for that...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add git-count-packs, like git-count-objects.
From: Jakub Narebski @ 2006-10-28 14:28 UTC (permalink / raw)
To: git
In-Reply-To: <20061028065143.GA14607@spearce.org>
Shawn Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>>
>> > Now that we are starting to save packs rather than unpacking into
>> > loose objects its nice to have a way to list the number of current
>> > packs and their total size. This can help the user in deciding
>> > when its time to run `git repack -a -d`.
>>
>> Why not just do "ls -lh $GIT_OBJECT_DIR/pack/pack-*.pack"???
>
> Because whatever we decide to use to make a pack 'active' may not
> be that simple.
>
> Whatever. It was clearly a very tiny patch put together quickly
> before dinner tonight, perhaps not worth including at this point.
> Lets see what comes out of the other pack oriented discussion first.
Perhaps to nod add yet another command to already large set, rename
git-count-objects to git-count end enhance it to count both loose objects
and packs (or not, and use git-count-objects name).
BTW what does "garbage:" in git-count-objects -v mean? And in what units
git-count-objects -v returns "size:" (git-count-objects says "kilobytes",
why git-count-objects -v doesn't do the same)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-28 14:58 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <ehvnal$tjg$1@sea.gmane.org>
Jakub Narebski wrote:
>> You can't just diff branchA/foo branchB/foo.
>
> You can: either using "git diff branchA branchB -- foo" which means
> difference between branches branchA and branchB limited to the differences
> on branch foo (where foo can be directory name or filename)
Sorry, it should be:
"limited to the differences on pathname foo (where foo can be directory name
or filename)"
^ permalink raw reply
* Re: [PATCH] gitweb: Add "next" link to commitdiff view
From: Jakub Narebski @ 2006-10-28 16:10 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Petr Baudis
In-Reply-To: <200610230037.57183.jnareb@gmail.com>
Jakub Narebski wrote:
> Add a kind of "next" view in the bottom part of navigation bar for
> "commitdiff" view.
>
> For commitdiff between two commits:
> (from: _commit_)
> For commitdiff for one single parent commit:
> (parent: _commit_)
> For commitdiff for one merge commit
> (merge: _commit_ _commit_ ...)
> For commitdiff for root (parentless) commit
> (initial)
> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
> display, everything is perhaps unnecessary esc_html on display.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
>
> Junio (and others), is it what you wanted? The idea was to change
> "commitdiff" view only in minimal way, and preserve similarity
> to "commit" format.
Any reasons not to accept this patch? I find it very useful.
The idea to use fixed string instead of shortened SHA-1 of commit
was abandoned after some discussion in this thread.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Jakub Narebski @ 2006-10-28 17:30 UTC (permalink / raw)
To: git
Update information about value of <format> used when it is left
unspecified. Add information about `%%` and `%xx` interpolation
(URL encoding).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Could any of you review this, fix wording (if needed)?
By the way one thing missing from git-for-each-ref to use it
in gitweb without changing its output is ablility to sort on
"epoch", i.e. taggerdate for tags and committerdate for commits.
This is needed to sort heavyweight and lightweight tags together
on epoch in "summary" and "tags" views in gitweb. (It is not
needed for heads/branches, but it is the tags sorting that
cripples gitweb "summary" view performance.)
We could either add "fake" field `date` which will be `taggerdate`
for tags and `committerdate` for commits, and empty for trees
and blobs, or allow in <key> for more than one field to be
specified.
I also wish for change of %(field) to %{field}, adding %nn{field}
and %-nn{field} field width specifiers, committerepoch and
committertz fields (and equivalent for tagger and author) or
%{committer:date} like field-format specifiers. And for peace
on Earth while at it... ;-)
Documentation/git-for-each-ref.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index d5fdcef..4af1ebf 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -38,7 +38,11 @@ OPTIONS
is prefixed with an asterisk (`*`) and the ref points
at a tag object, the value for the field in the object
tag refers is used. When unspecified, defaults to
- `%(refname)`.
+ `%(objectname) SPC %(objecttype) TAB %(refname)`.
+ It also interpolates `%%` to `%`, and `%xx` where `xx`
+ are hex digits interpolates to character with hex code
+ `xx`; for example `%00` interpolates to `\0` (NUL),
+ `%09` to `\t` (TAB) and `%0a` to `\n` (LF).
<pattern>::
If given, the name of the ref is matched against this
--
1.4.3.3
^ permalink raw reply related
* [PATCH] gitweb: Move git_get_last_activity subroutine earlier
From: Jakub Narebski @ 2006-10-28 17:43 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Good test for git-pickaxe (git-blame2).
gitweb/gitweb.perl | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5f6a562..cbab3c9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -976,6 +976,24 @@ sub git_get_project_owner {
return $owner;
}
+sub git_get_last_activity {
+ my ($path) = @_;
+ my $fd;
+
+ $git_dir = "$projectroot/$path";
+ open($fd, "-|", git_cmd(), 'for-each-ref',
+ '--format=%(refname) %(committer)',
+ '--sort=-committerdate',
+ 'refs/heads') or return;
+ my $most_recent = <$fd>;
+ close $fd or return;
+ if ($most_recent =~ / (\d+) [-+][01]\d\d\d$/) {
+ my $timestamp = $1;
+ my $age = time - $timestamp;
+ return ($age, age_string($age));
+ }
+}
+
sub git_get_references {
my $type = shift || "";
my %refs;
@@ -1082,24 +1100,6 @@ sub parse_tag {
return %tag
}
-sub git_get_last_activity {
- my ($path) = @_;
- my $fd;
-
- $git_dir = "$projectroot/$path";
- open($fd, "-|", git_cmd(), 'for-each-ref',
- '--format=%(refname) %(committer)',
- '--sort=-committerdate',
- 'refs/heads') or return;
- my $most_recent = <$fd>;
- close $fd or return;
- if ($most_recent =~ / (\d+) [-+][01]\d\d\d$/) {
- my $timestamp = $1;
- my $age = time - $timestamp;
- return ($age, age_string($age));
- }
-}
-
sub parse_commit {
my $commit_id = shift;
my $commit_text = shift;
--
1.4.3.3
^ permalink raw reply related
* Re: fetching packs and storing them as packs
From: Linus Torvalds @ 2006-10-28 17:59 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061028072146.GB14607@spearce.org>
On Sat, 28 Oct 2006, Shawn Pearce wrote:
>
> Why not just use create a new flag file?
>
> Lets say that a pack X is NOT eligible to be repacked if
> "$GIT_DIR/objects/pack/pack-X.keep" exists.
Yeah, me likee. Simple and straightforward, and mixes well with the
"--keep" flag that has been discussed for git repack anyway.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Junio C Hamano @ 2006-10-28 18:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061028072146.GB14607@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I take this above statement to mean that you answered your own
> question about how my sequence is able to resolve the race condition?
Yes. I needed more thought after I asked that question.
>...
> Why not just use create a new flag file?
>
> Lets say that a pack X is NOT eligible to be repacked if
> "$GIT_DIR/objects/pack/pack-X.keep" exists.
I like it.
^ permalink raw reply
* Re: [PATCH] gitweb: Add "next" link to commitdiff view
From: Junio C Hamano @ 2006-10-28 19:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610281810.36892.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Jakub Narebski wrote:
>> Add a kind of "next" view in the bottom part of navigation bar for
>> "commitdiff" view.
>>
>> For commitdiff between two commits:
>> (from: _commit_)
>> For commitdiff for one single parent commit:
>> (parent: _commit_)
>> For commitdiff for one merge commit
>> (merge: _commit_ _commit_ ...)
>> For commitdiff for root (parentless) commit
>> (initial)
>> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
>> display, everything is perhaps unnecessary esc_html on display.
>>
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>> ---
>>
>> Junio (and others), is it what you wanted? The idea was to change
>> "commitdiff" view only in minimal way, and preserve similarity
>> to "commit" format.
>
> Any reasons not to accept this patch?
Nothing other than it was lost in the noise (I am partly
responsible for) that followed the patch.
Message-ID: <200610230037.57183.jnareb@gmail.com>
Who acked this in the discussion? I'd like to add "Acked-by:"
for them when I make the commit.
^ permalink raw reply
* Re: [PATCH] gitweb: Move git_get_last_activity subroutine earlier
From: Junio C Hamano @ 2006-10-28 19:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610281943.40456.jnareb@gmail.com>
Why is this needed?
^ permalink raw reply
* Re: Generating docu in 1.4.3.3.g01929
From: Junio C Hamano @ 2006-10-28 19:04 UTC (permalink / raw)
To: Sean; +Cc: git, Horst H. von Brand
In-Reply-To: <BAYC1-PASMTP060BC6AED24731185AD6E5AE050@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Fri, 27 Oct 2006 22:45:51 -0700
> Junio C Hamano <junkio@cox.net> wrote:
>
>> Eh, do you mean bisecting asciidoc? I am not seeing the problem
>> with these on a freshly installed FC6:
>
> Yeah.. don't see the problem here either. But assuming there
> is some strange interaction with Horst's environment, bisecting
> would narrow it down. Even though I don't really think bisecting
> will turn up a problem in Git, it might identify the problem in
> the environment..
Horst has a non-working combination that is:
- tip of "master" of the day
- Fedora rawhide i386 (whatever that is -- sorry I am new to RPM world)
- asciidoc 7.0.2 3.fc6
- xmlto 0.0.18 13.1
I have a working combination:
- tip of "master" of the day
- FC6 i386 (freshly installed)
- asciidoc 7.0.2 3.fc6
- xmlto 0.0.18 13.1
So the difference between me and Horst that can be bisected is
not what are listed above. I wonder what other things come into
the picture.
"rpm -q --requires" tells us that:
- asciidoc wants python >= 2.3
- xmlto wants docbook-dtds, docbook-xsl >= 1.56.0, flex,
libxslt, passivetex >= 1.11, util-linux, w3m
and here is what I have:
asciidoc-7.0.2-3.fc6
xmlto-0.0.18-13.1
python-2.4.3-18.fc6
docbook-dtds-1.0-30.1
package docbook-xsl is not installed
flex-2.5.4a-41.fc6
libxslt-1.1.17-1.1
passivetex-1.25-5.1.1
util-linux-2.13-0.44.fc6
w3m-0.5.1-14.1
"rpm -q --whatprovides docbook-xsl" says:
docbook-style-xsl-1.69.1-5.1
and it is installed on the FC6 box.
^ permalink raw reply
* Re: Generating docu in 1.4.3.3.g01929
From: Sean @ 2006-10-28 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Horst H. von Brand
In-Reply-To: <7vmz7g8don.fsf@assigned-by-dhcp.cox.net>
On Sat, 28 Oct 2006 12:04:24 -0700
Junio C Hamano <junkio@cox.net> wrote:
> Horst has a non-working combination that is:
>
> - tip of "master" of the day
> - Fedora rawhide i386 (whatever that is -- sorry I am new to RPM world)
> - asciidoc 7.0.2 3.fc6
> - xmlto 0.0.18 13.1
>
> I have a working combination:
>
> - tip of "master" of the day
> - FC6 i386 (freshly installed)
> - asciidoc 7.0.2 3.fc6
> - xmlto 0.0.18 13.1
>
> So the difference between me and Horst that can be bisected is
> not what are listed above. I wonder what other things come into
> the picture.
The thing is, Horst implied everything worked before a recent pull.
It's worth at least going back to see if that's true. Quite likely
that older version will no longer work anymore either, but maybe it
will. Of course, if an older version no longer works, there's no
need to bisect further, something in the environment has changed.
Either way, it'll help narrow things down a bit.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Junio C Hamano @ 2006-10-28 19:15 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061028084001.GC14607@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Shawn Pearce <spearce@spearce.org> wrote:
>> Why not just use create a new flag file?
>>
>> Lets say that a pack X is NOT eligible to be repacked if
>> "$GIT_DIR/objects/pack/pack-X.keep" exists.
>
> Here's the `git repack -a -d` portion of that.
> Thoughts?
> + args=--unpacked
> + active=
> + if test -d "$PACKDIR"
> + then
> + for p in `find "$PACKDIR" -type f -name '*.pack' -print`
This change to run 'find "$PACKDIR"' is fragile when your
$GIT_OBJECT_DIRECTORY has $IFS in it; running "find ." after
"cd" in a subprocess was done very much on purpose to avoid that
issue. Please don't break it.
> + do
> + n=`basename "$p" .pack`
> + d=`dirname "$p"`
> + if test -e "$d/$n.keep"
> + then
> + : keep
> + else
> + args="$args --unpacked=$p"
> + active="$active $n"
> + fi
> + done
> + fi
> + if test "X$args" = X--unpacked
> + then
> + args='--unpacked --incremental'
> + fi
> ;;
> esac
I do not remember offhand what --incremental meant, but
presumably this is for the very initial "repack" (PACKDIR did
not exist or find loop did not find anything to repack) and the
flag would not make a difference? Care to explain?
Other than that, the overall structure seems quite sane.
^ permalink raw reply
* Re: [PATCH] gitweb: Move git_get_last_activity subroutine earlier
From: Jakub Narebski @ 2006-10-28 19:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vvem48dsr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Why is this needed?
This is purely cosmetic, and originally was to be first patch in series
converting git_summary, git_heads and git_tags to use of git-for-each-ref...
but unfortunately git-for-each-ref lacks sorting on taggerdate OR
committerdate (i.e. use taggerdate if applicable, committerdate otherwise).
I'd rather not have git_get_last_activity between two parse_* subroutines...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Generating docu in 1.4.3.3.g01929
From: Junio C Hamano @ 2006-10-28 19:22 UTC (permalink / raw)
To: Sean; +Cc: git, Horst H. von Brand
In-Reply-To: <BAYC1-PASMTP11A0267A1CE74A17EDE925AE050@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
>> So the difference between me and Horst that can be bisected is
>> not what are listed above. I wonder what other things come into
>> the picture.
>
> The thing is, Horst implied everything worked before a recent pull.
Ah, Ok.
I explicitly asked about things that would help to narrow down
and Horst did not answer to any, so I took that "no info" as (0)
this is the first doc generation so it is unknown if older git
sources would generate docs correctly in the environment, (1)
not just git-daemon.1 but generating git-anything.1 is broken,
(2) not just git-daemon.1 but generating git-daemon.html is also
broken.
You interpreted the "no info" differently, which is valid.
> It's worth at least going back to see if that's true. Quite likely
> that older version will no longer work anymore either, but maybe it
> will. Of course, if an older version no longer works, there's no
> need to bisect further, something in the environment has changed.
> Either way, it'll help narrow things down a bit.
Very true.
^ permalink raw reply
* Re: [PATCH] gitweb: Move git_get_last_activity subroutine earlier
From: Junio C Hamano @ 2006-10-28 19:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ei0ags$l1l$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Why is this needed?
>
> This is purely cosmetic, and originally was to be first patch in series
> converting git_summary, git_heads and git_tags to use of git-for-each-ref...
> but unfortunately git-for-each-ref lacks sorting on taggerdate OR
> committerdate (i.e. use taggerdate if applicable, committerdate otherwise).
>
> I'd rather not have git_get_last_activity between two parse_* subroutines...
Ok, will apply but the last line of your response _should_ have
been in the proposed commit log message without being asked.
^ permalink raw reply
* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Junio C Hamano @ 2006-10-28 20:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610281930.05889.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way one thing missing from git-for-each-ref to use it
> in gitweb without changing its output is ablility to sort on
> "epoch", i.e. taggerdate for tags and committerdate for commits.
> This is needed to sort heavyweight and lightweight tags together
> on epoch in "summary" and "tags" views in gitweb. (It is not
> needed for heads/branches, but it is the tags sorting that
> cripples gitweb "summary" view performance.)
I guess something like this, but I haven't tested it heavily.
If you want it in "next" please ack (with necessary fix-up
patches if any).
-- >8 --
[PATCH] for-each-ref: epoch and epochdate
This adds "epoch" (which is parallel to "tagger" or "committer")
and "epochdate" (corresponds to "taggerdate" and
"committerdate").
As other "date" fields, "epochdate" sorts numerically
and displays human readably
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 698618b..3dc68cc 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -59,6 +59,8 @@ static struct {
{ "taggername" },
{ "taggeremail" },
{ "taggerdate", FIELD_TIME },
+ { "epoch" },
+ { "epochdate", FIELD_TIME },
{ "subject" },
{ "body" },
{ "contents" },
@@ -401,6 +403,29 @@ static void grab_person(const char *who,
else if (!strcmp(name + wholen, "date"))
grab_date(wholine, v);
}
+
+ /* For a tag or a commit object, if "epoch" or "epochdate" is
+ * requested, do something special.
+ */
+ if (strcmp(who, "tagger") && strcmp(who, "committer"))
+ return; /* "author" for commit object is not wanted */
+ if (!wholine)
+ wholine = find_wholine(who, wholen, buf, sz);
+ if (!wholine)
+ return;
+ for (i = 0; i < used_atom_cnt; i++) {
+ const char *name = used_atom[i];
+ struct atom_value *v = &val[i];
+ if (!!deref != (*name == '*'))
+ continue;
+ if (deref)
+ name++;
+
+ if (!strcmp(name, "epochdate"))
+ grab_date(wholine, v);
+ else if (!strcmp(name, "epoch"))
+ v->s = copy_line(wholine);
+ }
}
static void find_subpos(const char *buf, unsigned long sz, const char **sub, const char **body)
^ permalink raw reply related
* Re: [PATCH] Bash completion support for aliases
From: Junio C Hamano @ 2006-10-28 20:37 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20061028121220.G3421aba@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> - Add aliases to the list of available git commands.
> - Make completion work for aliased commands.
You are my hero.
I started to get annoyed that "git co" does not complete my
branch names and I needed to say "git checkout". This fixes it
nicely.
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Junio C Hamano @ 2006-10-28 20:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehvnob$tmj$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Andy Parkins wrote:
>
>> prune_object() in show_only mode would previously just show the path to the
>> object that would be deleted. The path the object is stored in shouldn't be
>> shown to users, they only know about sha1 identifiers so show that instead.
>
> This allowed to 'rm -f' [some] of what git-prune -n shows.
>
> Did anybody used that? I don't know...
Yes and probably no because the output did not have enough clues
to help picking which ones to remove. If the command said
something like this:
.git/objetcts/11/feed0... ;# commit 2006-08-28: WIP for "foo"
it might have been a good clue and would have made sense, though.
^ permalink raw reply
* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Junio C Hamano @ 2006-10-28 20:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610281930.05889.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Update information about value of <format> used when it is left
> unspecified. Add information about `%%` and `%xx` interpolation
> (URL encoding).
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Could any of you review this, fix wording (if needed)?
Looks fine; thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: Move git_get_last_activity subroutine earlier
From: Junio C Hamano @ 2006-10-28 20:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610281943.40456.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Good test for git-pickaxe (git-blame2).
"git pickaxe -M v1.4.3.. -- gitweb/gitweb.perl" finds copies by
you just fine (It is interesting to compare it with output
without -M), thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Jakub Narebski @ 2006-10-28 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslh86uz9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> [PATCH] for-each-ref: epoch and epochdate
>
> This adds "epoch" (which is parallel to "tagger" or "committer")
> and "epochdate" (corresponds to "taggerdate" and
> "committerdate").
>
> As other "date" fields, "epochdate" sorts numerically
> and displays human readably
I was thinking about having only "epochdate" (corresponding to either
"taggerdate" or "committerdate"), only named "epoch". There is I think
no need for field which would be "tagger" or "committer", and
especially not named "epoch" ;-).
Otherwise looks fine, thanks a lot.
BTW. I had to translate
+ if (strcmp(who, "tagger") && strcmp(who, "committer"))
to
+ if (strcmp(who, "tagger") == 0 || strcmp(who, "committer") == 0)
to understand it. But this is probably my lack of contact with such
C idioms.
--
Jakub Narebski
^ permalink raw reply
* Re: VCS comparison table
From: Robin Rosenberg @ 2006-10-28 22:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehvnal$tjg$1@sea.gmane.org>
lördag 28 oktober 2006 15:53 skrev Jakub Narebski:
> But for example git(7) man page lists git commands clearly divided between
> low-level commands (plumbing): manipulation commands, interrogation
> commands, synching commands and high level commands (porcelain): main
> commands, ancillary commands. The "git help" and "git --help" shows the
> most commonly used git commands with short description of each command
> ("git help -a" show all commands).
I believe people tend to skim through documentation looking for pieces of
information rather than read it from start to end. So they find themselves
reading the plumbing documentation first. Simply reordering documentation to
list the porcelain commands before the plumbing would make the git man page
less scary to newcomers.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Eran Tromer @ 2006-10-28 22:31 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce
In-Reply-To: <20061028072146.GB14607@spearce.org>
Hi Shawn,
On 2006-10-28 09:21, Shawn Pearce wrote:
> Lets say that a pack X is NOT eligible to be repacked if
> "$GIT_DIR/objects/pack/pack-X.keep" exists.
>
> Thus we want to have the new ".keep" file for historical packs and
> incoming receive-pack between steps c and g. In the former case
> the historical pack is already "very large" and thus one additional
> empty file to indicate we want to retain that pack as-is is trivial
> overhead (relatively speaking); in the latter case the lifespan of
> the file is relatively short and thus any overhead associated with it
> on the local filesystem is free (it may never even hit the platter).
Sounds perfect.
It would be nice to have whoever creates a pack-*.keep file put
something useful as the content of the file, so we'll know what to clean
up after abnormal termination:
$ grep -l ^git-receive-pack $GIT_DIR/objects/pack/pack-*.keep
^ 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