* Re: [PATCH 4/4] Add git-rewrite-commits
From: Johannes Schindelin @ 2007-07-09 14:59 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <20070709144248.GW1528MdfPADPa@greensroom.kotnet.org>
Hi,
On Mon, 9 Jul 2007, Sven Verdoolaege wrote:
> On Mon, Jul 09, 2007 at 03:11:45PM +0100, Johannes Schindelin wrote:
> > On Mon, 9 Jul 2007, Sven Verdoolaege wrote:
> > > The current git-rewrite-commits will rewrite all SHA1's it can find,
> > > irrespective of any 'commit ' that may precede it.
> >
> > Even abbreviated ones?
>
> Yes. I'll add that to the documentation.
That is definitely something you want to control. I have seen commit
messages referencing certain hexadecimal numbers, and they were definitely
no commit names. The shorter they are, the more likely they are to be
rewritten by your magic.
> > * rename the darned things to "filter" again.
> >
> > * --write-sha1-mappings=<directory> (or --write-commit-mappings), possibly
> > defaulting to .git/mappings/. Be careful not to overwrite an existing
> > such directory.
> >
> > * change the semantics of the commit filter: the output is a list
> > (possibly empty) of replacement sha1's for this commit.
> >
> > * if any filters are called, provide a script with convenience functions,
> > and an environment variable pointing to it. These functions should
> > include:
> >
> > * map
> > * commit
> > * save
> > * restore
>
> Hmm... you're tricking me into write shell code.
Ah, oh well. If you do the rest, I'll do the shell code.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Make fetch-pack a builtin with an internal API
From: Florian Weimer @ 2007-07-09 15:10 UTC (permalink / raw)
To: git
In-Reply-To: <20070709144030.GE16032@thunk.org>
* Theodore Tso:
> On Mon, Jul 09, 2007 at 02:16:35PM +0100, Andy Parkins wrote:
>> Perhaps I'm reading it wrong but:
>>
>> "All identifiers beginning with an underscore are reserved for ordinary
>> identifiers (functions, variables, typedefs, enumeration constants) with file
> ^^^^^^^^^
>> scope."
> ^^^^^^
>>
>> Doesn't agree with what you've said. I think that you _can_ use _[a-z]* for
>> labels or structure members - however, not within file or function scope.
>
> I think the above does agree with what I said. It says that you can
> use functions, variables, typdefs, enumeration constants (not just
> labels or structure members) WITH FILE SCOPE.
No, they are are reserved.
> I.e., so long as it doesn't leak across a .o linkage. So one .o
> file can use a static _my_strdup, and another .o file can use a
> static _my_strdup, and they don't have to worry about multiply
> defined function conflicts, since they are static functions with
> file or smaller scoping.
This is not sufficient because the implementation might have a
*typedef* for _my_strdup in any header file, and neither translation
unit would compile. Or they could have been declared with a different
prototype.
^ permalink raw reply
* merge-one-file, was Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Johannes Schindelin @ 2007-07-09 15:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Rémi Vanicat
In-Reply-To: <7v8x9q1x5t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 8 Jul 2007, Junio C Hamano wrote:
> [PATCH] Fix merge-one-file for our-side-added/our-side-removed cases
FWIW I have a patch series in my local repo, which makes merge-one-file a
builtin, and even avoids fork()+exec()ing the program when called from
unpack_trees(). However, I never came around to understand all the corner
cases, and therefore did not write tests for it. Therefore, I am not
really sure if it works as intended. So I'd be very grateful if you could
write tests while you are touching it anyway...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Make fetch-pack a builtin with an internal API
From: Andy Parkins @ 2007-07-09 15:28 UTC (permalink / raw)
To: git; +Cc: Theodore Tso, Junio C Hamano, Daniel Barkalow
In-Reply-To: <20070709144030.GE16032@thunk.org>
On Monday 2007 July 09, Theodore Tso wrote:
> > "All identifiers beginning with an underscore are reserved for ordinary
> > identifiers (functions, variables, typedefs, enumeration constants) with
> > file
> > scope."
> I think the above does agree with what I said. It says that you can
> use functions, variables, typdefs, enumeration constants (not just
> labels or structure members) WITH FILE SCOPE. I.e., so long as it
> doesn't leak across a .o linkage. So one .o file can use a static
I'm reading it as meaning they are reserved at file scope; not that you can
use them at file scope.
> _my_strdup, and another .o file can use a static _my_strdup, and they
> don't have to worry about multiply defined function conflicts, since
> they are static functions with file or smaller scoping.
Erm, but we're not talking about your own .o files we're talking about
conflicting with the library; what you say would be true for any identifier.
We have no way of guaranteeing that _my_strdup() isn't defined by one of the
standard library headers that have been included. The standard header is
entitled to use underscore identifiers because they have been reserved at
file scope.
Reading a little further into the FAQ you posted, I found the following in the
list of exceptions:
"You may use identifiers consisting of an underscore followed by a digit or
lower case letter for labels and structure/union members."
and
"You may use identifiers consisting of an underscore followed by a digit or
lower case letter at function, block, or prototype scope."
I'm more sure now - you can't use underscore identifiers at file scope.
Regardless, we're just splitting hairs now. We seem to both agree that it's
easiest just to outright not use underscore-prefixed identifiers; so I'm
happy. :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] rerere: record resolution even if file is not in merge base
From: Uwe Kleine-König @ 2007-07-09 15:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707091445450.5546@racer.site>
Hello Johannes, hello Junio,
Johannes Schindelin wrote:
> Two-file merges were rare enough that they were dropped outside of the
> radar. This fix is a trivial change to builtin-rerere.c::find_conflict().
> It is still sane to insist that we do not do rerere for symlinks, and
> require to have stages #2 and #3, but we can drop the requirement to have
> stage #1. rerere does not use information from there anyway.
>
> This fix is from Junio, together with two tests to verify that it works
> as expected.
>
> Noticed by Uwe Kleine-König.
when I tested Junio's patch and wrote that it doesn't work, I was wrong.
I just recompiled git-rerere and called that instead of the installed
version. The problem there was, that merge didn't called the updated.
So:
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
--
Uwe Kleine-König
http://www.google.com/search?q=1+hertz+in+sec**-1
^ permalink raw reply
* Re: Preferring shallower deltas on repack
From: Nicolas Pitre @ 2007-07-09 15:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git
In-Reply-To: <7v1wfixhvk.fsf@assigned-by-dhcp.cox.net>
On Sun, 8 Jul 2007, Junio C Hamano wrote:
> It would become worrysome (*BUT* infinitely more interesting)
> once you start talking about a tradeoff between slightly larger
> delta and much shorter delta. Such a tradeoff, if done right,
> would make a lot of sense, but I do not offhand think of a way
> to strike a proper balance between them efficiently.
We already do something similar to that with max_size being a function
of the delta depth. This already has the effect of favoring shalower
deltas even if deeper deltas could be smaller, and therefore creating a
wider delta tree (see commits 4e8da195 and c3b06a69).
Maybe this max_size curve could be modified a bit to increase the bias
towards shallow deltas even in the case where a delta was already found
instead of the current constant flat curve.
[...]
OK here it is. And results on the GIT repo and another patalogical test
repo I keep around are actually really nice! Not only the pack itself
is a bit smaller, but the delta depth distribution as shown by
git-verify-pack -v is much nicer with the bulk of deltas in the low
depth end of the spectrum and no more peak at the max depth level.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 54b9d26..1eb86ed 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1332,12 +1332,14 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
/* Now some size filtering heuristics. */
trg_size = trg_entry->size;
- max_size = trg_size/2 - 20;
+ if (!trg_entry->delta)
+ max_size = trg_size/2 - 20;
+ else
+ max_size = trg_entry->delta_size * max_depth /
+ (max_depth - trg_entry->depth + 1);
max_size = max_size * (max_depth - src_entry->depth) / max_depth;
if (max_size == 0)
return 0;
- if (trg_entry->delta && trg_entry->delta_size <= max_size)
- max_size = trg_entry->delta_size;
src_size = src_entry->size;
sizediff = src_size < trg_size ? trg_size - src_size : 0;
if (sizediff >= max_size)
^ permalink raw reply related
* Re: Preferring shallower deltas on repack
From: Junio C Hamano @ 2007-07-09 16:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Brian Downing, git
In-Reply-To: <alpine.LFD.0.999.0707090954550.26459@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Sun, 8 Jul 2007, Junio C Hamano wrote:
>
>> It would become worrysome (*BUT* infinitely more interesting)
>> once you start talking about a tradeoff between slightly larger
>> delta and much shallower depth. Such a tradeoff, if done right,
>> would make a lot of sense, but I do not offhand think of a way
>> to strike a proper balance between them efficiently.
>
> We already do something similar to that with max_size being a function
> of the delta depth. ...
Yeah, we had a fun thread about that; I forgot about it until
now.
> OK here it is. And results on the GIT repo and another patalogical test
> repo I keep around are actually really nice! Not only the pack itself
> is a bit smaller, but the delta depth distribution as shown by
> git-verify-pack -v is much nicer with the bulk of deltas in the low
> depth end of the spectrum and no more peak at the max depth level.
Looks obviously correct. Brian, it would be very interesting to
see what Nico's patch does to your dataset.
^ permalink raw reply
* Re: [PATCH] Disallow empty GIT_AUTHOR_NAME or GIT_COMMITTER_NAME
From: Brandon Casey @ 2007-07-09 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vlkdsdaxo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
...
>> This still allows an empty GIT_AUTHOR_EMAIL or GIT_COMMITTER_EMAIL.
>> Possibly someone would want to use these variables to disable
>> the respective email address string?
>>
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>
> Thanks. But this makes me wonder why you do not do the same
> check for !*email
I thought someone may want to disable the author or committer email
address by setting GIT_AUTHOR_EMAIL or GIT_COMMITTER_EMAIL to an
empty string. I wasn't sure this was useful that's why I put a '?'
at the end of my commit message.
>> Then I send the patch to myself using git-format-patch and then
>> git-send-email. These two format the patch appropriately for
>> submission and allow me to set the message-id.
>>
>> Then I select the message, right-click and choose "Edit As New...",
>> edit, select the recipients, and send. I also now have a record of
>> the sent message which I would not have if I used only git-send-email.
>
> I would just add myself to --bcc when running send-email; much
> simpler ;-).
currently I can only use send-email to send email to myself, so this
was an alternative to setting up an external editor in thunderbird.
It's currently the path of least resistance for me.
-brandon
^ permalink raw reply
* How to Import a bitkeeper repo into git
From: free cycle @ 2007-07-09 16:57 UTC (permalink / raw)
To: git
Hi,
I'm looking for the best path to import a bk repo into git.
I was not able to find the download site for the tailor repo-conversion application.
Is it still supported and maintained?
I think bk can export to CVS and then git can import from CVS.
Is this the best way?
Thanks in advance,
Scott
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: VMiklos @ 2007-07-09 17:37 UTC (permalink / raw)
To: free cycle; +Cc: git
In-Reply-To: <598689.78740.qm@web56015.mail.re3.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
Na Mon, Jul 09, 2007 at 09:57:09AM -0700, free cycle <freecycler23@yahoo.com> pisal(a):
> I was not able to find the download site for the tailor repo-conversion application.
> Is it still supported and maintained?
http://progetti.arstecnica.it/tailor/
yes, it's maintained but it does not support bitkeeper
> I think bk can export to CVS and then git can import from CVS.
i think so
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Linus Torvalds @ 2007-07-09 17:51 UTC (permalink / raw)
To: VMiklos; +Cc: free cycle, git
In-Reply-To: <20070709173720.GS29994@genesis.frugalware.org>
On Mon, 9 Jul 2007, VMiklos wrote:
>
> > I think bk can export to CVS and then git can import from CVS.
>
> i think so
That's how I did my kernel history, and cvsps has a special "BK mode",
which knows to trust the CVS timestamps more when importing from a BK CVS
archive (since the timestamps will then be exact).
That said, the quality of the result isn't stellar. The CVS export will
obviously linearize the BK information, so you do lose things. So there's
actually a better kernel BK->git archive around which doesn't do that, but
that was done apparently from a custom database, so it's not reproducible.
Linus
^ permalink raw reply
* Re: [PATCH v2] Make fetch-pack a builtin with an internal API
From: René Scharfe @ 2007-07-09 18:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707090142130.6977@iabervon.org>
Daniel Barkalow schrieb:
> On Sun, 8 Jul 2007, Junio C Hamano wrote:
>
>> Are _identifiers with leading underscore Kosher thing to do, I
>> wonder... We do have ones with trailing ones (mostly qsort
>> functions) and I think they are done that way for the sake of
>> standards conformance.
>
> I'm not sure; I inherited that bit of code from Julian. Do we have a
> standard idiom for a function that sets a bunch of static variables?
You could put all flags and settings into a struct fetch_pack_args.
You could then go one step further by exporting the struct definition
and letting the internal interface take a pointer to such a struct,
thereby getting rid of static variables and their setup routine.
René
^ permalink raw reply
* Re: [PATCH v2] Make fetch-pack a builtin with an internal API
From: Daniel Barkalow @ 2007-07-09 18:16 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <469278B3.40905@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1394 bytes --]
On Mon, 9 Jul 2007, René Scharfe wrote:
> Daniel Barkalow schrieb:
> > On Sun, 8 Jul 2007, Junio C Hamano wrote:
> >
> >> Are _identifiers with leading underscore Kosher thing to do, I
> >> wonder... We do have ones with trailing ones (mostly qsort
> >> functions) and I think they are done that way for the sake of
> >> standards conformance.
> >
> > I'm not sure; I inherited that bit of code from Julian. Do we have a
> > standard idiom for a function that sets a bunch of static variables?
>
> You could put all flags and settings into a struct fetch_pack_args.
>
> You could then go one step further by exporting the struct definition
> and letting the internal interface take a pointer to such a struct,
> thereby getting rid of static variables and their setup routine.
This code is going to get an extensive refactor at some point (I'd like to
get to the point where git-fetch uses only a single connection), but
that's a much bigger patch, and I want to get builtin-fetch done with
minimal changes to other code; passing configuration through to everywhere
that uses it would add a lot of noise at this stage.
Passing a pointer to a struct instead of a pile of ints in hopefully the
right order is probably a worthwhile improvement to reviewability, though,
so I'll try that much this evening.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Preferring shallower deltas on repack
From: Brian Downing @ 2007-07-09 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vir8tv8dr.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 09, 2007 at 09:39:44AM -0700, Junio C Hamano wrote:
> > OK here it is. And results on the GIT repo and another patalogical test
> > repo I keep around are actually really nice! Not only the pack itself
> > is a bit smaller, but the delta depth distribution as shown by
> > git-verify-pack -v is much nicer with the bulk of deltas in the low
> > depth end of the spectrum and no more peak at the max depth level.
>
> Looks obviously correct. Brian, it would be very interesting to
> see what Nico's patch does to your dataset.
Nico's patch makes the overall statistics look better, but the
version.lisp-expr file still goes 593 levels deep, as opposed to about
65 with my patch. (That's better than 980 with stock Git, though.)
Pack statistics from my shoddy analysis tool (I'll post it a bit later):
"sizes" are all object sizes in the pack. For deltas this is just the
delta size. "path sizes" is the size of the /path/ to each object in
the file; this is the size of the base and each patch in the chain to
the object. This is approximately how much data you have to read to
get to an object. "depths" should be obvious.
SBCL, stock git:
all sizes: count 46829 total 30256118 min 0 max 1012295 mean 646.10 median 45 std_dev 9555.48
all path sizes: count 46829 total 1551200401 min 0 max 1012295 mean 33124.78 median 11661 std_dev 55310.88
depths: count 46829 total 4693372 min 0 max 980 mean 100.22 median 12 std_dev 188.21
SBCL, my patch:
all sizes: count 46829 total 30251762 min 0 max 1012295 mean 646.00 median 45 std_dev 9555.48
all path sizes: count 46829 total 1529629918 min 0 max 1012295 mean 32664.16 median 11213 std_dev 54930.06
depths: count 46829 total 2883121 min 0 max 787 mean 61.57 median 11 std_dev 127.64
SBCL, Nico's patch:
all sizes: count 46829 total 30253345 min 0 max 1012295 mean 646.04 median 45 std_dev 9555.49
all path sizes: count 46829 total 1518730701 min 0 max 1012295 mean 32431.41 median 10819 std_dev 54751.35
depths: count 46829 total 3694511 min 0 max 699 mean 78.89 median 12 std_dev 141.53
I'm vaguely working on an alternate weighting mechanism based on path
sizes, but so far all I've been able to do is generate some really
strange packs. :)
-bcd
^ permalink raw reply
* Re: [PATCH] gitweb: make search form generate pathinfo-style URLs
From: Luben Tuikov @ 2007-07-09 19:03 UTC (permalink / raw)
To: Junio C Hamano, Matt McCutchen; +Cc: git, jnareb, pasky, ltuikov
In-Reply-To: <7vejjk6i96.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <gitster@pobox.com> wrote:
> Matt McCutchen <hashproduct@gmail.com> writes:
>
> > The search form generated traditional-style URLs with a "p=" parameter
> > even when the pathinfo feature was on. This patch makes it generate
> > pathinfo-style URLs when appropriate.
> >
> > Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
> > ---
> > gitweb/gitweb.perl | 12 +++++++++---
> > 1 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index f36428e..7b0e110 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2215,12 +2215,18 @@ EOF
> > } else {
> > $search_hash = "HEAD";
> > }
> > + my $action = $my_uri;
> > + my ($use_pathinfo) = gitweb_check_feature('pathinfo');
> > + if ($use_pathinfo) {
> > + $action .= "/$project";
> > + } else {
> > + $cgi->param("p", $project);
> > + }
> > $cgi->param("a", "search");
> > $cgi->param("h", $search_hash);
> > - $cgi->param("p", $project);
> > - print $cgi->startform(-method => "get", -action => $my_uri) .
> > + print $cgi->startform(-method => "get", -action => $action) .
> > "<div class=\"search\">\n" .
> > - $cgi->hidden(-name => "p") . "\n" .
> > + (!$use_pathinfo && $cgi->hidden(-name => "p") . "\n") .
>
> Ahhhhh. (!$use_pathinfo && blah) when $use_pathinfo is true
> evaluates to an empty string, which saves you from protecting
> yourself from undef. Perhaps clever, but is not terribly nice.
>
> Other than that, the patch looks sane to me.
Good catch.
Luben
^ permalink raw reply
* Re: Preferring shallower deltas on repack
From: Nicolas Pitre @ 2007-07-09 19:13 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git
In-Reply-To: <20070709185353.GL4087@lavos.net>
On Mon, 9 Jul 2007, Brian Downing wrote:
> On Mon, Jul 09, 2007 at 09:39:44AM -0700, Junio C Hamano wrote:
> > > OK here it is. And results on the GIT repo and another patalogical test
> > > repo I keep around are actually really nice! Not only the pack itself
> > > is a bit smaller, but the delta depth distribution as shown by
> > > git-verify-pack -v is much nicer with the bulk of deltas in the low
> > > depth end of the spectrum and no more peak at the max depth level.
> >
> > Looks obviously correct. Brian, it would be very interesting to
> > see what Nico's patch does to your dataset.
>
> Nico's patch makes the overall statistics look better, but the
> version.lisp-expr file still goes 593 levels deep, as opposed to about
> 65 with my patch. (That's better than 980 with stock Git, though.)
Tuning for such an extreme without impacting normal cases is rather
hard.
My patch was meant to be used on top of yours. Is that what you tested?
Also I'd suggest you do not use a max depth of 1000. It is simply
insane and might possibly make the existing logic less effective. Even
for runtime pack access you want it to be reasonably short, say 100
maximum, or even the current default of 50. Any improvements you might
come with (like automatic depth determined on replay cost) should be
compared with that default which is known to work well already.
Nicolas
^ permalink raw reply
* Re: Preferring shallower deltas on repack
From: Brian Downing @ 2007-07-09 19:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0707091503000.26459@xanadu.home>
On Mon, Jul 09, 2007 at 03:13:54PM -0400, Nicolas Pitre wrote:
> Tuning for such an extreme without impacting normal cases is rather
> hard.
>
> My patch was meant to be used on top of yours. Is that what you tested?
>
> Also I'd suggest you do not use a max depth of 1000. It is simply
> insane and might possibly make the existing logic less effective. Even
> for runtime pack access you want it to be reasonably short, say 100
> maximum, or even the current default of 50. Any improvements you might
> come with (like automatic depth determined on replay cost) should be
> compared with that default which is known to work well already.
No, I didn't try it on top of mine; sorry. I'll try that out.
I realize a depth of 1000 is nuts, I'm just using it to expose any
suboptimal delta selection for the nasty versions.lisp-expr case, since
I know that with a window size of 100 it should be easy to keep it from
growing too deep.
-bcd
^ permalink raw reply
* [PATCH] Shoddy pack information tool
From: Brian Downing @ 2007-07-09 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <20070709185353.GL4087@lavos.net>
This tool will print vaguely pretty information about a pack. It
expects the output of "git-verify-pack -v" as input on stdin.
$ git-verify-pack -v pack | packinfo.pl
This prints some full-pack statistics; currently "all sizes", "all path
sizes", "tree sizes", "tree path sizes", and "depths".
* "all sizes" stats are across every object size in the file;
full sizes for base objects, and delta size for deltas.
* "all path sizes" stats are across all object's "path sizes".
A path size is the sum of the size of the delta chain, including the
base object. In other words, it's how many bytes need be read to
reassemble the file from deltas.
* "tree sizes" are object sizes grouped into delta trees.
* "tree path sizes" are path sizes grouped into delta trees.
* "depths" should be obvious.
When run as:
$ git-verify-pack -v pack | packinfo.pl -tree
The trees of objects are output along with the stats. This looks like:
0 commit 031321c6... 803 803
0 blob 03156f21... 1767 1767
1 blob f52a9d7f... 10 1777
2 blob a8cc5739... 51 1828
3 blob 660e90b1... 15 1843
4 blob 0cb8e3bb... 33 1876
2 blob e48607f0... 311 2088
size: count 6 total 2187 min 10 max 1767 mean 364.50 median 51 std_dev 635.85
path size: count 6 total 11179 min 1767 max 2088 mean 1863.17 median 1843 std_dev 107.26
The first number after the sha1 is the object size, the second number
is the path size. The statistics are across all objects in the previous
delta tree. Obviously they are omitted for trees of one object.
When run as:
$ git-verify-pack -v pack | packinfo.pl -tree -filenames
It adds filenames to the tree. Getting this information is somewhat
slow:
0 blob 03156f21... 1767 1767 Documentation/git-lost-found.txt @ tags/v1.2.0~142
1 blob f52a9d7f... 10 1777 Documentation/git-lost-found.txt @ tags/v1.5.0-rc1~74
2 blob a8cc5739... 51 1828 Documentation/git-lost+found.txt @ tags/v0.99.9h^0
3 blob 660e90b1... 15 1843 Documentation/git-lost+found.txt @ master~3222^2~2
4 blob 0cb8e3bb... 33 1876 Documentation/git-lost+found.txt @ master~3222^2~3
2 blob e48607f0... 311 2088 Documentation/git-lost-found.txt @ tags/v1.5.2-rc3~4
size: count 6 total 2187 min 10 max 1767 mean 364.50 median 51 std_dev 635.85
path size: count 6 total 11179 min 1767 max 2088 mean 1863.17 median 1843 std_dev 107.26
When run as:
$ git-verify-pack -v pack | packinfo.pl -dump
It prints out "sha1 size pathsize depth" for each sha1 in lexical order.
000079a2eaef17b7eae70e1f0f635557ea67b644 30 472 7
00013cafe6980411aa6fdd940784917b5ff50f0a 44 1542 4
000182eacf99cde27d5916aa415921924b82972c 499 499 0
...
This is handy for comparing two packs.
---
packinfo.pl | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 141 insertions(+), 0 deletions(-)
create mode 100644 packinfo.pl
diff --git a/packinfo.pl b/packinfo.pl
new file mode 100644
index 0000000..6abb7f2
--- /dev/null
+++ b/packinfo.pl
@@ -0,0 +1,141 @@
+#!/bin/perl
+
+use strict;
+use Getopt::Long;
+
+my $filenames = 0;
+my $tree = 0;
+my $dump = 0;
+GetOptions("tree" => \$tree,
+ "filenames" => \$filenames,
+ "dump" => \$dump);
+
+my $parents = {};
+my $children = {};
+my $sizes = {};
+my $roots = [];
+my $paths = {};
+my $types = {};
+my $commits = [];
+my $names = {};
+my $depths = {};
+my @depths;
+
+while (<STDIN>) {
+ my ($sha1, $type, $size, $offset, $depth, $parent) = split(/\s+/, $_);
+ next unless ($sha1 =~ /^[0-9a-f]{40}$/);
+ $depths->{$sha1} = $depth || 0;
+ push(@depths, $depth || 0);
+ push(@$commits, $sha1) if ($type eq 'commit');
+ push(@$roots, $sha1) unless $parent;
+ $parents->{$sha1} = $parent;
+ $types->{$sha1} = $type;
+ push(@{$children->{$parent}}, $sha1);
+ $sizes->{$sha1} = $size;
+}
+
+if ($filenames && $tree) {
+ open(NAMES, "git-name-rev --all|");
+ while (<NAMES>) {
+ if (/^(\S+)\s+(.*)$/) {
+ my ($sha1, $name) = ($1, $2);
+ $names->{$sha1} = $name;
+ }
+ }
+ close NAMES;
+
+ for my $commit (@$commits) {
+ my $name = $names->{$commit};
+ open(TREE, "git-ls-tree -t -r $commit|");
+ print STDERR "Plumbing tree $name\n";
+ while (<TREE>) {
+ if (/^(\S+)\s+(\S+)\s+(\S+)\s+(.*)$/) {
+ my ($mode, $type, $sha1, $path) = ($1, $2, $3, $4);
+ $paths->{$sha1} = "$path @ $name";
+ }
+ }
+ close TREE;
+ }
+}
+
+sub stats {
+ my @data = sort {$a <=> $b} @_;
+ my $min = $data[0];
+ my $max = $data[$#data];
+ my $total = 0;
+ my $count = scalar @data;
+ for my $datum (@data) {
+ $total += $datum;
+ }
+ my $mean = $total / $count;
+ my $median = $data[int(@data / 2)];
+ my $diff_sum = 0;
+ for my $datum (@data) {
+ $diff_sum += ($datum - $mean)**2;
+ }
+ my $std_dev = sqrt($diff_sum / $count);
+ return ($count, $total, $min, $max, $mean, $median, $std_dev);
+}
+
+sub print_stats {
+ my $name = shift;
+ my ($count, $total, $min, $max, $mean, $median, $std_dev) = stats(@_);
+ printf("%s: count %s total %s min %s max %s mean %.2f median %s std_dev %.2f\n",
+ $name, $count, $total, $min, $max, $mean, $median, $std_dev);
+}
+
+my @sizes;
+my @path_sizes;
+my @all_sizes;
+my @all_path_sizes;
+my $path_sizes = {};
+
+sub dig {
+ my ($sha1, $depth, $path_size) = @_;
+ $path_size += $sizes->{$sha1};
+ push(@sizes, $sizes->{$sha1});
+ push(@all_sizes, $sizes->{$sha1});
+ push(@path_sizes, $path_size);
+ push(@all_path_sizes, $path_size);
+ $path_sizes->{$sha1} = $path_size;
+ if ($tree) {
+ printf("%3d%s %6s %s %8d %8d %s\n",
+ $depth, (" " x $depth), $types->{$sha1},
+ $sha1, $sizes->{$sha1}, $path_size, $paths->{$sha1});
+ }
+ for my $child (@{$children->{$sha1}}) {
+ dig($child, $depth + 1, $path_size);
+ }
+}
+
+my @tree_sizes;
+my @tree_path_sizes;
+
+for my $root (@$roots) {
+ undef @sizes;
+ undef @path_sizes;
+ dig($root, 0, 0);
+ my ($aa, $sz_total) = stats(@sizes);
+ my ($bb, $psz_total) = stats(@path_sizes);
+ push(@tree_sizes, $sz_total);
+ push(@tree_path_sizes, $psz_total);
+ if ($tree) {
+ if (@sizes > 1) {
+ print_stats(" size", @sizes);
+ print_stats("path size", @path_sizes);
+ }
+ print "\n";
+ }
+}
+
+if ($dump) {
+ for my $sha1 (sort keys %$sizes) {
+ print "$sha1 $sizes->{$sha1} $path_sizes->{$sha1} $depths->{$sha1}\n";
+ }
+} else {
+ print_stats(" all sizes", @all_sizes);
+ print_stats(" all path sizes", @all_path_sizes);
+ print_stats(" tree sizes", @tree_sizes);
+ print_stats("tree path sizes", @tree_path_sizes);
+ print_stats(" depths", @depths);
+}
--
1.5.2.GIT
^ permalink raw reply related
* Re: Preferring shallower deltas on repack
From: Brian Downing @ 2007-07-09 19:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <20070709192403.GM4087@lavos.net>
On Mon, Jul 09, 2007 at 02:24:03PM -0500, Brian Downing wrote:
> No, I didn't try it on top of mine; sorry. I'll try that out.
The results with both your patch and mine are exactly the same as
yours applied to master (c956395e). The only thing mine adds on top of
yours is:
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 9a33698..2da78b4 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1373,6 +1373,12 @@ static int try_delta(struct unpacked *trg, struct unpacke
return 0;
if (trg_entry->delta_data) {
+ /* Prefer only shallower same-sized deltas. */
+ if (delta_size == trg_entry->delta_size &&
+ src_entry->depth + 1 >= trg_entry->depth) {
+ free(delta_buf);
+ return 0;
+ }
delta_cache_size -= trg_entry->delta_size;
free(trg_entry->delta_data);
}
Which was meant to pick off the cases where I got an equivalently
sized patch that was as deep or deeper. This was neccessary due to
my changing:
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1337,7 +1337,7 @@ static int try_delta(struct unpacked *trg, struct unpacked
if (max_size == 0)
return 0;
if (trg_entry->delta && trg_entry->delta_size <= max_size)
- max_size = trg_entry->delta_size-1;
+ max_size = trg_entry->delta_size;
src_size = src_entry->size;
sizediff = src_size < trg_size ? trg_size - src_size : 0;
if (sizediff >= max_size)
max_size = trg_entry->delta_size;
Your patch changed the max_size selection logic, so I'm not sure the
rest of mine will do anything anymore.
-bcd
^ permalink raw reply related
* Re: Preferring shallower deltas on repack
From: Nicolas Pitre @ 2007-07-09 20:22 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git
In-Reply-To: <20070709194931.GO4087@lavos.net>
On Mon, 9 Jul 2007, Brian Downing wrote:
> On Mon, Jul 09, 2007 at 02:24:03PM -0500, Brian Downing wrote:
> > No, I didn't try it on top of mine; sorry. I'll try that out.
>
> The results with both your patch and mine are exactly the same as
> yours applied to master (c956395e). The only thing mine adds on top of
> yours is:
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 9a33698..2da78b4 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1373,6 +1373,12 @@ static int try_delta(struct unpacked *trg, struct unpacke
> return 0;
>
> if (trg_entry->delta_data) {
> + /* Prefer only shallower same-sized deltas. */
> + if (delta_size == trg_entry->delta_size &&
> + src_entry->depth + 1 >= trg_entry->depth) {
> + free(delta_buf);
> + return 0;
> + }
> delta_cache_size -= trg_entry->delta_size;
> free(trg_entry->delta_data);
> }
>
> Which was meant to pick off the cases where I got an equivalently
> sized patch that was as deep or deeper. This was neccessary due to
> my changing:
>
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1337,7 +1337,7 @@ static int try_delta(struct unpacked *trg, struct unpacked
> if (max_size == 0)
> return 0;
> if (trg_entry->delta && trg_entry->delta_size <= max_size)
> - max_size = trg_entry->delta_size-1;
> + max_size = trg_entry->delta_size;
> src_size = src_entry->size;
> sizediff = src_size < trg_size ? trg_size - src_size : 0;
> if (sizediff >= max_size)
>
> max_size = trg_entry->delta_size;
>
> Your patch changed the max_size selection logic, so I'm not sure the
> rest of mine will do anything anymore.
It is still valid nevertheless.
Nicolas
^ permalink raw reply
* Re: Preferring shallower deltas on repack
From: Brian Downing @ 2007-07-09 20:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <20070709194931.GO4087@lavos.net>
On Mon, Jul 09, 2007 at 02:49:32PM -0500, Brian Downing wrote:
> The results with both your patch and mine are exactly the same as
> yours applied to master (c956395e).
Sorry, that's not quite right. The statistics were close enough that my
vdiff failed, though. :)
Here are all the diffs through my pack analyzer. There's amazingly few
and they very nearly cancel each other out:
--- treetree-nico 2007-07-09 15:19:10.000000000 -0500
+++ treetree-nicobd 2007-07-09 15:18:45.000000000 -0500
@@ -25392,12 +25392,15 @@
0 commit 7cde9fabcd145901785a468a87108f7d9c4291fc 544 544
0 blob 7ce2b21be4ac425a8423ec69c6036a53311df5cb 2347 2347
+ 1 blob 25140bfb264e7b9c8fe4b97318297630cc93b112 313 2660
+ 2 blob ba80ac333acefc68362e66d6f8e61531263e135a 15 2675
+ 3 blob 6f18434f6815a037d6fa15c38d3f460b530e585b 161 2836
1 blob 4dbd333da74ad866f0bff154d6cffea11b9a841a 9 2356
2 blob ddb93ae086bf0393c9d53247732a2c29af33c80c 313 2669
3 blob d34e346a0f2ea6fdb2acc414d10635dc4d326d25 11 2680
4 blob 368243c09993f7ee8b56c7ba184bef134a91607c 11 2691
- size: count 5 total 2691 min 9 max 2347 mean 538.20 median 11 std_dev 911.97
-path size: count 5 total 12743 min 2347 max 2691 mean 2548.60 median 2669 std_dev 161.11
+ size: count 8 total 3180 min 9 max 2347 mean 397.50 median 161 std_dev 747.23
+path size: count 8 total 20914 min 2347 max 2836 mean 2614.25 median 2675 std_dev 160.58
0 commit 7ce2c42adf3d62f03086de940adaee48e6161a40 579 579
@@ -47249,6 +47252,9 @@
0 commit d5319592583dda6833b74b34b52dbd2aa3109948 468 468
0 tree d53239e82aaed72745097f00b32807f2eb71997d 104 104
+ 1 tree 9c01548d14e5b766397e6d5595566269094057bb 5 109
+ size: count 2 total 109 min 5 max 104 mean 54.50 median 104 std_dev 49.50
+path size: count 2 total 213 min 104 max 109 mean 106.50 median 109 std_dev 2.50
0 commit d5393dd736972a5c84cd97fec9892cd3da80b669 450 450
@@ -48702,9 +48708,6 @@
path size: count 16 total 111347 min 6404 max 7298 mean 6959.19 median 7142 std_dev 333.27
0 tree df1a6239457293813f34eee001187d725e718062 104 104
- 1 tree 9c01548d14e5b766397e6d5595566269094057bb 5 109
- size: count 2 total 109 min 5 max 104 mean 54.50 median 104 std_dev 49.50
-path size: count 2 total 213 min 104 max 109 mean 106.50 median 109 std_dev 2.50
0 commit df1eebdf125384f3bf7eb2b15b874043504797e6 364 364
@@ -49407,10 +49410,14 @@
0 blob e4285f4b5739d4a2385b28c4e4fd60cc40beb2a1 217 217
0 blob e42a4ea85cbac543f20fba2e1cb95b35c3a8a553 1021 1021
+ 1 blob 9a7565236131c7c2b0f4bc5ae8ddb79cfc0eb418 112 1133
+ 2 blob 9d8583de4217d0515125464300321f20539355e1 65 1198
+ 2 blob f8994669d23fa5c008cfdf58ea63a0b88e46f651 14 1147
+ 3 blob 3eec762b65518ffe72ffb29cd30a1bb481f6e898 19 1166
1 blob ae1a1001c0d71a8407a3432ff9e2ba7dab59166b 43 1064
2 blob 3127f77e001d0b45359254ca59af9f6a62401d77 12 1076
- size: count 3 total 1076 min 12 max 1021 mean 358.67 median 43 std_dev 468.51
-path size: count 3 total 3161 min 1021 max 1076 mean 1053.67 median 1064 std_dev 23.61
+ size: count 7 total 1286 min 12 max 1021 mean 183.71 median 43 std_dev 343.41
+path size: count 7 total 7805 min 1021 max 1198 mean 1115.00 median 1133 std_dev 58.30
0 blob e431cf36086c97b6e22eb741e7566100d3133c42 4766 4766
1 blob 344136d826427f400d93240f12b8c070d700ece2 448 5214
@@ -52503,13 +52510,9 @@
2 blob 651668cdb7db56dba200db8a53732ac984aaac04 12 4524
3 blob b31d0f38830ff8fdcdfd81b386993bc2b2216a38 16 4540
4 blob ec7899967381c5993e45df411077b598c7d25831 12 4552
- 1 blob 9a7565236131c7c2b0f4bc5ae8ddb79cfc0eb418 112 4567
- 2 blob 9d8583de4217d0515125464300321f20539355e1 65 4632
- 2 blob f8994669d23fa5c008cfdf58ea63a0b88e46f651 14 4581
- 3 blob 3eec762b65518ffe72ffb29cd30a1bb481f6e898 19 4600
1 blob e8a23b634fef5a9d906e3185d65fae8979612851 20 4475
- size: count 60 total 7628 min 11 max 4455 mean 127.13 median 20 std_dev 569.75
-path size: count 60 total 298378 min 4455 max 5455 mean 4972.97 median 5017 std_dev 318.40
+ size: count 56 total 7418 min 11 max 4455 mean 132.46 median 20 std_dev 589.29
+path size: count 56 total 279998 min 4455 max 5455 mean 4999.96 median 5031 std_dev 312.48
0 tree ee1ece9ab33edbe7ec1eebcbe9b259c7a9dded4c 196 196
@@ -54809,16 +54812,13 @@
0 commit fb76e3acd8b8a53cdadaa65bce1d090d99e004a0 324 324
0 blob fb7b9c91f11921e2d3ac5b20d2c10728dd5ba173 2417 2417
- 1 blob 25140bfb264e7b9c8fe4b97318297630cc93b112 313 2730
- 2 blob ba80ac333acefc68362e66d6f8e61531263e135a 15 2745
- 3 blob 6f18434f6815a037d6fa15c38d3f460b530e585b 161 2906
1 blob f0d45243029e1e1a9ef4d499dcb5934de4c523b9 11 2428
2 blob c9eab11115a061a457bb84e0a4b0fa1a140cf0da 41 2469
3 blob b54b3745c995f8284d1700a8f9b61eed0ed7548e 7 2476
1 blob fb107f406660f5faff8d00d060af1478ad21a6bf 15 2432
2 blob 829950c079edad38eeaeb4663ea8e96b4d6fedb7 7 2439
- size: count 9 total 2987 min 7 max 2417 mean 331.89 median 15 std_dev 743.62
-path size: count 9 total 23042 min 2417 max 2906 mean 2560.22 median 2469 std_dev 172.26
+ size: count 6 total 2498 min 7 max 2417 mean 416.33 median 15 std_dev 894.80
+path size: count 6 total 14661 min 2417 max 2476 mean 2443.50 median 2439 std_dev 21.61
0 commit fb8533122551bbb7aea669f40bc91c1211809b58 778 778
@@ -56646,7 +56646,7 @@
0 commit ffe8d65266ed7c2c67a0a6ce7ff0de633000037e 474 474
all sizes: count 46829 total 30253345 min 0 max 1012295 mean 646.04 median 45 std_dev 9555.49
- all path sizes: count 46829 total 1518730701 min 0 max 1012295 mean 32431.41 median 10819 std_dev 54751.35
+ all path sizes: count 46829 total 1518716755 min 0 max 1012295 mean 32431.12 median 10819 std_dev 54751.51
tree sizes: count 6442 total 30253345 min 0 max 1012295 mean 4696.27 median 422 std_dev 28603.08
-tree path sizes: count 6442 total 1518730701 min 0 max 306510684 mean 235754.53 median 458 std_dev 4198348.32
+tree path sizes: count 6442 total 1518716755 min 0 max 306510684 mean 235752.37 median 458 std_dev 4198348.25
depths: count 46829 total 3694511 min 0 max 699 mean 78.89 median 12 std_dev 141.53
^ permalink raw reply
* Re: [PATCH] branch --track: code cleanup and saner handling of local branches
From: Junio C Hamano @ 2007-07-09 21:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.64.0707091228290.5546@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> @@ -349,125 +345,111 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev,
> free_ref_list(&ref_list);
> }
>
> -static char *config_repo;
> -static char *config_remote;
> -static const char *start_ref;
> +static struct {
> + const char *ref;
> + int ref_len;
> + char *remote;
> + char *merge;
> + int matches;
> +} tracking;
>
> -static int get_remote_branch_name(const char *value)
> +static int tracking_config(const char *key, const char *value)
> {
> const char *colon;
> + int key_len, value_len, match_len;
> + char *merge = NULL;
>
> - colon = strchr(value, ':');
> - if (!colon)
> + /* we want: remote.<nick>.fetch = <merge>:<ref> */
> + if (prefixcmp(key, "remote.") || (key_len = strlen(key)) < 6 ||
> + strcmp(key + key_len - 6, ".fetch") ||
> + !(colon = strchr(value, ':')))
> return 0;
>
> - end = value + strlen(value);
> + if (*value == '+')
> + value++;
>
> /*
> - * Try an exact match first. I.e. handle the case where the
> - * value is "$anything:refs/foo/bar/baz" and start_ref is exactly
> - * "refs/foo/bar/baz". Then the name at the remote is $anything.
> + * A remote.<name>.fetch value can have two forms:
> + *
> + * - exact:
> + *
> + * refs/heads/gnu:refs/heads/my-upstream
> + *
> + * - wildcard:
> + *
> + * refs/heads/ *:refs/remotes/gnu/ *
> + *
> + * try exact match first:
> */
It strikes me a bit odd if Daniel's remote.[ch] infrastructure
does not give you easy access to this kind of information...
^ permalink raw reply
* Re: [PATCH] branch --track: code cleanup and saner handling of local branches
From: Johannes Schindelin @ 2007-07-09 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <7v4pkduw2f.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 9 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > -static int get_remote_branch_name(const char *value)
> > +static int tracking_config(const char *key, const char *value)
> > [...]
> > /*
> > - * Try an exact match first. I.e. handle the case where the
> > - * value is "$anything:refs/foo/bar/baz" and start_ref is exactly
> > - * "refs/foo/bar/baz". Then the name at the remote is $anything.
> > + * A remote.<name>.fetch value can have two forms:
> > + *
> > + * - exact:
> > + *
> > + * refs/heads/gnu:refs/heads/my-upstream
> > + *
> > + * - wildcard:
> > + *
> > + * refs/heads/ *:refs/remotes/gnu/ *
> > + *
> > + * try exact match first:
> > */
>
> It strikes me a bit odd if Daniel's remote.[ch] infrastructure
> does not give you easy access to this kind of information...
Yes, probably. However, at the time he was sending that patch, I was
already preparing the patch. Besides, we can always go back and change
the code, if you really want to pull in the remotes stuff into
builtin-branch (as of yet, they are almost independent).
My vote is to have it indpendent for now, if only to fix existing issues.
But in the end it is your choice.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: New cgi parameter: filter
From: VMiklos @ 2007-07-09 21:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Petr Baudis, Jakub Narebski, Luben Tuikov
In-Reply-To: <20070708013543.GD29994@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Hello,
Na Sun, Jul 08, 2007 at 03:35:43AM +0200, Miklos Vajna <vmiklos@frugalware.org> pisal(a):
> Currently the only supported value is "nomerges". This allows one to filter
> merges from many actions, like rss, log and shortlog.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
What do you think about this patch? Is it something that useful only for
me?
Some Frugalware users claimed about that most git-log-like command have
a --no-merges opcion but the rss feed, that's why i added such a
feature.
Thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] branch --track: code cleanup and saner handling of local branches
From: Junio C Hamano @ 2007-07-09 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.64.0707092203100.5546@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> It strikes me a bit odd if Daniel's remote.[ch] infrastructure
>> does not give you easy access to this kind of information...
>
> Yes, probably. However, at the time he was sending that patch, I was
> already preparing the patch.
I was talking about existing remote.[ch] patches, which has been
in tree since late May this year, not his recent round of
"approach to builtin git-fetch" series.
^ 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