On Fri, Jul 12, 2013 at 2:18 AM, Junio C Hamano wrote:
> A command that has to deal with input/output that may contain LF
> needs to offer the "-z" (--nul-terminated-records) option, and if it
> does not support separate --nul-terminated-{input,output} options,
> the "-z" option should govern both
On Fri, Jul 12, 2013 at 2:34 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> ... Is it desirable to do so
>> or should the user have more fine-grained control? ("xargs -0" comes
>> to mind when thinking of a null-termination input switch.)
>
> For the purposes of check-attr and check-ignor
We take in a "struct object_info" which contains pointers to
storage for items the caller cares about. But then rather
than pass the whole object to the low-level loose/packed
helper functions, we pass the individual pointers.
Let's pass the whole struct instead, which will make adding
more items
Each caller of sha1_object_info_extended sets up an
object_info struct to tell the function which elements of
the object it wants to get. Until now, getting the type of
the object has always been required (and it is returned via
the return type rather than a pointer in object_info).
This can invol
Eric Sunshine writes:
>> I find it easier than your original, but I do not know if you would
>> want to repeat the "Name... or " at the end. It does not
>> seem to add much useful information and is distracting.
>
> Next attempt:
>
> For each ``Name '' or ``'' from the
> command-
To calculate the type of a packed object, we must walk down
its delta chain until we hit a true base object with a real
type. Most of the code in packed_object_info is for handling
this case.
Let's hoist it out into a separate helper function, which
will make it easier to make the type-lookup opti
Currently, packed_object_info can save some work by not
calculating the size or disk_size of the object if the
caller is not interested. However, it always calculates the
true object type, whether the caller cares or not, and only
optionally returns the easy-to-get "representation type".
Let's swa
Until recently, the only items to request from
sha1_object_info_extended were type and size. This meant
that we always had to open a loose object file to determine
one or the other. But with the addition of the disk_size
query, it's possible that we can fulfill the query without
even opening the o
Eric Sunshine writes:
> On Fri, Jul 12, 2013 at 1:48 AM, Junio C Hamano wrote:
>> Jonathan Nieder writes:
>>
>>> My current thinking is "no" --- the patch has as a justification "Now
>>> we can test these aspects of .mailmap handling directly with a
>>> low-level tool instead of using the tool
On Fri, Jul 12, 2013 at 1:47 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> For each contact information (either in the form of ``Name
>>> '' or ...)
>>>
>>> in order to clarify that the two forms of input is what you call
>>> "contact information".
>>
>> Is this easier t
The value we get from each low-level object_info function
(e.g., loose, packed) is actually the object type (or -1 for
error). Let's explicitly call it "type", which will make
further refactorings easier to read.
Signed-off-by: Jeff King
---
sha1_file.c | 20 ++--
1 file changed,
A common use of "cat-file --batch-check" is to feed a list
of objects from "rev-list --objects" or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately
Unless a command has separate --nul-terminated-{input,output}
options, the --nul-terminated-records (-z) option should apply
to both input and output for consistency. The caller knows that its
input paths may need to be protected for LF, and the program shows
these problematic paths to its output.
A command that has to deal with input/output that may contain LF
needs to offer the "-z" (--nul-terminated-records) option, and if it
does not support separate --nul-terminated-{input,output} options,
the "-z" option should govern both input and output. A caller that
uses "-z" knows that the paths
Unless a command has separate --nul-terminated-{input,output}
options, the --nul-terminated-records (-z) option should apply
to both input and output for consistency. The caller knows that its
input paths may need to be protected for LF, and the program shows
these problematic paths to its output.
Signed-off-by: Junio C Hamano
---
builtin/check-attr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 075d01d..7cc9b5d 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -13,14 +13,14 @@ N_("git check-attr
Signed-off-by: Junio C Hamano
---
builtin/check-ignore.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 0240f99..be22bce 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -12,7 +12,7 @@ stati
In my earlier series introducing "git cat-file --batch-check=",
found here:
http://thread.gmane.org/gmane.comp.version-control.git/229761/focus=230041
I spent a little time optimizing revindex generation, and measured by
requesting information on a single object from a large repository. This
se
On Fri, Jul 12, 2013 at 1:48 AM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> My current thinking is "no" --- the patch has as a justification "Now
>> we can test these aspects of .mailmap handling directly with a
>> low-level tool instead of using the tool most people will use, so do
>>
Nguyễn Thái Ngọc Duy writes:
> + number of limitations (you cannot clone or fetch from it, nor
> + push into it), but is adequate if you are only interested in
> + the recent history of a large project with a long history.
Ahh, sorry for the noise. You still say you cannot push _in
Nguyễn Thái Ngọc Duy writes:
> The document says one cannot push from a shallow clone. But that is
> not true (maybe it was at some point in the past). The client does not
> stop such a push nor does it give any indication to the receiver that
> this is a shallow push. If the receiver accepts it
Jonathan Nieder writes:
> My current thinking is "no" --- the patch has as a justification "Now
> we can test these aspects of .mailmap handling directly with a
> low-level tool instead of using the tool most people will use, so do
> so", which sounds an awful lot like "Reduce test coverage of co
Eric Sunshine writes:
>> For each contact information (either in the form of ``Name
>> '' or ...)
>>
>> in order to clarify that the two forms of input is what you call
>> "contact information".
>
> Is this easier to read?
>
> For each ``Name '' or ``'' from the
>
The document says one cannot push from a shallow clone. But that is
not true (maybe it was at some point in the past). The client does not
stop such a push nor does it give any indication to the receiver that
this is a shallow push. If the receiver accepts it, it's in.
Since 52fed6e (receive-pack:
On Thu, Jul 11, 2013 at 3:04 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> +DESCRIPTION
>> +---
>> +
>> +For each ``Name '' or ``'' provided on
>> +the command-line or standard input (when using `--stdin`), prints a line
>> with
>> +the canonical contact information for
On Thu, Jul 11, 2013 at 8:55 PM, Jonathan Nieder wrote:
> Eric Sunshine wrote:
>> On Thu, Jul 11, 2013 at 3:07 PM, Junio C Hamano wrote:
>>> Eric Sunshine writes:
>
With the introduction of check-mailmap, it is now possible to check
.mailmap functionality directly rather than indirectl
Eric Sunshine wrote:
> On Thu, Jul 11, 2013 at 3:07 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>> With the introduction of check-mailmap, it is now possible to check
>>> .mailmap functionality directly rather than indirectly as a side-effect
>>> of other commands (such as git-shortlog),
On Thu, Jul 11, 2013 at 3:07 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> With the introduction of check-mailmap, it is now possible to check
>> .mailmap functionality directly rather than indirectly as a side-effect
>> of other commands (such as git-shortlog), therefore, do so.
>
> Doe
On 12 July 2013 09:43, Stephen & Linda Smith wrote:
> I'm working on a project that used to use a proprietary CM system (aka
> oldCM). At a point in time, the state of the code was frozen and used as
> the basis for commits in SVN.
>
> What I would like to to do is take the individal commits f
I'm working on a project that used to use a proprietary CM system (aka oldCM).
At a point in time, the state of the code was frozen and used as the basis for
commits in SVN.
What I would like to to do is take the individal commits from the oldCM and
place them into git knowing that the time/d
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Thanks.
The differences since the last round I see are these. And I think
the series overall makes sense (I haven't look hard enough to pick
any nits yet, though).
Thanks, will queue.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 9ae2508..f0e179e 100644
--- a/Do
"Kyle J. McKay" writes:
> +static size_t http_option_max_matched_len[opt_max];
> +
> static int curl_ssl_verify = -1;
> static int curl_ssl_try;
> static const char *ssl_cert;
> @@ -141,34 +169,122 @@ static void process_curl_messages(void)
> }
> #endif
>
> +static size_t http_options_url_
Matthijs Kooijman writes:
[administrivia: you seem to have mail-followup-to that points at you
and the list; is that really needed???]
> This happens when a client issues a fetch with a depth bigger or equal
> to the number of commits the server is ahead of the client.
Do you mean "smaller" (no
If a config parsing error in a file occurs we can die and let the user
fix the issue. This is different for the buf parsing function since it
can be used to parse blobs of .gitmodules files. If a parsing error
occurs here we should proceed since otherwise a database containing such
an error in a si
This can be used to read configuration values directly from git's
database. For example it is useful for reading to be checked out
.gitmodules files directly from the database.
Signed-off-by: Heiko Voigt
---
Documentation/git-config.txt | 7
builtin/config.c | 31 +-
To simplify adding other sources we extract all functions needed for
parsing into a list of callbacks. We implement those callbacks for the
current file parsing. A new source can implement its own set of callbacks.
Instead of storing the concrete FILE pointer for parsing we store a void
pointer. A
The global variable cf is set with an initialized value in all codepaths before
calling this function.
The complete call graph looks like this:
git_config_from_file
-> do_config_from
-> git_parse_file
-> get_next_char
-> get_value
-> get_next_char
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that stack from
git_config_from_file. Let's factor it out to allow new
sources of config data.
Signed-off-by: Heiko Voigt
---
config
Hi,
I finally got around rerolling this series.
The fourth iteration can be found here[1]. You can also find these patches as a
branch on my github[2].
There is not many changes since the last iteration. I have added some
documentation for the --blob option and now there is no rename of the
do_c
This plugs the push_cas_option data collected by the command line
option parser to the transport system with a new function
apply_push_cas(), which is called after match_push_refs() has
already been called.
At this point, we know which remote we are talking to, and what
remote refs we are going to
The command line parser of "git push" for "--tags", "--delete", and
"--thin" options still used outdated OPT_BOOLEAN. Because these
options do not give escalating levels when given multiple times,
they should use OPT_BOOL.
Signed-off-by: Junio C Hamano
---
builtin/push.c | 6 +++---
1 file chan
Update "git push" and "git send-pack" to parse this commnd line
option.
The intended sematics is:
* "--lockref" alone, without specifying the details, will protect
_all_ remote refs that are going to be updated by requiring their
current value to be the same as the remote-tracking branch w
So here is a reroll to make "--lockref" a weaker form of "--force"
that by itself makes "git push" bypass the usual "must fast-forward"
check but enforces a different check "the old ref must be at X"
instead, taking ideas from J6t. This allows "--force" to be again
the big red button to bypass all
Prepare two repositories, src and dst, the latter of which is a
clone of the former (with tracking branches), and push from the
latter into the former, using --lockref=name (using tracking ref for
"name" when updating "name"), --lockref=name:value, --lockref=name:
(i.e. check creation), and --lockr
The definition of "struct ref" in "cache.h", a header file so
central to the system, always confused me. This structure is not
about the local ref used by sha1-name API to name local objects.
It is what refspecs are expanded into, after finding out what refs
the other side has, to define what ref
This teaches the deepest part of the callchain for "git push" (and
"git send-pack") to enforce "the old value of the ref must be this,
otherwise fail this push" (aka "compare-and-swap" / "--lockref").
Signed-off-by: Junio C Hamano
---
builtin/send-pack.c | 5 +
remote.c| 49
Johannes Sixt writes:
> Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
[remote "ko"]
url = kernel.org:/pub/scm/git/git.git
push = maste
Hi folks,
while playing with shallow fetches, I've found that in some
circumstances running git fetch with --depth can return too many objects
(in particular, _all_ the objects for the requested revisions are
returned, even when some of those objects are already known to the
client).
This happens
Johannes Sixt writes:
>> Or perhaps you were implicitly assuming that "--lockref" would
>> automatically mean "I know I am rewinding, so as soon as I say
>> --lockref, I mean --allow-no-ff", and I did not realize that.
>
> That's what I mean, sort of. Because of your 4 cases of a ref update, I
>
The value is considered a match to a url if the value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So "https://example.com/test"; will
match "https://example.com/test"; and "https://example.com/test/too";
but not "https://example.com/testextra";.
On Jul 11, 2013, at 12:26, Junio C Hamano wrote:
"Kyle J. McKay" writes:
+static int http_option_maxlen[opt_max];
I understand that this is to keep track of the length of the longest
one that has matched (hence the current candidate). The name "maxlen"
captures the "longest" part, but "has
On Thu, Jul 11, 2013 at 5:16 AM, Jeff King wrote:
> Here's an update of the radix-sort patch. It fixes the "unsigned" issue
> Brandon pointed out, along with a few other comment/naming/style fixes.
> I also updated the commit message with more explanation of the
> timings.
Very nice.
For
Am 10.07.2013 01:08, schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> I _think_ I am OK if we introduced "--allow-no-ff" that means the
>> current "--force" (i.e. "rewinding is OK"), that does not defeat the
>> "--lockref" safety. That is the intended application (you know that
>> push does
On Thu, Jul 11, 2013 at 07:36:53AM -0400, Jeff King wrote:
> On Wed, Jul 10, 2013 at 08:59:51PM +0530, Ramkumar Ramachandra wrote:
>
> > Jeff King wrote:
> > > git rev-list --objects HEAD |
> > > git cat-file --batch-check='%(objectsize) %(text)'
> >
> > If anything, I would have expected %(
"Kyle J. McKay" writes:
> Longer matches take precedence over shorter matches with
> environment variable settings taking precedence over all.
OK.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index b4d4887..3731a3a 100644
> --- a/Documentation/config.txt
> +++ b/Document
Eric Sunshine writes:
> With the introduction of check-mailmap, it is now possible to check
> .mailmap functionality directly rather than indirectly as a side-effect
> of other commands (such as git-shortlog), therefore, do so.
Does this patch mean that we will now ignore future breakages in
sho
Eric Sunshine writes:
> +DESCRIPTION
> +---
> +
> +For each ``Name '' or ``'' provided on
> +the command-line or standard input (when using `--stdin`), prints a line with
> +the canonical contact information for that person according to the 'mailmap'
> +(see "Mapping Authors" belo
Stefan Beller writes:
> On 07/11/2013 07:33 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>> ...
>>> I intend to contact each of the persons individually and ask whether
>>> just their mail address changed, or if they are indeed different persons.
>>
>> Has anything happen to this topic
On 07/11/2013 07:33 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>>
>> I noticed many duplicates in email addresses but having the same name by
>> running:
>>
>> # Finding out duplicates by comparing names:
>> git shortlog -sne |awk '{ NF--; $1=""; print }' |sort |uniq -d
>>
>> Most o
Jeff King writes:
> On Wed, Jul 10, 2013 at 08:59:51PM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > git rev-list --objects HEAD |
>> > git cat-file --batch-check='%(objectsize) %(text)'
>>
>> If anything, I would have expected %(rest), not %(text). This atom is
>> specific
Torsten Bögershausen wrote:
> On 30.06.13 19:28, Ramsay Jones wrote:
[ ... ]
>>> You have just described my second patch! :D
>> Unfortunately, I have not had any time to work on the patch this weekend.
>> However, despite the patch being a bit rough around the edges, I decided
>> to send it out (
Stefan Beller writes:
>
> I noticed many duplicates in email addresses but having the same name by
> running:
>
> # Finding out duplicates by comparing names:
> git shortlog -sne |awk '{ NF--; $1=""; print }' |sort |uniq -d
>
> Most of these entries are most probably the same person, but w
> From: Thomas Rast
> May I ask why you need this, and to what extent this problem cannot be
> solved by instead redirecting from/to /dev/null?
The situation in which the problem arose is described here:
> wor...@alum.mit.edu (Dale R. Worley) writes:
>
> > (The original problem and the discuss
From: "Kyle J. McKay"
The value is considered a match to a url if the value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So "https://example.com/test"; will
match "https://example.com/test"; and "https://example.com/test/too";
but not "https://
Kyle McKay writes:
> On Jul 9, 2013, at 16:09, Junio C Hamano wrote:
>> * km/svn-1.8-serf-only (2013-07-07) 2 commits
>> - git-svn: allow git-svn fetching to work using serf
>> - Git.pm: add new temp_is_locked function
>>
>> Comments?
>
>
> Since neither David nor Jonathan have piped in here (the
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> * bp/mediawiki-preview (2013-07-08) 7 commits
>> - git-remote-mediawiki: add preview subcommand into git mw
>> - git-remote-mediawiki: add git-mw command
>> - git-remote-mediawiki: factoring code between git-remote-mediawiki and
>> Git::Medi
Thomas Rast writes:
> But still, log -L should then be changed to match this behavior (for all
> args affecting a single file). Currently it always does the scan for
> the start of the range from line 1 of the file.
Thanks, I think that makes sense.
--
To unsubscribe from this list: send the li
Jeff King writes:
> I started on this, and it turned out not to really be any simpler
> So I went ahead with the full formats for my re-roll. It turned out
> pretty reasonable, I think.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
On Jul 10, 2013, at 4:35 PM, Antoine Pelisse wrote:
> On Wed, Jul 10, 2013 at 6:36 PM, Brian Gernhardt
> wrote:
>> I am somewhat stuck on how to fix it. Any ideas?
>
> I don't have anything to reproduce here, but usually I start
> investigating this kind of problems by attaching the hung proc
On Jul 11, 2013, at 9:34 AM, Jeff King wrote:
> On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:
>
>> The newest test in t0008 "streaming support for --stdin",
>> Experimentation has led me to find that it is hanging when trying to read
>> the 2nd response from check-ignore.
Jeff King writes:
> On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:
>
>> The newest test in t0008 "streaming support for --stdin", seems to
>> hang sporadically on my MacBook Pro (running 10.8.4). The hang seems
>> to be related to running it in parallel with other tests, as I c
Andreas Krey writes:
> I'm wondering if there is (or will be) a way of doing almost
>
> git clone --reference localrepo host:canonrep
>
> Basically, I don't want the implications of --reference but still the
> performance advantages of reusing local objects/pack files.
I think the standard ope
Duy Nguyen writes:
> On Thu, Jul 11, 2013 at 6:25 PM, Matthijs Kooijman wrote:
>> Commit 682c7d2 (upload-pack: fix off-by-one depth calculation in shallow
>> clone) introduced a new check in get_shallow_commits to decide when to
>> stop traversing the history and mark the current commit as a sha
Doug Bell writes:
> The docs seem to say that doing
>
> git show-ref --head --tags
>
> would show both the HEAD ref and all the tag refs. However, doing
> both --head and either of --tags or --heads would filter out the HEAD
> ref.
>
> Signed-off-by: Doug Bell
> ---
I think this patch fel
wor...@alum.mit.edu (Dale R. Worley) writes:
> (The original problem and the discussion that ensued is on the
> git-users mailing list:
> https://groups.google.com/forum/#!topic/git-users/lNQ7Cn35EqA)
>
> "git commit" (and probably other operations) fail if standard input
> (fd 0) is closed when g
(The original problem and the discussion that ensued is on the
git-users mailing list:
https://groups.google.com/forum/#!topic/git-users/lNQ7Cn35EqA)
"git commit" (and probably other operations) fail if standard input
(fd 0) is closed when git starts. A simple test case follows. (The
execution i
This is a re-roll of [1] which introduces git-check-mailmap. The
primary motivation for this command is to expose git's stable,
well-tested C-implementation of .mailmap functionality to scripts and
porcelains, thus relieving them of the need to reimplement support
themselves. The git-contacts [2] s
The simple two-commit test-repository created by 'setup' is no longer
needed by any of the tests retrofitted to use check-mailmap. Subsequent,
more complex tests of git-shortlog, git-log, and git-blame functionality
expand the repository by adding five commits. Consolidate the creation
of this seve
With the introduction of check-mailmap, it is now possible to check
.mailmap functionality directly rather than indirectly as a side-effect
of other commands (such as git-shortlog), therefore, do so.
Signed-off-by: Eric Sunshine
---
t/t4203-mailmap.sh | 133 ++
Introduce command check-mailmap, similar to check-attr and check-ignore,
which allows direct testing of .mailmap configuration.
As plumbing accessible to scripts and other porcelain, check-mailmap
publishes the stable, well-tested .mailmap functionality employed by
built-in Git commands. Conseque
Test the command-line interface of check-mailmap. (Actual .mailmap
functionality is already covered by existing tests.)
Signed-off-by: Eric Sunshine
---
t/t4203-mailmap.sh | 50 ++
1 file changed, 50 insertions(+)
diff --git a/t/t4203-mailmap.sh b
On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:
> The newest test in t0008 "streaming support for --stdin", seems to
> hang sporadically on my MacBook Pro (running 10.8.4). The hang seems
> to be related to running it in parallel with other tests, as I can
> only reliably cause i
On Thu, Jul 11, 2013 at 7:26 PM, Thomas Gummerer wrote:
> Duy Nguyen writes:
>
>> On Thu, Jul 11, 2013 at 6:39 PM, Thomas Gummerer
>> wrote:
Question about the possibility of updating index file directly. If git
updates a few fields of an entry (but not entrycrc yet) and crashes,
On Thu, Jul 11, 2013 at 6:42 PM, Duy Nguyen wrote:
> On Thu, Jul 11, 2013 at 6:30 PM, Thomas Gummerer wrote:
>> Duy Nguyen writes:
>> Hrm, I played around a bit with this idea, but I couldn't figure out how
>> to make it work. For it to work we would still have to load some
>> entries in a dire
Duy Nguyen writes:
> On Thu, Jul 11, 2013 at 6:39 PM, Thomas Gummerer wrote:
>>> Question about the possibility of updating index file directly. If git
>>> updates a few fields of an entry (but not entrycrc yet) and crashes,
>>> the entry would become corrupt because its entrycrc does not match
Here's an update of the radix-sort patch. It fixes the "unsigned" issue
Brandon pointed out, along with a few other comment/naming/style fixes.
I also updated the commit message with more explanation of the
timings.
The interdiff is:
diff --git a/pack-revindex.c b/pack-revindex.c
On Thu, Jul 11, 2013 at 6:25 PM, Matthijs Kooijman wrote:
> Commit 682c7d2 (upload-pack: fix off-by-one depth calculation in shallow
> clone) introduced a new check in get_shallow_commits to decide when to
> stop traversing the history and mark the current commit as a shallow
> root.
>
> With this
On Thu, Jul 11, 2013 at 6:39 PM, Thomas Gummerer wrote:
>> Question about the possibility of updating index file directly. If git
>> updates a few fields of an entry (but not entrycrc yet) and crashes,
>> the entry would become corrupt because its entrycrc does not match the
>> content. What do we
On Thu, Jul 11, 2013 at 6:30 PM, Thomas Gummerer wrote:
> Duy Nguyen writes:
>
>> On Wed, Jul 10, 2013 at 3:10 AM, Thomas Gummerer
>> wrote:
If you happen to know that certain entries match the given pathspec,
you could help the caller avoid match_pathspec'ing again by set a bit
Duy Nguyen writes:
> On Sun, Jul 7, 2013 at 3:11 PM, Thomas Gummerer wrote:
>> +== File entry (fileentries)
>> +
>> + File entries are sorted in ascending order on the name field, after the
>> + respective offset given by the directory entries. All file names are
>> + prefix compressed, meani
On Wed, Jul 10, 2013 at 08:59:51PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > git rev-list --objects HEAD |
> > git cat-file --batch-check='%(objectsize) %(text)'
>
> If anything, I would have expected %(rest), not %(text). This atom is
> specific to commands that accept input
Duy Nguyen writes:
> On Wed, Jul 10, 2013 at 3:10 AM, Thomas Gummerer wrote:
>>> If you happen to know that certain entries match the given pathspec,
>>> you could help the caller avoid match_pathspec'ing again by set a bit
>>> in ce_flags.
>>
>> I currently don't know which entries do match the
Commit 682c7d2 (upload-pack: fix off-by-one depth calculation in shallow
clone) changed the meaning of the fetch depth sent over the wire to mean
the total number of commits to return, instead of the number of commits
beyond the first. However, when this change is deployed on some servers
but not o
This server feature changes the meaning of the fetch depth, allowing
fetching only a single revision instead of at least two as before. To
make sure the behaviour only depends on the client version, the depth
value sent over the wire is corrected depending on wether the server has
the fix.
There i
Commit 682c7d2 (upload-pack: fix off-by-one depth calculation in shallow
clone) introduced a new check in get_shallow_commits to decide when to
stop traversing the history and mark the current commit as a shallow
root.
With this new check in place, the old check can no longer be true, since
the fi
On Wed, Jul 10, 2013 at 08:21:15PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > +If `--batch` or `--batch-check` is given, `cat-file` will read objects
> > +from stdin, one per line, and print information about them.
> > +
> > +You can specify the information shown for each object by
On Wed, Jul 10, 2013 at 10:10:16AM -0700, Brandon Casey wrote:
> > On the linux.git repo, with about 3M objects to sort, this
> > yields a 400% speedup. Here are the best-of-five numbers for
> > running "echo HEAD | git cat-file --batch-disk-size", which
> > is dominated by time spent building the
On Wed, Jul 10, 2013 at 06:47:49PM +0530, Ramkumar Ramachandra wrote:
> > For a 64-bit off_t, using 16-bit "digits" gives us k=4.
>
> Wait, isn't off_t a signed data type? Did you account for that in
> your algorithm?
It is signed, but the values we are storing in the revindex are all
positive
Hi Junio,
> While implementing the above, I noticed my fix now introduced an
> off-by-one error the other way. When investigating, I found this commit:
>
> commit 682c7d2f1a2d1a5443777237450505738af2ff1a
> Author: Nguyễn Thái Ngọc Duy
> Date: Fri Jan 11 16:05:47 2013 +0700
>
1 - 100 of 104 matches
Mail list logo
