* [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-11-26 23:18 UTC (permalink / raw)
To: gitster; +Cc: git, Robin Rosenberg
This patch makes it possible to drag files and directories from
a graphical browser and drop them onto a shell and feed them
to common git operations without editing away the path to the
root of the work tree.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
setup.c | 16 ++++++++++++++
t/t3904-abspatharg.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 69 insertions(+), 0 deletions(-)
create mode 100755 t/t3904-abspatharg.sh
Was it this simple?
diff --git a/setup.c b/setup.c
index 43cd3f9..9b3a9ff 100644
--- a/setup.c
+++ b/setup.c
@@ -6,6 +6,22 @@ static int inside_work_tree = -1;
const char *prefix_path(const char *prefix, int len, const char *path)
{
+ if (is_absolute_path(path)) {
+ const char *work_tree = get_git_work_tree();
+ int n = strlen(work_tree);
+ if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
+ if (path[n])
+ path += 1;
+ path += n;
+ if (prefix && !strncmp(path, prefix, len - 1)) {
+ if (path[len - 1] == '/')
+ path += len;
+ else
+ if (!path[len - 1])
+ path += len - 1;
+ }
+ }
+ }
const char *orig = path;
for (;;) {
char c;
diff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh
new file mode 100755
index 0000000..aa47602
--- /dev/null
+++ b/t/t3904-abspatharg.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (C) 2007 Robin Rosenberg
+#
+
+test_description='Test absolute filename arguments to various git
+commands. Absolute arguments pointing to a location within the git
+work tree should behave the same as relative arguments. '
+
+. ./test-lib.sh
+
+test_expect_success 'add files using absolute path names' '
+echo a >afile &&
+echo b >bfile &&
+git-add afile &&
+git-add $(pwd)/bfile &&
+test "afile bfile" = "$(echo $(git ls-files))"
+mkdir x &&
+cd x &&
+echo c >cfile &&
+echo d >dfile &&
+git-add cfile &&
+git-add $(pwd) &&
+cd .. &&
+test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
+test "$(echo $(git ls-files x))" = "$(echo $(git ls-files $(pwd)/x))"
+'
+
+test_expect_success 'commit using absolute path names' '
+git commit -m "foo" &&
+echo aa >>bfile &&
+git commit -m "bb" $(pwd)/bfile
+'
+
+test_expect_success 'log using absolute path names' '
+git log afile >f1.txt &&
+git log $(pwd)/afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_expect_success 'blame using absolute path names' '
+git blame afile >f1.txt &&
+git blame $(pwd)/afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_expect_success 'diff using absolute path names' '
+git diff HEAD^ -- $(pwd)/afile >f1.txt &&
+git diff HEAD^ -- afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_done
--
1.5.3.5.1.gb2df9
^ permalink raw reply related
* Re: Git Screencast ?
From: Christian MICHON @ 2007-11-26 23:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0711261333p4c99f447k81c3833cd679e551@mail.gmail.com>
On Nov 26, 2007 10:33 PM, Scott Chacon <schacon@gmail.com> wrote:
> I've created a screencast on using Git to manage and deploy Rails
> applications. It's not purely about Git - goes into some Rails and
> Capistrano usage, but there is a good amount of practical git workflow
> - pushing, pulling, branching, etc. It's free, too. You can
> watch/download it here:
>
> http://jointheconversation.org/railsgit
>
nice :)
it's very useful...
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 23:28 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85bq9gy5e0.fsf@lola.goethe.zz>
On Tue, 27 Nov 2007, David Kastrup wrote:
> On the other hand: why bother participating in a community that turns
> openly hostile whenever one experiences problems? Where is the fun in
> that? That one will at one point of time be in the situation to lambast
> others for their shortcomings, and feel that one is entirely in-style
> doing so here?
David, honestly, my problem with you is that you seem to be the only one
having such relational problems around here, and instead of doing some
homework and obvious guessing on your own to save everyone's nerves, you
instead write dissertations about the list hostility, etc. Which in
turns will obviously earn you more hostilities.
Please get a grip.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-11-26 23:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261817450.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 27 Nov 2007, David Kastrup wrote:
>
>> On the other hand: why bother participating in a community that turns
>> openly hostile whenever one experiences problems? Where is the fun in
>> that? That one will at one point of time be in the situation to lambast
>> others for their shortcomings, and feel that one is entirely in-style
>> doing so here?
>
> David, honestly, my problem with you is that you seem to be the only one
> having such relational problems around here,
I am the only one? I quote from your reply to my original contribution
in this thread:
>On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > [ I get really really annoyed when your replies to me aren't directly
>> > addressed to me, Jakub. Told you so repeatedly in the past as well.
>> > Why are you the only one on this list apparently not able to use a
>> > proper email setup? ]
>>
>> X-Injected-Via-Gmane: http://gmane.org/
>>
>> And Jakub by far is not the only one using gmane for reading and writing
>> to the list.
>
>It is strange, though, that Jakub is the only one I've noticed who isn't
>able to do me the courtesy of addressing me directly when replying to
>me.
So here you are telling Jakub off as discourteous and the "only one on
this list apparently not able to use a proper email setup". And when I
explain that I have been in the same situation with a different account
of mine and that this has nothing to do with discourtesy, the heat turns
over to me.
And, again, this is declared an absolutely isolated phenomenon
restricted to a single person.
I am afraid that I am too stupid to understand what goal is supposed to
be achieved by this sort of behavior. I don't see anything except
annoyance for everybody involved.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Junio C Hamano @ 2007-11-27 0:24 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1196119109-27483-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> Was it this simple?
>
> diff --git a/setup.c b/setup.c
> index 43cd3f9..9b3a9ff 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -6,6 +6,22 @@ static int inside_work_tree = -1;
>
> const char *prefix_path(const char *prefix, int len, const char *path)
> {
> + if (is_absolute_path(path)) {
> + const char *work_tree = get_git_work_tree();
> + int n = strlen(work_tree);
> + if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
> + if (path[n])
> + path += 1;
> + path += n;
> + if (prefix && !strncmp(path, prefix, len - 1)) {
> + if (path[len - 1] == '/')
> + path += len;
> + else
> + if (!path[len - 1])
> + path += len - 1;
> + }
> + }
> + }
> const char *orig = path;
Decl after statement.
I do not think there is fundamental reason to object to this change, as
long as the prefixing is done to the path that is trying to name a path
in the working tree.
Also some codepath that does not require any work tree may want to call
prefix_path(). I do not know what would happen in such a case.
Although I didn't look at all the callers, I think the caller from
config.c is not talking about a path in the work tree, and not all users
of config.c need to have work-tree.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 1:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Wincent Colaiuta, Jan Hudec, David Kastrup, Nicolas Pitre,
Jakub Narebski, git
In-Reply-To: <7vhcj8g0op.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Wincent Colaiuta <win@wincent.com> writes:
> >
> > $ git-<tab>
> > Display all 146 possibilities? (y or n)
>
> The tab completion for bash and zsh would also help you here, but I see
> there are quite a few commands that should not be there, and it's time
> to clean it up.
...
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index cad842a..1bba68b 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -359,6 +359,15 @@ __git_commands ()
> upload-pack) : plumbing;;
> write-tree) : plumbing;;
> verify-tag) : plumbing;;
> + annotate) : use blame;;
> + checkout-index) : plumbing;;
> + diff-stages) : plumbing;;
> + get-tar-commit-id) : plumbing;;
> + lost-found) : deprecated;;
> + rebase--interactive) : plumbing;;
> + relink) : obsolete;;
> + whatchanged) : plumbing;;
> + verify-pack) : plumbing;;
> *) echo $i;;
> esac
> done
Ack'd-by: Shawn O. Pearce <spearce@spearce.org>
;-)
--
Shawn.
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Shawn O. Pearce @ 2007-11-27 1:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <7vy7ckgbpf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> I would not object to renaming all of them to have the leading
> underscore, though. That would make it clear that they are very
> different from ordinary environment variables for the user to set
> (e.g. GIT_INDEX_FILE, GIT_AUTHOR_NAME). Does any third party tool like
> qgit already use GITHEAD_${objectname} and/or GIT_REFLOG_ACTION?
git-gui apparently doesn't use either name right now. It avoids
needing to use GIT_REFLOG_ACTION by invoking only plumbing, except
in the case of git-merge, where it invokes git-merge and thus avoids
the need to set GITHEAD_* to get conflict markers right when the
recursive strategy gets used.
I had started to replace git-merge in Tcl and have git-gui directly
invoke merge-recursive but I haven't gotten around to really
doing that.
So I guess we could rename those two "internal" environment variables
to use a leading _ to make them different from "user level" variables,
but why change them now? I really don't see a compelling reason to
break that part of the "API" between porcelain/plumbing.
--
Shawn.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 1:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: Andy Parkins, git
In-Reply-To: <e5bfff550711261125i92fb057i85d7217b18cd495d@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> On Nov 26, 2007 5:46 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> > Jakub Narebski wrote:
> >
> > > If you would write git from scratch now, from the beginning, without
> > > concerns for backwards compatibility, what would you change, or what
> > > would you want to have changed?
> >
> > - "git-gui" would be written in Qt (ducks)
>
> But...wait...Qt would require...(I'm scared to say!)... that awful,
> painful, hopeless thing called C++. Probably you didn't mean what you
> said ;-)
Heh.
I'll never port git-gui to Qt. Because of that awful, painful
thing called C++ that it uses. I despise C++. No, please don't
start a C++ language war again on the list. :-)
I recently considered porting git-gui to XUL, as nobody has ever
said "Firefox isn't native enough on my OS!". It also (maybe) has
the benefit of having a large developer base (everyone and their
dog has coded in HTML and Javascript before, except maybe Linus).
But XUL doesn't support launching a process and connecting pipes
to its stdin and stdout. I started to try and create an XPCOM
extension to provide that functionality from NSPR and started to
run into major problems compiling the XPCOM plugin, getting the
necessary interfaces implemented, etc.
In the end I was able to recreate the bulk of the main git-gui UI in
XUL in just an hour or so, but spent days trying to just do a basic
thing like "git diff-index --cached -z HEAD" and consume the result.
I never even got that to work so I just gave up on the idea.
So git-gui is in Tcl/Tk for the long-term. However I'm going
to try and port git-gui over to the Tcl/Tk 8.5 "tiles" extension
(if it is available on your system) so we can get better looking
native widgets. I'll still fall back to the old style widgets for
Tcl/Tk 8.4 so existing users aren't forced to upgrade to 8.5 just
to use the latest git-gui. (But really, 8.5 isn't that hard to
build and install...)
--
Shawn.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 1:25 UTC (permalink / raw)
To: Dana How; +Cc: Jakub Narebski, git
In-Reply-To: <56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com>
Dana How <danahow@gmail.com> wrote:
> On Nov 25, 2007 1:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > If you would write git from scratch now, from the beginning, without
> > concerns for backwards compatibility, what would you change, or what
> > would you want to have changed?
>
> Currently data can be quickly copied from pack to pack,
> but data cannot be quickly copied blob->pack or pack->blob
I agree with Nico's comment that you probably don't need pack->loose
object as its just not something you want to do. But otherwise
above you mean "loose->pack" or "pack->loose" as blob is one type
of loose object but there are others (tree, commit, tag).
> (there was an alternate blob format that supported this,
> but it was deprecated). Using the pack format for blobs
> would fix this. It would also mean blobs wouldn't need to
> be uncompressed to get the blob type or size I believe.
The alternate format for loose objects *was* the packfile format,
but without the packfile header or trailer as that was really
quite unnecessary for a single object storage.
Unfortunately we removed that alternate format from the system.
We can't create it anymore. We can't efficiently copy it to the
packfile anymore. But we can still read it in case someone still
has loose objects using that alternate format in their repository.
I was sad when Nico removed the format in 726f852b0ed7e. I can
understand why he did so but I think it was a move in the wrong
direction.
--
Shawn.
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-27 1:25 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Sixt, Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <20071127010801.GF14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> So I guess we could rename those two "internal" environment variables
> to use a leading _ to make them different from "user level" variables,
> but why change them now? I really don't see a compelling reason to
> break that part of the "API" between porcelain/plumbing.
I don't either, which means I do not see a compelling reason to have
underscore in front of that cherry-pick message environment either.
About the patch itself, I think replacing the whole message, not just
"and commit the result." part, might make more sense.
help_message = getenv("_GIT_CHERRY_PICK_HELP");
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git add <paths>' "
"and %s.\n", me,
help_message ? help_message : "commit the result");
if (action == CHERRY_PICK && !help_message) {
fprintf(stderr, "When commiting, use the option "
"'-c %s' to retain authorship and message.\n",
find_unique_abbrev(commit->object.sha1,
...
Some other caller can be written to guide the user resolving and do the
"git add" part for the user, and "mark the corrected paths with 'git add
<paths>'" may not suit the need for such a caller.
Which would mean:
help_message = getenv("GIT_CHERRY_PICK_HELP");
if (!help_message) {
static char helpbuf[1024];
help_message = helpbuf;
sprintf(help_message,
" After resolving the conflits,\n"
"mark the corrected paths with 'git add <paths>' "
"and commit the result.\n"
"When commiting, use the option "
"'-c %s' to retain authorship and message.\n",
find_unique_abbrev(commit->object.sha1,
DEFAULT_ABBREV));
}
fprintf(stderr, "Automatic %s failed.%s", help_message);
exit(1);
But I do not care too deeply either way.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jakub Narebski @ 2007-11-27 1:46 UTC (permalink / raw)
To: git
In-Reply-To: <20071127012013.GG14735@spearce.org>
Shawn O. Pearce wrote:
[git-gui in XUL]
> But XUL doesn't support launching a process and connecting pipes
> to its stdin and stdout. I started to try and create an XPCOM
> extension to provide that functionality from NSPR and started to
> run into major problems compiling the XPCOM plugin, getting the
> necessary interfaces implemented, etc.
What about Ajax / Comet support in XUL, Can this be used for that?
(Just an [perhaps stupid] idea).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 1:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711252248.27904.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> If you would write git from scratch now, from the beginning, without
> concerns for backwards compatibility, what would you change, or what
> would you want to have changed?
- Sort tree entries by name, *not* by name+type
This has got to be my biggest gripe with Git. I think Linus really
screwed the pooch with this. We've talked it over a few times
on the list and he and I have just agreed to disagree on this.
Ask any database person and they'll tell you how wrong the
current tree ordering is. Or they are nuts and don't get
the concept of data integrity.
Linus' excuse is that the current ordering makes working with
the flat index faster as its just one index file. That doesn't
mean that the flat index file can't contain tree information.
Like it does in say that new fangled cache-tree extension. :-)
This particular "design decision" has brought all sorts of bugs
into the system, like the D/F merge conflict issues, and even one
from Linus himself when he first introduced the submodule support.
Lets not even talk about ugly that made things in jgit.
- Loose objects storage is difficult to work with
The standard loose object format of DEFLATE("$type $size\0$data")
makes it harder to work with as you need to inflate at least
part of the object just to see what the hell it is or how big
its final output buffer needs to be.
It also makes it very hard to stream into a packfile if you have
determined its not worth creating a delta for the object (or no
suitable delta base is available).
The new (now deprecated) loose object format that was based on
the packfile header format simplified this and made it much
easier to work with.
- No proper libgit
Already been stated but we don't have a great library and we
don't have a good way to build one right now either. A lot of
our internal code assumes die() will abort the process. That's a
very bad assumption to be making inside of a library.
- Binary packed-refs representation
I probably wouldn't have done an ASCII based packed-refs file,
or heck, even loose refs. I probably would have just gone with
a binary file that we wholesale rewrite every time there is any
sort of ref update.
We already do this with the index. So every time we update a
file path we are rewriting the entire index. And we update
file paths a heck of a lot more often than we update branch
heads. Or tags.
But tools like for-each-ref get invoked heavily, and fast access
to the ref database is important to overall performance.
- No GIT_OBJECT_DIRECTORY vs. GIT_DIR distinction
This is causing problems with $GIT_DIR/objects/info/alternates
and then try to repack repositories. Not having the ref space of
the alternates and/or borrowers considered during repacking can
cause all sorts of fun breakage that may be hard to recover from.
Plus it means you have to do funny "refs/forkee" hacks just to
avoid pushing unnecessary objects over the wire when the other
end is borrowing objects.
I probably would have had the object directory unified with its
ref database, so that they cannot be accessed individually.
All of the above is written with 20/20 hindsight and all that.
Looking back (and knowing myself well) I think the only item I
would have gotten right if I had written Git from scratch is the
first one above (the tree entry ordering). I probably would have
done something equally "as bad" as what we have today for all of
the others...
--
Shawn.
^ permalink raw reply
* Re: QGit: Shrink used memory with custom git log format
From: Shawn O. Pearce @ 2007-11-27 1:52 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550711240014n78f24b46qf012957d92b1a8e1@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> Now instead of --pretty=raw a custom made --pretty=format is given,
> this shrinks loaded data of 30% (17MB less on Linux tree) and gives a
> good speed up when you are low on memory (especially on big repos)
>
> Next step _would_ be to load log message body on demand (another 50%
> reduction) but this has two drawbacks:
>
> (1) Text search/filter on log message would be broken
>
> (2) Slower to browse through revisions because for each revision an
> additional git-rev-list /git-log command should be executed to read
> the body
>
> The second point is worsted by the fact that it is not possible to
> keep a command running and "open" like as example git-diff-tree
> --stdin and feed with additional revision's sha when needed. Avoiding
> the burden to startup a new process each time to read a new log
> message given an sha would let the answer much more quick especially
> on lesser OS's
>
> Indeed there is a git-rev-list --stdin option but with different
> behaviour from git-diff-tree --stdin and not suitable for this.
There was a proposed patch for git-cat-file that would let you run
it in a --stdin mode; the git-svn folks wanted this to speed up
fetching raw objects from the repository. That may help as you
could get commit bodies (in raw format - not reencoded format!)
quite efficiently.
Otherwise I think what you really want here is a libgit that you can
link into your process and that can efficiently inflate an object
on demand for you. Like the work Luiz was working on this past
summer for GSOC. Lots of downsides to that current tree though...
like die() kills the GUI...
--
Shawn.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Junio C Hamano @ 2007-11-27 1:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20071127014804.GJ14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> All of the above is written with 20/20 hindsight and all that.
>
> Looking back (and knowing myself well) I think the only item I
> would have gotten right if I had written Git from scratch is the
> first one above (the tree entry ordering). I probably would have
> done something equally "as bad" as what we have today for all of
> the others...
... not to mention countless others you would get wrong that you did not
list in the above, as the current git got them right ;-)
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 1:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fifstd$ilj$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
>
> [git-gui in XUL]
>
> > But XUL doesn't support launching a process and connecting pipes
> > to its stdin and stdout. I started to try and create an XPCOM
> > extension to provide that functionality from NSPR and started to
> > run into major problems compiling the XPCOM plugin, getting the
> > necessary interfaces implemented, etc.
>
> What about Ajax / Comet support in XUL, Can this be used for that?
> (Just an [perhaps stupid] idea).
Yes, XUL fully supports AJAX. If it didn't Google Maps and its
cool interface wouldn't exist. :-)
The problem there is that AJAX requires HTTP. So I'd have to
create a "micro HTTP server" that runs on the loopback interface
and listens for HTTP requests from the GUI, parses them, runs the
necessary Git action, then sends the results back to the GUI.
Sort of ugly.
My bigger concern is also for a shared machine; how do I secure
the HTTP server so only the git-gui process that is supposed to
be using it is able to access it? I guess I could create a 600
~/.gitguicookie file or some such entity and throw random data into
it to initialize it. That's basically all xauth is doing.
Actually I might revisit this XUL concept using an HTTP server and
AJAX. I could actually link the damn HTTP server against libgit.a
(Junio will hate me). If the server dies XUL can notice it and
simply restart it. But there's a whole suite of actions that I
can run through the internal APIs with high chances of success,
and a lot quicker than forking the corresponding plumbing process,
especially on fork challenged machines like Windows.
--
Shawn.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vd4twe9mn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > All of the above is written with 20/20 hindsight and all that.
> >
> > Looking back (and knowing myself well) I think the only item I
> > would have gotten right if I had written Git from scratch is the
> > first one above (the tree entry ordering). I probably would have
> > done something equally "as bad" as what we have today for all of
> > the others...
>
> ... not to mention countless others you would get wrong that you did not
> list in the above, as the current git got them right ;-)
Indeed.
Which is why nobody is looking to rewrite Git from scratch.
Except myself and a few other nuts who want a pure Java
implementation for Eclipse plugins. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Shawn O. Pearce @ 2007-11-27 2:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711252236350.4725@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> This program dumps (parts of) a git repository in the format that
> fast-import understands.
...
> +-------------------------------------------------------------------
> +$ git fast-export --all | (cd /empty/repository && git fast-import)
> +-------------------------------------------------------------------
> +
> +This will export the whole repository and import it into the existing
> +empty repository. Except for reencoding commits that are not in
> +UTF-8, it would be a one-to-one mirror.
WTF?
Why are you reencoding the commits on output in fast-export?
Why aren't you dumping them raw to the stream? fast-import takes
them raw. Oh, it doesn't have a way to set the encoding header.
DOH.
I think this should be prefixed by fast-import patch to teach it
something like "encoding N" as a subcommand of commit, so that you
can feed data in a non UTF-8 encoding and get it to include the
proper encoding header in the commit object it creates. That way
a pipeline like the above really does create a duplicate repository,
with the same commit SHA-1s, even if the commits weren't in UTF-8.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] git-gui: Update git-gui.pot with latest (few) string additions and changes.
From: Shawn O. Pearce @ 2007-11-27 2:12 UTC (permalink / raw)
To: Christian Stimming; +Cc: Johannes Schindelin, git
In-Reply-To: <200711241104.32371.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> ---
> I've attached this and the following (German translation update) patch as
> tarball as well, just in case mailers will mess with whitespaces again.
Thanks. I've applied these to my master tree.
I'll wait a little bit and see if we get any updates for the hu,
ru and zh_cn translations as they have some fuzzy and untranslated
strings right now, but will do a 0.9.1 in the near future before
Git 1.5.4 ships.
--
Shawn.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jakub Narebski @ 2007-11-27 2:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071127015942.GM14735@spearce.org>
Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> ... not to mention countless others you would get wrong that you did not
>> list in the above, as the current git got them right ;-)
>
> Indeed.
>
> Which is why nobody is looking to rewrite Git from scratch.
>
> Except myself and a few other nuts who want a pure Java
> implementation for Eclipse plugins. :-)
And the project to implement git in C# / Mono (I wonder what is
the status of those implementations...)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Junio C Hamano @ 2007-11-27 3:35 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Wincent Colaiuta, Jan Hudec, David Kastrup, Nicolas Pitre,
Jakub Narebski, git
In-Reply-To: <20071127010350.GE14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Wincent Colaiuta <win@wincent.com> writes:
>> >
>> > $ git-<tab>
>> > Display all 146 possibilities? (y or n)
>>
>> The tab completion for bash and zsh would also help you here, but I see
>> there are quite a few commands that should not be there, and it's time
>> to clean it up.
> ...
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index cad842a..1bba68b 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -359,6 +359,15 @@ __git_commands ()
>> upload-pack) : plumbing;;
>> write-tree) : plumbing;;
>> verify-tag) : plumbing;;
>> + annotate) : use blame;;
>> + checkout-index) : plumbing;;
>> + diff-stages) : plumbing;;
>> + get-tar-commit-id) : plumbing;;
>> + lost-found) : deprecated;;
>> + rebase--interactive) : plumbing;;
>> + relink) : obsolete;;
>> + whatchanged) : plumbing;;
>> + verify-pack) : plumbing;;
>> *) echo $i;;
>> esac
>> done
>
> Ack'd-by: Shawn O. Pearce <spearce@spearce.org>
>
> ;-)
Seriously, speaking I find this "negative" list ugly. I am wondering if
it makes more sense to use positive "Porcelain" list, or perhaps even
"The most commonly used" list from "git help" output.
Here is an alternate attempt to it.
---
Documentation/cmd-list.perl | 59 ++++++++++++------------
Makefile | 2 +-
contrib/completion/git-completion.bash | 77 ++------------------------------
generate-cmdlist.sh | 34 ++------------
4 files changed, 40 insertions(+), 132 deletions(-)
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index b709551..a966b5e 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -26,10 +26,11 @@ sub format_one {
if (!defined $description) {
die "No description found in $name.txt";
}
+
if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
print $out "gitlink:$name\[1\]::\n\t";
- if ($attr) {
- print $out "($attr) ";
+ if ($attr =~ /deprecated/) {
+ print $out "(deprecated) ";
}
print $out "$text.\n\n";
}
@@ -75,27 +76,27 @@ for my $cat (qw(ancillaryinterrogators
# The following list is sorted with "sort -d" to make it easier
# to find entry in the resulting git.html manual page.
__DATA__
-git-add mainporcelain
+git-add mainporcelain common
git-am mainporcelain
git-annotate ancillaryinterrogators
-git-apply plumbingmanipulators
+git-apply plumbingmanipulators common
git-archimport foreignscminterface
-git-archive mainporcelain
-git-bisect mainporcelain
+git-archive mainporcelain common
+git-bisect mainporcelain common
git-blame ancillaryinterrogators
-git-branch mainporcelain
+git-branch mainporcelain common
git-bundle mainporcelain
git-cat-file plumbinginterrogators
git-check-attr purehelpers
-git-checkout mainporcelain
+git-checkout mainporcelain common
git-checkout-index plumbingmanipulators
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
-git-cherry-pick mainporcelain
+git-cherry-pick mainporcelain common
git-citool mainporcelain
git-clean mainporcelain
-git-clone mainporcelain
-git-commit mainporcelain
+git-clone mainporcelain common
+git-commit mainporcelain common
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators
git-count-objects ancillaryinterrogators
@@ -104,12 +105,12 @@ git-cvsimport foreignscminterface
git-cvsserver foreignscminterface
git-daemon synchingrepositories
git-describe mainporcelain
-git-diff mainporcelain
+git-diff mainporcelain common
git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
git-diff-tree plumbinginterrogators
git-fast-import ancillarymanipulators
-git-fetch mainporcelain
+git-fetch mainporcelain common
git-fetch-pack synchingrepositories
git-filter-branch ancillarymanipulators
git-fmt-merge-msg purehelpers
@@ -118,24 +119,24 @@ git-format-patch mainporcelain
git-fsck ancillaryinterrogators
git-gc mainporcelain
git-get-tar-commit-id ancillaryinterrogators
-git-grep mainporcelain
+git-grep mainporcelain common
git-gui mainporcelain
git-hash-object plumbingmanipulators
git-http-fetch synchelpers
git-http-push synchelpers
git-imap-send foreignscminterface
git-index-pack plumbingmanipulators
-git-init mainporcelain
+git-init mainporcelain common
git-instaweb ancillaryinterrogators
gitk mainporcelain
-git-log mainporcelain
+git-log mainporcelain common
git-lost-found ancillarymanipulators deprecated
git-ls-files plumbinginterrogators
git-ls-remote plumbinginterrogators
git-ls-tree plumbinginterrogators
git-mailinfo purehelpers
git-mailsplit purehelpers
-git-merge mainporcelain
+git-merge mainporcelain common
git-merge-base plumbinginterrogators
git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
@@ -144,7 +145,7 @@ git-mergetool ancillarymanipulators
git-merge-tree ancillaryinterrogators
git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
-git-mv mainporcelain
+git-mv mainporcelain common
git-name-rev plumbinginterrogators
git-pack-objects plumbingmanipulators
git-pack-redundant plumbinginterrogators
@@ -152,13 +153,13 @@ git-pack-refs ancillarymanipulators
git-parse-remote synchelpers
git-patch-id purehelpers
git-peek-remote purehelpers deprecated
-git-prune ancillarymanipulators
+git-prune ancillarymanipulators common
git-prune-packed plumbingmanipulators
-git-pull mainporcelain
-git-push mainporcelain
+git-pull mainporcelain common
+git-push mainporcelain common
git-quiltimport foreignscminterface
git-read-tree plumbingmanipulators
-git-rebase mainporcelain
+git-rebase mainporcelain common
git-receive-pack synchelpers
git-reflog ancillarymanipulators
git-relink ancillarymanipulators
@@ -166,28 +167,28 @@ git-remote ancillarymanipulators
git-repack ancillarymanipulators
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
-git-reset mainporcelain
-git-revert mainporcelain
+git-reset mainporcelain common
+git-revert mainporcelain common
git-rev-list plumbinginterrogators
git-rev-parse ancillaryinterrogators
-git-rm mainporcelain
+git-rm mainporcelain common
git-runstatus ancillaryinterrogators
git-send-email foreignscminterface
git-send-pack synchingrepositories
git-shell synchelpers
git-shortlog mainporcelain
-git-show mainporcelain
-git-show-branch ancillaryinterrogators
+git-show mainporcelain common
+git-show-branch ancillaryinterrogators common
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
git-sh-setup purehelpers
git-stash mainporcelain
-git-status mainporcelain
+git-status mainporcelain common
git-stripspace purehelpers
git-submodule mainporcelain
git-svn foreignscminterface
git-symbolic-ref plumbingmanipulators
-git-tag mainporcelain
+git-tag mainporcelain common
git-tar-tree plumbinginterrogators deprecated
git-unpack-file plumbinginterrogators
git-unpack-objects plumbingmanipulators
diff --git a/Makefile b/Makefile
index ccf522a..ca1c2f5 100644
--- a/Makefile
+++ b/Makefile
@@ -804,7 +804,7 @@ git-merge-subtree$X: git-merge-recursive$X
$(BUILT_INS): git$X
$(QUIET_BUILT_IN)$(RM) $@ && ln git$X $@
-common-cmds.h: ./generate-cmdlist.sh
+common-cmds.h: ./generate-cmdlist.sh Documentation/cmd-list.perl
common-cmds.h: $(wildcard Documentation/git-*.txt)
$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 599b2fc..d54b415 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -287,79 +287,10 @@ __git_commands ()
echo "$__git_commandlist"
return
fi
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ ')
- do
- case $i in
- add--interactive) : plumbing;;
- applymbox) : ask gittus;;
- applypatch) : ask gittus;;
- archimport) : import;;
- cat-file) : plumbing;;
- check-attr) : plumbing;;
- check-ref-format) : plumbing;;
- commit-tree) : plumbing;;
- cvsexportcommit) : export;;
- cvsimport) : import;;
- cvsserver) : daemon;;
- daemon) : daemon;;
- diff-files) : plumbing;;
- diff-index) : plumbing;;
- diff-tree) : plumbing;;
- fast-import) : import;;
- fsck-objects) : plumbing;;
- fetch--tool) : plumbing;;
- fetch-pack) : plumbing;;
- fmt-merge-msg) : plumbing;;
- for-each-ref) : plumbing;;
- hash-object) : plumbing;;
- http-*) : transport;;
- index-pack) : plumbing;;
- init-db) : deprecated;;
- local-fetch) : plumbing;;
- mailinfo) : plumbing;;
- mailsplit) : plumbing;;
- merge-*) : plumbing;;
- mktree) : plumbing;;
- mktag) : plumbing;;
- pack-objects) : plumbing;;
- pack-redundant) : plumbing;;
- pack-refs) : plumbing;;
- parse-remote) : plumbing;;
- patch-id) : plumbing;;
- peek-remote) : plumbing;;
- prune) : plumbing;;
- prune-packed) : plumbing;;
- quiltimport) : import;;
- read-tree) : plumbing;;
- receive-pack) : plumbing;;
- reflog) : plumbing;;
- repo-config) : plumbing;;
- rerere) : plumbing;;
- rev-list) : plumbing;;
- rev-parse) : plumbing;;
- runstatus) : plumbing;;
- sh-setup) : internal;;
- shell) : daemon;;
- send-pack) : plumbing;;
- show-index) : plumbing;;
- ssh-*) : transport;;
- stripspace) : plumbing;;
- svn) : import export;;
- symbolic-ref) : plumbing;;
- tar-tree) : deprecated;;
- unpack-file) : plumbing;;
- unpack-objects) : plumbing;;
- update-index) : plumbing;;
- update-ref) : plumbing;;
- update-server-info) : daemon;;
- upload-archive) : plumbing;;
- upload-pack) : plumbing;;
- write-tree) : plumbing;;
- verify-tag) : plumbing;;
- *) echo $i;;
- esac
- done
+ git help | sed -e '
+ 1,/^The most commonly used git/d
+ s/^ *\([^ ][^ ]*\)[ ].*/\1/
+ '
}
__git_commandlist=
__git_commandlist="$(__git_commands 2>/dev/null)"
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 17df47b..28f9749 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,35 +9,11 @@ struct cmdname_help
static struct cmdname_help common_cmds[] = {"
-sort <<\EOF |
-add
-apply
-archive
-bisect
-branch
-checkout
-cherry-pick
-clone
-commit
-diff
-fetch
-grep
-init
-log
-merge
-mv
-prune
-pull
-push
-rebase
-reset
-revert
-rm
-show
-show-branch
-status
-tag
-EOF
+sed -n -e '
+ 1,/__DATA__/d
+ s/^git-\([^ ]*\)[ ].*[ ]common/\1/p
+' Documentation/cmd-list.perl |
+sort |
while read cmd
do
sed -n '
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-27 4:05 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85oddgva33.fsf@lola.goethe.zz>
On Tue, 27 Nov 2007, David Kastrup wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > David, honestly, my problem with you is that you seem to be the only one
> > having such relational problems around here,
>
> I am the only one? I quote from your reply to my original contribution
> in this thread:
>
> >On Mon, 26 Nov 2007, David Kastrup wrote:
> >
> >> Nicolas Pitre <nico@cam.org> writes:
> >>
> >> > [ I get really really annoyed when your replies to me aren't directly
> >> > addressed to me, Jakub. Told you so repeatedly in the past as well.
> >> > Why are you the only one on this list apparently not able to use a
> >> > proper email setup? ]
> >>
> >> X-Injected-Via-Gmane: http://gmane.org/
> >>
> >> And Jakub by far is not the only one using gmane for reading and writing
> >> to the list.
> >
> >It is strange, though, that Jakub is the only one I've noticed who isn't
> >able to do me the courtesy of addressing me directly when replying to
> >me.
>
> So here you are telling Jakub off as discourteous and the "only one on
> this list apparently not able to use a proper email setup".
Exact.
> And when I explain that I have been in the same situation with a
> different account of mine and that this has nothing to do with
> discourtesy, the heat turns over to me.
Then it must be laziness. And while Jakub admits there is a problem,
you insist otherwise, building hostility towards you in the process.
> And, again, this is declared an absolutely isolated phenomenon
> restricted to a single person.
OK now you are two. So what? This still looks like a tiny minority to
me.
> I am afraid that I am too stupid to understand what goal is supposed to
> be achieved by this sort of behavior. I don't see anything except
> annoyance for everybody involved.
You are really annoying indeed.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-27 4:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20071127014804.GJ14735@spearce.org>
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> - Loose objects storage is difficult to work with
>
> The standard loose object format of DEFLATE("$type $size\0$data")
> makes it harder to work with as you need to inflate at least
> part of the object just to see what the hell it is or how big
> its final output buffer needs to be.
It is a bit cumbersome indeed, but I'm afraid we're really stuck with it
since every object SHA1 depends on that format.
> It also makes it very hard to stream into a packfile if you have
> determined its not worth creating a delta for the object (or no
> suitable delta base is available).
>
> The new (now deprecated) loose object format that was based on
> the packfile header format simplified this and made it much
> easier to work with.
Not really. Since separate zlib compression levels for loose objects
and packed objects were introduced, there was a bunch of correctness
issues. What do you do when both compression levels are different?
Sometimes ignore them, sometimes not? Because the default loose object
compression level is about speed and the default pack compression level
is about good space reduction, the correct thing to do by default would
have been to always decompress and recompress anyway when copying an
otherwise unmodified loose object into a pack.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-27 5:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dana How, Jakub Narebski, git
In-Reply-To: <20071127012518.GH14735@spearce.org>
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> Dana How <danahow@gmail.com> wrote:
> > (there was an alternate blob format that supported this,
> > but it was deprecated). Using the pack format for blobs
> > would fix this. It would also mean blobs wouldn't need to
> > be uncompressed to get the blob type or size I believe.
>
> The alternate format for loose objects *was* the packfile format,
> but without the packfile header or trailer as that was really
> quite unnecessary for a single object storage.
What I'm suggesting, though, is to actually create a real pack for those
blobs where the recompression is really an issue. all the code is
there and only needs to be called.
In most usage cases, though, the proportion of blobs that gets copied
directly into a pack is minimal, and even then they don't amount to a
lot of cycles compared to the majority of deltified objects.
(yeah, "deltified" is said to be wrong by some, but it is really
convenient a word.)
> I was sad when Nico removed the format in 726f852b0ed7e. I can
> understand why he did so but I think it was a move in the wrong
> direction.
I wish I could convince you otherwise by now.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Steven Grimm @ 2007-11-27 5:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Wincent Colaiuta, Jan Hudec, David Kastrup,
Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <7v7ik4e4xa.fsf@gitster.siamese.dyndns.org>
On Nov 26, 2007, at 7:35 PM, Junio C Hamano wrote:
> Seriously, speaking I find this "negative" list ugly. I am
> wondering if
> it makes more sense to use positive "Porcelain" list, or perhaps even
> "The most commonly used" list from "git help" output.
Yes, a positive list makes much more sense. If for no other reason
than that it will require the author of a new command to make a
conscious decision before that command will be suggested to users.
-Steve
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Dana How @ 2007-11-27 5:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Jakub Narebski, git, danahow
In-Reply-To: <alpine.LFD.0.99999.0711262346410.9605@xanadu.home>
On Nov 26, 2007 8:58 PM, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> > - Loose objects storage is difficult to work with
> >
> > The standard loose object format of DEFLATE("$type $size\0$data")
> > makes it harder to work with as you need to inflate at least
> > part of the object just to see what the hell it is or how big
> > its final output buffer needs to be.
>
> It is a bit cumbersome indeed, but I'm afraid we're really stuck with it
> since every object SHA1 depends on that format.
Yes, now I remember: this was the same argument you used to
convince me that losing the "new" (deprecated) loose format was OK.
However, if we changed
WRITE(DEFLATE(SHA1("$type $size\0$data")))
(where SHA1(x) = x but has the side-effect of updating the SHA-1)
to
WRITE($pack_style_object_header)
SHA1("$type $size\0")
WRITE(DEFLATE(SHA1($data)))
then the SHA-1 result is the same but we get the pack-style header,
and blobs can be sucked straight into packs when not deltified.
The SHA-1 result is still usable at the end to rename the temporary
loose object file
(and put it in the correct xx subdirectory).
Because we can't change the SHA-1 result we unfortunately can
never drop the 2nd call above [this is something that could
have been different, to respond to the email that started this thread].
You didn't like the duplication between the 1st and 2nd call,
but I can't say I see that as a big deal.
> > It also makes it very hard to stream into a packfile if you have
> > determined its not worth creating a delta for the object (or no
> > suitable delta base is available).
> >
> > The new (now deprecated) loose object format that was based on
> > the packfile header format simplified this and made it much
> > easier to work with.
>
> Not really. Since separate zlib compression levels for loose objects
> and packed objects were introduced, there was a bunch of correctness
> issues. What do you do when both compression levels are different?
> Sometimes ignore them, sometimes not? Because the default loose object
> compression level is about speed and the default pack compression level
> is about good space reduction, the correct thing to do by default would
> have been to always decompress and recompress anyway when copying an
> otherwise unmodified loose object into a pack.
Not exactly. I did think about this. When you are packing to stdout,
and only sending the resulting packfile locally, you don't want to
bother with recompressing everything. [This is the "workgroup" case
that concerns me.] Other cases, sure,
recompression could help (e.g., packing to a file means the file
will probably be around for a while, so you want to recompress
if the levels are unequal; and you probably want to recompress
as well if the packfile will be sent over a "slow" link).
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ 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