Hi Michał,
you probably would have received a more timely response if you
1. had avoided top-posting, and
2. had kicked into action yourself rather than feeling somebody else
should solve your problem.
On Tue, 5 Apr 2016, Michał Staruch wrote:
> Thanks for the information that binary builds
On Wed, 13 Apr 2016 14:58:40 -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > $ cd t/
> > $ git merge ...
> > ...
> > Auto-merging builtin/submodule--helper.c
> > Auto-merging builtin/fetch.c
> > CONFLICT (content): Merge conflict in builtin/fetch.c
> > Auto-merging builtin/clone.c
> >
Mike Hommey writes:
> On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:
>> Mike Hommey writes:
>>
>> > Should git-rebase use full sha-1s under the hood to avoid these type of
>> > races?
>>
>> It already should be doing so since Aug 2013, IIRC.
>
> I'm using 2.8.1. Would there ha
Stefan Beller writes:
> On Wed, Apr 13, 2016 at 10:39 AM, Junio C Hamano wrote:
>
>> here, create a "GitHub-Travis CI hints" section just before "MUA
>> specific hints" section,
>
> Somebody (I think it was you, Lars?) at GitMerge suggested to break
> up the SubmittingPatches document into more
Hello,
A "git stash -u" cleans all untracked files (after storing them), and
normally does not clean ignored files.
But: It cleans ignored files _within_ a directory, when the directory
itself is not ignored, but its content (e.g. a "dir/*" ignore filter).
The bug seems to be that in the cleanup
On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote:
> I suspect you did:
>
> $ git rebase -i
> # editor pops up
> # switch to another terminal and fetch from elsewhere
> # close editor
That's possible, but I don't remember with certainty. At least it's
plausible.
> Then only, git turns
On Wed, 13 Apr 2016, Jeff King wrote:
However, I don't think even that would give you what you want. Because I
think that even if we provide a credential, curl will make an initial
request (presumably to find out which auth type it should use, but that
is just a guess). I don't know if there is
On Thu, Apr 14, 2016 at 1:47 AM, David Turner wrote:
> On Wed, 2016-04-13 at 20:43 +0700, Duy Nguyen wrote:
>> On Wed, Apr 13, 2016 at 7:32 AM, David Turner <
>> dtur...@twopensource.com> wrote:
>> > +NOTES
>> > +-
>> > +
>> > +$GIT_DIR/index-helper.path is a symlink
>>
>> In multiple worktree
On Wed, Apr 13, 2016 at 1:05 AM, Junio C Hamano wrote:
>>> - access is slow (unless cached, but we can't be sure)
>>
>> We could solve this (and the other problem) with mlock.
>
> Probably you meant madvise(2)?
>
> For something of a size comparable to the index file held by
> index-helper-daemon
Mike Hommey writes:
> Yeah, that definitely is a weird corner case. Interestingly, it was
> complaining about "error: short SHA1 e34ff55 is ambiguous." when apply
> *other* commits that were in the list prior to it,
I think it did before: when normalizing the list to long sha1, i.e.
right after
On Tue, 12 Apr 2016, Stefan Beller wrote:
> On Wed, Apr 6, 2016 at 10:47 AM, Jacob Keller wrote:
> >
> > I started attempting to implement this heuristic within xdiff, but I
> > am at a loss as to how xdiff actually works. I suspect this would go
> > in xdi_change_compact or after it, but I reall
On Tue, Apr 12, 2016 at 12:08:33PM -0700, Junio C Hamano wrote:
>> +static void prepare_bases(struct base_tree_info *bases,
>> + const char *base_commit,
>> + struct commit **list,
>> + int total)
>> +{
>> +struct commit *base = NUL
Hi,
just cloned a repo and it checked-out wihtout any error (with git 2.2.0)
but got come corrupted files (because I got some sdd failures).
Then, I get a git core dump when trying to "git status" into the repo
which have a "bad sector" on sdd drive (crypted partition).
I tried with git 2.2
So twice now during this particular rebase I have had this happen. All of
the work in this commit after being applied is gone. The only caveat is
that I had sourcetree running at the time, and I wonder if that is
somehow causing the
issue.
aaron@aaron MINGW64 /c/src/FORB (mybranch|REBASE 12/42)
$
Hi Cameron,
On Wed, 13 Apr 2016, Cameron Currie wrote:
> > > On Thu, 7 Apr 2016, daurnimator wrote:
> > >
> > >> Cameron Currie cameroncurrie.net> writes:
> > >> > This is helpful for folks with commit.gpgsign = true in their
> > >> > .gitconfig.
> > >>
> > >> > https://github.com/git/git/pull/1
Hi Junio,
On Wed, 13 Apr 2016, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > Should git-rebase use full sha-1s under the hood to avoid these type of
> > races?
>
> It already should be doing so since Aug 2013, IIRC.
Indeed. It is one of the things that makes interactive rebases so
unbeara
Nguyễn Thái Ngọc Duy writes:
> This is basically a resend from last time, which happened during rc
> time.
It would have made them a much more pleasant read if you re-read
them during that time and added the missing "why" to many of the
commit log message.
> It adds 4 more commands, basically
Thanks, picked up and queued.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks, picked up and re-queued.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ye Xiaolong writes:
>>> + for (i = 0; i < total; i++) {
>>> + if (!in_merge_bases(base, list[i]) || base == list[i])
>>> + die(_("base commit should be the ancestor of revision
>>> list"));
>>
>>This check looks overly expensive, but I do not think of a more
>>effic
David Turner writes:
> $GIT_DIR/index-helper.path is a symlink to the socket for the daemon
> process. The daemon reads from the socket and executes commands.
We generally avoid using symbolic links inside $GIT_DIR (we used to
represent the current branch by a symbolic link HEAD pointing at the
Theodore Ts'o wrote:
> OK, so how does this map to git? First of all, from a collision
> perspective, the two blobs have to map into valid C code
Git provides other places to hide the colliding blobs; the best seems to
be as an added header in the commit object, or as trailing data after a \0
in
On Thu, 2016-04-14 at 09:56 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > $GIT_DIR/index-helper.path is a symlink to the socket for the
> > daemon
> > process. The daemon reads from the socket and executes commands.
>
> We generally avoid using symbolic links inside $GIT_DIR (we used
Matthieu Moy writes:
> Mike Hommey writes:
>
> > Yeah, that definitely is a weird corner case. Interestingly, it was
> > complaining about "error: short SHA1 e34ff55 is ambiguous." when apply
> > *other* commits that were in the list prior to it,
>
> I think it did before: when normalizing the
On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote:
> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
> >
> > If SHA-1 is broken (in certain ways), someone *can* replace an
> > arbitrary blob. GPG does not help in this case, because the
> > signature
> > is over the commit objec
On April 14, 2016 10:23:03 AM PDT, David Turner
wrote:
>On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote:
>> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
>> >
>> > If SHA-1 is broken (in certain ways), someone *can* replace an
>> > arbitrary blob. GPG does not help in thi
Matthieu Moy writes:
> Stefan Beller writes:
>
>> On Wed, Apr 13, 2016 at 10:39 AM, Junio C Hamano wrote:
>>
>>> here, create a "GitHub-Travis CI hints" section just before "MUA
>>> specific hints" section,
>>
>> Somebody (I think it was you, Lars?) at GitMerge suggested to break
>> up the Subm
The pattern taken by all the validations in this function is:
if (notice a violation exists) {
err = report(... VIOLATION_KIND ...);
if (err)
return err;
}
where report() returns zero if specified kind of violation is set to
Even though a Git commit object is designed to be capable of storing
any binary data as its payload, in practice people use it to describe
the changes in textual form, and tools like "git log" are designed to
treat the payload as text.
Detect and warn when we see any commit object with a NUL byte
On Thu, Apr 14, 2016 at 11:07:08AM -0700, Junio C Hamano wrote:
> The pattern taken by all the validations in this function is:
>
> if (notice a violation exists) {
> err = report(... VIOLATION_KIND ...);
> if (err)
> return err;
> }
>
Duy Nguyen writes:
> On Wed, Apr 13, 2016 at 1:05 AM, Junio C Hamano wrote:
- access is slow (unless cached, but we can't be sure)
>>>
>>> We could solve this (and the other problem) with mlock.
>>
>> Probably you meant madvise(2)?
>>
>> For something of a size comparable to the index file
Jeff King writes:
> On Thu, Apr 14, 2016 at 11:07:08AM -0700, Junio C Hamano wrote:
>
>> The pattern taken by all the validations in this function is:
>>
>> if (notice a violation exists) {
>> err = report(... VIOLATION_KIND ...);
>> if (err)
>>
This is another round for sb/submodule-init.
Changes since last round:
* Also iterate over the submodules in the C helper. With that missing piece
`git submodule init` is completely handled in C now except for the usage
string and the command->subcommand selection. (i.e. when calling
`git su
Later on we want to automatically call `git submodule init` from
other commands, such that the users don't have to initialize the
submodule themselves. As these other commands are written in C
already, we'd need the init functionality in C, too. The
`resolve_relative_url` function is a large part
By having the `submodule init` functionality in C, we can reference it
easier from other parts in the code in later patches. The code is split
up to have one function to initialize one submodule and a calling function
that takes care of the rest, such as argument handling and translating the
argume
Jeff King writes:
>> +const char *buffer_begin = buffer;
>>
>> if (verify_headers(buffer, size, &commit->object, options))
>> return -1;
>
> You need this "buffer_begin" because we move the "buffer" pointer
> forward as we parse. But perhaps whole-buffer checks should simp
On Thu, Apr 14, 2016 at 02:21:03PM -0400, Jeff King wrote:
> So yet another alternative would be to include this check in
> verify_headers(). It would parse to the end of the headers as now, and
> then from there additionally look for a NUL in the body.
Hmm. Looking at verify_headers(), I think i
Stefan Beller writes:
> * This applies on another base commit, such that we make use of the tests
> written in origin/sb/submodule-path-misc-bugs. (I am not sure if I have too
> many series in flight stomping on each other here)
I actually am quite sure that is the case ;-)
> * This time I
On Thu, Apr 14, 2016 at 11:07:09AM -0700, Junio C Hamano wrote:
> Even though a Git commit object is designed to be capable of storing
> any binary data as its payload, in practice people use it to describe
> the changes in textual form, and tools like "git log" are designed to
> treat the payload
On Thu, 2016-04-14 at 11:12 -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Wed, Apr 13, 2016 at 1:05 AM, Junio C Hamano
> > wrote:
> > > > > - access is slow (unless cached, but we can't be sure)
> > > >
> > > > We could solve this (and the other problem) with mlock.
> > >
> > > P
On Thu, Apr 14, 2016 at 11:25:29AM -0700, Junio C Hamano wrote:
> > You need this "buffer_begin" because we move the "buffer" pointer
> > forward as we parse. But perhaps whole-buffer checks should simply go at
> > the top (next to verify_headers) before we start advancing the pointer.
> > To me,
Thanks very much Eric & Jeff for your reply .
Personally, I would recommend setting the SO_RECVTIMEO for GIT server
sockets to a fixed default (eg. 5mins) , settable by a
'--receive-timeout' argument or configuration parameter .
The problem I was trying to overcome was cloning all the repositor
On Thu, Apr 14, 2016 at 06:56:39AM -0700, Davide Libenzi wrote:
> That was a zillions of years ago :) , but from a quick look at email
> thread, if you want to do it within xdiff, xdi_change_compact would be
> the place. The issue is knowing in which situations one diff look
> better than another
Jeff King writes:
> On Thu, Apr 14, 2016 at 02:21:03PM -0400, Jeff King wrote:
>
>> So yet another alternative would be to include this check in
>> verify_headers(). It would parse to the end of the headers as now, and
>> then from there additionally look for a NUL in the body.
>
> Hmm. Looking a
Jeff King writes:
> But I do agree in general that we should be checking as many things as
> we can.
I was about to say "I agree with that in principle, but there are
cases where you would want to say 'if the object does not pass even
this basic check, it is not worth validating it further', and
On Thu, Apr 14, 2016 at 3:35 AM, Jeff King wrote:
>
> The cross-prefix behavior I put into the test is not something I feel
> strongly about; it was mostly just restoring the earlier behavior. I do
> think shortening everything is fine, too, as long as there's some way to
> get the fully qualified
Am 14.04.2016 um 20:18 schrieb Stefan Beller:
> @@ -298,4 +305,40 @@ test_git_path GIT_COMMON_DIR=bar config
> bar/config
> test_git_path GIT_COMMON_DIR=bar packed-refs bar/packed-refs
> test_git_path GIT_COMMON_DIR=bar shallow bar/shallow
>
>
On Thu, Apr 14, 2016 at 12:35 PM, Johannes Sixt wrote:
> Am 14.04.2016 um 20:18 schrieb Stefan Beller:
>> @@ -298,4 +305,40 @@ test_git_path GIT_COMMON_DIR=bar config
>> bar/config
>> test_git_path GIT_COMMON_DIR=bar packed-refs bar/packed-refs
>> test_git_path
On Fri, Apr 15, 2016 at 12:47:15AM +0530, Karthik Nayak wrote:
> That does make sense, I guess then I'll stick to shortening all symref's
> by default and allowing the user to change this if needed via the '--format'
> option.
Thanks.
> About %(symref) not getting enough formatting options, I do
Hi,
I stumbled upon an interesting problem when checking out a branch.
I had to switch to a testing branch to merge in some changes from yet
another branch, but when I tried to check out the testing branch I got
a message saying that I'm already on the target branch.
I used worktree a few times,
On Thu, Apr 14, 2016 at 04:05:30PM -0400, Jeff King wrote:
> It looks like that's a little tricky for %(upstream) and %(push), which
> have extra tracking options, but it's pretty trivial for %(symref):
> [...]
> I suspect it could work for the remote_ref_atom_parser, too, if you did
> something l
On Sun, Apr 10, 2016 at 12:15:10AM +0530, Karthik Nayak wrote:
> +static void refname_atom_parser(struct used_atom *atom, const char *arg)
> +{
> + if (!arg)
> + atom->u.refname.option = R_NORMAL;
> + else if (!strcmp(arg, "short"))
> + atom->u.refname.option = R_SH
On Thu, Apr 14, 2016 at 11:34 AM, Jeff King wrote:
> On Thu, Apr 14, 2016 at 06:56:39AM -0700, Davide Libenzi wrote:
>
>> That was a zillions of years ago :) , but from a quick look at email
>> thread, if you want to do it within xdiff, xdi_change_compact would be
>> the place. The issue is knowi
A simple reproduction. Doing one of these
$ git commit --amend --no-edit
$ echo >MSG frotz; git commit --amend -F MSG
on any commit, whether it is your own commit or somebody else's,
seems to always show the "Date:" of the original commit, e.g.
$ git checkout v2.8.0^0
$ git comm
After the authenticated request, curl says it's keeping the connection
open, but the next fetch seems to do two handshakes again. The
unauthenticated request closes the connection, so the 2nd handshake is
forced, but I'm not sure why subsequent git fetches still do
handshakes. I did a bit of sleu
On Tue, Apr 12, 2016 at 4:59 PM, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 2:42 AM, Duy Nguyen wrote:
>>> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
Hi Greg,
Thanks for your talk at the Git Merge 2016!
>>
>> Huh? It already happened?? Any interesting summary to sha
Most of the guidance on how to use submitGit will stay with the tool
itself, so the edits here are mostly to make the choice clear to users.
Because generation of patches is quite different for MUA-users and
submitGit users, I've merged section 3 and 4 together:
section 3 - 'Generate your patch u
When a944af1d (merge: teach -Xours/-Xtheirs to binary ll-merge
driver, 2012-09-08) introduced FAVOR_OURS/FAVOR_THEIRS to the binary
ll-merge driver, it changed what happens to the merge result for the
outer merge, and updated the comment from:
The tentative merge result is "ours" for the final
No editorial changes in this commit, the text that is transferred into the
second file is unchanged apart from minor chunk re-ordering.
The split is based on:
* Information needed for all users, whether using `git send-email` or
submitGit (ie good commit practice, mailing list etiquette)
* Info
Roberto Tyley writes:
> Subject: Re: [PATCH 1/2] Partition SubmittingPatches doc into two files
That violates the first paragraph of "(2) Describe your changes
well."
SubmittingPatches: separate parts specific to mailed-in patches
or something like that, to
- Prefix with the "area";
Roberto Tyley writes:
> +(3) Generate and send your patch to the Git mailing list
>
> People on the Git mailing list need to be able to read and
> comment on the changes you are submitting. It is important for
> a developer to be able to "quote" your changes, using standard
> e-mail tools,
On Thu, Apr 14, 2016 at 10:28:50AM -0700, H. Peter Anvin wrote:
>
> Either way, I agree with Ted, that we have enough time to do it
> right, but that is a good reason to do it sooner rather than later
> (see also my note about freezing the cryptographic properties.)
Sure, I think we should do it
The primary use of conflict markers is to help the user who resolves
the final (outer) merge by hand to show which part came from which
branch by separating the blocks of lines apart. When the conflicted
parts from a "virtual ancestor" merge created by merge-recursive
remains in the common ancesto
Junio C Hamano writes:
> The primary use of conflict markers is to help the user who resolves
> the final (outer) merge by hand to show which part came from which
> branch by separating the blocks of lines apart. When the conflicted
> parts from a "virtual ancestor" merge created by merge-recurs
Junio C Hamano writes:
>> +Because of these factors, it's recommended that you use one of these
>> +specific methods to generate and send your patchs:
>
> Perhaps:
>
> It's recommended ... your patches, unless you already know how
> to correctly send your patches as plain-text e-mails.
>
On Thu, Apr 14, 2016 at 3:51 PM, Krzysztof Voss wrote:
> I stumbled upon an interesting problem when checking out a branch.
> I had to switch to a testing branch to merge in some changes from yet
> another branch, but when I tried to check out the testing branch I got
> a message saying that I'm a
On Thu, Apr 14, 2016 at 3:51 PM, Krzysztof Voss wrote:
> Hi,
>
> I stumbled upon an interesting problem when checking out a branch.
> I had to switch to a testing branch to merge in some changes from yet
> another branch, but when I tried to check out the testing branch I got
> a message saying th
On Fri, Apr 15, 2016 at 12:02 AM, David Turner wrote:
>> > On webkit.git with index format v2, duplicating 8 times to 1.4m
>> > entries and 200MB in size:
>> >
>> > (vanilla) 0.986986364 s: read_index_from .git/index
>> > (index-helper) 0.267850279 s: read_index_from .git/index
>> >
>> > Inte
TODO(sbeller):
* describe the discussion on why this is better
* see if this can be tested?
Signed-off-by: Stefan Beller
---
xdiff/xdiffi.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 2358a2d..24eb9a0 100644
-
On Fri, Apr 15, 2016 at 1:12 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Apr 13, 2016 at 1:05 AM, Junio C Hamano wrote:
> - access is slow (unless cached, but we can't be sure)
We could solve this (and the other problem) with mlock.
>>>
>>> Probably you meant madvi
On Thu, Apr 14, 2016 at 2:05 PM, Stefan Beller wrote:
> On Thu, Apr 14, 2016 at 11:34 AM, Jeff King wrote:
>> On Thu, Apr 14, 2016 at 06:56:39AM -0700, Davide Libenzi wrote:
>>
>>> That was a zillions of years ago :) , but from a quick look at email
>>> thread, if you want to do it within xdiff,
On Thu, Apr 14, 2016 at 5:07 PM, Stefan Beller wrote:
> TODO(sbeller):
> * describe the discussion on why this is better
> * see if this can be tested?
>
Thanks for taking time to do this! It looks like a few things are
still missing, CRLF obviously, and making it a configuration option.
> Signe
On Thu, Apr 14, 2016 at 11:08 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This is basically a resend from last time, which happened during rc
>> time.
>
> It would have made them a much more pleasant read if you re-read
> them during that time and added the missing "why" to man
On Thu, Apr 14, 2016 at 5:26 PM, Jacob Keller wrote:
> On Thu, Apr 14, 2016 at 5:07 PM, Stefan Beller wrote:
>> TODO(sbeller):
>> * describe the discussion on why this is better
>> * see if this can be tested?
>>
>
> Thanks for taking time to do this! It looks like a few things are
> still missin
On Thu, Apr 14, 2016 at 5:40 PM, Duy Nguyen wrote:
> On Thu, Apr 14, 2016 at 11:08 PM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> This is basically a resend from last time, which happened during rc
>>> time.
>>
>> It would have made them a much more pleasant read if you re-rea
Duy Nguyen writes:
> We don't hold this memory forever though. If the daemon is idle for a
> while, it exits, releasing memory back to system. And not using
> mlock() already gives the OS more freedom in memory usage.
Yup, that is why I suspected you wanted to use something other than
mlock().
-
On Thu, Apr 14, 2016 at 02:07:50PM -0700, Junio C Hamano wrote:
> A simple reproduction. Doing one of these
>
> $ git commit --amend --no-edit
> $ echo >MSG frotz; git commit --amend -F MSG
>
> on any commit, whether it is your own commit or somebody else's,
> seems to always show the "
On Thu, Apr 14, 2016 at 03:27:18PM -0700, Junio C Hamano wrote:
> > + - Create a pull request on https://github.com/git/git and
> > +use https://submitgit.herokuapp.com/ to send it as a patch series
> > +to the mailing list. Note that the PR is just the place where your
> > +patch is
On Thu, Apr 14, 2016 at 5:43 PM, Stefan Beller wrote:
> On Thu, Apr 14, 2016 at 5:26 PM, Jacob Keller wrote:
>> On Thu, Apr 14, 2016 at 5:07 PM, Stefan Beller wrote:
>>> TODO(sbeller):
>>> * describe the discussion on why this is better
>>> * see if this can be tested?
>>>
>>
>> Thanks for takin
Stefan Beller writes:
>
> +static int starts_with_emptyline(const char *recs)
> +{
> + return recs[0] == '\n'; /* CRLF not covered here */
> +}
> +
> +
That's "is-empty-line", not "starts-with" ;-)
> +
> + /*
> + * If a group can be moved back and forth, see if th
Jeff King writes:
> That's working as I intended it in both cases. The point is to show
> extra information whenever we have picked an ident or date that is not
> the "normal" one.
OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
On Thu, Apr 14, 2016 at 06:40:51PM -0400, Theodore Ts'o wrote:
> Also, remember that while we can write programs that look for
> suspicious git objects that have stuff hidden after the null
> terminator (in fact, maybe that would be a good thing to add to git,
> hmmm?)[...]
Detecting the hidden b
On Thu, Apr 14, 2016 at 02:05:03PM -0700, Stefan Beller wrote:
> > Looking over the code, I agree that xdl_change_compact() is the place we
> > would want to put it. We'd probably tie it to a command-line option and
> > let people play around with it, and then consider making it the default
> > if
Jeff King writes:
> [2] Somewhere in the list archive is my patch to find partial
> collisions like "git commit --sha1=31337", and I did in fact use
> that micro-optimization. That, along with multi-threading, made it
> feasible to do 6-8 character prefixes, as I recall.
In our tests
On Thu, Apr 14, 2016 at 07:18:53PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > [2] Somewhere in the list archive is my patch to find partial
> > collisions like "git commit --sha1=31337", and I did in fact use
> > that micro-optimization. That, along with multi-threading, made
On Thu, Apr 14, 2016 at 7:09 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>
>> +static int starts_with_emptyline(const char *recs)
>> +{
>> + return recs[0] == '\n'; /* CRLF not covered here */
>> +}
>> +
>> +
>
> That's "is-empty-line", not "starts-with" ;-)
heh, ok.
To understand t
86 matches
Mail list logo
