[PATCH] stash: disable renames when calling git-diff

On Tue, Dec 06, 2016 at 10:25:30AM -0500, Jeff King wrote: > I agree that the second stash not saving the deletion seems like a bug. > Oddly, just stashing a deletion, like: > > rm a > git stash > git stash apply > > does store it. So it's not like we can't represent the deletion. Somehow

Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling

On Mon, Dec 05, 2016 at 10:01:19AM -0800, Junio C Hamano wrote: > > That said, I think the right patch may be to just drop --abbrev > > entirely. > > ... > > I think at that point it was a noop, as 7 should have been the default. > > And now we probably ought to drop it, so that we can use the >

Re: Bug: stash staged file move loses original file deletion

On Mon, Dec 05, 2016 at 09:37:51AM -0500, Matthew Patey wrote: > Git version 2.8.0 (sorry can't update to more recent on my machine) on Ubuntu. The behavior is the same on more recent versions of git, too. The short answer is "use --index". The longer one is below. > After moving a file, if the

Re: [PATCH] git-p4: add p4 shelf support

It seems if you do shelve and then later submit the p4 workspace is left dirty (just like --prepare-p4-only would've done). Vinicius Alexandre Kursancew On Tue, Dec 6, 2016 at 8:36 AM, Luke Diamand wrote: > On 6 December 2016 at 02:02, Nuno

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Tue, Dec 06, 2016 at 03:48:38PM +0100, Johannes Schindelin wrote: > > Should it blindly look at ".git/config"? > > Absolutely not, of course. You did not need me to say that. > > > Now your program behaves differently depending on whether you are in the > > top-level of the working tree. >

Re: Bug: stash staged file move loses original file deletion

On Tue, Dec 06, 2016 at 02:45:05PM +, Matthew Patey wrote: > Thanks for the reply! I agree that it is weird that applying a stash with a > move only puts the addition back in the index, and thanks for the tip on > "index" to properly apply that. For this case I was focusing on the > behavior

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

Hi Peff, On Tue, 6 Dec 2016, Jeff King wrote: > On Tue, Dec 06, 2016 at 02:16:35PM +0100, Johannes Schindelin wrote: > > > > Johannes Schindelin writes: > > > > > > > Seriously, do you really think it is a good idea to have > > > > git_config_get_value() *ignore*

Re: git add -p doesn't honor diff.noprefix config

On Sat, Dec 03, 2016 at 07:45:18AM +0100, paddor wrote: > I set the config diff.noprefix = true because I don't like the a/ and > b/ prefixes, which nicely changed the output of `git diff`. > Unfortunately, the filenames in the output of `git add --patch` are > still prefixed. > > To me, this

Re: [PATCH v7 4/4] transport: add from_user parameter to is_transport_allowed

Jeff King writes: > I don't know if that makes things any easier. I feel funny saying "no, > no, mine preempts yours because it is more maint-worthy", but I think > that order does make sense. > > I think it would be OK to put Brandon's on maint, too, though. It is a > refactor of

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

On 11/30, Junio C Hamano wrote: > Junio C Hamano forgot to Cc: the author of the > most relevant change to the issue, d426430e6e ("pathspec: warn on > empty strings as pathspec", 2016-06-22). > > > Kevin Daudt writes: > > > >> On Wed, Nov 30, 2016 at

Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling

Jeff King writes: > On Mon, Dec 05, 2016 at 10:01:19AM -0800, Junio C Hamano wrote: > >> > That said, I think the right patch may be to just drop --abbrev >> > entirely. >> > ... >> > I think at that point it was a noop, as 7 should have been the default. >> > And now we probably

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Tue, Dec 6, 2016 at 7:09 AM, Jeff King wrote: >> >> Maybe even go a step further and say that the config code needs a context >> "object". > > If I were writing git from scratch, I'd consider making a "struct > repository" object. I'm not sure how painful it would be to

[PATCH v2 6/6] http-walker: complain about non-404 loose object errors

Since commit 17966c0a6 (http: avoid disconnecting on 404s for loose objects, 2016-07-11), we turn off curl's FAILONERROR option and instead manually deal with failing HTTP codes. However, the logic to do so only recognizes HTTP 404 as a failure. This is probably the most common result, but if we

[PATCH v2 5/6] http: treat http-alternates like redirects

The previous commit made HTTP redirects more obvious and tightened up the default behavior. However, there's another way for a server to ask a git client to fetch arbitrary content: by having an http-alternates file (or a regular alternates file, which is used as a backup). Similar to the HTTP

[PATCH v2 2/6] http: always update the base URL for redirects

If a malicious server redirects the initial ref advertisement, it may be able to leak sha1s from other, unrelated servers that the client has access to. For example, imagine that Alice is a git user, she has access to a private repository on a server hosted by Bob, and Mallory runs a malicious

[PATCH v2 4/6] http: make redirects more obvious

We instruct curl to always follow HTTP redirects. This is convenient, but it creates opportunities for malicious servers to create confusing situations. For instance, imagine Alice is a git user with access to a private repository on Bob's server. Mallory runs her own server and wants to access

[PATCH v2 3/6] remote-curl: rename shadowed options variable

The discover_refs() function has a local "options" variable to hold the http_get_options we pass to http_get_strbuf(). But this shadows the global "struct options" that holds our program-level options, which cannot be accessed from this function. Let's give the local one a more descriptive name

[PATCH v2 1/6] http: simplify update_url_from_redirect

This function looks for a common tail between what we asked for and where we were redirected to, but it open-codes the comparison. We can avoid some confusing subtractions by using strip_suffix_mem(). Signed-off-by: Jeff King --- http.c | 10 -- 1 file changed, 4

Re: [PATCH] clone,fetch: explain the shallow-clone option a little more clearly

Duy Nguyen writes: > On Tue, Dec 6, 2016 at 1:28 AM, Junio C Hamano wrote: >> I however offhand do not think the feature can be used to make the >> repository shallower > > I'm pretty sure it can,... I wrote my message after a short local testing, but it

[PATCH v2] jk/http-walker-limit-redirect rebased to maint-2.9

On Tue, Dec 06, 2016 at 01:10:08PM -0500, Jeff King wrote: > > I think I merged yours and then Brandon's on jch/pu branches in that > > order, and the conflict resolution should look OK. > > > > I however forked yours on v2.11.0-rc1, which would need to be > > rebased to one of the earlier

inconsistent output from git add about ignored files

Dear Git gurus, It seems that there is some inconsistency in output of git while it is ignoring files: if a single path within ignored directory is provided -- git outputs the file path. If multiple files are provided (some of which aren't ignored) -- git outputs only the ignored directory

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Tue, Dec 06, 2016 at 10:22:21AM -0800, Stefan Beller wrote: > >> Maybe even go a step further and say that the config code needs a context > >> "object". > > > > If I were writing git from scratch, I'd consider making a "struct > > repository" object. I'm not sure how painful it would be to

Re: [PATCH v15 11/27] bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Hey Stephan, Sorry for the late replies. My end semester exams just got over. On Fri, Nov 18, 2016 at 2:29 AM, Stephan Beyer wrote: > > Hi Pranit, > > On 10/14/2016 04:14 PM, Pranit Bauva wrote: > > Also reimplement `bisect_voc` shell function in C and call it from > >

BUG: "cherry-pick A..B || git reset --hard OTHER"

I was burned a few times with this in the past few years, but it did not irritate me often enough that I didn't write it down. But I think this is serious enough that deserves attention from those who were involved. A short reproduction recipe, using objects from git.git that are publicly

Re: [PATCH v7 4/4] transport: add from_user parameter to is_transport_allowed

On Tue, Dec 06, 2016 at 09:53:53AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I don't know if that makes things any easier. I feel funny saying "no, > > no, mine preempts yours because it is more maint-worthy", but I think > > that order does make sense. > > > > I

Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling

On Tue, Dec 06, 2016 at 10:17:55AM -0800, Junio C Hamano wrote: > Yup, that is what I meant to say with "that is already possible" and > we are on the same page. As all three of us seem to be happy with > just dropping --abbrev and letting describe do its default thing (as > configured by

[PATCH 1/2] name-rev: allow passing multiple patterns using --refs

From: Jacob Keller Allow git name-rev to take a string list of patterns instead of only a single pattern. All patterns are matched inclusively, meaning that a ref only needs to match one pattern to be included. Add tests and documentation for this change. Signed-off-by:

Re: [PATCH] real_path: make real_path thread-safe

Brandon Williams writes: > +/* removes the last path component from 'path' except if 'path' is root */ > +static void strip_last_component(struct strbuf *path) > +{ > + if (path->len > 1) { > + char *last_slash = find_last_dir_sep(path->buf); > +

Re: [PATCH v15 23/27] bisect--helper: `bisect_replay` shell function in C

Hi Pranit and Christian and Lars ;) On 12/07/2016 12:02 AM, Pranit Bauva wrote: > On Tue, Nov 22, 2016 at 6:19 AM, Stephan Beyer wrote: >> Okay Pranit, >> >> this is the last patch for me to review in this series. >> >> Now that I have a coarse overview of what you did, I have

Re: Merging .gitmodules files

David Turner writes: > I could set my .gitattributes for the .gitmodules file to use a > custom merge driver. But: (a) I don't see an off-the-shelf one > that does what I want ("union" happens to work in the add/add > case, but not in the add/remove case or other

Re: [PATCH] real_path: make real_path thread-safe

On 12/06, Junio C Hamano wrote: > Brandon Williams writes: > > > +/* removes the last path component from 'path' except if 'path' is root */ > > +static void strip_last_component(struct strbuf *path) > > +{ > > + if (path->len > 1) { > > + char *last_slash =

What's cooking in git.git (Dec 2016, #01; Tue, 6)

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. The 'next' branch has been

[no subject]

unsubscribe

Re: [PATCH v15 19/27] bisect--helper: `bisect_state` & `bisect_head` shell function in C

Hi Pranit, On 12/06/2016 11:40 PM, Pranit Bauva wrote: > On Tue, Nov 22, 2016 at 5:42 AM, Stephan Beyer wrote: >> On 10/14/2016 04:14 PM, Pranit Bauva wrote: >>> +static int bisect_state(struct bisect_terms *terms, const char **argv, >>> + int argc) >>> +{

Merging .gitmodules files

Consider two commits: one adds file A, and the other adds file B. These commits don't conflict; you can merge them with no problem. But if the two commits instead add submodules A and B, and you try to merge, you'll likely get a conflict in .gitmodules. This seems wrong; .gitmodules happens

Re: [PATCH] real_path: make real_path thread-safe

On 07/12/16 00:10, Brandon Williams wrote: > On 12/06, Junio C Hamano wrote: >> POSIX cares about treating "//" at the very beginning of the path >> specially. Is that supposed to be handled here, or by a lot higher >> level up in the callchain? > > What exactly does "//" mean in this context?

git add -p with new file

If you do git add -p new_file it says: No changes. Which is a rather confusing message. I would expect it to show me the content of the file in patch form, in the normal way that -p works, let me edit it, etc. (Note: I am aware I can do -N first, but when I specifically enter the name of

[PATCH 2/2] describe: add support for multiple match patterns

From: Jacob Keller Convert "--match" into a string list that accumulates patterns. If any patterns are given, then include all tags that match at least one pattern. This allows the user to construct multiple small patterns and compose them. If desired, a future patch

[PATCH v4] diff: handle --no-abbrev in no-index case

There are two different places where the --no-abbrev option is parsed, and two different places where SHA-1s are abbreviated. We normally parse --no-abbrev with setup_revisions(), but in the no-index case, "git diff" calls diff_opt_parse() directly, and diff_opt_parse() didn't handle --no-abbrev

[PATCH v4] diff: handle --no-abbrev in no-index case

There are two different places where the --no-abbrev option is parsed, and two different places where SHA-1s are abbreviated. We normally parse --no-abbrev with setup_revisions(), but in the no-index case, "git diff" calls diff_opt_parse() directly, and diff_opt_parse() didn't handle --no-abbrev

Re: [PATCH v4] diff: handle --no-abbrev in no-index case

On 06/12/16 09:56 AM, Jack Bates wrote: There are two different places where the --no-abbrev option is parsed, and two different places where SHA-1s are abbreviated. We normally parse --no-abbrev with setup_revisions(), but in the no-index case, "git diff" calls diff_opt_parse() directly, and

Re: Re: Feature request: Set git svn options in .git/config file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Am 05.12.2016 um 23:54 schrieb Eric Wong: > So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor > config keys work and can be documented? yes, I can confirm, that adding this configuration keys works with git 2.1.4 work. I have

Re: [PATCH v4 1/3] update-unicode.sh: automatically download newer definition files

On 05.12.16 21:31, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> On Sat, Dec 03, 2016 at 10:00:47PM +0100, Beat Bolli wrote: >>> Checking just for the unicode data files' existence is not sufficient; >>> we should also download them if a newer version exists on the

Re: [PATCH] stash: disable renames when calling git-diff

On Tue, Dec 06, 2016 at 11:20:18AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> If you run: > >> > >> git -c diff.renames=false stash > >> > >> then it works. > > > > And here's a patch to fix it. > > Yuck. This obviously has easier to bite more people since we >

Re: [PATCH v15 08/27] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

Hey Stephan, On Thu, Nov 17, 2016 at 5:17 AM, Stephan Beyer wrote: > Hi, > > On 10/14/2016 04:14 PM, Pranit Bauva wrote: >> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c >> index d84ba86..c542e8b 100644 >> --- a/builtin/bisect--helper.c >> +++

Re: [PATCH] stash: disable renames when calling git-diff

Jeff King writes: >> If you run: >> >> git -c diff.renames=false stash >> >> then it works. > > And here's a patch to fix it. Yuck. This obviously has easier to bite more people since we enabled the renames by default. Thanks for a quick fix. I wonder why we are using "git

Re: [PATCH] stash: disable renames when calling git-diff

Jeff King writes: > On Tue, Dec 06, 2016 at 11:20:18AM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> >> If you run: >> >> >> >> git -c diff.renames=false stash >> >> >> >> then it works. >> > >> > And here's a patch to fix it. >> >> Yuck. This

Re: [PATCH] stash: disable renames when calling git-diff

Jeff King writes: > Here it is in patch form. Perhaps I am missing some subtle case that > diff-index would not handle, but it does pass the test suite. And > looking over the original thread, I don't see any particular reason to > prefer git-diff. Ah, our mails crossed ;-) I am

Re: [PATCH v15 18/27] bisect--helper: `bisect_autostart` shell function in C

Hey Stephan, On Mon, Nov 21, 2016 at 1:45 AM, Stephan Beyer wrote: > Hi, > > On 10/14/2016 04:14 PM, Pranit Bauva wrote: >> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c >> index 502bf18..1767916 100644 >> --- a/builtin/bisect--helper.c >> +++

Re: [PATCH] stash: disable renames when calling git-diff

On Tue, Dec 06, 2016 at 03:11:30PM -0500, Jeff King wrote: > > Yeah, it looks like "add -u" to me, too. Perhaps the script was old > > enough that it didn't exist back then? I dunno. > > Hmm, nope. It _was_ "git add -u" at one point and switched. See > 7aa5d43cc (stash: Don't overwrite files

Re: [PATCH] stash: disable renames when calling git-diff

Junio C Hamano writes: > Jeff King writes: > >> I think you are right that diff-index could work, though. I always >> forget that without "--cached", diff-index looks at the working tree >> files. > > I'll reword the log message while queuing. The last

Re: [PATCH] stash: disable renames when calling git-diff

On Tue, Dec 06, 2016 at 11:51:16AM -0800, Junio C Hamano wrote: > > I don't think there's a plumbing command which works for diffing the > > working tree directly to a git tree. In the long run, it might be a good > > idea to remedy that. > > I do not think that one is doing anything different

Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling

On 06/12/16 18:26, Jeff King wrote: > On Tue, Dec 06, 2016 at 10:17:55AM -0800, Junio C Hamano wrote: > >> Yup, that is what I meant to say with "that is already possible" and >> we are on the same page. As all three of us seem to be happy with >> just dropping --abbrev and letting describe do

Re* [BUG] Index.lock error message regression in git 2.11.0

Junio C Hamano writes: > Perhaps the attached would fix it (not even compile tested, though)? > > I would prefer to make 0 to mean "show error but return -1", 1 to > mean "die on error", and 2 to mean "be silent and return -1 on > error", though. Asking to be silent should be

Re: [PATCH v7 4/4] transport: add from_user parameter to is_transport_allowed

On 12/06, Jeff King wrote: > On Mon, Dec 05, 2016 at 12:04:52PM -0800, Junio C Hamano wrote: > > > > I'm sending out another reroll of this series so that in Jeff's he can > > > just call 'get_curl_allowed_protocols(-1)' for the non-redirection curl > > > option, which should make this test stop

Re: [PATCH 10/17] pathspec: simpler logic to prefix original pathspec elements

On Tue, Dec 6, 2016 at 1:51 PM, Brandon Williams wrote: > struct strbuf sb = STRBUF_INIT; > - if (prefixlen && !literal_global) { > - /* Preserve the actual prefix length of each pattern > */ > - if

Re: [PATCH 16/17] pathspec: small readability changes

On Tue, Dec 6, 2016 at 1:51 PM, Brandon Williams wrote: > A few small changes to improve readability. This is done by grouping related > assignments, adding blank lines, ensuring lines are <80 characters, etc. The 'etc' sounds a bit sloppy in the commit message. Maybe

Re: [PATCH 10/17] pathspec: simpler logic to prefix original pathspec elements

On 12/06, Stefan Beller wrote: > On Tue, Dec 6, 2016 at 1:51 PM, Brandon Williams wrote: > > > struct strbuf sb = STRBUF_INIT; > > - if (prefixlen && !literal_global) { > > - /* Preserve the actual prefix length of each > >

Re: [PATCH v15 19/27] bisect--helper: `bisect_state` & `bisect_head` shell function in C

Hey Stephan, On Tue, Nov 22, 2016 at 5:42 AM, Stephan Beyer wrote: > Hi, > > On 10/14/2016 04:14 PM, Pranit Bauva wrote: >> Reimplement the `bisect_state` shell function in C and also add a >> subcommand `--bisect-state` to `git-bisect--helper` to call it from >> git-bisect.sh .

Re: [PATCH] git-p4: add p4 shelf support

On 6 December 2016 at 02:02, Nuno Subtil wrote: > Extends the submit command to support shelving a commit instead of > submitting it to p4 (similar to --prepare-p4-only). Is this just the same as these two changes? http://www.spinics.net/lists/git/msg290755.html

Re: [PATCH] clone,fetch: explain the shallow-clone option a little more clearly

On Tue, Dec 6, 2016 at 1:28 AM, Junio C Hamano wrote: > I however offhand do not think the feature can be used to make the > repository shallower I'm pretty sure it can, though it's a waste because you should be able to shorten your history without talking to a remote server.

Re: [PATCH] commit: make --only --allow-empty work without paths

On Mon, 05 Dec 2016 12:36:19 +, Junio C Hamano wrote: > Jeff King writes: > > On Sat, Dec 03, 2016 at 07:59:49AM +0100, Andreas Krey wrote: ... > >> Tool: git commit --allow-empty -m 'FIX: A-123' > > > > OK. I think "tool" is slightly funny here, but I get that is part of the >

INFO

Did you receive my last e-mail … You’re sincerely, Savelieva Costa

[PATCH v2 2/6] shallow.c: stop abusing COMMIT_SLAB_SIZE for paint_info's memory pools

We need to allocate a "big" block of memory in paint_alloc(). The exact size does not really matter. But the pool size has no relation with commit-slab. Stop using that macro here. Signed-off-by: Nguyễn Thái Ngọc Duy --- shallow.c | 6 -- 1 file changed, 4 insertions(+),

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Tue, Dec 06, 2016 at 02:16:35PM +0100, Johannes Schindelin wrote: > > Johannes Schindelin writes: > > > > > Seriously, do you really think it is a good idea to have > > > git_config_get_value() *ignore* any value in .git/config? > > > > When we do not know

Re: [PATCH] difftool: fix dir-diff index creation when in a subdirectory

Hi David, On Mon, 5 Dec 2016, David Aguilar wrote: > 9ec26e797781239b36ebccb87c590e5778358007 corrected how path arguments How about using the "whatis" instead, i.e. "9ec26e7977 (difftool: fix argument handling in subdirs, 2016-07-18)"? Ciao, Dscho

[PATCH v2 0/6] shallow.c improvements

After staring not-so-hard and not-for-so-long at the code. This is what I come up with. Rasmus I replaced two of your commits with my own (and thank you for giving me an opportunity to refresh my memory with this stuff). The first two commits are new and the result of Jeff's observation on

Re: [PATCH v2 0/6] shallow.c improvements

On Tue, Dec 6, 2016 at 8:42 PM, Jeff King wrote: > The final one _seems_ reasonable after reading your explanation, but I > lack enough context to know whether or not there might be a corner case > that you're missing. I'm inclined to trust your assessment on it. Yeah I basically

[PATCH v2 1/6] shallow.c: rename fields in paint_info to better express their purposes

paint_alloc() is basically malloc(), tuned for allocating a fixed number of bits on every call without worrying about freeing any individual allocation since all will be freed at the end. It does it by allocating a big block of memory every time it runs out of "free memory". "slab" is a poor

Re: [PATCH v2 0/6] shallow.c improvements

On Tue, Dec 06, 2016 at 07:53:33PM +0700, Nguyễn Thái Ngọc Duy wrote: > Nguyễn Thái Ngọc Duy (4): > shallow.c: rename fields in paint_info to better express their purposes > shallow.c: stop abusing COMMIT_SLAB_SIZE for paint_info's memory pools > shallow.c: make paint_alloc slightly more

Re: [PATCH v7 4/4] transport: add from_user parameter to is_transport_allowed

On Mon, Dec 05, 2016 at 12:04:52PM -0800, Junio C Hamano wrote: > > I'm sending out another reroll of this series so that in Jeff's he can > > just call 'get_curl_allowed_protocols(-1)' for the non-redirection curl > > option, which should make this test stop barfing. > > I was hoping to

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

Hi Junio, On Mon, 5 Dec 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Seriously, do you really think it is a good idea to have > > git_config_get_value() *ignore* any value in .git/config? > > When we do not know ".git/" directory we see is the

[PATCH v2 4/6] shallow.c: avoid theoretical pointer wrap-around

From: Rasmus Villemoes The expression info->free+size is technically undefined behaviour in exactly the case we want to test for. Moreover, the compiler is likely to translate the expression to (unsigned long)info->free + size > (unsigned long)info->end where there's

[PATCH v2 5/6] shallow.c: bit manipulation tweaks

From: Rasmus Villemoes First of all, 1 << 31 is technically undefined behaviour, so let's just use an unsigned literal. If i is 'signed int' and gcc doesn't know that i is positive, gcc generates code to compute the C99-mandated values of "i / 32" and "i % 32", which is

[PATCH v2 6/6] shallow.c: remove useless code

Some context before we talk about the removed code. This paint_down() is part of step 6 of 58babff (shallow.c: the 8 steps to select new commits for .git/shallow - 2013-12-05). When we fetch from a shallow repository, we need to know if one of the new/updated refs needs new "shallow commits" in

[PATCH v2 3/6] shallow.c: make paint_alloc slightly more robust

paint_alloc() allocates a big block of memory and splits it into smaller, fixed size, chunks of memory whenever it's called. Each chunk contains enough bits to present all "new refs" [1] in a fetch from a shallow repository. We do not check if the new "big block" is smaller than the requested

Re: [PATCH] stash: disable renames when calling git-diff

Jeff King writes: > I think you are right that diff-index could work, though. I always > forget that without "--cached", diff-index looks at the working tree > files. I'll reword the log message while queuing. It was super surprising to me to hear that there was something "git

Re: [PATCH] stash: disable renames when calling git-diff

On Tue, Dec 06, 2016 at 12:22:25PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I think you are right that diff-index could work, though. I always > > forget that without "--cached", diff-index looks at the working tree > > files. > > I'll reword the log message while

[PATCH 13/17] pathspec: create parse_long_magic function

Factor out the logic responsible for parsing long magic into its own function. As well as hoist the prefix check logic outside of the inner loop as there isn't anything that needs to be done after matching "prefix:". Signed-off-by: Brandon Williams --- pathspec.c | 92

[PATCH 05/17] pathspec: remove the deprecated get_pathspec function

Now that all callers of the old 'get_pathspec' interface have been migrated to use the new pathspec struct interface it can be removed from the codebase. Since there are no more users of the '_raw' field in the pathspec struct it can also be removed. This patch also removes the old functionality

[PATCH 12/17] pathspec: create parse_short_magic function

Factor out the logic responsible for parsing short magic into its own function. Signed-off-by: Brandon Williams --- pathspec.c | 54 -- 1 file changed, 36 insertions(+), 18 deletions(-) diff --git a/pathspec.c b/pathspec.c

[PATCH 11/17] pathspec: factor global magic into its own function

Create helper functions to read the global magic environment variables in additon to factoring out the global magic gathering logic into its own function. Signed-off-by: Brandon Williams --- pathspec.c | 120 + 1

[PATCH 10/17] pathspec: simpler logic to prefix original pathspec elements

The logic used to prefix an original pathspec element with 'prefix' magic is more general purpose and can be used for more than just short magic. Remove the extra code paths and rename 'prefix_short_magic' to 'prefix_magic' to better indicate that it can be used in more general situations. Also,

[PATCH 09/17] pathspec: always show mnemonic and name in unsupported_magic

For better clarity, always show the mnemonic and name of the unsupported magic being used. This lets users have a more clear understanding of what magic feature isn't supported. And if they supplied a mnemonic, the user will be told what its corresponding name is which will allow them to more

[PATCH 04/17] ls-tree: convert show_recursive to use the pathspec struct interface

Convert 'show_recursive()' to use the pathspec struct interface from using the '_raw' entry in the pathspec struct. Signed-off-by: Brandon Williams --- builtin/ls-tree.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/builtin/ls-tree.c

[PATCH 07/17] mv: small code cleanup

Now that the call to 'parse_pathspec()' doesn't modify the passed in const char **array there isn't a need to duplicate the pathspec element prior to freeing the intermediate strings. This small cleanup just makes the code a bit easier to read. Signed-off-by: Brandon Williams

[PATCH 01/17] mv: convert to using pathspec struct interface

Convert the 'internal_copy_pathspec()' function to use the pathspec struct interface from using the deprecated 'get_pathspec()' interface. In addition to this, fix a memory leak caused by only duplicating some of the pathspec elements. Instead always duplicate all of the the pathspec elements as

[PATCH 02/17] dir: convert create_simplify to use the pathspec struct interface

Convert 'create_simplify()' to use the pathspec struct interface from using the '_raw' entry in the pathspec. Signed-off-by: Brandon Williams --- dir.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/dir.c b/dir.c index

[PATCH 00/17] pathspec cleanup

The intent of this series is to cleanup some of the pathspec initialization code as well as finally migrating the remaining users of the _raw field or get_pathspec() to the pathspec struct interface. This way both the _raw field and get_pathspec() can be removed from the codebase. This also

[PATCH 03/17] dir: convert fill_directory to use the pathspec struct interface

Convert 'fill_directory()' to use the pathspec struct interface from using the '_raw' entry in the pathspec struct. Signed-off-by: Brandon Williams --- dir.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dir.c b/dir.c index 7df292b..8730a4f 100644 ---

[PATCH 06/17] pathspec: copy and free owned memory

The 'original' string entry in a pathspec_item is only duplicated some of the time, instead always make a copy of the original and take ownership of the memory. Since both 'match' and 'original' string entries in a pathspec_item are owned by the pathspec struct, they need to be freed when

[PATCH 15/17] pathspec: create strip submodule slash helpers

Factor out the logic responsible for stripping the trailing slash on pathspecs referencing submodules into its own function. Signed-off-by: Brandon Williams --- pathspec.c | 68 ++ 1 file changed, 42 insertions(+),

[PATCH 14/17] pathspec: create parse_element_magic helper

Factor out the logic responsible for the magic in a pathspec element into its own function. Also avoid calling into the parsing functions when `PATHSPEC_LITERAL_PATH` is specified since it causes magic to be ignored and all paths to be treated as literals. Signed-off-by: Brandon Williams

[PATCH 08/17] pathspec: remove unused variable from unsupported_magic

Removed unused variable 'n' from the 'unsupported_magic()' function. Signed-off-by: Brandon Williams --- pathspec.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/pathspec.c b/pathspec.c index 8f367f0..ec0d590 100644 --- a/pathspec.c +++ b/pathspec.c

[PATCH 16/17] pathspec: small readability changes

A few small changes to improve readability. This is done by grouping related assignments, adding blank lines, ensuring lines are <80 characters, etc. Signed-off-by: Brandon Williams --- pathspec.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff

[PATCH 17/17] pathspec: remove outdated comment

Remove part of the function header comment to prefix_pathspec as it is no longer relevant. Signed-off-by: Brandon Williams --- pathspec.c | 9 - 1 file changed, 9 deletions(-) diff --git a/pathspec.c b/pathspec.c index 8a07b02..66db257 100644 --- a/pathspec.c +++

Re: [BUG] Index.lock error message regression in git 2.11.0

Robbie Iannucci writes: > I just upgraded to 2.11.0 from 2.10.2, and I noticed that some > commands no longer print an error message when the `index.lock` file > exists (such as `git merge --ff-only`). > > It appears this bug was introduced in >

Re: [PATCH v2] tag, branch, for-each-ref: add --ignore-case for sorting and filtering

Nguyễn Thái Ngọc Duy writes: > This options makes sorting ignore case, which is great when you have > branches named bug-12-do-something, Bug-12-do-some-more and > BUG-12-do-what and want to group them together. Sorting externally may > not be an option because we lose

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

Brandon Williams writes: > On 11/30, Junio C Hamano wrote: >> Junio C Hamano forgot to Cc: the author of the >> most relevant change to the issue, d426430e6e ("pathspec: warn on >> empty strings as pathspec", 2016-06-22). >> ... > > I've been doing a bit of

Re: [PATCH] xdiff: Do not enable XDL_FAST_HASH by default

Jeff King writes: > This is a nice incremental step in the sense that people can still > enable it if they want to in order to time it, play with it, etc. But > given what we know, I wonder if the help text here should warn people. > > Or I guess we could move straight to dropping

  1   2   >