* Re: WARNING: THIS PATCH CAN BREAK YOUR REPO, was Re: [PATCH 2/3] Only repack active packs by skipping over kept packs.
From: Jan Harkes @ 2006-10-30 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b95wjmg.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 30, 2006 at 01:59:03PM -0800, Junio C Hamano wrote:
> Jan Harkes <jaharkes@cs.cmu.edu> writes:
>
> > The following patch does fix the problem Nicolas reported, but for some
> > reason I'm still getting only 102 objects (only tags and the commits
> > they refer to?) with your test.
>
> One potential downside of this is that this makes an obscure but
> useful "gitk --unpacked" useless (robs performance).
>
> http://thread.gmane.org/gmane.comp.version-control.git/19197/focus=19207
If I use 'git fetch' followed later on by a 'git fetch -k', the result
from --unpacked would not include the unpacked objects created by the
first fetch. Although it may have been fast, it seems to be somewhat
counter-intuitive.
> But other than that, I think it is an Ok change. The original
> semantics of --unpacked (with or without "pretend as if objects
> in this pack are loose") were, eh, "strange".
Do you need a resend with a proper 'Signed-Off-By' line?
Jan
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-30 22:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610301458.33634.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I have realized that it is not as easy as it sounds, at least for the
> git-diff-tree output...
I do not think so.a The output is designed to be machine
parsable. See Documentation/diff-format.txt and also please
refer to 65a9289d:diff-helper.c for a sample code to see how to
parse the output.
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-30 23:00 UTC (permalink / raw)
To: ltuikov; +Cc: git, Jakub Narebski
In-Reply-To: <578323.77588.qm@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> That was just to note that if you don't agree with default, you can change
>> it very easily. It is probably the time where people would disagree (for
>> example infamous "redundant links" debate) on the gitweb UI; the possibility
>> to tailor it easily to your own UI concepts and ideas is in my opinion
>> very important (and very nice).
>
> I would like to keep the visual default as stable as possible.
>
> Luben
Seconded.
^ permalink raw reply
* Re: [PATCH 2/2] git push: add verbose flag and allow overriding of default target repository
From: Junio C Hamano @ 2006-10-30 23:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610300825470.25218@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This adds a command line flag "-v" to enable a more verbose mode, and
> "--repo=" to override the default target repository for "git push" (which
> otherwise always defaults to "origin").
>
> This, together with the patch to allow dashes in config variable names,
> allows me to do
>
> [alias]
> push-all = push -v --repo=all
>
> in my user-global config file, and then I can (for any project I maintain)
> add to the project-local config file
>
> [remote "all"]
> url=one.target.repo:/directory
> url=another.target:/pub/somewhere/else
>
> and now "git push-all" just updates all the target repositories, and shows
> me what it does - regardless of which repo I am in.
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> ---
>
> Maybe this is just useful to me? I dunno.
I would say if something is useful to you it is useful to your
subsystem people and anybody who has a public tree and more than
one machines to verify the tips of his branches on, including
me.
^ permalink raw reply
* Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.
From: Junio C Hamano @ 2006-10-30 23:04 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061030223615.GH5775@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Currently this leaves every received pack as a kept pack. We really
> don't want that as received packs will tend to be small.
Until this is resolved, I feel there should be some way to
control the behaviour, so while I agree with the general
direction, I think the patch to revert the sender's wish should
come at the end.
^ permalink raw reply
* Re: [PATCH] Move deny_non_fast_forwards handling completely into receive-pack.
From: Junio C Hamano @ 2006-10-30 23:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061030223518.GF5775@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> The 'receive.denynonfastforwards' option has nothing to do with
> the repository format version. Since receive-pack already uses
> git_config to initialize itself before executing any updates we
> can use the normal configuration strategy and isolate the receive
> specific variables away from the core variables.
Sounds sane. Thanks.
^ permalink raw reply
* Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.
From: Junio C Hamano @ 2006-10-30 23:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061030223615.GH5775@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Since keeping a pushed pack or exploding it into loose objects should
> be a local repository decision this teaches receive-pack to decide
> if it should call unpack-objects or index-pack --stdin --fix-thin
> based on the setting of receive.unpackLooseObjects.
One thing you can cheaply do is to tell the number of new
commits that is coming to receive-pack from send-pack when it
sends the old..new pairs before it sends the packfile payload.
It would be just a single internal rev-list call inside
send-pack, which is reasonably cheap.
If the receiving end knows how to process that new information
(invent a "send-count" protocol extension and send it just like
we already send "report-status" request), send one extra packet
after flushing the list of old..new from send-pack to
receive-pack, to tell what the number of commits are, and make a
matching change in receive-pack.
Then, instead of receive.unpackLooseObjects being a boolean, you
can have it as a ceiling to decide if you have more than 100
commits you would keep it packed and otherwise you would
explode. That would be very specific to the projects' size
(width of the tree) and style (huge commits vs lots of small
changes).
^ permalink raw reply
* Re: WARNING: THIS PATCH CAN BREAK YOUR REPO, was Re: [PATCH 2/3] Only repack active packs by skipping over kept packs.
From: Junio C Hamano @ 2006-10-30 23:24 UTC (permalink / raw)
To: Jan Harkes; +Cc: git
In-Reply-To: <20061030225500.GG3617@delft.aura.cs.cmu.edu>
Jan Harkes <jaharkes@cs.cmu.edu> writes:
> On Mon, Oct 30, 2006 at 01:59:03PM -0800, Junio C Hamano wrote:
>> Jan Harkes <jaharkes@cs.cmu.edu> writes:
>>
>> > The following patch does fix the problem Nicolas reported, but for some
>> > reason I'm still getting only 102 objects (only tags and the commits
>> > they refer to?) with your test.
>>
>> One potential downside of this is that this makes an obscure but
>> useful "gitk --unpacked" useless (robs performance).
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/19197/focus=19207
>
> If I use 'git fetch' followed later on by a 'git fetch -k', the result
> from --unpacked would not include the unpacked objects created by the
> first fetch. Although it may have been fast, it seems to be somewhat
> counter-intuitive.
>
>> But other than that, I think it is an Ok change. The original
>> semantics of --unpacked (with or without "pretend as if objects
>> in this pack are loose") were, eh, "strange".
>
> Do you need a resend with a proper 'Signed-Off-By' line?
Oh, I was planning to write a fairly detailed explanation
myself, but the description with S-o-b by the original author
would certainly be more appropriate. Thanks.
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-30 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iyhv29o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I have realized that it is not as easy as it sounds, at least for the
>> git-diff-tree output...
>
> I do not think so.a The output is designed to be machine
> parsable. See Documentation/diff-format.txt and also please
> refer to 65a9289d:diff-helper.c for a sample code to see how to
> parse the output.
What I wanted to say is that the output is not easy to use in
"split first, parse later", with sometimes counting number of entries
in between. With current format you rather have to pass in one go,
for '-z' format reading filenames from the stream.
By the way, git-ls-tree -z uses TAB as a start of filename, while
git-diff-tree -z uses NUL as a start of (first) filename. Why?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-30 23:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610310032.09726.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, git-ls-tree -z uses TAB as a start of filename, while
> git-diff-tree -z uses NUL as a start of (first) filename. Why?
I do not know a good explanation other than hysterical raisins.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-10-31 0:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610301959.05313.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Use "&iquot;" Latin 1 entity ("¿" -- inverted question mark =
> turned question mark, U+00BF ISOnum) instead '?' as replacements for
> control characters and other undisplayable characters.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Do you have something against our Spanish and Latin American
friends? ;-)
I wonder if there is a more suitable replacement character that
is accepted across scripts?
Japanese printing industry has a long tradition of using U+3013
("geta") as a filler character. Originally they placed a type
of otherwise unused character upside down while packing types
into a row, and the reverse side of a type, when inked and
printed, left imprint that looked like footprint somebody who
wore a "geta" (a traditional footware) would leave.
http://ja.wikipedia.org/wiki/%E4%B8%8B%E9%A7%84
shows how a "geta" looks like, and
http://unicode.org/charts/PDF/U3000.pdf
shows how the filler character looks like.
Note that I am not suggesting to use ௅ as a replacement at
all. I however think inverted question is inappropriate, and we
should pick something else if we are fixing the question mark
which is obviously inappropriate.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-10-31 1:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7vzmbds4pw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Use "&iquot;" Latin 1 entity ("¿" -- inverted question mark =
>> turned question mark, U+00BF ISOnum) instead '?' as replacements for
>> control characters and other undisplayable characters.
>>
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>
> Do you have something against our Spanish and Latin American
> friends? ;-)
>
> I wonder if there is a more suitable replacement character that
> is accepted across scripts?
I have a suspicion that instead of finding an exotic character,
just showing the byte value in \octal, perhaps in different
color, might be more portable and easier. For one thing, it
helps to show the exact byte value than just one substitution
character if you are troubleshooting gitweb.
^ permalink raw reply
* Re: Use memmove instead of memcpy for overlapping areas
From: Junio C Hamano @ 2006-10-31 1:37 UTC (permalink / raw)
To: Edgar Toernig; +Cc: git
In-Reply-To: <20061030222615.1e38908b.froese@gmx.de>
Edgar Toernig <froese@gmx.de> writes:
> There may be more - this is just the result of a quick eye-grep
> for memcpy(x, x+i).
Thanks. Sign-off?
Among many false hit,
$ git grep 'memcpy.*( *\(.*\),.*\1.*+'
gives this one:
builtin-unpack-objects.c: memcpy(buffer, buffer + offset, len);
^ permalink raw reply
* [PATCH] Continue traversal when rev-list --unpacked finds a packed commit.
From: Jan Harkes @ 2006-10-31 1:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcxltmit.fsf@assigned-by-dhcp.cox.net>
When getting the list of all unpacked objects by walking the commit history,
we would stop traversal whenever we hit a packed commit. However the fact
that we found a packed commit does not guarantee that all previous commits
are also packed. As a result the commit walkers did not show all reachable
unpacked objects.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
revision.c | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/revision.c b/revision.c
index 280e92b..a69c873 100644
--- a/revision.c
+++ b/revision.c
@@ -418,9 +418,6 @@ static void limit_list(struct rev_info *
if (revs->max_age != -1 && (commit->date < revs->max_age))
obj->flags |= UNINTERESTING;
- if (revs->unpacked &&
- has_sha1_pack(obj->sha1, revs->ignore_packed))
- obj->flags |= UNINTERESTING;
add_parents_to_list(revs, commit, &list);
if (obj->flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
@@ -1149,17 +1146,18 @@ struct commit *get_revision(struct rev_i
* that we'd otherwise have done in limit_list().
*/
if (!revs->limited) {
- if ((revs->unpacked &&
- has_sha1_pack(commit->object.sha1,
- revs->ignore_packed)) ||
- (revs->max_age != -1 &&
- (commit->date < revs->max_age)))
+ if (revs->max_age != -1 &&
+ (commit->date < revs->max_age))
continue;
add_parents_to_list(revs, commit, &revs->commits);
}
if (commit->object.flags & SHOWN)
continue;
+ if (revs->unpacked && has_sha1_pack(commit->object.sha1,
+ revs->ignore_packed))
+ continue;
+
/* We want to show boundary commits only when their
* children are shown. When path-limiter is in effect,
* rewrite_parents() drops some commits from getting shown,
--
1.4.2.4.gd5de
^ permalink raw reply related
* Re: [PATCH] Continue traversal when rev-list --unpacked finds a packed commit.
From: Junio C Hamano @ 2006-10-31 1:47 UTC (permalink / raw)
To: Jan Harkes; +Cc: git, Linus Torvalds
In-Reply-To: <20061031013749.GA19885@delft.aura.cs.cmu.edu>
Jan Harkes <jaharkes@cs.cmu.edu> writes:
> When getting the list of all unpacked objects by walking the commit history,
> we would stop traversal whenever we hit a packed commit. However the fact
> that we found a packed commit does not guarantee that all previous commits
> are also packed. As a result the commit walkers did not show all reachable
> unpacked objects.
>
> Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
Thanks.
With this, I think revs->unpacked should not mean "limited", so
I suspect this is also needed, no?
diff --git a/revision.c b/revision.c
index 93f2513..2d7cad9 100644
--- a/revision.c
+++ b/revision.c
@@ -1010,7 +1010,7 @@ int setup_revisions(int argc, const char
add_pending_object(revs, object, def);
}
- if (revs->topo_order || revs->unpacked)
+ if (revs->topo_order)
revs->limited = 1;
if (revs->prune_data) {
^ permalink raw reply related
* Re: [PATCH] Continue traversal when rev-list --unpacked finds a packed commit.
From: Jan Harkes @ 2006-10-31 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vk62hs1ct.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 30, 2006 at 05:47:14PM -0800, Junio C Hamano wrote:
> Jan Harkes <jaharkes@cs.cmu.edu> writes:
>
> > When getting the list of all unpacked objects by walking the commit history,
> > we would stop traversal whenever we hit a packed commit. However the fact
> > that we found a packed commit does not guarantee that all previous commits
> > are also packed. As a result the commit walkers did not show all reachable
> > unpacked objects.
> >
> > Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
>
> Thanks.
>
> With this, I think revs->unpacked should not mean "limited", so
> I suspect this is also needed, no?
I'm not familiar enough with the code to know for sure, but my gut
feeling is that that would be needed. Let me check...
When that flag is set, the code calls limit_list, which no longer stops
traversal when we hit a packed commit. So we end up with a list of all
commits in memory. If the flag is not set, the list is kept minimal and
parents are only traversed as they are encountered.
So it looks like not setting the flag reduces memory usage we traverse
all parents in both cases. Yes, you are correct.
Jan
^ permalink raw reply
* Re: [PATCH 1/2] Allow '-' in config variable names
From: Junio C Hamano @ 2006-10-31 3:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vodrtv2wy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> I need this in order to allow aliases of the same form as "ls-tree",
>> "rev-parse" etc, so that I can use
>>
>> [alias]
>> my-cat=--paginate cat-file -p
>>
>> to add a "git my-cat" command.
>
> I do not have problem with this (and would perhaps also want to
> add '_' to keychar set), but people who envisioned parsing
> config from scripts (i.e. Perly git) might prefer if we stayed
> within alnum, since I'd suspect then they may be able to reuse
> existing .ini parsers. I do not much care about that myself,
> but I am bringing it up just in case other people might.
>
> Other than that, this sounds nice.
One thing I forgot to add. Just like we downcase what user has
written in config file, it might make sense to also remove '-'
(and if we add '_' to keychar set, that one as well) to when
canonicalizing the key value. That way, somewhat awkward long
configuration variables we currently have can be written more
readably, e.g. repack.use-delta-base-offset
Likes, dislikes? It is not strictly needed, since we can do
CamelCase as well in the configuration file.
> By the way, everybody seems to do "alias.xxx = -p cat-file -p"
> (I have it as "git less"). Maybe we would want to make a
> built-in alias for that?
Seconds?
^ permalink raw reply
* Re: [PATCH 1/2] Allow '-' in config variable names
From: J. Bruce Fields @ 2006-10-31 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vfyd5rxvg.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 30, 2006 at 07:02:27PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > By the way, everybody seems to do "alias.xxx = -p cat-file -p"
> > (I have it as "git less"). Maybe we would want to make a
> > built-in alias for that?
>
> Seconds?
Yes!
I'd vote for calling it just "git cat".
^ permalink raw reply
* Re: [PATCH 2/2] git push: add verbose flag and allow overriding of default target repository
From: Junio C Hamano @ 2006-10-31 3:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0610300825470.25218@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> diff --git a/builtin-push.c b/builtin-push.c
> index f5150ed..3151fb7 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -10,7 +10,7 @@
>
> static const char push_usage[] = "git-push [--all] [--tags] [-f | --force] <repository> [<refspec>...]";
>
> -static int all, tags, force, thin = 1;
> +static int all, tags, force, thin = 1, verbose;
> static const char *execute;
>
> #define BUF_SIZE (2084)
By the way, has anybody noticed we use a funny value for the
buffer size?
^ permalink raw reply
* Re: [PATCH 1/2] Allow '-' in config variable names
From: Linus Torvalds @ 2006-10-31 3:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyd5rxvg.fsf@assigned-by-dhcp.cox.net>
On Mon, 30 Oct 2006, Junio C Hamano wrote:
>
> One thing I forgot to add. Just like we downcase what user has
> written in config file, it might make sense to also remove '-'
> (and if we add '_' to keychar set, that one as well) to when
> canonicalizing the key value. That way, somewhat awkward long
> configuration variables we currently have can be written more
> readably, e.g. repack.use-delta-base-offset
Well, then we need to teach "git <alias>" that "git <al-i-as>" is the same
thing as "alias".
> > By the way, everybody seems to do "alias.xxx = -p cat-file -p"
> > (I have it as "git less"). Maybe we would want to make a
> > built-in alias for that?
>
> Seconds?
I like it mainly as a great example of how to use aliases, not because I
actually much -use- the thing, so I don't personally care.
^ permalink raw reply
* Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.
From: Nicolas Pitre @ 2006-10-31 4:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vlkmxtmln.fsf@assigned-by-dhcp.cox.net>
On Mon, 30 Oct 2006, Junio C Hamano wrote:
> One thing you can cheaply do is to tell the number of new
> commits that is coming to receive-pack from send-pack when it
> sends the old..new pairs before it sends the packfile payload.
> It would be just a single internal rev-list call inside
> send-pack, which is reasonably cheap.
Well, it could even be avoided.
> If the receiving end knows how to process that new information
> (invent a "send-count" protocol extension and send it just like
> we already send "report-status" request), send one extra packet
> after flushing the list of old..new from send-pack to
> receive-pack, to tell what the number of commits are, and make a
> matching change in receive-pack.
I don't like this much since a commit can carry along very little or
very large amount of objects. You really want to decide on the number
of objects.
Why not just parse the pack header in receive-pack / fetch-pack, and
decide on the first-hand information? Sure the pack header is then
gone, but then the only thing that is needed is an extra flag to both
unpack-objects and index-pack to tell them that we've already parsed the
pack header and that the pack version is x and the number of objects is
y. Simply something like --pack_header=x,y. No protocol extension
needed, no extra rev-list, no reliance on the remote server providing
the needed info.
^ permalink raw reply
* Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.
From: Junio C Hamano @ 2006-10-31 4:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610302258400.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Why not just parse the pack header in receive-pack / fetch-pack, and
> decide on the first-hand information? Sure the pack header is then
> gone, but then the only thing that is needed is an extra flag to both
> unpack-objects and index-pack to tell them that we've already parsed the
> pack header and that the pack version is x and the number of objects is
> y. Simply something like --pack_header=x,y. No protocol extension
> needed, no extra rev-list, no reliance on the remote server providing
> the needed info.
I like it.
Because that approach assumes recieve-pack and unpack-objects
and index-pack are from the same vintage (otherwise your
receive-pack would need to have a way to see if unpack-objects
and index-pack would grok --pack_header argument), we could even
get away without passing the pack version if we wanted to.
^ permalink raw reply
* Re: [PATCH 1/5] upload-pack: no longer call rev-list
From: Junio C Hamano @ 2006-10-31 5:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610302008320.26682@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is trivial to do now,...
May be, but can we do something about these duplicated code?
> @@ -57,6 +60,40 @@ static ssize_t send_client_data(int fd,
> return safe_write(fd, data, sz);
> }
>
> +FILE *pack_pipe = NULL;
> +static void show_commit(struct commit *commit)
> +{
> + if (commit->object.flags & BOUNDARY)
> + fputc('-', pack_pipe);
> + if (fputs(sha1_to_hex(commit->object.sha1), pack_pipe) < 0)
> + die("broken output pipe");
> + fputc('\n', pack_pipe);
> + fflush(pack_pipe);
> + free(commit->buffer);
> + commit->buffer = NULL;
> +}
> +
> +static void show_object(struct object_array_entry *p)
> +{
> + /* An object with name "foo\n0000000..." can be used to
> + * confuse downstream git-pack-objects very badly.
> + */
> + const char *ep = strchr(p->name, '\n');
> + if (ep) {
> + fprintf(pack_pipe, "%s %.*s\n", sha1_to_hex(p->item->sha1),
> + (int) (ep - p->name),
> + p->name);
> + }
> + else
> + fprintf(pack_pipe, "%s %s\n",
> + sha1_to_hex(p->item->sha1), p->name);
> +}
> +
> +static void show_edge(struct commit *commit)
> +{
> + fprintf(pack_pipe, "-%s\n", sha1_to_hex(commit->object.sha1));
> +}
> +
^ permalink raw reply
* Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.
From: Shawn Pearce @ 2006-10-31 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu01ltnfs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Until this is resolved, I feel there should be some way to
> control the behaviour, so while I agree with the general
> direction, I think the patch to revert the sender's wish should
> come at the end.
I disagree, but I'm not the maintainer. :-)
I reverted it before making my changes as I was editing the same
lines as c7740a modified. Therefore reverting c7740a after my
changes would no longer be a clean revert, making it slightly
harder to actuallly do the revert as you would need to manually
fix up receive-pack.c.
--
^ permalink raw reply
* Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.
From: Shawn Pearce @ 2006-10-31 6:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v7iyhrsoi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Why not just parse the pack header in receive-pack / fetch-pack, and
> > decide on the first-hand information? Sure the pack header is then
> > gone, but then the only thing that is needed is an extra flag to both
> > unpack-objects and index-pack to tell them that we've already parsed the
> > pack header and that the pack version is x and the number of objects is
> > y. Simply something like --pack_header=x,y. No protocol extension
> > needed, no extra rev-list, no reliance on the remote server providing
> > the needed info.
>
> I like it.
>
> Because that approach assumes recieve-pack and unpack-objects
> and index-pack are from the same vintage (otherwise your
> receive-pack would need to have a way to see if unpack-objects
> and index-pack would grok --pack_header argument), we could even
> get away without passing the pack version if we wanted to.
Heh. On Saturday I almost did exactly what Nico proposes above.
But I thought both of you would find the --pack_header=x,y option
too brittle and would reject the change.
But since all three of us liked the same idea I'll code it up
and resend my receive-pack patch using Nico's suggestion instead.
Hopefully I'll get it out tomorrow.
BTW I think we do need to pass the pack version in the option.
If we ever do increment the pack version its going to be after this
option is introduced so supporting the option does not imply that
the callee is able to parse the pack file without knowing what
version the file is, especially if the callee supports both the
current version and the new version.
--
^ 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