Re: Expanding Includes in .gitignore

On Fri, Oct 28, 2016 at 4:32 PM, Aaron Pelly wrote: > Or how about a new githook that can intelligently create or return the > details? This would be my least favourite option unless it was > configured in an obvious place. I wonder if smudge/clean filters can be used to recreate

Re: Expanding Includes in .gitignore

On Fri, Oct 28, 2016 at 4:04 AM, Jeff King wrote: > On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote: > >> > I think the normal behavior in such "foo.d" directory is to just sort >> > the contents lexically and read them in order, as if they were all >> > concatenated

[PATCH] git-sh-setup: Restore sourcability from outside scripts

v2.10.0-rc0~45^2~2 “i18n: git-sh-setup.sh: mark strings for translation” broke outside scripts such as guilt that source git-sh-setup as described in the documentation: $ . "$(git --exec-path)/git-sh-setup" sh: 6: .: git-sh-i18n: not found This also affects

Re: [PATCH v1 10/19] read-cache: regenerate shared index if necessary

On Tue, Oct 25, 2016 at 12:16 PM, Duy Nguyen wrote: > On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder > wrote: >> @@ -2233,7 +2263,8 @@ int write_locked_index(struct index_state *istate, >> struct lock_file *lock, >> if ((v & 15)

Re: [PATCH v1 10/19] read-cache: regenerate shared index if necessary

On Sun, Oct 23, 2016 at 6:07 PM, Ramsay Jones wrote: >> >> +int too_many_not_shared_entries(struct index_state *istate) > > This function is a file-loacal symbol; could you please make it > a static function. Ok, it will be in the next version. Thanks, Christian.

Re: [PATCH v1 09/19] config: add git_config_get_max_percent_split_change()

On Tue, Oct 25, 2016 at 12:06 PM, Duy Nguyen wrote: > On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder > wrote: >> This new function will be used in a following commit to get the >> +int git_config_get_max_percent_split_change(void) >> +{ >> +

Re: [PATCH v1 05/19] update-index: warn in case of split-index incoherency

On Tue, Oct 25, 2016 at 12:00 PM, Duy Nguyen wrote: > On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder > wrote: >> When users are using `git update-index --(no-)split-index`, they >> may expect the split-index feature to be used or not according to

Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions

On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen wrote: > On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder > wrote: >> +void remove_split_index(struct index_state *istate) >> +{ >> + if (istate->split_index) { >> + /* >> +

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Sat, Oct 29, 2016 at 12:08:31PM -0400, Matt McCutchen wrote: > Let's focus on the first scenario.  There the user is just pulling and > pushing a master branch.  Are you saying that each time the user pulls, > they need to look over all the commits they pulled before pushing them > back?  I

Re: Fetch/push lets a malicious server steal the targets of "have" lines

So, like, Junio C Hamano said: > Matt McCutchen writes: > > > Then the server generates a commit X3 that lists Y2 as a parent, even > > though it doesn't have Y2, and advances 'x' to X3. The victim fetches > > 'x': > > > >victim server > > >

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Sat, Oct 29, 2016 at 1:25 AM, Johannes Schindelin wrote: > > Correct. We cannot change an open file handle's state ("FD_CLOEXEC") on > Windows, but we can ask open() to open said file handle with the correct > flag ("O_CLOEXEC", which is mapped to O_NOINHERIT on

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Sat, 2016-10-29 at 09:39 -0400, Jeff King wrote: > I'm not sure I understand how connecting to a remote server to fetch is > a big problem. The server may learn about the existence of particular > sha1s in your repository, but cannot get their content. > > It's the subsequent push that is a

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote: > Not sending to the list, where mails from Gmail/phone is known to get > rejected. [I guess I can go ahead and quote this to the list.] > No. I'm saying that the scenario you gave is bad and people should be > taught not to connect to

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Fri, Oct 28, 2016 at 11:33:49PM -0400, Matt McCutchen wrote: > On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote: > > Ah, I see.  My immediate reaction is that you can do worse things in > > the reverse direction compared to this, but your scenario does sound > > bad already. > > Are

[PATCH] commit: simplify building parents list

Push pptr down into the FROM_MERGE branch of the if/else statement, where it's actually used, and call commit_list_append() for appending elements instead of playing tricks with commit_list_insert(). Call copy_commit_list() in the amend branch instead of open-coding it. Don't bother setting pptr

Re: [PATCH 0/4] Make other git commands use trailer layout

On Sat, Oct 29, 2016 at 3:12 AM, Junio C Hamano wrote: > Jonathan Tan writes: > >> This is built off jt/trailer-with-cruft (commit 60ef86a). >> >> This patch set makes "commit -s", "cherry-pick -x", and >> "format-patch --signoff" use the new trailer

Re: [PATCH 2/4] trailer: avoid unnecessary splitting on lines

On Sat, Oct 29, 2016 at 2:05 AM, Jonathan Tan wrote: > trailer.c currently splits lines while processing a buffer (and also > rejoins lines when needing to invoke ignore_non_trailer). > > Avoid such line splitting, except when generating the strings > corresponding to

Re: [PATCH v2 1/2] read-cache: factor out get_sha1_from_index() helper

On Wed, Oct 12, 2016 at 8:47 PM, wrote: > From: Torsten Bögershausen > > Factor out the retrieval of the sha1 for a given path in > read_blob_data_from_index() into the function get_sha1_from_index(). > > This will be used in the next commit, when convert.c can do

Re: [PATCH v2 2/2] convert.c: stream and fast search for binary

On Wed, Oct 12, 2016 at 8:47 PM, wrote: > From: Torsten Bögershausen > > When statistics are done for the autocrlf handling, the search in > the content can be stopped, if e.g > - a search for binary is done, and a NUL character is found > - a search for CRLF is

Re: Is the entire working copy “at one branch”?

Hi Stefan, Generally with git, your entire working copy will have the same revision (set to current branch, aka HEAD). The idea behind this is that your working copy of a repository should always be in consistent state. You can check out specific files or directories from another revision

Re: [PATCH] valgrind: support test helpers

Am 28.10.2016 um 10:51 schrieb Johannes Schindelin: On Fri, 28 Oct 2016, René Scharfe wrote: Signed-off-by: Rene Scharfe Apart from the missing accent ("é") in your SOB: ACK. I sign off without accent out of habit, to avoid display problems -- better have a plain "e" than

Re: [PATCH] valgrind: support test helpers

Am 28.10.2016 um 14:50 schrieb Junio C Hamano: > Hmph. I somehow thought this was supposed to have been fixed by > 503e224180 ("t/test-lib.sh: fix running tests with --valgrind", > 2016-07-11) already. Its title seems to indicate that intention. Probably the quickest test script that calls a

Re: [ANNOUNCE] Git v2.10.2

Hi, On Fri, 28 Oct 2016, Junio C Hamano wrote: > The latest maintenance release Git v2.10.2 is now available at > the usual places. The corresponding Git for Windows version will be hopefully out on Tuesday: https://github.com/git-for-windows/git/milestone/5 Ciao, Johannes

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

Hi, On Fri, 28 Oct 2016, Junio C Hamano wrote: > Linus Torvalds writes: > > > Apparently windows doesn't even support it, at least not mingw > > Assuming that the above was a misunderstanding, assuming that we can > do O_CLOEXEC (but not FD_CLOEXEC) on

Re: [PATCHv2 27/36] attr: convert to new threadsafe API

Am 29.10.2016 um 00:06 schrieb Junio C Hamano: Probably this needs to be squashed in, now the MinGW discussion has settled. Yes, this looks good. Thank you very much, both of you. As I said, I won't be able to test this until late next week. -- Hannes attr.c | 2 +- common-main.c

[ANNOUNCE] Git v2.10.2

The latest maintenance release Git v2.10.2 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.10.2' tag and the 'maint' branch that the tag points at: url =

What's cooking in git.git (Oct 2016, #08; Fri, 28)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Git v2.10.2, the second