* Re: difftool -d symlinks, under what conditions
From: Junio C Hamano @ 2013-03-14 17:33 UTC (permalink / raw)
To: John Keeping
Cc: David Aguilar, Matt McClure, git@vger.kernel.org, Tim Henigan
In-Reply-To: <20130314172515.GB4256@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> The path passed to get_stream_filter is only used to decide what filters
> apply to the file, so shouldn't it be using "ce->name" and not "path"
> for the same reason that the call to convert_to_working_tree() further
> down the same function does?
Correct and well spotted.
>
> -- >8 --
> diff --git a/entry.c b/entry.c
> index 17a6bcc..63c52ed 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -145,7 +145,7 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
> struct stat st;
>
> if (ce_mode_s_ifmt == S_IFREG) {
> - struct stream_filter *filter = get_stream_filter(path, ce->sha1);
> + struct stream_filter *filter = get_stream_filter(ce->name, ce->sha1);
> if (filter &&
> !streaming_write_entry(ce, path, filter,
> state, to_tempfile,
^ permalink raw reply
* Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting
From: Kevin Bracey @ 2013-03-14 17:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, David Aguilar <davvid@gmail.com>l Antoine Pelisse,
Ciaran Jessup, Jeff King, Uwe Kleine-König, Scott Chacon,
Alex Riesen
In-Reply-To: <7vr4jiyqrj.fsf@alter.siamese.dyndns.org>
On 14/03/2013 16:56, Junio C Hamano wrote:
> Kevin Bracey <kevin@bracey.fi> writes:
>
>> Maybe the virtual base itself should be different. Maybe it should put
>> a ??????? marker in place of every unique line. So you get:
>>
>> Left ABCEFGH
>> Right XABCDEFJH -> Merge result <|X>ABC<|D>EF<G|J>H
>> VBase ?ABC?EF??H
>>
>> That actually feels like it may be the correct answer here.
> Interesting, though the approach has downsides with the diff3
> conflict style, no?
>
Well, yes, but I would assume that we would forcibly select normal diff
here somehow, if we aren't already. We should be - turning ABCDEFGH vs
ABCD into ABCD<EFGH|EFGH=> is silly.
This topic has a lot in common with the zdiff3 discussion going on. The
concern there is about large chunks of similar code appearing on two
sides, and not being in the base, leading to useless diff3.
This is just the special case of the base being totally empty.
The thought on zdiff3 philosophy was that common additions should be
treated as resolved, and not appear inside conflict markers. That's
exactly what we'd be doing. So, same conflict as above, but this time
embedded in a larger file, using zdiff3 logic:
Left aaaaaabaacaaABCEFGHeee
Base aaaaaaaaaaaaeee -> zdiff3
aaada<b|a=f>aacaaABC<|D>EF<G|J>Heee
Right aaadaafaaaaaABCDEFJHeee
Note that I've chosen to suppress the = marker if the lines surrounding
the conflict are not in the base. I think that helps highlight the fact
that we're in a diff2 section. EF<G|=J>H reads like an assertion that
the base has EFH. Whereas EF<G|J>H avoids that.
So, anyway, commonality with zdiff3 would be good. Even if we can't
share code, we should at least share the general style of result.
Kevin
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Junio C Hamano @ 2013-03-14 17:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <alpine.DEB.1.00.1303141756100.3794@s15462909.onlinehome-server.info>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hence my earlier suggestion (with the obvious tyop '^' instead of '~').
> You will also find the information in my mail (unless you plonk my mails)
> that ...
Our mails simply crossed. Comparing the two messages I think we are
in complete agreement.
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: difftool -d symlinks, under what conditions
From: John Keeping @ 2013-03-14 17:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Aguilar, Matt McClure, git@vger.kernel.org, Tim Henigan
In-Reply-To: <20130314094300.GN2317@serenity.lan>
On Thu, Mar 14, 2013 at 09:43:00AM +0000, John Keeping wrote:
> On Wed, Mar 13, 2013 at 09:45:47AM -0700, Junio C Hamano wrote:
> > Does the temporary checkout correctly apply the smudge filter and
> > crlf conversion, by the way? If not, regardless of the topic in
> > this thread, that may want to be fixed as well. I didn't check.
>
> What git-difftool does is to create a temporary index containing only
> the files that have changed (using git-update-index --index-info) and
> then check this out with "git checkout-index --prefix=...". So I think
> this question boils down to: does git-checkout-index still read
> .gitattributes from the working tree if given --prefix?
Having looked at this a bit more, I think it does mostly do the right
thing, but there is bug in write_entry() that means it won't handle
.gitattributes correctly when using a streaming filter.
The path passed to get_stream_filter is only used to decide what filters
apply to the file, so shouldn't it be using "ce->name" and not "path"
for the same reason that the call to convert_to_working_tree() further
down the same function does?
-- >8 --
diff --git a/entry.c b/entry.c
index 17a6bcc..63c52ed 100644
--- a/entry.c
+++ b/entry.c
@@ -145,7 +145,7 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
struct stat st;
if (ce_mode_s_ifmt == S_IFREG) {
- struct stream_filter *filter = get_stream_filter(path, ce->sha1);
+ struct stream_filter *filter = get_stream_filter(ce->name, ce->sha1);
if (filter &&
!streaming_write_entry(ce, path, filter,
state, to_tempfile,
^ permalink raw reply related
* Re: Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Johannes Schindelin @ 2013-03-14 16:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <7vy5dqx913.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Thu, 14 Mar 2013, Junio C Hamano wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
> > diff --git a/http.c b/http.c
> > index 3b312a8..528a736 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
> >
> > git_config(http_options, NULL);
> >
> > - curl_global_init(CURL_GLOBAL_ALL);
> > + curl_global_init(CURL_GLOBAL_WIN32 | (prefixcmp(url, "https:") ? 0 :
> > + CURL_GLOBAL_SSL));
>
> The first and obvious question is what the symbol with a name
> specific to one single platform doing in this generic codepath.
> In order to get convinced that the patch does not regress, one
> somehow need to know that bits in ALL other than WIN32 and SSL
> do not matter (or there is no such bit).
>
> I'd understand if it were "ALL & ~SSL" though.
Hence my earlier suggestion (with the obvious tyop '^' instead of '~').
You will also find the information in my mail (unless you plonk my mails)
that CURL_GLOBAL_ALL is defined as CURL_GLOBAL_WIN32 | CURL_GLOBAL_SSL,
and in kusma's response the suggestion to use DEFAULT & ~SSL instead.
Ciao,
Johannes
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Junio C Hamano @ 2013-03-14 16:46 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Schindelin, git, msysgit
In-Reply-To: <CABPQNSZNdGea9Nn91emWhfRGAZjZXm755UKArNr3EUy9CrSKHg@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
>> I wonder whether we want to have something like this instead:
>>
>> flags = CURL_GLOBAL_ALL;
>> if (prefixcmp(url, "https:"))
>> flags &= ^CURL_GLOBAL_SSL;
>> curl_global_init(flags);
>>
>> I do see that CURL_GLOBAL_ALL is #define'd as CURL_GLOBAL_WIN32 |
>> CURL_GLOBAL_SSL in curl.h, but that might change in the future, no?
>
> Good suggestion. But perhaps we'd want to use CURL_GLOBAL_DEFAULT
> instead?
That as a follow-up suggestion may be fine but if you go that route,
you would need to explicitly flip SSL on when you know it is going
to an SSL destination.
The way to determine SSL-ness has to be rock solid and that is much
more important than ALL vs DEFAULT. Is prefixcmp(url, "https://")
the right way to do so? Do we use this codepath only for HTTPS, or
does anybody use other protocol cURL supports over SSL with this,
too?
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Junio C Hamano @ 2013-03-14 16:04 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <1363269079-6124-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> diff --git a/http.c b/http.c
> index 3b312a8..528a736 100644
> --- a/http.c
> +++ b/http.c
> @@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
>
> git_config(http_options, NULL);
>
> - curl_global_init(CURL_GLOBAL_ALL);
> + curl_global_init(CURL_GLOBAL_WIN32 | (prefixcmp(url, "https:") ? 0 :
> + CURL_GLOBAL_SSL));
The first and obvious question is what the symbol with a name
specific to one single platform doing in this generic codepath.
In order to get convinced that the patch does not regress, one
somehow need to know that bits in ALL other than WIN32 and SSL
do not matter (or there is no such bit).
I'd understand if it were "ALL & ~SSL" though.
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* [PATCH] Make core.sharedRepository work under cygwin 1.7
From: Torsten Bögershausen @ 2013-03-14 16:01 UTC (permalink / raw)
To: git; +Cc: tboegi
When core.sharedRepository is used, set_shared_perm() in path.c
needs lstat() to return the correct POSIX permissions.
The default for cygwin is core.ignoreCygwinFSTricks = false, which
means that a simplified and fast implementation of lstat() is used.
Especially the file permission bits are wrong in cygwin_lstat_fn():
The read-only attribute of a file is used to calculate
the permissions, resulting in either rw-r--r-- or r--r--r--
Use a compile switch IGNORECYGWINFSTRICKS to disable the usage
of cygwin_lstat_fn() only in path.c
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
compat/cygwin.h | 2 ++
path.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/compat/cygwin.h b/compat/cygwin.h
index a3229f5..984efbe 100644
--- a/compat/cygwin.h
+++ b/compat/cygwin.h
@@ -5,5 +5,7 @@ typedef int (*stat_fn_t)(const char*, struct stat*);
extern stat_fn_t cygwin_stat_fn;
extern stat_fn_t cygwin_lstat_fn;
+#ifndef IGNORECYGWINFSTRICKS
#define stat(path, buf) (*cygwin_stat_fn)(path, buf)
#define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
+#endif
diff --git a/path.c b/path.c
index d3d3f8b..0acfabf 100644
--- a/path.c
+++ b/path.c
@@ -10,6 +10,8 @@
*
* which is what it's designed for.
*/
+#define IGNORECYGWINFSTRICKS
+
#include "cache.h"
#include "strbuf.h"
#include "string-list.h"
--
1.8.1.3
^ permalink raw reply related
* Re: [PATCH] Allow combined diff to ignore white-spaces
From: Antoine Pelisse @ 2013-03-14 15:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v7glayp4l.fsf@alter.siamese.dyndns.org>
On Thu, Mar 14, 2013 at 4:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> This form of 'echo' is not sufficiently portable. How about:
>>
>> tr -d Q <<-\EOF >test &&
>>
>> always coalesce
>> eol space coalesce Q
>> ...
>> EOF
>
> Much better.
>
>>> +test_expect_success 'check combined output (no ignore space)' '
>>> + git show | test_i18ngrep "^-\s*eol spaces" &&
>>> ...
>>> + git show | test_i18ngrep "^--\s*always coalesce"
>>
>> This loses the exit code of git show. We usually write this as
>>
>> git show >actual &&
>> grep "^- *eol spaces" &&
>> grep "^- *eol space coalesce" &&
>> ...
>>
>> (Same for later tests.)
>>
>> There is nothing i18n-ish in the test patterns. Use regular grep.
>>
>> BTW, there is compare_diff_patch() in diff-lib.sh. You can use it to
>> compare diff output to expected output. Then you do not need a grep
>> invocation for each line of the test file.
>
> All good suggestions. Thanks.
OK Very good,
I will resubmit tonight. I was indeed not really sure about the best
way to test here. Thanks for the tips and confirmation !
Cheers,
^ permalink raw reply
* Re: [PATCH v2] git-tag: Allow --points-at syntax to create a tag pointing to specified commit
From: Junio C Hamano @ 2013-03-14 15:48 UTC (permalink / raw)
To: Michal Novotny; +Cc: John Keeping, git
In-Reply-To: <5141E056.3090808@redhat.com>
Michal Novotny <minovotn@redhat.com> writes:
> Oh, interesting. It's working now and I didn't know that as it was not
> working some time ago I've been trying this approach. Maybe it's been
> added recently...
Pretty much from the very beginning "git tag <name> <commit>" has
been the way to create a tag, with missing <commit> defaulting to
HEAD. In retrospect, it _might_ have been a more consistent UI
organization if the object to point the new tag at were given with a
command line argument like --point-at=<object>, absence of which
defaults to HEAD, but it is a bit too late for that.
By the way, your implementation is wrong and it shows that you are
not aware that a tag, either annotated or lightweight, can point at
any object, not just a commit.
> ... as I also saw several sites having different approach of
> tagging to specified commit (usually creating a new branch, tagging
> there and rebasing etc.).
There are at least two explanations that are more plausible than
that.
When rebasing an existing branch, especially if you are not familiar
with Git and want to be extra cautious, it is not unreasonable to
practice it by running the rebase on a new branch that you are
willing to discard when something goes in an unexpected way. If the
tip of that throw-away branch happens to be where you want to tag,
it is easier to do
git checkout -b new-branch <<some long object name>>
git tag return-here
than
git checkout -b new-branch <<some long object name>>
git tag return-here <<the same long object name again>>
So it is understandable that "if untold, default to HEAD" is used in
such a workflow. After all, we made it to default to HEAD exactly
because that is one of the most common thing to do.
Another plausible explanation is that these "sites" are written by
people who do not know what they are writing, which is not a big
news in the Internet.
It would surely be nice to get these "sites" fixed.
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Erik Faye-Lund @ 2013-03-14 15:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.1303141621340.3794@s15462909.onlinehome-server.info>
On Thu, Mar 14, 2013 at 4:23 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi kusma,
>
> On Thu, 14 Mar 2013, Erik Faye-Lund wrote:
>
>> Since ancient times, we have been calling curl_global_init with the
>> CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
>> stack on Windows).
>>
>> Initializing SSL takes quite some time on Windows, so let's avoid
>> doing it when it's not needed.
>>
>> timing of echo "" | ./git-remote-http.exe origin http://localhost
>>
>> before
>>
>> best of 10 runs:
>> real 0m1.634s
>> user 0m0.015s
>> sys 0m0.000s
>>
>> worst of 10 runs:
>> real 0m2.701s
>> user 0m0.000s
>> sys 0m0.000s
>>
>> after
>>
>> best of 10 runs:
>> real 0m0.018s
>> user 0m0.000s
>> sys 0m0.000s
>>
>> worst of 10 runs:
>> real 0m0.024s
>> user 0m0.000s
>> sys 0m0.015s
>
> Good analysis!
>
>> diff --git a/http.c b/http.c
>> index 3b312a8..528a736 100644
>> --- a/http.c
>> +++ b/http.c
>> @@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
>>
>> git_config(http_options, NULL);
>>
>> - curl_global_init(CURL_GLOBAL_ALL);
>> + curl_global_init(CURL_GLOBAL_WIN32 | (prefixcmp(url, "https:") ? 0 :
>> + CURL_GLOBAL_SSL));
>>
>> http_proactive_auth = proactive_auth;
>
> I wonder whether we want to have something like this instead:
>
> flags = CURL_GLOBAL_ALL;
> if (prefixcmp(url, "https:"))
> flags &= ^CURL_GLOBAL_SSL;
> curl_global_init(flags);
>
> I do see that CURL_GLOBAL_ALL is #define'd as CURL_GLOBAL_WIN32 |
> CURL_GLOBAL_SSL in curl.h, but that might change in the future, no?
>
Good suggestion. But perhaps we'd want to use CURL_GLOBAL_DEFAULT
instead? I'm thinking that this define is probably what they'd include
any essential flags, but not non-essential flags. CURL_GLOBAL_ALL
might be extended to include initialization bits for other transports,
for instance... but this feels a bit hand-wavy. Simply masking out the
CURL_GLOBAL_SSL-flag would probably be the smallest logical change.
I don't have any strong feeling on this, really. I'd like to hear what
other people think, though.
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH] Allow combined diff to ignore white-spaces
From: Junio C Hamano @ 2013-03-14 15:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Antoine Pelisse, git
In-Reply-To: <51417773.5000401@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> This form of 'echo' is not sufficiently portable. How about:
>
> tr -d Q <<-\EOF >test &&
>
> always coalesce
> eol space coalesce Q
> ...
> EOF
Much better.
>> +test_expect_success 'check combined output (no ignore space)' '
>> + git show | test_i18ngrep "^-\s*eol spaces" &&
>> ...
>> + git show | test_i18ngrep "^--\s*always coalesce"
>
> This loses the exit code of git show. We usually write this as
>
> git show >actual &&
> grep "^- *eol spaces" &&
> grep "^- *eol space coalesce" &&
> ...
>
> (Same for later tests.)
>
> There is nothing i18n-ish in the test patterns. Use regular grep.
>
> BTW, there is compare_diff_patch() in diff-lib.sh. You can use it to
> compare diff output to expected output. Then you do not need a grep
> invocation for each line of the test file.
All good suggestions. Thanks.
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Johannes Schindelin @ 2013-03-14 15:23 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <1363269079-6124-1-git-send-email-kusmabite@gmail.com>
Hi kusma,
On Thu, 14 Mar 2013, Erik Faye-Lund wrote:
> Since ancient times, we have been calling curl_global_init with the
> CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
> stack on Windows).
>
> Initializing SSL takes quite some time on Windows, so let's avoid
> doing it when it's not needed.
>
> timing of echo "" | ./git-remote-http.exe origin http://localhost
>
> before
>
> best of 10 runs:
> real 0m1.634s
> user 0m0.015s
> sys 0m0.000s
>
> worst of 10 runs:
> real 0m2.701s
> user 0m0.000s
> sys 0m0.000s
>
> after
>
> best of 10 runs:
> real 0m0.018s
> user 0m0.000s
> sys 0m0.000s
>
> worst of 10 runs:
> real 0m0.024s
> user 0m0.000s
> sys 0m0.015s
Good analysis!
> diff --git a/http.c b/http.c
> index 3b312a8..528a736 100644
> --- a/http.c
> +++ b/http.c
> @@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
>
> git_config(http_options, NULL);
>
> - curl_global_init(CURL_GLOBAL_ALL);
> + curl_global_init(CURL_GLOBAL_WIN32 | (prefixcmp(url, "https:") ? 0 :
> + CURL_GLOBAL_SSL));
>
> http_proactive_auth = proactive_auth;
I wonder whether we want to have something like this instead:
flags = CURL_GLOBAL_ALL;
if (prefixcmp(url, "https:"))
flags &= ^CURL_GLOBAL_SSL;
curl_global_init(flags);
I do see that CURL_GLOBAL_ALL is #define'd as CURL_GLOBAL_WIN32 |
CURL_GLOBAL_SSL in curl.h, but that might change in the future, no?
Ciao,
Dscho
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH 2/2] difftool --dir-diff: symlink all files matching the working tree
From: Junio C Hamano @ 2013-03-14 15:18 UTC (permalink / raw)
To: John Keeping; +Cc: git, David Aguilar, Matt McClure, Tim Henigan
In-Reply-To: <796eafb6816b302c87873c8f4a1bd2225ce40c55.1363206651.git.john@keeping.me.uk>
John Keeping <john@keeping.me.uk> writes:
> +write_script .git/CHECK_SYMLINKS <<\EOF &&
> +#!/bin/sh
> +test -L "$2/file" &&
> +test -L "$2/file2" &&
> +test -L "$2/sub/sub"
> +echo $?
> +EOF
Please drop "#!/bin/sh" from the above; it is misleading and
pointless.
After all, you are using "write_script" to avoid having to know
where the user's shell is.
^ permalink raw reply
* Re: Tag peeling peculiarities
From: Junio C Hamano @ 2013-03-14 15:14 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git discussion list
In-Reply-To: <20130314053237.GA3552@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Mar 14, 2013 at 01:24:48AM -0400, Jeff King wrote:
>
>> So the only question is how much work we want to put into making sure
>> the new reader handles the old writer correctly. Doing 2c is obviously
>> more rigorous, and it is not that much work to add the fully-packed
>> flag, but I kind of wonder if anybody even cares. We can just say "it's
>> a bug fix; run `git pack-refs` again if you care" and call it a day
>> (i.e., 1b).
>
> Urgh, for some reason I kept writing "fully-packed" but obviously I
> meant "fully-peeled". Hopefully you figured it out.
>
> Just as a quick sketch of how much work is in involved in 2c, I think
> the complete solution would look like this (but note I haven't tested
> this at all):
Looks reasonable from a cursory look, and I think we cannot avoid
going with the route to add "fully-peeled" token, because we do have
to express "we know this ref outside refs/tags/ area is not an
annotated tag" by marking them as REF_KNOWS_PEELED for the peel_ref()
optimization to work.
> diff --git a/pack-refs.c b/pack-refs.c
> index f09a054..261a6a6 100644
> --- a/pack-refs.c
> +++ b/pack-refs.c
> @@ -27,6 +27,7 @@ static int handle_one_ref(const char *path, const unsigned char *sha1,
> int flags, void *cb_data)
> {
> struct pack_refs_cb_data *cb = cb_data;
> + struct object *o;
> int is_tag_ref;
>
> /* Do not pack the symbolic refs */
> @@ -39,14 +40,12 @@ static int handle_one_ref(const char *path, const unsigned char *sha1,
> return 0;
>
> fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
> - if (is_tag_ref) {
> - struct object *o = parse_object(sha1);
> - if (o->type == OBJ_TAG) {
> - o = deref_tag(o, path, 0);
> - if (o)
> - fprintf(cb->refs_file, "^%s\n",
> - sha1_to_hex(o->sha1));
> - }
> + o = parse_object(sha1);
> + if (o->type == OBJ_TAG) {
> + o = deref_tag(o, path, 0);
> + if (o)
> + fprintf(cb->refs_file, "^%s\n",
> + sha1_to_hex(o->sha1));
> }
>
> if ((cb->flags & PACK_REFS_PRUNE) && !do_not_prune(flags)) {
> @@ -128,7 +127,7 @@ int pack_refs(unsigned int flags)
> die_errno("unable to create ref-pack file structure");
>
> /* perhaps other traits later as well */
> - fprintf(cbdata.refs_file, "# pack-refs with: peeled \n");
> + fprintf(cbdata.refs_file, "# pack-refs with: peeled fully-peeled \n");
>
> for_each_ref(handle_one_ref, &cbdata);
> if (ferror(cbdata.refs_file))
> diff --git a/refs.c b/refs.c
> index 175b9fc..770abf4 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -808,6 +808,7 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
> struct ref_entry *last = NULL;
> char refline[PATH_MAX];
> int flag = REF_ISPACKED;
> + int fully_peeled = 0;
>
> while (fgets(refline, sizeof(refline), f)) {
> unsigned char sha1[20];
> @@ -818,13 +819,18 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
> const char *traits = refline + sizeof(header) - 1;
> if (strstr(traits, " peeled "))
> flag |= REF_KNOWS_PEELED;
> + if (strstr(traits, " fully-peeled "))
> + fully_peeled = 1;
> /* perhaps other traits later as well */
> continue;
> }
>
> refname = parse_ref_line(refline, sha1);
> if (refname) {
> - last = create_ref_entry(refname, sha1, flag, 1);
> + int this_flag = flag;
> + if (!fully_peeled && prefixcmp(refname, "refs/tags/"))
> + this_flag &= ~REF_KNOWS_PEELED;
> + last = create_ref_entry(refname, sha1, this_flag, 1);
> add_ref(dir, last);
> continue;
> }
>
> So it's really not that much code. The bigger question is whether we
> want to have to carry the "fully-peeled" tag forever, and how other
> implementations would treat it.
>
> -Peff
^ permalink raw reply
* Re: [PATCH] status: hint the user about -uno if read_directory takes too long
From: Junio C Hamano @ 2013-03-14 15:05 UTC (permalink / raw)
To: Duy Nguyen; +Cc: tboegi, git, artagnon, robert.allan.zeh, finnag
In-Reply-To: <CACsJy8BixM-9bPB3G_WO+W3cTHBFxLQ=YCU2NDEzHmCYW73ZPQ@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Wed, Mar 13, 2013 at 10:21 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>> + statusUno::
>>> + If collecting untracked files in linkgit:git-status[1]
>>> + takes more than 2 seconds, hint the user that the option
>>> + `-uno` could be used to stop collecting untracked files.
>> Thanks, I like the idea
>> could we make a "de-Luxe" version where
>>
>> statusUno is an integer, counting in milliseconds?
>
> No problem.
A huge problem, as it breaks consistency and more importantly, the
suggestion misses the entire point of what "advice.*" variables are.
"advise.*" variables are bools that indicate "Have I learned this
somewhat tricky feature and/or characteristics of Git yet or do I
still need a reminder?" There is no room for "I still need a
reminder if it takes more than N seconds". You either already have
got it, or you haven't.
>> "to speed up by stopping displaying untracked files" does not look
>> like giving a balanced suggestion. It is increasing the risk of
>> forgetting about newly created files the user may want to add, but
>> the risk is not properly warned.
>
> How about "It took X ms to collect untracked files.\nCheck out the
> option -u for a potential speedup"? I deliberately hide "no" so that
> the user cannot blindly type and run it without reading document
> first. We can give full explanation and warning there in the document.
But it makes the advise much less useful to introduce more levels of
indirections, no?
^ permalink raw reply
* Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting
From: Junio C Hamano @ 2013-03-14 14:56 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git, David Aguilar, Ciaran Jessup, Scott Chacon, Alex Riesen
In-Reply-To: <51416DD5.2030805@bracey.fi>
Kevin Bracey <kevin@bracey.fi> writes:
> I disagree here. At the minute, it does set ret to 1 (but further down
> the code - bringing it up here next to the "ERROR" print clarifies
> that), and will report the merge as failed, conflict in the 3-way
> merge or not. Which I think is correct.
OK. I agree that forcing users to always inspect the result of
"both side added" resolution sounds like a good safety measure.
> Maybe the virtual base itself should be different. Maybe it should put
> a ??????? marker in place of every unique line. So you get:
>
> Left ABCEFGH
> Right XABCDEFJH -> Merge result <|X>ABC<|D>EF<G|J>H
> VBase ?ABC?EF??H
>
> That actually feels like it may be the correct answer here.
Interesting, though the approach has downsides with the diff3
conflict style, no?
^ permalink raw reply
* Re: [ANN] git-arr 0.11
From: Nazri Ramliy @ 2013-03-14 14:42 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Alberto Bertogli, git
In-Reply-To: <vpqppz22luj.fsf@grenoble-inp.fr>
On Thu, Mar 14, 2013 at 8:43 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Can it run incrementally? I mean, if you have launched it for one
> revision, does re-running it on the next revision regenerate the whole
> set of pages, or does it only generate new pages?
>From the readme (http://blitiri.com.ar/git/r/git-arr/b/master/t/f=README.html):
The first time you generate, depending on the size of your repositories, it
can take some time. Subsequent runs should take less time, as it is smart
enough to only generate what has changed.
Seems like it does!
Nazri
^ permalink raw reply
* Re: [PATCH v2] git-tag: Allow --points-at syntax to create a tag pointing to specified commit
From: Michal Novotny @ 2013-03-14 14:36 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130314133629.GA4256@serenity.lan>
On 03/14/2013 02:36 PM, John Keeping wrote:
> On Thu, Mar 14, 2013 at 01:34:54PM +0100, Michal Novotny wrote:
>> This patch adds the option to specify SHA-1 commit hash using --points-at
>> option of git tag to create a tag pointing to a historical commit.
> What does this do that "git tag <name> <commit>" doesn't?
Oh, interesting. It's working now and I didn't know that as it was not
working some time ago I've been trying this approach. Maybe it's been
added recently as I also saw several sites having different approach of
tagging to specified commit (usually creating a new branch, tagging
there and rebasing etc.).
Thanks for information!
Michal
--
Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Erik Faye-Lund @ 2013-03-14 13:56 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <1363269079-6124-1-git-send-email-kusmabite@gmail.com>
On Thu, Mar 14, 2013 at 2:51 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> Since ancient times, we have been calling curl_global_init with the
> CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
> stack on Windows).
>
> Initializing SSL takes quite some time on Windows, so let's avoid
> doing it when it's not needed.
>
> timing of echo "" | ./git-remote-http.exe origin http://localhost
>
> before
>
> best of 10 runs:
> real 0m1.634s
> user 0m0.015s
> sys 0m0.000s
>
> worst of 10 runs:
> real 0m2.701s
> user 0m0.000s
> sys 0m0.000s
>
> after
>
> best of 10 runs:
> real 0m0.018s
> user 0m0.000s
> sys 0m0.000s
>
> worst of 10 runs:
> real 0m0.024s
> user 0m0.000s
> sys 0m0.015s
>
> Signed-off-by: Erik Faye-Lund <erik.faye-lund@hue.no>
Sorry, that sign-off has my wrong e-mail address. Please replace it with this:
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* [PATCH/RFC] http_init: only initialize SSL for https
From: Erik Faye-Lund @ 2013-03-14 13:51 UTC (permalink / raw)
To: git; +Cc: msysgit
Since ancient times, we have been calling curl_global_init with the
CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
stack on Windows).
Initializing SSL takes quite some time on Windows, so let's avoid
doing it when it's not needed.
timing of echo "" | ./git-remote-http.exe origin http://localhost
before
best of 10 runs:
real 0m1.634s
user 0m0.015s
sys 0m0.000s
worst of 10 runs:
real 0m2.701s
user 0m0.000s
sys 0m0.000s
after
best of 10 runs:
real 0m0.018s
user 0m0.000s
sys 0m0.000s
worst of 10 runs:
real 0m0.024s
user 0m0.000s
sys 0m0.015s
Signed-off-by: Erik Faye-Lund <erik.faye-lund@hue.no>
---
http.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/http.c b/http.c
index 3b312a8..528a736 100644
--- a/http.c
+++ b/http.c
@@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
git_config(http_options, NULL);
- curl_global_init(CURL_GLOBAL_ALL);
+ curl_global_init(CURL_GLOBAL_WIN32 | (prefixcmp(url, "https:") ? 0 :
+ CURL_GLOBAL_SSL));
http_proactive_auth = proactive_auth;
--
1.8.0.msysgit.0.3.gd0186ec
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply related
* Re: Tag peeling peculiarities
From: Jeff King @ 2013-03-14 13:40 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git discussion list
In-Reply-To: <5141B475.1000707@alum.mit.edu>
On Thu, Mar 14, 2013 at 12:28:53PM +0100, Michael Haggerty wrote:
> Perhaps if peel_ref() *were* 100% reliable, we might be able to use it
> to avoid object lookups in some other places.
In theory, some of the many uses of deref_tag could be adopted. However,
we do not always have the refname handy at that point (and I believe
peel_ref's optimization only kicks in during for_each_ref traversals
anyway).
It may still be a win to check the packed-refs file before peeling a
random sha1, as looking up there should be cheaper than actually loading
the object. But right now, the way the optimization is used is always
O(1) to just check the last ref loaded. With your recent ref
refactoring, I think we should be able to do lookups in O(lg n).
> > Another fun fact: upload-pack did not use peel_ref until recently
> > (435c833, in v1.8.1). So while it is tempting to say "well, this was
> > always broken, and nobody cared", it was not really; it is a fairly
> > recent regression in 435c833.
>
> I didn't realize that; thanks for pointing it out. Although peel_ref()
> itself has been broken since it was introduced, at least in the sense
> that it gives wrong answers for tags outside of refs/tags, prior to
> 435c833 it appears to only have been used for refs/tags.
Hmph. I coincidentally ran across another problem with 435c833 today.
Try this:
git init repo &&
cd repo &&
git commit --allow-empty -m one &&
git checkout -b other &&
git commit --allow-empty -m two &&
git checkout master &&
git commit --allow-empty -m three &&
git pack-refs --all &&
git.compile clone --no-local --depth=1 --no-single-branch . foo
I get:
Cloning into 'foo'...
fatal: (null) is unknown object
remote: Total 0 (delta 0), reused 0 (delta 0)
fatal: recursion detected in die handler
remote: aborting due to possible repository corruption on the remote side.
fatal: error in sideband demultiplexer
This is not due to the same problem you are describing with peel_refs,
but simply due to the fact that we do not load and parse objects anymore
(which is the point of the optimization). The client feeds these back to
us in the "want" list, and we then feed these objects to the revision
walker, which expects them to be parsed and have their "type" field
actually filled in.
We never noticed before because:
1. It only happens with --depth, because otherwise we do not do the
revision walk in-process.
2. Modern git, when given --depth, will default to --single-branch,
and so ask only about HEAD, which we do parse. However, older
versions of git (pre v1.7.10) will ask for much more, and trigger
the bug.
I haven't tried yet, but I suspect you may also be able to trigger
it by asking for "clone --depth=1 -b other".
That's the overtly visible symptom. We also check the type in
ok_to_give_up, so I suspect that can produce subtly wrong results in
some situations. The solution is to actually parse the objects in
question, but I need to figure out when is the optimal time. Obviously
any time we read a "want" line would be enough, but we may be able to
get by with less. OTOH, it probably doesn't matter that much; the point
of the optimization was to avoid touching objects for the ref
advertisement. Once we have a "want", the client really is going to
fetch objects, and accessing them will probably be lost in the noise.
But that's somewhat off-topic for this discussion. I'll look into it
further and try to make a patch later today or tomorrow.
> Your patch looks about right aside from its lack of comments :-). I was
> going to implement approximately the same thing in a patch series that I
> am working on, but if you prefer then go ahead and submit your patch and
> I will rebase my branch on top of it.
I just meant it as a quick sketch, since you said you were working in
the area. I'm not sure what you are working on. If we don't consider it
an urgent bugfix, I'm just as happy for you to incorporate the idea into
what you are doing.
But if we want to do it as a maint-track fix, I can clean up my patch.
Junio?
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-tag: Allow --points-at syntax to create a tag pointing to specified commit
From: John Keeping @ 2013-03-14 13:36 UTC (permalink / raw)
To: Michal Novotny; +Cc: git
In-Reply-To: <4150f65f3e425d6120ed80c6bec36c1fe209a876.1363264398.git.minovotn@redhat.com>
On Thu, Mar 14, 2013 at 01:34:54PM +0100, Michal Novotny wrote:
> This patch adds the option to specify SHA-1 commit hash using --points-at
> option of git tag to create a tag pointing to a historical commit.
What does this do that "git tag <name> <commit>" doesn't?
> This was pretty easy in the past for the lightweight tags that are just simple
> pointers (by creating .git/refs/tags/$tagname with SHA-1 hash) but it was not
> possible for signed and annotated commits.
>
> It's been tested for all of the tag types mentioned - lightweight tags, signed
> tags and also annotated tags and everything is working fine in all scenarios
> mentioned above.
>
> Differences between v1 and v2 (this one):
> - The bogus sha1-lookup.h hunk has been removed as it's not required and
> I accidentally forgot to remove it before posting v1
>
> Michal
>
> Signed-off-by: Michal Novotny <minovotn@redhat.com>
> ---
> builtin/tag.c | 32 ++++++++++++++++++++++++++------
> 1 file changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index f826688..f642acd 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -437,7 +437,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
> struct create_tag_options opt;
> char *cleanup_arg = NULL;
> int annotate = 0, force = 0, lines = -1, list = 0,
> - delete = 0, verify = 0;
> + delete = 0, verify = 0, points_at_commit = 0;
> const char *msgfile = NULL, *keyid = NULL;
> struct msg_arg msg = { 0, STRBUF_INIT };
> struct commit_list *with_commit = NULL;
> @@ -521,8 +521,24 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
> die(_("-n option is only allowed with -l."));
> if (with_commit)
> die(_("--contains option is only allowed with -l."));
> - if (points_at.nr)
> - die(_("--points-at option is only allowed with -l."));
> + if (points_at.nr) {
> + if (points_at.nr > 1)
> + die(_("--points-at option is only allowed with -l or a single "
> + "SHA-1 hash is allowed to create a tag to commit."));
> + else {
> + unsigned char *ref = points_at.sha1[0];
> +
> + struct object *obj = parse_object(ref);
> + if ((obj != NULL) && (obj->type == OBJ_COMMIT)) {
> + memcpy(object, ref, 20);
> + points_at_commit = 1;
> + }
> + else
> + die(_("--points-at option points to an invalid commit"));
> +
> + free(ref);
> + }
> + }
> if (delete)
> return for_each_tag_name(argv, delete_tag);
> if (verify)
> @@ -548,12 +564,16 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
>
> tag = argv[0];
>
> - object_ref = argc == 2 ? argv[1] : "HEAD";
> if (argc > 2)
> die(_("too many params"));
>
> - if (get_sha1(object_ref, object))
> - die(_("Failed to resolve '%s' as a valid ref."), object_ref);
> + /* Option --points-at option is setting this already */
> + if (!points_at_commit) {
> + object_ref = argc == 2 ? argv[1] : "HEAD";
> +
> + if (get_sha1(object_ref, object))
> + die(_("Failed to resolve '%s' as a valid ref."), object_ref);
> + }
>
> if (strbuf_check_tag_ref(&ref, tag))
> die(_("'%s' is not a valid tag name."), tag);
> --
> 1.7.11.7
^ permalink raw reply
* Re: [PATCH v3 00/13] Exclude optimizations
From: Duy Nguyen @ 2013-03-14 13:05 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1363093500-16796-1-git-send-email-pclouds@gmail.com>
Just thinking out loud. If I'm not mistaken, a directory's mtime is
only changed when files are added are removed in that directory. And
that's all we care about in read_directory. So if we keep a secondary
index containing the list of all (tracked and untracked) .gitignore
files and all untracked files (regardless ignore status), we could
avoid reading a directory if:
- all relevant .gitignore are unchanged
- the directory's stat is unchanged
In that case we already have the list of untracked files. Exclude can
be run over to filter out ignored files. And because we know these are
not tracked, we do not need to call index_name_exists (not if
ignore_case == 0).
In the best case, nothing's added or removed, read_directory just
issues a bunch of lstat (like index refresh), filter out ignored files
and _not_ trigger (nor pay penalty for) lazy_init_name_hash. webkit
has 11k untracked files. I don't think we have problems storing that
list as we already have to chew 182k entries in index.
Did I make any mistakes above?
--
Duy
^ permalink raw reply
* Re: [ANN] git-arr 0.11
From: Matthieu Moy @ 2013-03-14 12:43 UTC (permalink / raw)
To: Alberto Bertogli; +Cc: git
In-Reply-To: <20130313234143.GD14686@blitiri.com.ar>
Alberto Bertogli <albertito@blitiri.com.ar> writes:
> I wanted to let you know about git-arr, which is a git repository
> browser that can generate static HTML instead of having to run
> dynamically.
Can it run incrementally? I mean, if you have launched it for one
revision, does re-running it on the next revision regenerate the whole
set of pages, or does it only generate new pages?
If so, that could be a nice way to replace dynamic browsers for people
who do not have/want dynamic webpages, by just setting a hook or cron
job that generate the new pages when an update is made.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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