* [STGIT] stg refresh wish (splitting patches/removing files from a patch)
From: Peter Oberndorfer @ 2007-12-30 19:03 UTC (permalink / raw)
To: Git Mailing List
Hi,
I recently tried to split a stgit patch into 2 parts
and it was not as easy as i would like it to be.
How do i exclude a file from a patch(use version of file present in HEAD^)
without modifying the working dir?
with plain git i would use something like
git reset HEAD^ files_i_do_not_want_in_first_patch
git commit --amend
git add files_i_do_not_want_in_first_patch
git commit
So my idea was to add a --use-index [1] option to stg refresh
When it is passed stg refresh will use the current index for the contenst of the refreshed patch
instead of looking at the working dir.
This would solve my problem[2] and also make it possible to use git-gui for
staging hunks.
Do you think this would be a useful/good idea?
Or do we want a separate command for removing files from a patch anyway?
Another thing that might be useful (in my scenario) would be a stg commit --top extension
which commits at the top end of the stack
(unfortunately this will loose the patch history for splitting commits)
then i can edit this commits without being afraid of confusing stgit
and then stg assimilate /stg repair to make them managed by stg again
Greetings Peter
[1] rename by desire
[2] new way for splitting a patch with extension
git reset HEAD^ files_i_do_not_want_in_first_patch
stg refresh --use-index
stg refresh -e
git add files_i_do_not_want_in_first_patch
stg new
stg refresh --use-index
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Marco Costalba @ 2007-12-30 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzm08l9w.fsf@gitster.siamese.dyndns.org>
On Dec 30, 2007 12:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> With this patch, we actually see slight improvements in
> execution time as well.
I have applied both your patch above and what we have discussed today,
the patch to speedup prefixcmp() and mine experimental one to avoid a
lookup loop in strbuf_expand().
I don't see big differences with or without you patch applied.
Just for document the profiling I have uploaded a snapshot of
KCachegrind profiling data on a run of git-log on the git tree:
http://digilander.libero.it/mcostalba/callgrind_git_log1.png
>From there you can see that pretty.c and strbuf.c, after all the
optimizations, account for less then 8% of total time.
The biggest part is that 86.64% that is due almost entirely to zlib.
In particular
st = inflate(&stream, Z_FINISH);
called from unpack_compressed_entry() in sha1_file.c accounts for 72%
of total time.
Marco
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Marco Costalba @ 2007-12-30 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <e5bfff550712301106l133dd38btd2cc4be02159387d@mail.gmail.com>
On Dec 30, 2007 8:06 PM, Marco Costalba <mcostalba@gmail.com> wrote:
>
> In particular
>
> st = inflate(&stream, Z_FINISH);
>
> called from unpack_compressed_entry() in sha1_file.c accounts for 72%
> of total time.
>
That's the snapshot:
http://digilander.libero.it/mcostalba/callgrind_git_log2.png
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Linus Torvalds @ 2007-12-30 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzm08l9w.fsf@gitster.siamese.dyndns.org>
On Sun, 30 Dec 2007, Junio C Hamano wrote:
>
> With this patch, we actually see slight improvements in
> execution time as well. In the same partial kde repository
> (3.0GB pack, 95MB idx; the numbers are from the same machine as
> before, best of 5 runs):
Ok, I tried this a year ago, and never got any real improvement. And mine
was buggy. See
http://marc.info/?l=git&m=117537594112450&w=2
and I decided it wasn't worth it. Yours looks much better, and seems to
get a real performance improvement, so go for it, but I doubt that the
actual object lookup is really ever the main issue. I've never seen it
stand out in the real profiles, although if it is able to cut down on IO
(and your minor fault numbers are promising!), it might be more important
than I'd otherwise think.
Linus
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Junio C Hamano @ 2007-12-30 21:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.00.0712301150120.32517@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 30 Dec 2007, Junio C Hamano wrote:
>>
>> With this patch, we actually see slight improvements in
>> execution time as well. In the same partial kde repository
>> (3.0GB pack, 95MB idx; the numbers are from the same machine as
>> before, best of 5 runs):
>
> Ok, I tried this a year ago, and never got any real improvement.
Yes, I remember that one.
> and I decided it wasn't worth it. Yours looks much better, and seems to
> get a real performance improvement, so go for it, but I doubt that the
> actual object lookup is really ever the main issue. I've never seen it
> stand out in the real profiles, although if it is able to cut down on IO
> (and your minor fault numbers are promising!), it might be more important
> than I'd otherwise think.
The cost of the key comparison done in each round is
insignificant compared to the actual cost of accessing the
object data through zlib. The only potential performance
benefit that could come from this patch to reduce the average
number of rounds in the search is I/O reduction.
The only case I can think of that this may matter in real life
is accessing only small number of objects in a history with a
huge pack. Once you dig down the history deep enough to check
enough number of objects inside a single process, you would need
to touch every page of the mapped idx and the minor-fault gain
rapidly diminishes.
Accessing only small number of objects in a huge history most
often happens when building near the tip of the history
(e.g. commit, rebase, merge), but these operations tend to deal
with very young objects, often unpacked. We check pack first
and then loose objects, so the search for young loose objects
will benefit from the patch because the negative look-up to
notice that they do not live in any pack also becomes cheaper,
but I do not think it is such a big deal.
^ permalink raw reply
* Re: How to bypass the post-commit hook?
From: Jan Hudec @ 2007-12-30 21:50 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320712300712l78c1cdaeya5fa105be01f6b74@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Sun, Dec 30, 2007 at 23:12:12 +0800, Ping Yin wrote:
> --no-verify can bypass pre-commit hook? Then how to bypass post-commit hook?
>
> Usually I want post-commit take effect. However, in the middle of
> git-rebase, i want to bypass post-commit when 'git-commit --amend'
> since my post-commit hooks will modify the working directory and so
> make following rebase troubesome.
There does not seem to be an option to do it, but you can always temporarily
disable it (unset the executable permission on it).
By the way, what is your post-commit hook doing anyway? Modifying the work
tree *after* a commit does not sound like a common thing to do.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Marco Costalba @ 2007-12-30 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vodc77t0o.fsf@gitster.siamese.dyndns.org>
On Dec 30, 2007 10:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>
> The cost of the key comparison done in each round is
> insignificant compared to the actual cost of accessing the
> object data through zlib.
Sorry to ask, but just out of curiosity, what were the reasons to
choose zlib compression algorithm among the possible ones?
There is a thread where this has been discussed in the past? Sorry to
ask but I didn't find such a thread myself.
Thanks
Marco
^ permalink raw reply
* git over webdav: what can I do for improving http-push ?
From: Grégoire Barbier @ 2007-12-30 22:59 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]
Hi everybody.
I've just subscribed to the list, therefore I think it should be rude
not to introduce myself. My name is Grégoire Barbier (non
french-speaking people should call me Greg and don't bother with
non-ascii characters), I'm working mainly as a consultant (using
Powerpoint and wearing a tie) but have some personal and professional
interest in programming, especially about middlewares. BTW I apologize
for my poor english.
I'm using Git for a rather short time but enough to fall in love with
it. For a few days I'm trying to use it over webdav, that is over
http/https with write (push) access. As for me, the main rationale to
use http(s) rather than git or ssh is to get through corporate
firewalls, otherwise I would probably not bother with webdav.
With 1.5.3.6 and 1.5.4-rc2, I encounter severe issues that make me think
that http-push is not totally ready for production. That's why I would
like to have a discussion with some of you that use and maintain it, to
see what I can do to improve it or to help you improve it.
Here are some issues I encountered:
- http-push does not release locks when failing due to syntax error
(e.g. if one types "git push" instead of "git push origin master")
- http-push freezes with no message with urls not terminated by a slash
- http-push does not create directory for the object (objects/xx/) and
if the directory exists, it does not actually push objects without
having USE_CURL_MULTI defined (which is not the compilation default)
I've starting to look at the source code and make some little
improvements, but I feel that I should rather discuss with you to
understand why there are two rather independant modes in http-push
(USE_CURL_MULTI or not) and what is the real target (I don't want to
work twice, neither to mess up the work of someone else that would be
currently reorginzing this part of the code).
I attached some patches I did against 1.5.4-rc2, but I'm not sure they
are doing it the good way, so I wouldn't be suprised if you were not
okay to apply them as is.
--
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
[-- Attachment #2: 0001-Removed-double-free-int-http-push.c.patch --]
[-- Type: text/plain, Size: 903 bytes --]
>From 216f27db1f768fd80519a4e57dd835a1f497d902 Mon Sep 17 00:00:00 2001
From: Gregoire Barbier, gb at gbarbier dot org <gb@panoramix.(none)>
Date: Sun, 30 Dec 2007 17:45:54 +0100
Subject: [PATCH] Removed double-free() int http-push.c.
---
http-push.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index 64be904..55d0c94 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1979,7 +1979,6 @@ static int remote_exists(const char *path)
if (start_active_slot(slot)) {
run_active_slot(slot);
- free(url);
if (results.http_code == 404)
ret = 0;
else if (results.curl_result == CURLE_OK)
@@ -1987,7 +1986,6 @@ static int remote_exists(const char *path)
else
fprintf(stderr, "HEAD HTTP error %ld\n", results.http_code);
} else {
- free(url);
fprintf(stderr, "Unable to start HEAD request\n");
}
--
1.5.4.rc2.4.gcef60-dirty
[-- Attachment #3: 0002-Making-HTTP-push-more-robust-and-more-user-friendly.patch --]
[-- Type: text/plain, Size: 3780 bytes --]
>From 70226905d8f1dd6ed7d953285a6ee693f1e87b65 Mon Sep 17 00:00:00 2001
From: Gregoire Barbier, gb at gbarbier dot org <gb@panoramix.(none)>
Date: Sun, 30 Dec 2007 17:48:07 +0100
Subject: [PATCH] Making HTTP push more robust and more user-friendly: - fail when info/refs exists and is already locked (avoiding some repository corruption) - warn if the URL does not end with '/' (since 302 is not yet handled) - more explicit error message when the URL or password is not set correctly (instead of "no DAV locking support") - DAV locking time of 1 minute instead of 10 minutes (avoid waiting 10 minutes for a orphan lock to expire)
---
http-push.c | 17 ++++++++++++++++-
http.c | 25 +++++++++++++++++++++++++
http.h | 1 +
3 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/http-push.c b/http-push.c
index 55d0c94..c005903 100644
--- a/http-push.c
+++ b/http-push.c
@@ -57,7 +57,7 @@ enum XML_Status {
#define PROPFIND_ALL_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:allprop/>\n</D:propfind>"
#define LOCK_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:lockinfo xmlns:D=\"DAV:\">\n<D:lockscope><D:exclusive/></D:lockscope>\n<D:locktype><D:write/></D:locktype>\n<D:owner>\n<D:href>mailto:%s</D:href>\n</D:owner>\n</D:lockinfo>"
-#define LOCK_TIME 600
+#define LOCK_TIME 60
#define LOCK_REFRESH 30
/* bits #0-15 in revision.h */
@@ -2224,6 +2224,16 @@ int main(int argc, char **argv)
no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
+ /* Verify connexion string (agains bad URLs or password errors) */
+ if (remote->url && remote->url[strlen(remote->url)-1] != '/') {
+ fprintf(stderr, "Warning: remote URL does not end with a '/' which often leads to problems\n");
+ }
+ if (!http_test_connection(remote->url)) {
+ fprintf(stderr, "Error: cannot access to remote URL (maybe malformed URL, network error or bad credentials)\n");
+ rc = 1;
+ goto cleanup;
+ }
+
/* Verify DAV compliance/lock support */
if (!locking_available()) {
fprintf(stderr, "Error: no DAV locking support on remote repo %s\n", remote->url);
@@ -2239,6 +2249,11 @@ int main(int argc, char **argv)
info_ref_lock = lock_remote("info/refs", LOCK_TIME);
if (info_ref_lock)
remote->can_update_info_refs = 1;
+ else {
+ fprintf(stderr, "Error: cannot lock existing info/refs\n");
+ rc = 1;
+ goto cleanup;
+ }
}
if (remote->has_info_packs)
fetch_indices();
diff --git a/http.c b/http.c
index d2c11ae..8b04ae9 100644
--- a/http.c
+++ b/http.c
@@ -634,3 +634,28 @@ int http_fetch_ref(const char *base, const char *ref, unsigned char *sha1)
free(url);
return ret;
}
+
+int http_test_connection(const char *url)
+{
+ struct strbuf buffer = STRBUF_INIT;
+ struct active_request_slot *slot;
+ struct slot_results results;
+ int ret = 0;
+
+ 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 (results.curl_result == CURLE_OK)
+ ret = -1;
+ else
+ error("Cannot access to URL %s, return code %d", url, results.curl_result);
+ } else
+ error("Unable to start request");
+ strbuf_release(&buffer);
+ return ret;
+}
diff --git a/http.h b/http.h
index aeba930..b353007 100644
--- a/http.h
+++ b/http.h
@@ -77,6 +77,7 @@ extern void step_active_slots(void);
extern void http_init(void);
extern void http_cleanup(void);
+extern int http_test_connection(const char *url);
extern int data_received;
extern int active_requests;
--
1.5.4.rc2.4.gcef60-dirty
[-- Attachment #4: 0003-Releasing-webdav-lock-even-if-push-fails-because-of.patch --]
[-- Type: text/plain, Size: 1303 bytes --]
>From e00ae0f4b9ed0e61088fa729a7cabbfcbd006b98 Mon Sep 17 00:00:00 2001
From: Gregoire Barbier, gb at gbarbier dot org <gb@panoramix.(none)>
Date: Sun, 30 Dec 2007 19:35:31 +0100
Subject: [PATCH] Releasing webdav lock even if push fails because of bad (or no) reference on command line.
---
http-push.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/http-push.c b/http-push.c
index c005903..cbbf432 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2275,11 +2275,14 @@ int main(int argc, char **argv)
if (!remote_tail)
remote_tail = &remote_refs;
if (match_refs(local_refs, remote_refs, &remote_tail,
- nr_refspec, (const char **) refspec, push_all))
- return -1;
+ nr_refspec, (const char **) refspec, push_all)) {
+ rc = -1;
+ goto cleanup;
+ }
if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n");
- return 0;
+ rc = 0;
+ goto cleanup;
}
new_refs = 0;
@@ -2410,10 +2413,10 @@ int main(int argc, char **argv)
fprintf(stderr, "Unable to update server info\n");
}
}
- if (info_ref_lock)
- unlock_remote(info_ref_lock);
cleanup:
+ if (info_ref_lock)
+ unlock_remote(info_ref_lock);
free(remote);
curl_slist_free_all(no_pragma_header);
--
1.5.4.rc2.4.gcef60-dirty
[-- Attachment #5: 0004-Adding-define-DEFAULT_MAX_REQUESTS-for-USE_CURL_MUL.patch --]
[-- Type: text/plain, Size: 623 bytes --]
>From cef60c7940008487547894855eeed34d2edeb48e Mon Sep 17 00:00:00 2001
From: Gregoire Barbier, gb at gbarbier dot org <gb@panoramix.(none)>
Date: Sun, 30 Dec 2007 21:30:25 +0100
Subject: [PATCH] Adding #define DEFAULT_MAX_REQUESTS for USE_CURL_MULTI mode
---
http.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index 8b04ae9..7b1bcb8 100644
--- a/http.c
+++ b/http.c
@@ -4,6 +4,7 @@ int data_received;
int active_requests = 0;
#ifdef USE_CURL_MULTI
+#define DEFAULT_MAX_REQUESTS 4
static int max_requests = -1;
static CURLM *curlm;
#endif
--
1.5.4.rc2.4.gcef60-dirty
[-- Attachment #6: 0005-Moving-ifdef-endif-for-making-USE_CURL_MULTI-code.patch --]
[-- Type: text/plain, Size: 3170 bytes --]
>From b34d81c1fff43a806cb91615effd00e424bd0e6b Mon Sep 17 00:00:00 2001
From: Gregoire Barbier, gb at gbarbier dot org <gb@panoramix.(none)>
Date: Sun, 30 Dec 2007 23:40:18 +0100
Subject: [PATCH] Moving #ifdef/#endif for making USE_CURL_MULTI code more visible.
---
http-push.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
mode change 100644 => 100755 http-push.c
diff --git a/http-push.c b/http-push.c
old mode 100644
new mode 100755
index cbbf432..6dd3c45
--- a/http-push.c
+++ b/http-push.c
@@ -116,10 +116,12 @@ struct transfer_request
struct remote_lock *lock;
struct curl_slist *headers;
struct buffer buffer;
+#ifdef USE_CURL_MULTI
char filename[PATH_MAX];
char tmpfile[PATH_MAX];
int local_fileno;
FILE *local_stream;
+#endif
enum transfer_state state;
CURLcode curl_result;
char errorstr[CURL_ERROR_SIZE];
@@ -175,6 +177,7 @@ struct remote_ls_ctx
struct remote_ls_ctx *parent;
};
+#ifdef USE_CURL_MULTI
static void finish_request(struct transfer_request *request);
static void release_request(struct transfer_request *request);
@@ -186,7 +189,6 @@ static void process_response(void *callback_data)
finish_request(request);
}
-#ifdef USE_CURL_MULTI
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
void *data)
{
@@ -383,7 +385,6 @@ static void start_mkcol(struct transfer_request *request)
request->url = NULL;
}
}
-#endif
static void start_fetch_packed(struct transfer_request *request)
{
@@ -581,6 +582,7 @@ static void start_move(struct transfer_request *request)
request->url = NULL;
}
}
+#endif
static int refresh_lock(struct remote_lock *lock)
{
@@ -660,15 +662,18 @@ static void release_request(struct transfer_request *request)
entry->next = entry->next->next;
}
+#ifdef USE_CURL_MULTI
if (request->local_fileno != -1)
close(request->local_fileno);
if (request->local_stream)
fclose(request->local_stream);
+#endif
if (request->url != NULL)
free(request->url);
free(request);
}
+#ifdef USE_CURL_MULTI
static void finish_request(struct transfer_request *request)
{
struct stat st;
@@ -793,7 +798,6 @@ static void finish_request(struct transfer_request *request)
}
}
-#ifdef USE_CURL_MULTI
static int fill_active_slot(void *unused)
{
struct transfer_request *request = request_queue_head;
@@ -841,8 +845,10 @@ static void add_fetch_request(struct object *obj)
request->url = NULL;
request->lock = NULL;
request->headers = NULL;
+#ifdef USE_CURL_MULTI
request->local_fileno = -1;
request->local_stream = NULL;
+#endif
request->state = NEED_FETCH;
request->next = request_queue_head;
request_queue_head = request;
@@ -881,12 +887,13 @@ static int add_send_request(struct object *obj, struct remote_lock *lock)
request->url = NULL;
request->lock = lock;
request->headers = NULL;
+#ifdef USE_CURL_MULTI
request->local_fileno = -1;
request->local_stream = NULL;
+#endif
request->state = NEED_PUSH;
request->next = request_queue_head;
request_queue_head = request;
-
#ifdef USE_CURL_MULTI
fill_active_slots();
step_active_slots();
--
1.5.4.rc2.4.gcef60-dirty
^ permalink raw reply related
* Re: Updated Kernel Hacker's guide to git
From: Jan Engelhardt @ 2007-12-31 2:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <476E42BF.1010300@garzik.org>
On Dec 23 2007 06:13, Jeff Garzik wrote:
> Another year, another update! :)
>
> The kernel hacker's guide to git has received some updates:
>
> http://linux.yyz.us/git-howto.html
>
It says
"""Don't forget to download tags from time to time.
git pull only downloads sha1-indexed object data, and the requested
remote head. This misses updates to the .git/refs/tags/ and
.git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
But when I do git pull on a simple tracking tree (e.g. git-clone
torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Daniel Barkalow @ 2007-12-31 3:46 UTC (permalink / raw)
To: Grégoire Barbier; +Cc: git
In-Reply-To: <477822C3.9060002@gbarbier.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3227 bytes --]
On Sun, 30 Dec 2007, Grégoire Barbier wrote:
> Hi everybody.
>
> I've just subscribed to the list, therefore I think it should be rude not to
> introduce myself. My name is Grégoire Barbier (non french-speaking people
> should call me Greg and don't bother with non-ascii characters), I'm working
> mainly as a consultant (using Powerpoint and wearing a tie) but have some
> personal and professional interest in programming, especially about
> middlewares. BTW I apologize for my poor english.
>
> I'm using Git for a rather short time but enough to fall in love with it. For
> a few days I'm trying to use it over webdav, that is over http/https with
> write (push) access. As for me, the main rationale to use http(s) rather than
> git or ssh is to get through corporate firewalls, otherwise I would probably
> not bother with webdav.
In general, we've been able to either get through firewalls with ssh or
it's all in the same VPN. So it's kind of unloved at this point. People
poke at it occasionally, but mostly in the context of other fixes, I
think.
> With 1.5.3.6 and 1.5.4-rc2, I encounter severe issues that make me think that
> http-push is not totally ready for production. That's why I would like to have
> a discussion with some of you that use and maintain it, to see what I can do
> to improve it or to help you improve it.
>
> Here are some issues I encountered:
> - http-push does not release locks when failing due to syntax error (e.g. if
> one types "git push" instead of "git push origin master")
> - http-push freezes with no message with urls not terminated by a slash
> - http-push does not create directory for the object (objects/xx/) and if the
> directory exists, it does not actually push objects without having
> USE_CURL_MULTI defined (which is not the compilation default)
>
> I've starting to look at the source code and make some little improvements,
> but I feel that I should rather discuss with you to understand why there are
> two rather independant modes in http-push (USE_CURL_MULTI or not) and what is
> the real target (I don't want to work twice, neither to mess up the work of
> someone else that would be currently reorginzing this part of the code).
I think the issue is the CURL_MULTI library code is either not supported
or is broken in versions of curl that many distros still ship, but we can
do a lot better with it, so the duplicate implementation is plausibly
worthwhile.
One thing I personally thought would be worthwhile would be to separate
out the logic for sending stuff like the fetching logic is in
walker.{c,h}, and include the necessary methods in struct walker. There
were people interested in sftp (for the case where you can get ssh through
firewalls, but you aren't allowed to install programs on the file server
and git isn't installed system-wide).
One thing that's worth doing when looking at the code is using "git blame"
to find out where the lines you're changing came from, and "git log
<hash>" to find out what the person writing them was trying to do. This
will also turn up the people who've been working in the area, who you
might want to cc, since they'll be good reviewers.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: v1.5.4 plans
From: David D. Kilzer @ 2007-12-31 3:56 UTC (permalink / raw)
To: Eric Wong, Junio C Hamano; +Cc: git
In-Reply-To: <20071212184022.GB28377@untitled>
Eric Wong <normalperson@yhbt.net> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > * I've seen t9119-git-svn-info.sh fail in my k.org private repository
> > and have been skipping the test, but this needs to be diagnosed and
> > fixed [*1*]. It could be just that the code is fine and the test is
> > not rejecting SVN that is too-old. I dunno.
>
> I wouldn't mind dropping this test for now.
>
> 100% output compatibility with SVN is too difficult to achieve
> and IMHO not worth it for commands like `info' and `log'.
>
> David:
>
> I also noticed some race-conditions on this test when running this on my
> Centrino laptop (my fastest box, but I rarely use it for git
> development) and having git on my USB thumb drive. I'm pretty sure
> these were caused by inconsistencies in handling timestamps on symlinks
> vs timestamps on the files they link to.
The problem is that 'svn info' is reading the mtime from its hidden backup file
(in the .svn directory) instead of the file in the working directory, so
setting the mtime (and atime) of the git working copy file using the svn
working copy doesn't always work.
I'm working on a solution now.
Dave
^ permalink raw reply
* [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Ping Yin @ 2007-12-31 6:42 UTC (permalink / raw)
To: Git Mailing List
Following scripts can reproduce the problem: in the final line,
foo.txt is generated in bare foo.git
# create bare foo.git and its clone foo
mkdir foo
cd foo && echo foo>foo.txt &&
git init && git add . && git commit -m 'create project foo' && cd ..
cd foo && echo foo1>foo.txt && git commit -a -m "update foo.txt" && cd ..
git clone --bare foo foo.git && rm -rf foo
git clone foo.git foo
# reset bare and then push
cd foo.git && git reset --hard HEAD^ && cd ..
cd foo && git push && cd ..
ls foo.git
branches config description *foo.txt* HEAD hooks index info
objects ORIG_HEAD refs
--
Ping Yin
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Jeff King @ 2007-12-31 6:47 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320712302242m34b5267dlb3f26488293d5d51@mail.gmail.com>
On Mon, Dec 31, 2007 at 02:42:42PM +0800, Ping Yin wrote:
> Following scripts can reproduce the problem: in the final line,
> foo.txt is generated in bare foo.git
No, your script is wrong.
> # create bare foo.git and its clone foo
> mkdir foo
> cd foo && echo foo>foo.txt &&
> git init && git add . && git commit -m 'create project foo' && cd ..
> cd foo && echo foo1>foo.txt && git commit -a -m "update foo.txt" && cd ..
> git clone --bare foo foo.git && rm -rf foo
> git clone foo.git foo
>
> # reset bare and then push
> cd foo.git && git reset --hard HEAD^ && cd ..
Try looking in foo.git after this step. The "--hard" to git-reset is
creating the file foo.txt. --hard makes no sense in a bare repository (I
thought we were disallowing it, but apparently not).
-Peff
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Junio C Hamano @ 2007-12-31 6:50 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320712302242m34b5267dlb3f26488293d5d51@mail.gmail.com>
"Ping Yin" <pkufranky@gmail.com> writes:
> Following scripts can reproduce the problem: in the final line,
> foo.txt is generated in bare foo.git
> # reset bare and then push
> cd foo.git && git reset --hard HEAD^ && cd ..
"git reset" is about resetting *both* the branch tip and the
work tree. Doesn't it create unwanted work tree files when
misused this way at this point already?
> cd foo && git push && cd ..
"git push" never touches the work tree. It is possible that
there is a PEBCAK hook enabled in that bare repository that
creates random files upon receiving a push, but that is hardly
worth reporting _here_ on the list ;-).
Puzzled...
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Ping Yin @ 2007-12-31 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20071231064741.GA4250@coredump.intra.peff.net>
On Dec 31, 2007 2:47 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Dec 31, 2007 at 02:42:42PM +0800, Ping Yin wrote:
>
> > Following scripts can reproduce the problem: in the final line,
> > foo.txt is generated in bare foo.git
>
> No, your script is wrong.
>
> > # create bare foo.git and its clone foo
> > mkdir foo
> > cd foo && echo foo>foo.txt &&
> > git init && git add . && git commit -m 'create project foo' && cd ..
> > cd foo && echo foo1>foo.txt && git commit -a -m "update foo.txt" && cd ..
> > git clone --bare foo foo.git && rm -rf foo
> > git clone foo.git foo
> >
> > # reset bare and then push
> > cd foo.git && git reset --hard HEAD^ && cd ..
>
> Try looking in foo.git after this step. The "--hard" to git-reset is
> creating the file foo.txt. --hard makes no sense in a bare repository (I
> thought we were disallowing it, but apparently not).
>
Sorry for my inattention. However, i remembered the reason i added
'--hard' is to avoid the warn 'foo.txt: needs update' when 'git
reset HEAD^'. Now i know '--soft' will do the right thing.
So how about use '--soft' as default in the bare repository?
--
Ping Yin
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Jeff King @ 2007-12-31 7:07 UTC (permalink / raw)
To: Ping Yin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46dff0320712302302p4c125ee1n2abc1561ba10c47e@mail.gmail.com>
On Mon, Dec 31, 2007 at 03:02:25PM +0800, Ping Yin wrote:
> Sorry for my inattention. However, i remembered the reason i added
> '--hard' is to avoid the warn 'foo.txt: needs update' when 'git
> reset HEAD^'. Now i know '--soft' will do the right thing.
>
> So how about use '--soft' as default in the bare repository?
I started on this when I realized that --soft doesn't even work. I
remember posting a patch to make --soft work in a bare repo when
git-reset was still a script. However, Junio indicated that using "git
branch -f" is the recommended workflow. Perhaps git-reset should be
disabled in bare repos totally?
-Peff
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Jeff King @ 2007-12-31 7:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <20071231070749.GB4250@coredump.intra.peff.net>
On Mon, Dec 31, 2007 at 02:07:50AM -0500, Jeff King wrote:
> I started on this when I realized that --soft doesn't even work. I
Er, sorry, I'm somehow incompetent and failed to perform my test
correctly. --soft does work. I think the following is probably worth
doing.
-- >8 --
git-reset: refuse to do hard reset in a bare repository
It makes no sense since there is no working tree. A soft
reset should be fine, though.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-reset.c | 3 +++
t/t7103-reset-bare.sh | 28 ++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
create mode 100755 t/t7103-reset-bare.sh
diff --git a/builtin-reset.c b/builtin-reset.c
index 713c2d5..10dba60 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -244,6 +244,9 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
if (reset_type == NONE)
reset_type = MIXED; /* by default */
+ if (reset_type == HARD && is_bare_repository())
+ die("hard reset makes no sense in a bare repository");
+
/* Soft reset does not touch the index file nor the working tree
* at all, but requires them in a good order. Other resets reset
* the index file to the tree object we are switching to. */
diff --git a/t/t7103-reset-bare.sh b/t/t7103-reset-bare.sh
new file mode 100755
index 0000000..333d5ea
--- /dev/null
+++ b/t/t7103-reset-bare.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='git-reset in a bare repository'
+. ./test-lib.sh
+
+test_expect_success 'setup non-bare' '
+ echo one >file &&
+ git add file &&
+ git commit -m one
+ echo two >file &&
+ git commit -a -m two
+'
+
+test_expect_success 'setup bare' '
+ git clone --bare . bare.git &&
+ cd bare.git
+'
+
+test_expect_success 'hard reset is not allowed' '
+ ! git reset --hard HEAD^
+'
+
+test_expect_success 'soft reset is allowed' '
+ git reset --soft HEAD^ &&
+ test "`git show --pretty=format:%s | head -n 1`" = "one"
+'
+
+test_done
--
1.5.4.rc2.1101.g236e-dirty
^ permalink raw reply related
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Jeff King @ 2007-12-31 7:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <20071231071352.GC4250@coredump.intra.peff.net>
On Mon, Dec 31, 2007 at 02:13:52AM -0500, Jeff King wrote:
> +test_expect_success 'setup non-bare' '
> + echo one >file &&
> + git add file &&
> + git commit -m one
This is of course missing a && at the end.
-Peff
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Jeff King @ 2007-12-31 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <20071231071352.GC4250@coredump.intra.peff.net>
On Mon, Dec 31, 2007 at 02:13:52AM -0500, Jeff King wrote:
> git-reset: refuse to do hard reset in a bare repository
>
> It makes no sense since there is no working tree. A soft
> reset should be fine, though.
And then on top of this (plus one-liner fix I posted), as Ping Yin
suggested, we can do:
-- >8 --
git-reset: default to --soft in a bare repo
--mixed doesn't make sense, since we don't generally have an
index.
Signed-off-by: Jeff King <peff@peff.net>
---
This is a bit more contentious. There's no reason you can't have an
index in a bare repo, and this is changing the behavior of those who do.
They can always explicitly specify --mixed (since we haven't disallowed
that), but it might break some scripts.
builtin-reset.c | 2 +-
t/t7103-reset-bare.sh | 9 ++++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 10dba60..44e4eb4 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -242,7 +242,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
return read_from_tree(prefix, argv + i, sha1);
}
if (reset_type == NONE)
- reset_type = MIXED; /* by default */
+ reset_type = is_bare_repository() ? SOFT : MIXED;
if (reset_type == HARD && is_bare_repository())
die("hard reset makes no sense in a bare repository");
diff --git a/t/t7103-reset-bare.sh b/t/t7103-reset-bare.sh
index b25a77f..c2cdba4 100755
--- a/t/t7103-reset-bare.sh
+++ b/t/t7103-reset-bare.sh
@@ -7,8 +7,10 @@ test_expect_success 'setup non-bare' '
echo one >file &&
git add file &&
git commit -m one &&
+ git tag one &&
echo two >file &&
- git commit -a -m two
+ git commit -a -m two &&
+ git tag two
'
test_expect_success 'setup bare' '
@@ -25,4 +27,9 @@ test_expect_success 'soft reset is allowed' '
test "`git show --pretty=format:%s | head -n 1`" = "one"
'
+test_expect_success 'default to soft reset' '
+ git reset two &&
+ test "`git show --pretty=format:%s | head -n 1`" = "two"
+'
+
test_done
--
1.5.4.rc2.1102.g4735f-dirty
^ permalink raw reply related
* [ANNOUNCE] qgit-2.1 and qgit-1.5.8
From: Marco Costalba @ 2007-12-31 7:35 UTC (permalink / raw)
To: Git Mailing List, msysGit, Linux Kernel Development; +Cc: Pavel Roskin
Hi all,
new versions of Qt4 based qgit-2.1 and stable Qt3 based qgit-1.5.8
have been released.
Download tarballs from
http://sourceforge.net/project/showfiles.php?group_id=139897
Or directly from git repositories
git://git.kernel.org/pub/scm/qgit/qgit.git (qgit-1.5.8)
git://git.kernel.org/pub/scm/qgit/qgit4.git (qgit-2.1)
Stable qgit-1.5.8 has only maintenance fixes, not a lot indeed, it
happens to be already very stable.
New stuff is in qgit-2.1, you can find a detailed changelog at
http://git.kernel.org/?p=qgit/qgit.git;a=shortlog
After popular request, this time I have packaged qgit-2.1 in a nice
Windows installer (Inno Setup based) downloadable from the above
sourceforge link, so that our Window's friends can try qgit without
worrying about compilers, Qt libraries and other geeky things ;-)
Window installer will ask you to locate the msysgit directory. Indeed
msysgit is the only supported git distribution under Windows, because
Cygwin has some issues and is also muuuch slower.
So the only prerequisite is to have already installed msysgit
(http://code.google.com/p/msysgit/)
Happy new year 2008 !
Marco
^ permalink raw reply
* Re: How to bypass the post-commit hook?
From: Jan Hudec @ 2007-12-31 9:31 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320712302108i61f3b868obb93f89c1c24062c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
On Mon, Dec 31, 2007 at 13:08:05 +0800, Ping Yin wrote:
> On Dec 31, 2007 5:50 AM, Jan Hudec <bulb@ucw.cz> wrote:
> >
> > On Sun, Dec 30, 2007 at 23:12:12 +0800, Ping Yin wrote:
> > > --no-verify can bypass pre-commit hook? Then how to bypass post-commit hook?
> > >
> > > Usually I want post-commit take effect. However, in the middle of
> > > git-rebase, i want to bypass post-commit when 'git-commit --amend'
> > > since my post-commit hooks will modify the working directory and so
> > > make following rebase troubesome.
> >
> > There does not seem to be an option to do it, but you can always temporarily
> > disable it (unset the executable permission on it).
> >
> > By the way, what is your post-commit hook doing anyway? Modifying the work
> > tree *after* a commit does not sound like a common thing to do.
> >
> I have already considered disabling hook temporarily, but it is a
> little annoying.
Well, I guess noone thought it would be useful to disable it.
> I use post-commit because i don't find a better way to update imported
> css version automatically
>
> $ cat foo.css
> @import url(bar.css?57e708)
> ...
>
> When i modify bar.css and then commit it ( with blob sha1 bf7059)，I
> use post-commit to modify foo.css
> $ cat foo.css
> @import url(bar.css?bf7059)
> ...
But that file is not versioned, is it?
Because if it is, you want to commit it in the very same commit as bar.css
and therefore want to do it in the *pre*-commit hook. Since obviously the
foo.css wants to include the current version of bar.css, not the previous
one.
Note, that while you don't know the commit sha1 before the commit, you do
know the *blob* sha1s. So you can do this change in pre-commit hook.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: On the many files problem
From: Yannick Gingras @ 2007-12-31 10:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0712291055470.2778@woody.linux-foundation.org>
Thanks to you and to Junio for your replies,
Linus Torvalds <torvalds@linux-foundation.org> writes:
> No, no. The fastest way to store a bunch of files is to basically:
>
> - make the filenames as small as possible
>
> This improves density, and thus performance. You'll get more files to
> fit in a smaller directory, and filename compares etc will be faster
> too.
>
> If you don't need hashes, but can do with smaller names (for example,
> your names are really just sequential, and you can use some base-64
> encoding to make them smaller than numbers), you'll always be better
> off.
This is really interesting and I would not have suspected it. But it
begs the question: why does Git use the base-16 hash instead of the
base-64 hash?
After your replies I took a serious look at Git's storage and there is
indeed not that many loose objects in a typical repo: most is kept
into packs. So I guess Git doesn't need that much density and keeping
the filename in the format that is used in the UI probably helps power
users.
> - store them in a good final order. This is debatable, but depending on
> your load and the filesystem, it can be better to make sure that you
> create all files in order, because performance can plummet if you start
> removing files later.
>
> I suspect your benchmark *only* tested this case,
That is true.
> but if you want to check odder cases, try creating a huge
> directory, and then deleting most files, and then adding a few
> new ones. Some filesystems will take a huge hit because they'll
> still scan the whole directory, even though it's mostly empty!
>
> (Also, a "readdir() + stat()" loop will often get *much* worse access
> patterns if you've mixed deletions and creations)
This is something that will be interesting to benchmark later on. So,
an application with a lot of turnaround, say a mail server, should
delete and re-create the directories from time to time? I assume this
is specific to some file system types.
> - it's generally *much* more efficient to have one large file that you
> read and seek in than having many small ones, so if you can change your
> load so that you don't have tons of files at all, you'll probably be
> better off.
That makes a lot of sense.
Thanks again for those clarifications.
--
Yannick Gingras
^ permalink raw reply
* checkout --push/--pop idea (Re: What's cooking in git.git (topics))
From: Jan Hudec @ 2007-12-31 10:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vhci9u5qi.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 23, 2007 at 01:20:53 -0800, Junio C Hamano wrote:
> * ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
> - git-checkout --push/--pop
>
> A reasonably cleanly written cute hack, and I do not see this breaking
> the normal codepath. But I tend to agree with people that 'push' is
> too late for forgetful mortals, and just a single "previous" would be
> easier to use.
Shouldn't reflog of a symbolic ref contain (or also contain) the name of
pointee ref, instead of the resolved value? Than we could still get the exact
past revisions by looking at the pointee reflog by time, but could also get
the past branch names.
It would require an extension to the commitish syntax for specifying how to
resolve the pointee. Eg. HEAD^{1} would mean the previous sha1, HEAD^{1}{}
would mean the previous branch (but current value of it), and, by extension,
HEAD^{}{1} could mean previous value of currently selected branch.
Hm, the slight problem seems to be, that users would want previously checked
out branch even though commits were already done to the current one, so it is
not the previous reflog entry anymore...
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: How to bypass the post-commit hook?
From: Jan Hudec @ 2007-12-31 10:55 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320712310222m64d86e95l1499a7ffb1fff65c@mail.gmail.com>
On Mon, Dec 31, 2007 at 18:22:37 +0800, Ping Yin wrote:
> On Dec 31, 2007 5:31 PM, Jan Hudec <bulb@ucw.cz> wrote:
> > On Mon, Dec 31, 2007 at 13:08:05 +0800, Ping Yin wrote:
> > > On Dec 31, 2007 5:50 AM, Jan Hudec <bulb@ucw.cz> wrote:
> > Well, I guess noone thought it would be useful to disable it.
> >
> > > I use post-commit because i don't find a better way to update imported
> > > css version automatically
> > >
> > > $ cat foo.css
> > > @import url(bar.css?57e708)
> > > ...
> > >
> > > When i modify bar.css and then commit it ( with blob sha1 bf7059)，I
> > > use post-commit to modify foo.css
> > > $ cat foo.css
> > > @import url(bar.css?bf7059)
> > > ...
> >
> > But that file is not versioned, is it?
> >
> No, bar.css is also versioned
>
> > Because if it is, you want to commit it in the very same commit as bar.css
> > and therefore want to do it in the *pre*-commit hook. Since obviously the
> > foo.css wants to include the current version of bar.css, not the previous
> > one.
>
> If this happens, i have to commit twice (the last is amend)
Therefore the refered commit is dropped on the floor and will be eventually
expired. So using commit id of an amended commit was an error.
> > Note, that while you don't know the commit sha1 before the commit, you do
> > know the *blob* sha1s. So you can do this change in pre-commit hook.
>
> I chose post-commit because i used commit sha1 instead of blob sha1 as
> file version in the first time, and now pre-commit seems better. One
> more question, I use 'git ls-files' to fetch the blob sha1, so is the
> got sha1 the same when pre-commit and post-commit?
Yes, it should be.
Commit might be preparing the index to commit under different name than
default, but it will export GIT_INDEX_FILE environment variable to the
pre-commit hook and git commands you call will know to take the index from
there.
Note, that you can -- and should -- add the foo.css to the commit. But the
file might contain other changes in tree, that are not about to be commited,
so prefered way would be to get the content from the index, modify that and
update the index manually (with git update-index).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Stefan Richter @ 2007-12-31 11:26 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712310349260.2093@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
>> http://linux.yyz.us/git-howto.html
>
> It says
>
> """Don't forget to download tags from time to time.
>
> git pull only downloads sha1-indexed object data, and the requested
> remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>
> But when I do git pull on a simple tracking tree (e.g. git-clone
> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
A while ago the default behavior of git pull was changed to fetch all
tags which point to objects that can be reached from any of the tracked
heads.
Old behaviour: Option --tags was needed to fetch tags at all. Current
behavior: Option --tags forces to download all tags and the objects
they point to. Option --no-tags works like the old default behavior.
Readers of Kernel Hackers' Guide to git will most certainly have a
recent enough version of git so that the "download_tags" subsection can
be removed without replacement.
--
Stefan Richter
-=====-=-=== ==-- =====
http://arcgraph.de/sr/
^ 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