Re: [RFC PATCH, WAS: "weird diff output?"] Implement better chunk heuristics.

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

Re: Migrating away from SHA-1?

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

Re: Migrating away from SHA-1?

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

Re: weird diff output?

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 > >

Re: Migrating away from SHA-1?

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

Re: [Bug?] "git commit --amend" always gives author-date to summary?

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

Re: [RFC PATCH, WAS: "weird diff output?"] Implement better chunk heuristics.

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

Re: [RFC PATCH, WAS: "weird diff output?"] Implement better chunk heuristics.

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

Re: [PATCH 2/2] Add submitGit patch-submission information

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

Re: [Bug?] "git commit --amend" always gives author-date to summary?

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

Re: [PATCH v3 03/16] index-helper: new daemon for caching index and related stuff

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

Re: [RFC PATCH, WAS: "weird diff output?"] Implement better chunk heuristics.

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!

Re: [PATCH 00/25] worktree lock, move, remove and unlock

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

Re: [RFC PATCH, WAS: "weird diff output?"] Implement better chunk heuristics.

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

Re: weird diff output?

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,

Re: [PATCH v3 03/16] index-helper: new daemon for caching index and related stuff

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

Re: [PATCH v4 03/16] index-helper: new daemon for caching index and related stuff

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:

[RFC PATCH, WAS: "weird diff output?"] Implement better chunk heuristics.

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

Re: Cannot checkout a branch / worktree shows multiple branches for the same directory

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

Re: Cannot checkout a branch / worktree shows multiple branches for the same directory

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

Re: [PATCH 2/2] Add submitGit patch-submission information

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

Re: [PATCH/RFC] ll-merge: use a longer conflict marker for internal merge

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

[PATCH/RFC] ll-merge: use a longer conflict marker for internal merge

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

Re: Migrating away from SHA-1?

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

Re: [PATCH 2/2] Add submitGit patch-submission information

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

Re: [PATCH 1/2] Partition SubmittingPatches doc into two files

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

[PATCH 1/2] Partition SubmittingPatches doc into two files

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) *

[PATCH] ll-merge: fix typo in comment

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

[PATCH 2/2] Add submitGit patch-submission information

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

Re: 0 bot for Git

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! >>

Re: Default authentication over https?

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

[Bug?] "git commit --amend" always gives author-date to summary?

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

Re: weird diff output?

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.

Re: [PATCH v4 11/16] ref-filter: introduce refname_atom_parser()

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 =

Re: [PATCH v4 15/16] branch: use ref-filter printing APIs

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

Cannot checkout a branch / worktree shows multiple branches for the same directory

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,

Re: [PATCH v4 15/16] branch: use ref-filter printing APIs

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

Re: [PATCH 1/2] submodule: port resolve_relative_url from shell to C

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 >>

Re: [PATCH 1/2] submodule: port resolve_relative_url from shell to C

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 >

Re: [PATCH v4 15/16] branch: use ref-filter printing APIs

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

Re: [PATCH 2/2] fsck: detect and warn a commit with embedded NUL

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

Re: [PATCH 2/2] fsck: detect and warn a commit with embedded NUL

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. >

Re: weird diff output?

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

Re: clone hang prevention / timeout?

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

Re: [PATCH 2/2] fsck: detect and warn a commit with embedded NUL

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,

Re: [PATCH v3 03/16] index-helper: new daemon for caching index and related stuff

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

Re: [PATCH 2/2] fsck: detect and warn a commit with embedded NUL

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

Re: [PATCH 0/2] Port `submodule init` to C

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

Re: [PATCH 2/2] fsck: detect and warn a commit with embedded NUL

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

Re: [PATCH 2/2] fsck: detect and warn a commit with embedded NUL

Jeff King writes: >> +const char *buffer_begin = buffer; >> >> if (verify_headers(buffer, size, >object, options)) >> return -1; > > You need this "buffer_begin" because we move the "buffer" pointer > forward as we parse. But perhaps whole-buffer checks

[PATCH 2/2] submodule: port init from shell to C

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

[PATCH 1/2] submodule: port resolve_relative_url from shell to C

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

[PATCH 0/2] Port `submodule init` to C

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

Re: [PATCH 1/2] fsck_commit_buffer(): do not special case the last validation

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) >>

Re: [PATCH v3 03/16] index-helper: new daemon for caching index and related stuff

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

Re: [PATCH 1/2] fsck_commit_buffer(): do not special case the last validation

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; > }

[PATCH 2/2] fsck: detect and warn a commit with embedded NUL

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

[PATCH 1/2] fsck_commit_buffer(): do not special case the last validation

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

Re: [PATCH v1] Documentation: add setup instructions for Travis CI

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

Re: Migrating away from SHA-1?

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

Re: Migrating away from SHA-1?

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

Re: Ambiguous sha-1 during a rebase

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,

Re: [PATCH v4 03/16] index-helper: new daemon for caching index and related stuff

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

Re: Migrating away from SHA-1?

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

Re: [PATCH v4 03/16] index-helper: new daemon for caching index and related stuff

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

Re: [PATCH v4 2/4] format-patch: add '--base' option to record base tree info

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

Re: [PATCH 00/26] nd/shallow-deepen updates

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

Re: [PATCH 1/2] i18n: branch: unmark string for translation

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

Re: [PATCH 00/25] worktree lock, move, remove and unlock

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

Re: Ambiguous sha-1 during a rebase

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

Re: [PATCH] git-stash: Don't GPG sign when stashing changes

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. > > >> > > >> >

Commit empty during rebase 2.8.1 windows

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)

git status core dump with bad sector!

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

Re: [PATCH v4 2/4] format-patch: add '--base' option to record base tree info

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 =

Re: weird diff output?

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

Re: Ambiguous sha-1 during a rebase

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

Re: [PATCH v3 03/16] index-helper: new daemon for caching index and related stuff

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 >

Re: [PATCH v4 03/16] index-helper: new daemon for caching index and related stuff

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

Re: Default authentication over https?

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

Re: Ambiguous sha-1 during a rebase

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

Data loss when using "git stash -u" and ignored content in directories

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

Re: [PATCH v1] Documentation: add setup instructions for Travis CI

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

Re: Ambiguous sha-1 during a rebase

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,

Re: Merge conflicts are reported relative to root not cwd

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

Re: Is OS X still supported?

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