* Re: How do I clear the directory cache
From: eschvoca @ 2005-10-21 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzl34ikl.fsf@assigned-by-dhcp.cox.net>
On 10/21/05, Junio C Hamano <junkio@cox.net> wrote:
> eschvoca <eschvoca@gmail.com> writes:
>
> > Yes, ... is what I want (how do I do this with pure git?).
>
> How do you do *what* with pure git is something not clear to me,
> so let me try to rephrase you and see if I understood what you
> want correctly, in pure git terms:
>
> 0. Your last commit (.git/HEAD), your index file (.git/index)
> and the files in your working tree are in sync to begin
> with.
>
> 1. Then you do random changes in the working tree (add, modify,
> remove) and do git-update-index on them without making a
> commit. If your index file is fully in sync with your
> working tree, git-diff-files would say nothing after this.
> If you did git-update-index on some but not all, then
> git-diff-files would report unrecorded changes.
>
> 2. But you want to revert these changes to the index file. By
> "clearing the directory cache", you mean you want the index
> file to have what it had in step 0, but you want to keep
> what is on the filesystem intact.
>
> If that is what you want, then:
>
> $ git-read-tree HEAD
> $ git-update-index --refresh >/dev/null
Yes, this does exaclty what I want. Thankyou.
> would reset the index to the tree recorded in your last commit.
> You can see that
>
> $ git diff --name-status --cached HEAD
>
> does not report any difference between HEAD and your index, while
>
> $ git diff --name-status
>
> shows the differences between your index and your working tree.
>
> HOWEVER, the index file does not record "intent to add", so you
> would not see files you added in step 1. mentioned in the output
> of the last command.
>
>
>
>
^ permalink raw reply
* Re: [PATCH] Do not call git-rev-list from git-fetch-pack
From: Johannes Schindelin @ 2005-10-21 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtk6vlqz.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 21 Oct 2005, Junio C Hamano wrote:
> We send "haves" in order, without 2^n skipping nor binary search
> backtrack. Instead, add a logic in upload-pack to see if a
> newly arrived "have" is a direct child of anything that we have
> already heard about, and mark to ignore them. We need to add
> that MAX_HAS counting to fetch-pack side for this to work.
Yes. This makes it more simple, and is very efficient in the common case.
How about increasing MAX_HAS to 64?
Adapted patch for fetch-pack coming soon.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/3] Clean up CURL handles in unused request slots
From: Nick Hengeveld @ 2005-10-21 19:06 UTC (permalink / raw)
To: git
Clean up CURL handles in unused request slots
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
While it's not clear whether this fixes any of the reported problems, it
seems safer to close connections that we know aren't in use.
http-fetch.c | 26 ++++++++++++++++++++------
1 files changed, 20 insertions(+), 6 deletions(-)
applies-to: ce9a5a0fdd52a29e370d849a132b4509c844aca1
24cd59bf9c4f5519e7f529cdd5bf3a9fbec72e5e
diff --git a/http-fetch.c b/http-fetch.c
index a7dc2cc..d26fae8 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -291,11 +291,7 @@ static struct active_request_slot *get_a
}
if (slot == NULL) {
newslot = xmalloc(sizeof(*newslot));
-#ifdef NO_CURL_EASY_DUPHANDLE
- newslot->curl = get_curl_handle();
-#else
- newslot->curl = curl_easy_duphandle(curl_default);
-#endif
+ newslot->curl = NULL;
newslot->in_use = 0;
newslot->next = NULL;
@@ -311,6 +307,14 @@ static struct active_request_slot *get_a
slot = newslot;
}
+ if (slot->curl == NULL) {
+#ifdef NO_CURL_EASY_DUPHANDLE
+ slot->curl = get_curl_handle();
+#else
+ slot->curl = curl_easy_duphandle(curl_default);
+#endif
+ }
+
active_requests++;
slot->in_use = 1;
slot->done = 0;
@@ -612,6 +616,7 @@ void process_curl_messages(void)
void process_request_queue(void)
{
struct transfer_request *request = request_queue_head;
+ struct active_request_slot *slot = active_queue_head;
int num_transfers;
while (active_requests < max_requests && request != NULL) {
@@ -624,6 +629,14 @@ void process_request_queue(void)
}
request = request->next;
}
+
+ while (slot != NULL) {
+ if (!slot->in_use && slot->curl != NULL) {
+ curl_easy_cleanup(slot->curl);
+ slot->curl = NULL;
+ }
+ slot = slot->next;
+ }
}
#endif
@@ -1297,7 +1310,8 @@ int main(int argc, char **argv)
#endif
slot = active_queue_head;
while (slot != NULL) {
- curl_easy_cleanup(slot->curl);
+ if (slot->curl != NULL)
+ curl_easy_cleanup(slot->curl);
slot = slot->next;
}
#ifdef USE_CURL_MULTI
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH 3/3] Allow running requests to finish after a pull error
From: Nick Hengeveld @ 2005-10-21 19:06 UTC (permalink / raw)
To: git
Allow running requests to finish after a pull error
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
applies-to: 3f355bb154eb7b68de698d1e2692615820445cae
584ac10ab8c1f869ea475246012683db95c9088c
diff --git a/http-fetch.c b/http-fetch.c
index ed1053a..1ee1df2 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1226,6 +1226,8 @@ int main(int argc, char **argv)
struct active_request_slot *slot;
char *low_speed_limit;
char *low_speed_time;
+ char *wait_url;
+ int rc = 0;
while (arg < argc && argv[arg][0] == '-') {
if (argv[arg][1] == 't') {
@@ -1313,7 +1315,7 @@ int main(int argc, char **argv)
alt->next = NULL;
if (pull(commit_id))
- return 1;
+ rc = 1;
curl_slist_free_all(pragma_header);
curl_slist_free_all(no_pragma_header);
@@ -1323,6 +1325,15 @@ int main(int argc, char **argv)
#endif
slot = active_queue_head;
while (slot != NULL) {
+ if (slot->in_use) {
+ if (get_verbosely) {
+ curl_easy_getinfo(slot->curl,
+ CURLINFO_EFFECTIVE_URL,
+ &wait_url);
+ fprintf(stderr, "Waiting for %s\n", wait_url);
+ }
+ run_active_slot(slot);
+ }
if (slot->curl != NULL)
curl_easy_cleanup(slot->curl);
slot = slot->next;
@@ -1331,5 +1342,5 @@ int main(int argc, char **argv)
curl_multi_cleanup(curlm);
#endif
curl_global_cleanup();
- return 0;
+ return rc;
}
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH 2/3] Switched back to loading alternates as needed
From: Nick Hengeveld @ 2005-10-21 19:06 UTC (permalink / raw)
To: git
Switched back to loading alternates as needed
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Always loading alternates causes unnecessary requests, especially
when a repository is being cloned and git-http-fetch is run repeatedly
with different commit IDs. On a related note, in such a case could we
pass multiple IDs to the commit walkers (perhaps via stdin?)
http-fetch.c | 45 +++++++++++++++++++++++++++++----------------
1 files changed, 29 insertions(+), 16 deletions(-)
applies-to: 6a0c92c60e0b46581276e7592e4f7a1b12f3dc7e
274889e0d7a97eaf060851653166b7cbc72dd3f6
diff --git a/http-fetch.c b/http-fetch.c
index d26fae8..ed1053a 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -25,6 +25,7 @@
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
+static int got_alternates = 0;
static int active_requests = 0;
static int data_received;
@@ -85,6 +86,7 @@ struct active_request_slot
int in_use;
int done;
CURLcode curl_result;
+ long http_code;
struct active_request_slot *next;
};
@@ -235,6 +237,7 @@ static size_t fwrite_sha1_file(void *ptr
static void process_curl_messages(void);
static void process_request_queue(void);
#endif
+static int fetch_alternates(char *base);
static CURL* get_curl_handle(void)
{
@@ -580,6 +583,9 @@ void process_curl_messages(void)
slot->done = 1;
slot->in_use = 0;
slot->curl_result = curl_message->data.result;
+ curl_easy_getinfo(slot->curl,
+ CURLINFO_HTTP_CODE,
+ &slot->http_code);
request = request_queue_head;
while (request != NULL &&
request->slot != slot)
@@ -590,19 +596,20 @@ void process_curl_messages(void)
if (request != NULL) {
request->curl_result =
curl_message->data.result;
- curl_easy_getinfo(slot->curl,
- CURLINFO_HTTP_CODE,
- &request->http_code);
+ request->http_code = slot->http_code;
request->slot = NULL;
+ request->state = COMPLETE;
/* Use alternates if necessary */
- if (request->http_code == 404 &&
- request->repo->next != NULL) {
- request->repo = request->repo->next;
- start_request(request);
+ if (request->http_code == 404) {
+ fetch_alternates(alt->base);
+ if (request->repo->next != NULL) {
+ request->repo =
+ request->repo->next;
+ start_request(request);
+ }
} else {
finish_request(request);
- request->state = COMPLETE;
}
}
} else {
@@ -765,6 +772,9 @@ static int fetch_alternates(char *base)
struct active_request_slot *slot;
+ if (got_alternates)
+ return 0;
+
data = xmalloc(4096);
buffer.size = 4096;
buffer.posn = 0;
@@ -797,6 +807,8 @@ static int fetch_alternates(char *base)
run_active_slot(slot);
if (slot->curl_result != CURLE_OK) {
free(buffer.buffer);
+ if (slot->http_code == 404)
+ got_alternates = 1;
return 0;
}
}
@@ -868,6 +880,7 @@ static int fetch_alternates(char *base)
i = posn + 1;
}
+ got_alternates = 1;
free(buffer.buffer);
return ret;
}
@@ -1059,16 +1072,16 @@ static int fetch_object(struct alt_base
run_active_slot(request->slot);
#ifndef USE_CURL_MULTI
request->curl_result = request->slot->curl_result;
- curl_easy_getinfo(request->slot->curl,
- CURLINFO_HTTP_CODE,
- &request->http_code);
+ request->http_code = request->slot->http_code;
request->slot = NULL;
/* Use alternates if necessary */
- if (request->http_code == 404 &&
- request->repo->next != NULL) {
- request->repo = request->repo->next;
- start_request(request);
+ if (request->http_code == 404) {
+ fetch_alternates(alt->base);
+ if (request->repo->next != NULL) {
+ request->repo = request->repo->next;
+ start_request(request);
+ }
} else {
finish_request(request);
request->state = COMPLETE;
@@ -1121,6 +1134,7 @@ int fetch(unsigned char *sha1)
while (altbase) {
if (!fetch_pack(altbase, sha1))
return 0;
+ fetch_alternates(alt->base);
altbase = altbase->next;
}
return error("Unable to find %s under %s\n", sha1_to_hex(sha1),
@@ -1297,7 +1311,6 @@ int main(int argc, char **argv)
alt->got_indices = 0;
alt->packs = NULL;
alt->next = NULL;
- fetch_alternates(alt->base);
if (pull(commit_id))
return 1;
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] Do not call git-rev-list from git-fetch-pack
From: Junio C Hamano @ 2005-10-21 17:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510211111440.4950@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Note that the best thing would probably be to add a binary search to that,
> and *not* stop at the first ack'ed rev, but rather count them, and stop at
> MAX_HAS.
Another alternative.
We send "haves" in order, without 2^n skipping nor binary search
backtrack. Instead, add a logic in upload-pack to see if a
newly arrived "have" is a direct child of anything that we have
already heard about, and mark to ignore them. We need to add
that MAX_HAS counting to fetch-pack side for this to work.
This is not even compile tested, but just to outline the idea.
(... now off to day-job ...)
---
diff --git a/upload-pack.c b/upload-pack.c
index 8a41caf..d98a28e 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -3,9 +3,11 @@
#include "pkt-line.h"
#include "tag.h"
#include "object.h"
+#include "commit.h"
static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
+#define THEY_HAVE (1U << 0)
#define MAX_HAS (16)
#define MAX_NEEDS (256)
static int nr_has = 0, nr_needs = 0;
@@ -92,6 +94,20 @@ static int got_sha1(char *hex, unsigned
return 0;
nr = nr_has;
if (nr < MAX_HAS) {
+ struct object *o = lookup_object(sha1);
+ if (!o || (o->parsed || !parse_object(sha1)))
+ die("oops");
+ if (o->type == commit_type) {
+ struct commit_list *parents;
+ if (o->flags & THEY_HAVE)
+ return 0;
+ o->flags |= THEY_HAVE;
+ for (parents = ((struct commit*)o)->parents;
+ parents;
+ parents = parents->next) {
+ parents->item->object.flags |= THEY_HAVE;
+ }
+ }
memcpy(has_sha1[nr], sha1, 20);
nr_has = nr+1;
}
@@ -104,6 +120,9 @@ static int get_common_commits(void)
unsigned char sha1[20];
int len;
+ track_object_refs = 0;
+ save_commit_buffer = 0;
+
for(;;) {
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
^ permalink raw reply related
* [PATCH] Silence confusing and false-positive curl error message
From: Petr Baudis @ 2005-10-21 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-http-fetch spits out curl 404 error message when unable to fetch an object,
but that's confusing since no error really happenned and the object is usually
found in a pack it tries right after that. And if the object still cannot be
retrieved, it will say another error message anyway. OTOH other HTTP errors
(403 etc) are likely fatal and the user should be still informed about them.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
http-fetch.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index a7dc2cc..2d76ee1 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1069,9 +1069,12 @@ static int fetch_object(struct alt_base
}
if (request->curl_result != CURLE_OK && request->http_code != 416) {
- ret = error("%s (curl_result = %d, http_code = %ld, sha1 = %s)",
- request->errorstr, request->curl_result,
- request->http_code, hex);
+ if (request->http_code == 404)
+ ret = -1; /* Be silent, it is probably in a pack. */
+ else
+ ret = error("%s (curl_result = %d, http_code = %ld, sha1 = %s)",
+ request->errorstr, request->curl_result,
+ request->http_code, hex);
release_request(request);
return ret;
}
^ permalink raw reply related
* Re: [PATCH] Do not send "want" lines for complete objects
From: Daniel Barkalow @ 2005-10-21 15:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510210114370.10503@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 21 Oct 2005, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 20 Oct 2005, Daniel Barkalow wrote:
>
> > On Thu, 20 Oct 2005, Johannes Schindelin wrote:
> >
> > > Hi,
> > >
> > > > > + ((o = parse_object(remote)) != NULL) &&
> > > > > + (o->flags & COMPLETE) &&
> > >
> > > I just realized that parse_object() always reads the file, then does a
> > > lookup (which makes the above code work), and then parses the file. It
> > > always does all of these steps, even if the object was already parsed. Any
> > > reason for this?
> >
> > I'm lazy and haven't sent in a patch to clean that up. There's no reason
> > it couldn't check whether the value it gets is already parsed.
>
> Actually, you don't have to... Junio already replaced parse_object() by
> lookup_object() in this case.
It often gets used in cases where it isn't completely obvious that the
object has already been parsed; this is the second place that it's been
replaced.
> I did not use it originally, because lines 24-25 of commit.h say
>
> /** Internal only **/
> struct object *lookup_object(const unsigned char *sha1);
>
> Is this obsolete?
I'd intended it to be internal, for use by things like lookup_tree(), but
I suppose that it could be used more generally, if it got a comment that
says that, unlike lookup_tree() and such, it returns NULL if the object
has not already been read (because it doesn't know how to create it).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: rsync update appears broken now
From: Linus Torvalds @ 2005-10-21 15:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <861x2fdloj.fsf@blue.stonehenge.com>
On Fri, 21 Oct 2005, Randal L. Schwartz wrote:
>
> Doesn't yet work for me. What do I need to do now?
>
> * committish: 4ae22d96fe9248dac4f26b1fc91154ba5e879799
> branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
> * refs/heads/origin: same as branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
> Updating from ea5a65a59916503d2a14369c46b1023384d51645 to 4ae22d96fe9248dac4f26b1fc91154ba5e879799.
> fetch-pack.c: needs update
Your previous failed pull had left the unfinished merge around, so now
when you try to pull and it tries to update, it can't.
Do a
git checkout -f
first to reset your tree to your old HEAD, and then try again. It should
work then.
(Or do "git reset --hard", which should end up doing the same thing)
Linus
^ permalink raw reply
* Re: Split up tree diff functions into tree-diff.c library
From: Linus Torvalds @ 2005-10-21 15:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v64rr2y4q.fsf@assigned-by-dhcp.cox.net>
On Thu, 20 Oct 2005, Junio C Hamano wrote:
>
> I have not closely studied the user of this change, rev-list,
> but I have a hunch that you might be better off, if you define a
> new diff "format", DIFF_FORMAT_CALLBACK, and hook into
> diff_flush(), instead of hooking into diff_addremove() and
> diff_change().
No, I did that on purpose.
I did _not_ want the library interface users to have to use the flushing
and all the associated memory management and complexity issues.
The thing is, the only thing rev-list wants to know is whether there was a
diff at all, and I want to eventually make "opt->change()" and
"opt->add_remove()" return a possible error code so that the whole diff
library can just stop on the first change, since once we've seen _any_
change, we don't care any more.
Also, by taking it over at this lieve, you don't need to do any of the
diff setup at all to use the core routines.
Now, if somebody _wants_ to hook into flushing, you can still do so: you
just do
opt->add_remove = diff_addremove;
opt->change = diff_change;
and then you can hook into the higher-level functions if you want to. But
for a lot of uses, I bet we do _not_ want to. And those higher-level
routines have had some _serious_ memory use problems etc: by hooking into
the lower level, we can bypass all of that.
(A memory leak in diff in git-rev-parse would be deadly on big archives).
> Right now, you are only making the parallel tree traversing and
> comparing part from diff-tree available in the library form
> (which is fine), but that way leaves the door open for it to
> also use the rest of the diffcore machinery.
The point is, we don't _want_ to use the rest of the diffcore machinery.
It's too expensive and fragile.
Linus
^ permalink raw reply
* Re: [PATCH] Cogito README: add a block describing team workflow with git+ssh
From: Petr Baudis @ 2005-10-21 15:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11298728883894-git-send-email-martin@catalyst.net.nz>
Dear diary, on Fri, Oct 21, 2005 at 07:34:48AM CEST, I got a letter
where Martin Langhoff <martin@catalyst.net.nz> told me that...
> This is a resend, with a silly typo (chgroup/chgrp) fixed.
It was missing the signoff, but I worked that around by taking your
original patch from the end of September. ;-)
> The README doesn't talk about teams with "peer" access to a shared repo.
> It took me a while to figure our the /right/ way to do it. Document for
> future generations and general happiness.
Thanks. The long sequence of permissions setup inspired me to adding
cg-admin-setuprepo which automates that. I also changed the git-push
to cg-push. Please review the final result.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: rsync update appears broken now
From: Randal L. Schwartz @ 2005-10-21 13:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510201752050.10477@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> On Fri, 21 Oct 2005, Junio C Hamano wrote:
>>
>> I am reasonably sure that the screw-up was only rewinding one commit too much.
>> I've done the merge so things should look better once mirrors catch up.
Linus> Yup, works at least for me. Thx,
Doesn't yet work for me. What do I need to do now?
* committish: 4ae22d96fe9248dac4f26b1fc91154ba5e879799
branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
Updating from ea5a65a59916503d2a14369c46b1023384d51645 to 4ae22d96fe9248dac4f26b1fc91154ba5e879799.
fetch-pack.c: needs update
fatal: Entry 'daemon.c' would be overwritten by merge. Cannot merge.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] Quote COGITO_LIB in scripts
From: Jonas Fonseca @ 2005-10-21 13:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
... so they work when prefix contains spaces.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/Makefile b/Makefile
index fd52992..1b61953 100644
--- a/Makefile
+++ b/Makefile
@@ -92,12 +92,12 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT)
$(INSTALL) $(LIB_SCRIPT) $(DESTDIR)$(libdir)
cd $(DESTDIR)$(bindir); \
for file in $(SCRIPT); do \
- sed -e 's/\$${COGITO_LIB}/\$${COGITO_LIB:-$(sedlibdir)\/}/g' $$file > $$file.new; \
+ sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
cd $(DESTDIR)$(libdir); \
for file in $(LIB_SCRIPT); do \
- sed -e 's/\$${COGITO_LIB}/\$${COGITO_LIB:-$(sedlibdir)\/}/g' $$file > $$file.new; \
+ sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] cg-fetch: retrieve missing commits with a smarter optimization
From: Petr Baudis @ 2005-10-21 12:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11298726913836-git-send-email-martin@catalyst.net.nz>
Could you please resend your patches signed off? Thanks.
Dear diary, on Fri, Oct 21, 2005 at 07:31:31AM CEST, I got a letter
where Martin Langhoff <martin@catalyst.net.nz> told me that...
> + will check tagrefs, trying to ensure it actually has the relevant
> commits. If the commits are missing, it'll go out and fetch them.
I'd prefer the approach to throw away the tag. Otherwise we get into
problems when we want to grab only a single branch from multi-branch
repository.
> + if the tagref points to a blob and we have it, it'll skip it
The problem is that the ^{blob} syntax is not in 0.98, so this would
make Cogito depend on a yet unreleased GIT version, which is
troublesome.
So I guess this patch will end up in my post-0.99/1.0 queue for now.
But by that time, this part of cg-fetch will be probably already totally
rewritten. ;-)
> This isn't a complete solution for cg-fetch -- git-fetch is actually
> much smarter now, and cg-fetch should perhaps be a thin wrapper
> around it, dropping all the duplicate code.
I'm still thinking about it. I will certainly try to at least somehow
reuse git-fetch's remote parser, if not anything else - reimplementing
that would be just stupid.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: How do I clear the directory cache
From: Petr Baudis @ 2005-10-21 10:52 UTC (permalink / raw)
To: eschvoca; +Cc: git
In-Reply-To: <2b05065b0510202023i62ab7c03uea1381d76535dcc7@mail.gmail.com>
Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter
where eschvoca <eschvoca@gmail.com> told me that...
> Yes, "cg-reset --adds-removals" is what I want (how do I do this with
> pure git?).
git-read-tree HEAD
git-update-cache --refresh
> I would like to clear/reset the index because I've screwed it all up.
> I don't think I can do as you suggested because of the way I got into
> this mess.
>
> I'm using git/cogito to version control my hard drive and I've been
> gradually adding more entries into the .gitignore file because some
> files change too frequently or I don't want them backed up. The OS
> modified a bunch of files, I cg-rm'd 1/4 of them, then I changed my
> mind and added them back, also did some genuine cg-adds, etc. and now
> I'm all confused (it's a whole hard drive).
Well, cg-status should show you what you effectively did, and then you
could just do something like:
cg-status -w | grep ^D | tr '\n' '\0' | xargs -0 cg-add
cg-status -w | grep ^A | tr '\n' '\0' | xargs -0 cg-rm
> If other people are interested in doing this I can pass on the lessons
> I learned.
>
> What I found it git is amazingly fast! cg-status only takes a few
> seconds. I think there are some problems if you try to do:
>
> cd /
> cg-add -r usr
> cg-commit -m "take a long break"
>
> It seems that cg-add-ing and cg-commit-ing smaller chunks is faster
> than one big chunk.
Interesting. I cannot spot anything which would bog it down in Cogito.
Is both cg-add and cg-commit significantly slower? (That is, if it takes
longer than sum of the smaller chunks.) Perhaps it's a cache issue, not
everything from the chunk fits into your cache during cg-add, so
cg-commit has to reread it from the disk.
> I think commands for the following should be added to cogito:
I'd prefer:
> cg-status -<status_flag> # list files with given status flag (without
> status flag in column 1)
> git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore
All right, this might be useful. Implemented as cg-status -s '?' and such,
thanks for the idea.
> cg-add [-r] -<status_flag> # add files with a given status flag
> git-ls-files [--others|--deleted|etc]
> --exclude-per-directory=/.gitignore | while read i; do cg-add "$i;
> done
>
> cg-rm [-r] -<status_flag> # you get the idea.
>
> cg-addremove # recursively add new files, remove deleted files
I implemented the cg-reset --adds-removes option, but I don't feel
comfortable with the cg-add change - just -r would be enough to add new
files, and if you are in mess big enough, you can just cg-reset. It
would be useful to make cg-rm symmetric to cg-add, though. Then you
could do just
cg-add -r . && cg-rm -r .
and it would be equivalent to cg-addremove.
> I use "while read i" so it will work with spaces in filenames.
And break with leading spaces unless you modified $IFS properly. Note
that those people having filenames starting by spaces are either
seriously sick or script kiddies who just rooted you (or warez kiddies
on your FTP server with anonymously-writable incoming).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Do not call git-rev-list from git-fetch-pack
From: Johannes Schindelin @ 2005-10-21 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virvrw8w1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 21 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > + Branch1 has 40 commits since it last merged with branch2,
> > + and branch2 has 2 more commits since then.
> > +
> > + On the other end, branch1 is up-to-date, but branch2 is not.
> > + When fetching branch1, the 40 commits get sent, the first
> > + is acknowledged as common, and the local head of branch2
> > + never gets sent.
> > +
> > + As a consequence, the whole history of branch2
> > + (git-rev-list branch2 ^branch1) gets packed and transmitted.
>
> Arrrgggggggh. The description above captures the essense of the
> problem very well, but faking dates and still popping by recency
> looks like a really ugly hack to me.
It is ugly. But it is a good heuristic. And the code is simple, because I
could use the existing functions for inserting into a commit_list.
> Wouldn't it be cleaner if you traversed commits starting from
> local refs, and assign distance from the tip of the branch to
> each object (use generic object->util field for it), and
> maintain an object_list that is sorted by depth, similar to
> commit_list sorted by commit date? Then you can pop from the
> list by depth, closer to tip first, and tell the other end that
> you have branch1, branch2, branch1^, branch2^, branch1~2,
> branch2~1,... which is the order the above situation benefits
> from.
I have an example from the real world why this is bad as well: I have a
repository imported from CVS, which has this silly CVS initial import
marked as it's own branch. This was long, long, long ago, but
git-cvsimport faithfully creates the branch "initial" for it anyway.
Imagine now the case that I added 40 revisions locally between the last
fetch and now. What would happen is this:
In both cases, your git-fetch-pack and mine, the tips would get sent, the
(very old one) "initial" acknowledged. A few of those 40 revisions would
get sent, too, (and in your case, the root rev), but not at all the
optimal merge base. In essence, almost all would get sent again.
How about this on top of your idea:
Send only those branch{i}^n where n is a power of 2. This is a tradeoff
between the speed we find sensible common revs, and the accurateness of
the best pick.
Note that the best thing would probably be to add a binary search to that,
and *not* stop at the first ack'ed rev, but rather count them, and stop at
MAX_HAS.
Ciao,
Dscho
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Petr Baudis @ 2005-10-21 9:15 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: Dmitry Torokhov, git
In-Reply-To: <4358597A.6000306@catalyst.net.nz>
Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter
where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> Almost. No, truly, I'm very impressed with git-merge.sh, which first
> does the simple git-read-tree -m, and it can then try several merger
> scripts to resolve the index. The "smartest" merge resolver we have
> follows renames, but we could have language-specific and
> project-specific resolvers, for instance.
Yes, following renames is nice. But as long as it is three-way, it
suffers of inherent and rather nasty problems. Well, I'm watching the
weave merge effort and plan to give it a try to port it to GIT when I
have some time.
> If you combine the coolness of git-merge.sh with the fact that cg-merge
> right now is buggy[*]... I'm starting to rely on doing cg-fetch and
> running git-merge.sh by hand.
>
> * I just merged your latest fixes, knowing that they'd conflict on
> cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only
> complained like this:
>
> MERGE ERROR: : Not handling case -> ->
>
> But there were no conflicts at all in the tree! It seems to be that it's
> dropping the upstream changes it doesn't like.
There was a bug in argument parsing of cg-Xmergefile, already fixed now.
Well, it's true that cg-Xmergefile still does not handle all merge
cases, but it certainly will not be silent about it, at least. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Do not call git-rev-list from git-fetch-pack
From: Junio C Hamano @ 2005-10-21 8:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510210413210.26388@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> + Branch1 has 40 commits since it last merged with branch2,
> + and branch2 has 2 more commits since then.
> +
> + On the other end, branch1 is up-to-date, but branch2 is not.
> + When fetching branch1, the 40 commits get sent, the first
> + is acknowledged as common, and the local head of branch2
> + never gets sent.
> +
> + As a consequence, the whole history of branch2
> + (git-rev-list branch2 ^branch1) gets packed and transmitted.
Arrrgggggggh. The description above captures the essense of the
problem very well, but faking dates and still popping by recency
looks like a really ugly hack to me.
Wouldn't it be cleaner if you traversed commits starting from
local refs, and assign distance from the tip of the branch to
each object (use generic object->util field for it), and
maintain an object_list that is sorted by depth, similar to
commit_list sorted by commit date? Then you can pop from the
list by depth, closer to tip first, and tell the other end that
you have branch1, branch2, branch1^, branch2^, branch1~2,
branch2~1,... which is the order the above situation benefits
from.
^ permalink raw reply
* Re: How to create a new branch based on a tag?
From: Junio C Hamano @ 2005-10-21 8:20 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <43593E08.1060208@ust.hk>
Ben Lau <benlau@ust.hk> writes:
>>Linus or somebody authoritative could do:
>>
>> $ commit=$(echo v2.6.11 | \
>> git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)
>> $ git-tag -s -m 'v2.6.11 canonical "fake" commit' v2.6.11fake $commit
>>
>>and tell everybody interested to have:
>>
>>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 xxxxxxxxxx
>>
>>(where xxxxx... is the value of $commit above) in their
>>info/grafts file. Then we *could* pretend that v2.6.12-rc2's
>>parent is v2.6.11. You could branch off from v2.6.11fake commit
>>and base your development, and later you could merge that into
>>later development history (say, v2.6.14-rc5) if you wanted to.
>>
> Thanks for detail explanation.
>
> It is a little bit difficult for me. The result of `git log`
> shows that the eldest commit is 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> which is linux-2.6.12-rc2. Is that means the git repository do not
> store the history before this tag?
Linux development on git, at least the history available
officially, starts from 2.6.12-rc2.
Let's try to find things together. In the typescript below,
": siamese;" is my shell prompt $PS1.
First, look at v2.6.12-rc2 object. What type is it?
: siamese; git-cat-file -t v2.6.12-rc2
tag
It is a tag. Let's see what's inside.
: siamese; git-cat-file tag v2.6.12-rc2
object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
type commit
tag v2.6.12-rc2
Linux v2.6.12-rc2 release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCbW8ZF3YsRnbiHLsRAgFRAKCq/TkuDaEombFABkPqYgGCgWN2lQCcC0qc
wznDbFU45A54dZC8RZ5JxyE=
=ESRP
-----END PGP SIGNATURE-----
OK, that points at a commit and object name is 1da177e4c...
Let's look at that object. You can abbreviate object name here.
: siamese; git-cat-file commit 1da177e4c
tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d
author Linus Torvalds <torvalds@ppc970.osdl.org> 1113690036 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> 1113690036 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Notice the top three lines? There is no "parent " line, like
recent commits, for example:
: siamese; git-cat-file commit v2.6.13
tree 9b182c47688d261775f8c49e06cb795dfc8931dc
parent 20b1730af3ae05450b0e03f5aed40c4313f65db6
author Linus Torvalds <torvalds@g5.osdl.org> 1125272461 -0700
committer Linus Torvalds <torvalds@g5.osdl.org> 1125272461 -0700
Linux v2.6.13
What this means is that 2.6.12-rc2 was the big-bang, the
beginning of time, as far as the history recorded in git is
concerned. There was nothing before that time. On the other
hand, v2.6.13 has a "parent " line -- this names another commit,
and Linus has some change between that parent commit and
v2.6.13.
: siamese; git diff v2.6.13^ v2.6.13
diff --git a/Makefile b/Makefile
index 300f61f..5acd1fc 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 13
-EXTRAVERSION =-rc7
+EXTRAVERSION =
NAME=Woozy Numbat
# *DOCUMENTATION*
Of course, the version number has changed. v2.6.13^ is a
short-hand to say "first parent of v2.6.13" (see git-rev-parse
documentation).
> Then how can `git-read-tree v2.6.11` fetchs the content of
> v2.6.11?
Trees do not have their position in timeline. Only commits do.
This is explained by King Penguin himself. If you are reading
the documentation on the web,
http://www.kernel.org/pub/software/scm/git/docs/
find the link "The [Discussion] section below contains much
useful information...", and follow it. README in the git source
tree at the top level has the same. The description there
covers the object database and blob/tree/commit/tag objects, and
how these things fit together.
Think of a tree as if you created a tar archive (but without
even timestamps) of an extracted kernel source tree. It is a
snapshot of directory structure and file contents. You can have
many such snapshots, but they themselves do not describe how
each of them is related with other snapshots. Commit objects
tie them together and give them their position in time. The
"parent " line above refers to another commit (note that you can
have more than one "parent " lines to denote a merge).
> By the way, How could you find the
> c39ae07f393806ccf406ef966e9a15afc43cc36a out?
: siamese; git-cat-file tag v2.6.11-tree
object c39ae07f393806ccf406ef966e9a15afc43cc36a
type tree
tag v2.6.11-tree
This is the 2.6.11 tree object.
NOTE! There's no commit for this, since it happened before I started with git.
Eventually we'll import some sort of history, and that should tie this tree
object up to a real commit. In the meantime, this acts as an anchor point for
doing diffs etc under git.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCeV/eF3YsRnbiHLsRAl+SAKCVp8lVXwpUhMEvy8N5jVBd16UCmACeOtP6
KLMHist5yj0sw1E4hDTyQa0=
=/bIK
-----END PGP SIGNATURE-----
When v2.6.11 was released, there was no git. Linus can create a
tree out of that release, and that is what he did.
He could have created a commit that claimed it was the beginning
of time. He did not do that because what he could not do was to
retroactively make that commit a parent of the v2.6.12-rc2
commit he already made.
This is because any git object (any type) has a name based on a
cryptographically secure hash of its contents, and "the
contents" in the case of a commit object includes those header
lines (which tree object that commit records, what commits its
parents are, who wrote it and who committed it when).
Retroactively adding/modifying parent to an existing commit
would mean you would change its contents -- hence its name. An
existing child of that commit now needs to get its "parent "
line changed to point at the updated parent. Which means
rewriting the whole history since v2.6.12-rc2 commit.
The "graft" facility I mentioned in my previous message was
invented much later. It lets you pretend that a given commit
object has an arbitrary set of commit objects as its parents,
which is typically different from its real parents. By using
it, you *could* pretend that v2.6.12-rc2 is a child of
v2.6.11fake commit (which you create by wrapping the v2.6.11
tree into it).
There is a mention on "graft" facility in the repository layout
documentation:
http://www.kernel.org/pub/software/scm/git/docs/repository-layout.html
we might want to also refer to this from git-log documentation,
and perhaps git-merge-base documentation.
^ permalink raw reply
* Re: How to create a new branch based on a tag?
From: Ben Lau @ 2005-10-21 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmp3319v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Ben Lau <benlau@ust.hk> writes:
>
>
>
>>>The way you know is as good as it gets. v2.6.11-tree case is
>>>really an unfortunate special case.
>>>
>>>
>>>
>>What is wrong with the v2.6.11-tree? I just thought it is a duplicate tag
>>of v2.6.11.
>>
>>
>
>They are not *wrong* per-se. They are tags to tree objects
>without any associated commit history -- that makes them
>inappropriate to be used as branch heads.
>
>Linus or somebody authoritative could do:
>
> $ commit=$(echo v2.6.11 | \
> git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)
> $ git-tag -s -m 'v2.6.11 canonical "fake" commit' v2.6.11fake $commit
>
>and tell everybody interested to have:
>
>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 xxxxxxxxxx
>
>(where xxxxx... is the value of $commit above) in their
>info/grafts file. Then we *could* pretend that v2.6.12-rc2's
>parent is v2.6.11. You could branch off from v2.6.11fake commit
>and base your development, and later you could merge that into
>later development history (say, v2.6.14-rc5) if you wanted to.
>
>If Linus does something like the above, the graft probably be
>better done between the current v2.6.12-rc2 based commit history
>and the corresponding commit in the history resurrected from
>BKCVS (torvalds/old-2.6-bkcvs.git). Then you could even base
>your development on top of v2.4.0 ;-).
>
>Funnily, v2.6.12-rc2 commit in the current history and BKCVS
>v2.6.12-rc2 commit in the resurrected history have different
>tree IDs.
>
>I am however not quite sure how useful the above would be,
>though. EVen between 2.6.11 and 2.6.12-rc2 much have happened,
>so unless the changes you are making apply to the part that did
>not change between those two, merge conflict resolution might be
>quite a chore.
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe git" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Thanks for detail explanation.
It is a little bit difficult for me. The result of `git log`
shows that the eldest commit is 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
which is linux-2.6.12-rc2. Is that means the git repository do not
store the history before this tag? Then how can `git-read-tree
v2.6.11` fetchs the content of v2.6.11?
By the way, How could you find the
c39ae07f393806ccf406ef966e9a15afc43cc36a out?
I have followed your instuctions and now have my own 2.6.11
branch(my2.6.11). Should be fine
now. Many thanks to all you guys.
^ permalink raw reply
* Re: Split up tree diff functions into tree-diff.c library
From: Junio C Hamano @ 2005-10-21 6:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510202058030.10477@g5.osdl.org>
I have not closely studied the user of this change, rev-list,
but I have a hunch that you might be better off, if you define a
new diff "format", DIFF_FORMAT_CALLBACK, and hook into
diff_flush(), instead of hooking into diff_addremove() and
diff_change(). Instead of calling diff_flush_raw() or
diff_flush_name(), or diff_flush_patch(), your callback function
would be called with each filepair.
Right now, you are only making the parallel tree traversing and
comparing part from diff-tree available in the library form
(which is fine), but that way leaves the door open for it to
also use the rest of the diffcore machinery.
By doing things this way, later round of rev-list that culls
uninteresting commits could be taught to also follow renames.
Am I grossly off the mark?
^ permalink raw reply
* [PATCH] Cogito README: add a block describing team workflow with git+ssh
From: Martin Langhoff @ 2005-10-21 5:34 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
This is a resend, with a silly typo (chgroup/chgrp) fixed.
---
The README doesn't talk about teams with "peer" access to a shared repo.
It took me a while to figure our the /right/ way to do it. Document for
future generations and general happiness.
---
README | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
applies-to: 06a96ef8bc54639d5e42319c86cac2d812327cf0
1217193450bf9ae108af2341f1383eb496d31b62
diff --git a/README b/README
index 70908bc..fb87adb 100644
--- a/README
+++ b/README
@@ -268,6 +268,41 @@ Note that we gave only a glimpse to the
- merging (`cg-merge`), moving your tree to an older commit (`cg-seek`),
pushing (`cg-push`), etc.
+Using Cogito for Team Work
+--------------------------
+
+A small team with SSH access to a shared server can use Cogito in a way
+similar to traditional CVS over SSH.
+
+If you are bootstrapping the project, and you have a local Cogito working copy,
+you must set up the shared repository and push a local head to it.
+
+To set up the shared repository, for example in
+remoteserver:/var/git, login to the remote server and do
+
+ $ umask 002
+ $ mkdir /var/git
+ $ chgrp gitcommit /var/git
+ $ chmod 2775 /var/git
+ $ mkdir -p /var/git/projectname.git
+ $ GIT_DIR=/var/git/projectname.git git-init-db
+
+Note: All the developers with "commit" access must belong to the gitcommit
+group and have a 002 umask on the remote server.
+
+Going back to your Cogito working copy, run
+
+ $ git-push remoteserver:/var/git/projectname.git master branchname
+
+Now your other teammembers can start working with you, doing
+
+ $ cg-clone git+ssh://remoteserver/var/git/project.git#branchname localdir
+
+And when they are ready to push their work onto the shared repository, just do
+
+ $ cg-update
+ $ cg-push
+
Understanding GIT branching and merging
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] cg-fetch: Fixed missing $COGITO_LIB path
From: Martin Langhoff @ 2005-10-21 5:31 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Trivial fix -- prevents cg-fetch from working on systems where the COGITO_LIB
env var isn't set.
---
cg-fetch | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 6dd73afff0a1f3e2433b90e2ea42f8500393bd97
ae2ea27f59cdb22d7587aaa49f12f29e1b1f77e1
diff --git a/cg-fetch b/cg-fetch
index f0c11aa..80b2a03 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -39,7 +39,7 @@ deprecated_alias cg-fetch cg-pull
fetch_progress()
{
- exec cg-Xfetchprogress "$_git_objects"
+ exec ${COGITO_LIB}cg-Xfetchprogress "$_git_objects"
}
show_changes_summary()
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] cg-fetch: retrieve missing commits with a smarter optimization
From: Martin Langhoff @ 2005-10-21 5:31 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
I've actually rebased this one so Petr doesn't have to deal
with the silly conflicts. It also turns out that my repo got
fsck'd in one of the last updates, and cg-merge was seriously
broken. I guess did an update in the middle of the transition
between positional parameters and named parameters, and got stuck.
Actual commit message follows.
---
+ will check tagrefs, trying to ensure it actually has the relevant
commits. If the commits are missing, it'll go out and fetch them.
+ if the tagref points to a blob and we have it, it'll skip it
This isn't a complete solution for cg-fetch -- git-fetch is actually
much smarter now, and cg-fetch should perhaps be a thin wrapper
around it, dropping all the duplicate code.
This version uses ^0 instead of ^{commit} which does a more thorough check,
so we don't need to call git-cat-file.
---
cg-fetch | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
applies-to: e6fab694ece986de77f6e17c16df9f17276c6666
e2cf1ab9b594d3d12655dd93377dfea03247379e
diff --git a/cg-fetch b/cg-fetch
index b004ab3..f0c11aa 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -377,7 +377,8 @@ $get -i -s -u -d "$uri/refs/tags" "$_git
for tag in *; do
[ "$tag" = "*" ] && break
tagid="$(cat "$tag")"
- GIT_DIR=../.. git-cat-file -t "$tagid" >/dev/null 2>&1 && continue
+ GIT_DIR=../.. git-rev-parse --verify "$tag"^0 2>/dev/null >> /dev/null && continue
+ GIT_DIR=../.. git-cat-file blob `git-rev-parse --verify "$tag"^{blob} 2>/dev/null` 2>/dev/null >> /dev/null && continue
echo -n "Missing object of tag $tag... "
if [ "$fetch" != "fetch_rsync" ] && GIT_DIR=../.. $fetch "$tagid" "$uri" 2>/dev/null >&2; then
echo "retrieved"
---
0.99.8.GIT
^ permalink raw reply related
* Re: How to create a new branch based on a tag?
From: Junio C Hamano @ 2005-10-21 5:08 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <4359161B.5000808@ust.hk>
Ben Lau <benlau@ust.hk> writes:
>>The way you know is as good as it gets. v2.6.11-tree case is
>>really an unfortunate special case.
>>
> What is wrong with the v2.6.11-tree? I just thought it is a duplicate tag
> of v2.6.11.
They are not *wrong* per-se. They are tags to tree objects
without any associated commit history -- that makes them
inappropriate to be used as branch heads.
Linus or somebody authoritative could do:
$ commit=$(echo v2.6.11 | \
git-commit-tree c39ae07f393806ccf406ef966e9a15afc43cc36a)
$ git-tag -s -m 'v2.6.11 canonical "fake" commit' v2.6.11fake $commit
and tell everybody interested to have:
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 xxxxxxxxxx
(where xxxxx... is the value of $commit above) in their
info/grafts file. Then we *could* pretend that v2.6.12-rc2's
parent is v2.6.11. You could branch off from v2.6.11fake commit
and base your development, and later you could merge that into
later development history (say, v2.6.14-rc5) if you wanted to.
If Linus does something like the above, the graft probably be
better done between the current v2.6.12-rc2 based commit history
and the corresponding commit in the history resurrected from
BKCVS (torvalds/old-2.6-bkcvs.git). Then you could even base
your development on top of v2.4.0 ;-).
Funnily, v2.6.12-rc2 commit in the current history and BKCVS
v2.6.12-rc2 commit in the resurrected history have different
tree IDs.
I am however not quite sure how useful the above would be,
though. EVen between 2.6.11 and 2.6.12-rc2 much have happened,
so unless the changes you are making apply to the part that did
not change between those two, merge conflict resolution might be
quite a chore.
^ 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