* Re: [Census] So who uses git?
From: J. Bruce Fields @ 2006-01-31 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vd5i8w2nc.fsf@assigned-by-dhcp.cox.net>
On Tue, Jan 31, 2006 at 12:41:59PM -0800, Junio C Hamano wrote:
> On the tutorial front, maybe we could start teaching people to
> always use "commit -a", and not tell them about update-index nor
> "commit paths.." at all. Have them do "hello world", review
> changes since the last commit with "git diff", and make commit
> with "git commit -a". Next tell them about index, and after
> they understand index, finally tell them "commit paths..." is
> there merely to reduce typing.
Yeah, I think that's approximately what you get right now if you read
tutorial.txt followed by core-tutorial.txt, though the two currently may
not really work together well as sequels.
So I'm inclined to start by revising the two to make them read well as
sequels, then maybe moving some of core-tutorial.txt into the earlier
tutorial.txt. By the time we're done the two might end up being one
document. Or they might still be two, but with the split being more
clearly beginning/advanced instead of high-level/low-level.
Feedback from people who'd actually worked through the two would
obviously be useful.
--b.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-01-31 20:43 UTC (permalink / raw)
To: Radoslaw Szkodzinski
Cc: Greg KH, Keith Packard, cworth, Martin Langhoff, Linus Torvalds,
Git Mailing List
In-Reply-To: <43DFBF9A.2020409@gorzow.mm.pl>
Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> writes:
> Radoslaw Szkodzinski wrote:
>> Cloning without -l option is much slower - some minutes vs below a minute.
>> I could have time(8)d it, but it's no use.
>>
>
> Make that time(1)d.
>
> Results for the kernel follow. Disc cache has been preheated with find.
While you are at it, "git clone -l -s -n" might be more interesting.
^ permalink raw reply
* Re: [Census] So who uses git?
From: J. Bruce Fields @ 2006-01-31 20:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Johannes Schindelin, Carl Baldwin, Keith Packard,
Martin Langhoff, Git Mailing List
In-Reply-To: <7vbqxsyyym.fsf@assigned-by-dhcp.cox.net>
On Tue, Jan 31, 2006 at 11:33:21AM -0800, Junio C Hamano wrote:
> I think many good stuff git offers would not be helpful to the
> users until index is understood as the third entity, in addition
> to the usual "committed state" and "working tree state". It
> might be better to talk about it sooner rather than later. And
> the tool is geared towards taking advantage of it, so until the
> user understands that, behaviour of some tools would feel
> unintuitive.
Yeah, makes sense. But I'd like to introduce that while still
introducing the higher-level tools earlier on than core-tutorial.txt
does. I'll give some thought to how to move things in that direction,
maybe this weekend....
--b.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-01-31 19:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1138736666.24410.38.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> I have done this style of "update-index on more-or-less OK
> files in order to clear up the diff. And it is also in that
> time frame that I start feeling that certain changes belong
> to "one commit" or another. The result is, I want to then
> pick the parts that get committed together. But _really_
> being certain exactly which files, and _only_ those files,
> will really be committed is tough.
$ git diff --cached
would help. If you are _only_ comitting either all changes or no
change per path, 'git diff --cached --name-status' would be
sufficient.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Radoslaw Szkodzinski @ 2006-01-31 19:50 UTC (permalink / raw)
To: Greg KH
Cc: Keith Packard, Junio C Hamano, cworth, Martin Langhoff,
Linus Torvalds, Git Mailing List
In-Reply-To: <43DFAD91.4080105@gorzow.mm.pl>
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
Radoslaw Szkodzinski wrote:
> Cloning without -l option is much slower - some minutes vs below a minute.
> I could have time(8)d it, but it's no use.
>
Make that time(1)d.
Results for the kernel follow. Disc cache has been preheated with find.
git version: 5b2bcc7b2d546c636f79490655b3347acc91d17f
Filesystem: ext3 data=writeback
Kernel: 2.6.16-rc1-astorm2 (mostly -ck patchset with "hotfix")
Elevator: CFQ
time git clone linux-2.6.git linux-2.6.git.new
Packing 180025 objects
real 8m31.637s
user 3m19.571s
sys 0m42.211s
Extremely bad. The task is mostly cpu-bound.
Made some background applications swap out late in the process.
(that's the cause of the sys time)
time git clone -l linux-2.6.git linux-2.6.git.local
0 blocks
real 0m42.339s
user 0m2.818s
sys 0m4.040s
Good enough for me. Possibly cp -rl of objects and then a checkout.
time cp -rl linux-2.6.git linux-2.6.git.rl
real 0m18.333s
user 0m0.103s
sys 0m1.732s
Really fast, but requires additional file modification.
(namely .git/remotes/origin, removal of gitrc)
Also incompatible with apps having problems with hardlinks.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [Census] So who uses git?
From: Jon Loeliger @ 2006-01-31 19:44 UTC (permalink / raw)
To: Git List
In-Reply-To: <7vbqxsyyym.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-01-31 at 13:33, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> I think many good stuff git offers would not be helpful to the
> users until index is understood as the third entity, in addition
> to the usual "committed state" and "working tree state". It
> might be better to talk about it sooner rather than later. And
> the tool is geared towards taking advantage of it, so until the
> user understands that, behaviour of some tools would feel
> unintuitive.
Agreed.
> You can have local throw-away modifications while applying
> patches and merging (I once broke merges by ignoring that it is
> perfectly valid to have index and working tree files be
> different and keep working that way. That was a hard lesson).
> The index file knows what working tree changes are meant to be
> committed. Another thing I find useful, which cannot be done
> without index, is to sanity check while developing. When "git
> diff" gives too many diffs, running update-index on paths that I
> think are more-or-less OK helps to reduce clutter, and I can
> view only further changes to those paths.
And right there is where people get caught by surprise.
What "they" then want to do is actually pick certain
files to commit. And when they do, they get caught off
guard by the _additional_ files.
I have done this style of "update-index on more-or-less OK
files in order to clear up the diff. And it is also in that
time frame that I start feeling that certain changes belong
to "one commit" or another. The result is, I want to then
pick the parts that get committed together. But _really_
being certain exactly which files, and _only_ those files,
will really be committed is tough.
jdl
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-01-31 19:33 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Linus Torvalds, Johannes Schindelin, Carl Baldwin, Keith Packard,
Martin Langhoff, Git Mailing List
In-Reply-To: <20060131181248.GE11955@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Jan 31, 2006 at 09:30:48AM -0800, Linus Torvalds wrote:
>>
>> The "ignore the index" approach is the simple one to explain. It's
>> strictly less powerful, but hey, what else is new?
>
> Yeah, I do wonder what's likely to be the best approach for most users.
> My goal with the new tutorial was to get a reader doing something fun
> and useful as quickly as possible. So it just refers elsewhere for any
> discussion of the index file or SHA1 names. But probably everyone needs
> to pick up that stuff eventually anyway, and maybe it's better to get to
> it a little sooner, I dunno.
I think many good stuff git offers would not be helpful to the
users until index is understood as the third entity, in addition
to the usual "committed state" and "working tree state". It
might be better to talk about it sooner rather than later. And
the tool is geared towards taking advantage of it, so until the
user understands that, behaviour of some tools would feel
unintuitive.
You can have local throw-away modifications while applying
patches and merging (I once broke merges by ignoring that it is
perfectly valid to have index and working tree files be
different and keep working that way. That was a hard lesson).
The index file knows what working tree changes are meant to be
committed. Another thing I find useful, which cannot be done
without index, is to sanity check while developing. When "git
diff" gives too many diffs, running update-index on paths that I
think are more-or-less OK helps to reduce clutter, and I can
view only further changes to those paths.
In a sense, update-index can be thought of to check in the
changes without committing. You can check in number of times,
and the cumulative effect is committed later. "reset --mixed"
is undoing these uncommitted check-ins. "reset --hard" undoes
the last commit.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-01-31 19:21 UTC (permalink / raw)
To: Keith Packard
Cc: Johannes Schindelin, Carl Baldwin, Junio C Hamano,
Martin Langhoff, Git Mailing List
In-Reply-To: <1138734110.18852.26.camel@evo.keithp.com>
On Tue, 31 Jan 2006, Keith Packard wrote:
> On Tue, 2006-01-31 at 09:30 -0800, Linus Torvalds wrote:
>
> > - ignore it. Never _ever_ use git-update-index directly, and don't tell
> > people about use individual filenames to git-commit. Maybe even add
> > "-a" by default to the git-commit flags as a special installation
> > addition.
>
> As a newly initiated user, this would have been a more gentle
> introduction to the system. But, it would be hard to make it entirely
> invisible given the current interfaces. I'm not sure if obscuring the
> presense of the index is a great plan; it's already hard enough to
> figure out how it works.
Now, I do agree. I don't actually like hiding the index too much.
Understanding the index is _invaluable_ whenever you're doing a merge with
conflicts, and understanding what tools are available to you to resolve
those conflicts.
The index is also obviously very important when you do a partial commit,
and it's something I do end up doing quite often. Again, maybe that's not
something that a new git user should be encouraged to ever do, but it's a
huge convenience feature for power-users.
Understanding the index also allows people to understand certain
performance-characteristics of git, and explains how "git add" (and
remove, if we had one) actually works independently of the commit.
So I'm actually of the "revel in the index" camp (as could probably be
guessed by the original tutorial).
My personal suggestion would be to introduce git "gently" by ignoring it,
but by the time a person actually _works_ on a project (as opposed to just
going through a tutorial or following another persons project), he/she
should probably have been introduced to the index in order to understand
what happens and to use its power.
(In particular, the difference between "git diff" and "git diff HEAD" is
an important one to understand eventually).
Linus
^ permalink raw reply
* [PATCH] Fix HTTP request result processing after slot reuse
From: Nick Hengeveld @ 2006-01-31 19:06 UTC (permalink / raw)
To: git
Add a way to store the results of an HTTP request when a slot finishes
so the results can be processed after the slot has been reused.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 20 ++++++++++++++------
http.c | 9 ++++++++-
http.h | 7 +++++++
3 files changed, 29 insertions(+), 7 deletions(-)
ecda781d5eec60edc3683a4e7408c99eb93b463c
diff --git a/http-fetch.c b/http-fetch.c
index 61b2188..92326f9 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -375,6 +375,7 @@ static int fetch_index(struct alt_base *
FILE *indexfile;
struct active_request_slot *slot;
+ static struct slot_results results;
if (has_pack_index(sha1))
return 0;
@@ -393,6 +394,7 @@ static int fetch_index(struct alt_base *
filename);
slot = get_active_slot();
+ slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_FILE, indexfile);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -414,7 +416,7 @@ static int fetch_index(struct alt_base *
if (start_active_slot(slot)) {
run_active_slot(slot);
- if (slot->curl_result != CURLE_OK) {
+ if (results.curl_result != CURLE_OK) {
fclose(indexfile);
return error("Unable to get pack index %s\n%s", url,
curl_errorstr);
@@ -616,6 +618,7 @@ static int fetch_indices(struct alt_base
int i = 0;
struct active_request_slot *slot;
+ static struct slot_results results;
if (repo->got_indices)
return 0;
@@ -632,15 +635,16 @@ static int fetch_indices(struct alt_base
sprintf(url, "%s/objects/info/packs", repo->base);
slot = get_active_slot();
+ slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_FILE, &buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
if (start_active_slot(slot)) {
run_active_slot(slot);
- if (slot->curl_result != CURLE_OK) {
- if (slot->http_code == 404 ||
- slot->curl_result == CURLE_FILE_COULDNT_READ_FILE) {
+ if (results.curl_result != CURLE_OK) {
+ if (results.http_code == 404 ||
+ results.curl_result == CURLE_FILE_COULDNT_READ_FILE) {
repo->got_indices = 1;
free(buffer.buffer);
return 0;
@@ -695,6 +699,7 @@ static int fetch_pack(struct alt_base *r
struct curl_slist *range_header = NULL;
struct active_request_slot *slot;
+ static struct slot_results results;
if (fetch_indices(repo))
return -1;
@@ -721,6 +726,7 @@ static int fetch_pack(struct alt_base *r
filename);
slot = get_active_slot();
+ slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_FILE, packfile);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -742,7 +748,7 @@ static int fetch_pack(struct alt_base *r
if (start_active_slot(slot)) {
run_active_slot(slot);
- if (slot->curl_result != CURLE_OK) {
+ if (results.curl_result != CURLE_OK) {
fclose(packfile);
return error("Unable to get pack file %s\n%s", url,
curl_errorstr);
@@ -894,6 +900,7 @@ int fetch_ref(char *ref, unsigned char *
struct buffer buffer;
char *base = alt->base;
struct active_request_slot *slot;
+ static struct slot_results results;
buffer.size = 41;
buffer.posn = 0;
buffer.buffer = hex;
@@ -901,13 +908,14 @@ int fetch_ref(char *ref, unsigned char *
url = quote_ref_url(base, ref);
slot = get_active_slot();
+ slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_FILE, &buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
if (start_active_slot(slot)) {
run_active_slot(slot);
- if (slot->curl_result != CURLE_OK)
+ if (results.curl_result != CURLE_OK)
return error("Couldn't get %s for %s\n%s",
url, ref, curl_errorstr);
} else {
diff --git a/http.c b/http.c
index 75e6717..eefb0f0 100644
--- a/http.c
+++ b/http.c
@@ -335,6 +335,7 @@ struct active_request_slot *get_active_s
active_requests++;
slot->in_use = 1;
slot->local = NULL;
+ slot->results = NULL;
slot->callback_data = NULL;
slot->callback_func = NULL;
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
@@ -421,7 +422,13 @@ static void finish_active_slot(struct ac
active_requests--;
slot->in_use = 0;
curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);
-
+
+ /* Store slot results so they can be read after the slot is reused */
+ if (slot->results != NULL) {
+ slot->results->curl_result = slot->curl_result;
+ slot->results->http_code = slot->http_code;
+ }
+
/* Run callback if appropriate */
if (slot->callback_func != NULL) {
slot->callback_func(slot->callback_data);
diff --git a/http.h b/http.h
index ed4ea33..d6dc9d8 100644
--- a/http.h
+++ b/http.h
@@ -22,6 +22,12 @@
#define NO_CURL_EASY_DUPHANDLE
#endif
+struct slot_results
+{
+ CURLcode curl_result;
+ long http_code;
+};
+
struct active_request_slot
{
CURL *curl;
@@ -29,6 +35,7 @@ struct active_request_slot
int in_use;
CURLcode curl_result;
long http_code;
+ struct slot_results *results;
void *callback_data;
void (*callback_func)(void *data);
struct active_request_slot *next;
--
1.1.6.g1a5c3-dirty
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Keith Packard @ 2006-01-31 19:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: keithp, Johannes Schindelin, Carl Baldwin, Junio C Hamano,
Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601310926330.7301@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
On Tue, 2006-01-31 at 09:30 -0800, Linus Torvalds wrote:
> - ignore it. Never _ever_ use git-update-index directly, and don't tell
> people about use individual filenames to git-commit. Maybe even add
> "-a" by default to the git-commit flags as a special installation
> addition.
As a newly initiated user, this would have been a more gentle
introduction to the system. But, it would be hard to make it entirely
invisible given the current interfaces. I'm not sure if obscuring the
presense of the index is a great plan; it's already hard enough to
figure out how it works.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Census] So who uses git?
From: Radoslaw Szkodzinski @ 2006-01-31 18:33 UTC (permalink / raw)
To: Greg KH
Cc: Keith Packard, Junio C Hamano, cworth, Martin Langhoff,
Linus Torvalds, Git Mailing List
In-Reply-To: <20060129181240.GA11721@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
Greg KH wrote:
> On Sun, Jan 29, 2006 at 12:18:45PM +0100, Radoslaw Szkodzinski wrote:
>> The only drawback is local cloning. This operation is like 4x slower
>> than plain copying of the repository. Probably because it works like an
>> ssh clone - creates a pack, copies it, then unpacks. This is just
>> inefficient on a local machine.
>
> Have you tried the "-l" option for cloneing locally? It's _very_ fast,
> even for my tiny little old laptop.
Because it's cp -rl <one-tree> <second-tree> and some file modifications, right?
It's what I've been using already.
This -l option should be more prominent in the documentation.
Maybe it even already is. I've taught myself using git before 0.9.
Thank you. This helps a lot.
> If you add a "-n" that will not checkout the source tree, so you can
> compare the time of cloning with the checkout portion.
Cloning without -l option is much slower - some minutes vs below a minute.
I could have time(8)d it, but it's no use.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] Shallow clone: low level machinery.
From: Junio C Hamano @ 2006-01-31 18:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601311904410.10944@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Worse, you cannot pull from older servers into shallow repos.
"have X" means different thing if you do not have matching
grafts information, so I suspect that is fundamentally
unsolvable.
I am not sure you can convince "git-rev-list ^A" to mean "not at
A but things before that is still interesting", especially when
you give many other heads to start traversing from, but if you
can, then you can do things at rev-list command line parameter
level without doing the "exchange and use the same grafts"
trickery. That _might_ be easier to implement but I do not see
an obvious correctness guarantee in the approach.
Implementation bugs aside, it is obvious the things _would_ work
correctly with "exchange and use the same grafts" approach.
^ permalink raw reply
* Re: [Census] So who uses git?
From: J. Bruce Fields @ 2006-01-31 18:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Carl Baldwin, Junio C Hamano, Keith Packard,
Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601310926330.7301@g5.osdl.org>
On Tue, Jan 31, 2006 at 09:30:48AM -0800, Linus Torvalds wrote:
> I really think you should explain it one of two ways:
>
> - ignore it. Never _ever_ use git-update-index directly, and don't tell
> people about use individual filenames to git-commit. Maybe even add
> "-a" by default to the git-commit flags as a special installation
> addition.
>
> - talk about the index, and revel in it as a way to explain the staging
> area. This is what the old tutorial.txt did before it got simplified.
>
> The "ignore the index" approach is the simple one to explain. It's
> strictly less powerful, but hey, what else is new?
Yeah, I do wonder what's likely to be the best approach for most users.
My goal with the new tutorial was to get a reader doing something fun
and useful as quickly as possible. So it just refers elsewhere for any
discussion of the index file or SHA1 names. But probably everyone needs
to pick up that stuff eventually anyway, and maybe it's better to get to
it a little sooner, I dunno.
Besides the git-add/git-commit thing, the other thing that caught me by
suprise was the behaviour of git reset. I expected there to be an
"inverse" to git commit -a, meaning that
1) the sequence
git reset HEAD^
git commit -a
would be a no-op, in the sense that the new commit would
get the same changes as the old one, and
2) the sequence
git commit -a
git reset HEAD^
would be a no-op, in the sense that "git diff" would report
the same diff before and after.
But there isn't, and explaining how --soft and --mixed actually work
requires referring to the index file.
Is that something that can be fixed in the tools or does the user
fundamentally need to know about the index file to do this kind of
stuff?
--b.
^ permalink raw reply
* Re: [PATCH] Shallow clone: low level machinery.
From: Johannes Schindelin @ 2006-01-31 18:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5i81e4e.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 31 Jan 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > apart from my thinking this is not backward-compatible (you are supposed
> > to be able to pull from a complete repo, even if it has a
> > non-shallow-capable upload-pack), here are my comments:
>
> It cannot do a shallow clone against older servers, no.
Worse, you cannot pull from older servers into shallow repos.
> > - The custom_graft issue could be handled in a more elegant manner if
> > git was lib'ified (no temporary file). Since that is already the
> > plan, why not do that first, and come back later?
>
> That is why it does not write any temporary files. It
> introduces a way to read graft information from an environment
> variable.
Ooops. I only saw that you setup_custom_grafts and assumed wrongly.
Ciao,
Dscho
^ permalink raw reply
* Re: git-http-fetch failure/segfault -- alas no patch
From: Nick Hengeveld @ 2006-01-31 17:58 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <17374.30792.548889.344768@metalzone.distorted.org.uk>
On Mon, Jan 30, 2006 at 08:34:16PM +0000, Mark Wooding wrote:
> run_active_slot. As far as I can make out, the slot used to collect
> .../info/packs is being /reused/ by fill_active_slots (called by
> step_active_slots) before fetch_indices is returned to.
Good catch, there were a couple of places where slot result data could
be processed after the slot had been reused, with rather unpredictable
results.
There's a patch on the way after a bit more testing.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Shallow clone: low level machinery.
From: Junio C Hamano @ 2006-01-31 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601311449040.8033@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> apart from my thinking this is not backward-compatible (you are supposed
> to be able to pull from a complete repo, even if it has a
> non-shallow-capable upload-pack), here are my comments:
It cannot do a shallow clone against older servers, no. I think
it should be able to do a full clone from older servers, but I
need to double check -- at least that is how I meant to write
that thing but it was late night ;-).
> - it is good that MAXPARENT and struct commit_graft are in more public
> places now.
>
> - reparse_* is misleading. Nothing is reparsed, but rather "unparsed".
I meant to reparse them thear but forgot. Will remember to fix.
> - I'd hesitate to let git-daemon write temporary files. That is a whole
> new can of security worms.
>
> - The custom_graft issue could be handled in a more elegant manner if
> git was lib'ified (no temporary file). Since that is already the
> plan, why not do that first, and come back later?
That is why it does not write any temporary files. It
introduces a way to read graft information from an environment
variable.
> - It looks wrong to me to define MAX_PARENTS as 20 in upload-pack.c, when
> MAXPARENT is defined as 16 in cache.h.
This is remnant from my earlier one that did not move MAXPARENT
out from commit-tree I forgot to clean up before calling it a
day. Will remember to clean up.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-01-31 17:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Carl Baldwin, Junio C Hamano, Keith Packard, Martin Langhoff,
Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0601311127250.25248@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 31 Jan 2006, Johannes Schindelin wrote:
>
> On Mon, 30 Jan 2006, Carl Baldwin wrote:
>
> > In general, I think it is grasping the reason for the index file and how
> > git commands like git-commit and git-diff interact with it.
>
> IMHO this is the one big showstopper. I had problems explaining the
> concept myself.
>
> For example, I had a hard time explaining to a friend why a git-add'ed
> file is committed when saying "git commit some_other_file", but not
> another (modified) file. Very unintuitive.
I really think you should explain it one of two ways:
- ignore it. Never _ever_ use git-update-index directly, and don't tell
people about use individual filenames to git-commit. Maybe even add
"-a" by default to the git-commit flags as a special installation
addition.
- talk about the index, and revel in it as a way to explain the staging
area. This is what the old tutorial.txt did before it got simplified.
The "ignore the index" approach is the simple one to explain. It's
strictly less powerful, but hey, what else is new?
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.1.5
From: Eric Sandall @ 2006-01-31 17:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virs5x8im.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 27 Jan 2006, Junio C Hamano wrote:
> The latest maintenance release GIT 1.1.5 is available at the
> usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.1.5.tar.{gz,bz2} (tarball)
> RPMS/$arch/git-*-1.1.5-1.$arch.rpm (RPM)
>
> Mark Wooding noticed that there is a bug in git-checkout-index
> to overflow its internal buffer, if you construct a blob that
> records an insanely long symbolic link in your index file and
> try to check it out. This makes it dump core or worse.
>
> The fix for this problem is the only change from v1.1.4. The
> master branch has been updated with the same fix (so has "pu").
>
>
> ---
>
> By the way, "dump core or worse" is a subtle way to say that
> this is a security fix. To be victimized, you have to somehow
> first get such a bogus symbolic link in your index. Merging
> with somebody of dubious trustworthiness is a way to do so;
> please practice safe merge ;-).
I've updated the Source Mage GNU/Linux package, thanks!
- -sandalle
- --
Eric Sandall | Source Mage GNU/Linux Developer
eric@sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFD36CPHXt9dKjv3WERAhpUAKCXdVE+RgUUEY2BGl2jf0Bicdo7lgCgu/PJ
yfRqXjYEzA8etWJBWQ+fK7E=
=4UVq
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 0/3] Remove more parsers
From: Linus Torvalds @ 2006-01-31 17:16 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0601291645060.25300@iabervon.org>
On Sun, 29 Jan 2006, Daniel Barkalow wrote:
>
> I'll look into discarding the struct trees after use (since we're not
> keeping flags on them, or storing references to them long-term), so we can
> use the same parser without worse memory behavior. It does seem to take a
> bunch more memory (and, oddly, be very slow) as I currently have it.
Really, trying to use "struct tree" just is _broken_.
Even if you start freeing the memory, performance will absolutely _suck_.
You'll be using a "malloc()" (and eventually, a "free()") and copying the
tree entries around for absolutely zero gain. You'll make things follow
pointers and have indirection, instead of just walking the data structure
directly.
IOW, it will be about ten times more expensive in CPU time, in the most
performance-critical part of git.
I would actually argue that if you want to use a common structure, try to
convert existing users of "struct tree" to the "struct tree_desc"
iterators. Yes, their use is a little awkward, but there's really no way
you can use anything but the fast ones for tree diffing.
The "struct tree_desc" can only be used for traversing a tree linearly in
one order, but I bet that nobody really ever does anything else.
To make "struct tree_desc" more generic, you'd obviously have to export
the "update_tree_entry()" and "extract()" functions (and the latter would
probably need to be re-named to "extract_tree_entry()").
Oh, and to make freeign the tree entry a bit simpler, you'd probably want
to replace
void *buf
unsigned int size;
with a
const void *const tree_base;
const unsigned int tree_size;
unsigned int offset;
so that you'd just update "offset" and leave tree_base/size untouched (to
make freeing easier - right now the person who populates the "struct
tree_desc" has to free the thing by hand).
Linus
^ permalink raw reply
* Re: [PATCH] Make apply accept the -pNUM option like patch does.
From: Linus Torvalds @ 2006-01-31 17:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ian Molton, git
In-Reply-To: <Pine.LNX.4.64.0601310015460.25300@iabervon.org>
On Tue, 31 Jan 2006, Daniel Barkalow wrote:
>
> This only applies to traditional diffs, not to git diffs.
Also, be careful: the default for git-apply is very different from the
default for a regular "patch".
"patch" without any "-p" at all will try to automagically figure out the
right file, which has burnt me more than once when you have the same name
(usually "Makefile") in multiple sub-directories and "patch" makes the
wrong automagic guess.
git-apply with this patch will continue to use -p1. No guessing, no gray
areas.
I do believe that the right thing to do is to just make SVN output "-p1"
patches (I cannot imagine that you can't do so, since -p1 is a much saner
format than -p0), but I guess teaching git-apply to take -pN for
traditional patches is fine.
But if somebody suggests we do the automatic thing that "patch" does, I'll
scream. Too many times have I been burnt by patch being "helpful" (in
general, patch by default will try very hard to apply a patch, whether it
makes sense or not).
Linus
^ permalink raw reply
* Re: [PATCH 3/3] Use struct tree in diff-tree
From: Linus Torvalds @ 2006-01-31 16:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0601291405250.25300@iabervon.org>
On Sun, 29 Jan 2006, Daniel Barkalow wrote:
>
> It had been open-coding a tree parser. This updates the programs that
> call diff_tree() to send it the struct tree instead of a buffer and
> size.
Please don't.
parse_tree() is extremely broken, and expensive.
The "struct tree_desc" is a much better abstraction, and avoids all
overhead. Yes, it's slightly more opaque, and the interfaces could be
improved: for example, instead of having a
desc.buf = read_object_with_reference(new, "tree", &desc.size, NULL);
if (!desc.buf)
die("unable to read tree");
it might make make sense to introduce a function that does this for you,
ie just a
if (populate_tree_descriptor(new, &desc) < 0)
die("unable to read tree");
...
free_tree_descriptor(&desc);
which is perhaps more readable and maintainable.
The "diff_tree()" functions are _extremely_ performance-critical, arguably
more so than _any_ other part of git. Diffing two trees is one of _the_
most common operations, especially so when you want to follow just a
subset of files with "git-rev-list -- <filename>*", and it's extremely
important that you don't do malloc()/free() all the time.
So using "struct tree" and the general tree-parsing functions is _wrong_.
Really REALLY wrong.
>From what I can tell, your version doesn't even do the "free()". Which
probably means that not only is it slower, but I bet that if you have a
big repository like the kernel, and you do a slightly more complex
git-rev-list with multiple files, you'll use up tons and tons and tons of
memory.
Junio, please don't apply this.
Linus
^ permalink raw reply
* Third newbie question: gitk --all refresh?
From: Romano Giannetti @ 2006-01-31 16:46 UTC (permalink / raw)
To: git
I have a little problem: is gitk supposed to be possibly run in background
and then refresh when told? It seems to me that it can track only some
changes... Better let git (1.0.8) speak:
pern:~/% mkdir gitk_r
pern:~/% cd gitk_r
pern:~/gitk_r% git init-db
defaulting to local storage area
pern:~/gitk_r% echo "one" > one.txt
pern:~/gitk_r% echo "two" > two.txt
pern:~/gitk_r% git add .
pern:~/gitk_r% git commit -a -m "commit 1"
Committing initial tree efa4c546776cd5539cb54969a5e1c110b3232ee2
pern:~/gitk_r% git branch
* master
pern:~/gitk_r% git checkout -b second master
pern:~/gitk_r% git branch
master
* second
pern:~/gitk_r% echo "three" > three.txt
pern:~/gitk_r% git add three.txt
pern:~/gitk_r% ls
one.txt three.txt two.txt
pern:~/gitk_r% git commit -a -m "commit second"
pern:~/gitk_r% echo "one one" >> one.txt
pern:~/gitk_r% git commit -a -m "commit on second #2"
pern:~/gitk_r% git checkout master
pern:~/gitk_r% echo "two two" >> two.txt
pern:~/gitk_r% gitk --all &
[1] 787
pern:~/gitk_r% : Now git is showing ok
pern:~/gitk_r% git pull . second
Trying really trivial in-index merge...
Wonderful.
In-index merge
one.txt | 1 +
three.txt | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 three.txt
pern:~/gitk_r% : Now gitk refreshes ok
What I mean if that I select update - reread references it's all ok, I see
the merge.
pern:~/gitk_r% git branch -d second
Deleted branch second.
pern:~/gitk_r% : Now gitk did not delete the second branch
What I mean that I can do the same update - reread references but "second"
branch stay there...
pern:~/gitk_r% : but
pern:~/gitk_r% gitk --all
pern:~/gitk_r% : this is ok
That is, the two instances of gitk --all are showing different things: the
"old" running one continue to show the old "second" branch in green.
Is this supposed to be like that? Or is "driver" (aka /me) error?
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
http://www.dea.icai.upcomillas.es/romano/
^ permalink raw reply
* Re: Possible git-rev-list bug
From: Linus Torvalds @ 2006-01-31 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7vmzhekcz3.fsf@assigned-by-dhcp.cox.net>
On Sun, 29 Jan 2006, Junio C Hamano wrote:
> Marco Costalba <mcostalba@yahoo.it> writes:
>
> > $ git-rev-list --max-count=1 --parents addafaf92eeb86033da91323d0d3ad7a496dae83 -- rev-list.c
> > addaf.. d8f6b.. 93b74.. d8f6b.. d8f6b.. 3815f..
> >
> > We have the same parent (d8f6b..) multiple times.
>
> I think it probably is a bug.
Well, it's not strictly a bug, and multiple of the same parents _can_
happen in real life due to buggy commits, so a tool that depends on some
kind of parent uniqueness are a bit fragile. There is nothing fundamental
in the git data structures that says that you couldn't have the same
parent twice.
In this case, it didn't start out with the same parent - we had five
unique parents, but by the time the tree had been simplified, some of them
had become common.
So I don't know if it's a "bug", and the bad reaction by gitk and qgit are
arguably the _real_ bugs.
But Junio's patch is simple, and perhaps the right thing to do.
Linus
^ permalink raw reply
* Re: [Census] So who uses git?
From: Johannes Schindelin @ 2006-01-31 15:31 UTC (permalink / raw)
To: Carl Baldwin
Cc: Junio C Hamano, Keith Packard, Martin Langhoff, Linus Torvalds,
Git Mailing List
In-Reply-To: <20060131152429.GA26817@hpsvcnb.fc.hp.com>
Hi,
On Tue, 31 Jan 2006, Carl Baldwin wrote:
> Its difficult to explain because it breaks away from the precedent set
> by other SCMs. I wouldn't call it a show-stopper for this reason.
I don't.
The strange concept from the user's perspective is that
git commit -m "some message" file-a.txt
can commit file-b.txt also.
> [...] In other circumstances I simply bypass it by adding -a to the
> command-line.
This is a different thing.
Ciao,
Dscho
^ permalink raw reply
* Re: [Census] So who uses git?
From: Carl Baldwin @ 2006-01-31 15:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Keith Packard, Martin Langhoff, Linus Torvalds,
Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0601311127250.25248@wbgn013.biozentrum.uni-wuerzburg.de>
Its difficult to explain because it breaks away from the precedent set
by other SCMs. I wouldn't call it a show-stopper for this reason. In
fact, some who have wrapped their heads around the concept might call it
a valuable feature. I, myself, have found it a handy thing in certain
circumstances. In other circumstances I simply bypass it by adding -a
to the command-line.
This doesn't fit my definition of a show-stopper.
Carl
On Tue, Jan 31, 2006 at 11:27:34AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 30 Jan 2006, Carl Baldwin wrote:
>
> > In general, I think it is grasping the reason for the index file and how
> > git commands like git-commit and git-diff interact with it.
>
> IMHO this is the one big showstopper. I had problems explaining the
> concept myself.
>
> For example, I had a hard time explaining to a friend why a git-add'ed
> file is committed when saying "git commit some_other_file", but not
> another (modified) file. Very unintuitive.
>
> Ciao,
> Dscho
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin RADCAD (R&D CAD)
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ 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