Re: [PATCH] doc: clarify non-recursion for ignore paths like `foo/`

> I think it makes more sense to document it where it's documented now, > i.e. under how "!" works in general, since this is an edge case with > negative matching. My reasoning is/was that while yes, that's true, I think it's likely that the positive matches would be added before (in terms of git

Re: [PATCH] doc: clarify non-recursion for ignore paths like `foo/`

since it requires recursion into subdirectories." `foo/*` will let `!foo/file` work but still seems to prevent `!foo/bar/file`. On Wed, Mar 21, 2018 at 7:53 AM, Dakota Hawkins <dak...@dakotahawkins.com> wrote: > First, apologies since I didn't get the in-reply-to correct in my > emai

Re: [PATCH] doc: clarify non-recursion for ignore paths like `foo/`

First, apologies since I didn't get the in-reply-to correct in my email header. I'm not sure how to do that (using gmail/gsuite). Meant to reply to: https://public-inbox.org/git/20180321075041.ga24...@sigill.intra.peff.net/ > Just before the context your patch quotes, we have this in

[PATCH] doc: clarify non-recursion for ignore paths like `foo/`

sequent matching patterns to matter, while they do not. For example: foo/ # Ignores `foo` directories and everything inside of them !foo/*.txt # Does nothing Explain this behavior (and its implications) more explicitly. Signed-off-by: Dakota Hawkins <daktoahawk...@gmail.com> ---

Re: .gitattributes override behavior (possible bug, or documentation bug)

> I think it means "for the rest of the description of how the patterns > work". I.e., "foo/" matches as "foo" when the rest of the matching rules > are applied. I agree it's a bit awkward. Patches welcome. :) I'd be more than happy to do that! It will take me a while, this (email and

Re: .gitattributes override behavior (possible bug, or documentation bug)

pasted in there, and the exclusion was an attempt to exclude some things that shouldn't have been ignored. Even in the same file, the exclusion doesn't work. I had to change it to: build/* ... !alpine/build/ Good times :) - Dakota On Wed, Mar 21, 2018 at 3:36 AM, Dakota Hawkins <

Re: .gitattributes override behavior (possible bug, or documentation bug)

> I think that ignoring all of /ignore-most/ is much more efficient, since > we don't have to enumerate the paths inside it at all (which is why the > current behavior works as it does). That's definitely true, but I wonder what the impact would be for most cases (even for most cases with large

Re: .gitattributes override behavior (possible bug, or documentation bug)

e "desired" effect. What do you think? On Tue, Mar 20, 2018 at 12:28 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Tue, Mar 20, 2018 at 5:40 AM, Jeff King <p...@peff.net> wrote: >> On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: >> >>>

Re: .gitattributes override behavior (possible bug, or documentation bug)

> So I think the "recommended subset" is basically "everything but these > few constructs". We just need to document them. ;) Mentioned so-far/running list? - Matching directories recursively, or at all I guess (e.g. "/") - (???) Instead: "/*" - Negative matches - (???) Instead: Is there any

Re: [PATCH] doc/gitattributes: mention non-recursive behavior

That's perfect, thank you so much! On Tue, Mar 20, 2018 at 12:14 AM, Jeff King wrote: > On Tue, Mar 20, 2018 at 12:04:11AM -0400, Jeff King wrote: > >> > I guess my takeaway is that it would be _good_ if the gitattributes >> > documentation contained the caveat about not matching

Re: .gitattributes override behavior (possible bug, or documentation bug)

> Right. The technical reason is mostly "that is not how it was designed, > and it would possibly break some corner cases if we switched it now". I'm just spitballing here, but do you guys think there's any subset of the combined .gitignore and .gitattributes matching functionality that could at

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:33 PM, Junio C Hamano wrote: > Jeff King writes: > >> The best you can probably do is: >> >> /.readme-docs/* diff=foo >> >> Since you have no diff.foo.* config, that will behave in the default way >> (including respecting the usual

Re: .gitattributes override behavior (possible bug, or documentation bug)

explicit exclusions without any "diff=foo" shenanigans. Thanks again, - Dakota On Mon, Mar 19, 2018 at 11:10 PM, Dakota Hawkins <dak...@dakotahawkins.com> wrote: > Thanks for the quick reply! > > On Mon, Mar 19, 2018 at 10:34 PM, Jeff King <p...@peff.net> wrote:

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thanks for the quick reply! On Mon, Mar 19, 2018 at 10:34 PM, Jeff King <p...@peff.net> wrote: > On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > >> Summary: Trying to apply attributes to file extensions everywhere >> except in one directory. >> >

.gitattributes override behavior (possible bug, or documentation bug)

According to the gitattributes docs: "When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute." I had a need to do this recently, and while the attributes are git-lfs specific, I think the issue may be generic. Summary: Trying

Re: [RFC] Case insensitive Git attributes

Apologies for the delayed bump. I think because we're talking about affecting the behavior of .gitattributes that it would be better to have a distinct .gitattributes option, whether or not you also have a similar config option. Since .gitattributes is versioned and config options are not, I

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

> As you know currently the checkout doesn't touch submodules, i.e. > you have to run "git submodule update" whenever the submodule > changes. So when you checkout a different part of history, that moved > a submodule, this will fail as the submodule still resides at the old > place (and may have

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

, Dakota On Tue, Sep 6, 2016 at 4:02 PM, Dakota Hawkins <dakotahawk...@gmail.com> wrote: > On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller <sbel...@google.com> wrote: >> On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <dakotahawk...@gmail.com> >> wrote: &

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

You guys are the best, I'm really impressed with all of the responses to this issue! Thank you all for all of your hard work! Dakota On Fri, Sep 9, 2016 at 3:00 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Johannes Schindelin

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller <sbel...@google.com> wrote: > On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <dakotahawk...@gmail.com> > wrote: >> Below is a simple reproduction of the issue. >> >> The _real_ problem is that this is how our p

Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

Is there any additional information I could provide that would be helpful? Dakota On Fri, Sep 2, 2016 at 3:22 PM, Dakota Hawkins <dakotahawk...@gmail.com> wrote: > Below is a simple reproduction of the issue. > > The _real_ problem is that this is how our pull request merges

If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

Below is a simple reproduction of the issue. The _real_ problem is that this is how our pull request merges work, they're not allowed to do fast-forward merges. To work around this we are having to split this up into two pull requests/merges: One that copies the submodules to the new location and

Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Dakota, > > On Tue, 23 Aug 2016, Dakota Hawkins wrote: > >> I use GFW almost exclusively, but I pretty much always consult the >> upstream documentation anyway (because

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

On Tue, Aug 23, 2016 at 5:42 PM, Junio C Hamano wrote: > > Junio C Hamano writes: > > > One way to avoid that risk may be to release the new feature as > > "experimental-and-subject-to-change", so that interested users on > > Windows can actually try it out

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 6:49 PM, Jeff King wrote: > On Fri, Jul 29, 2016 at 03:45:35PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > TBH, I'm not sure anybody cares that much between the three. Even before >> > user.useConfigOnly, this could be an

Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

but if that's the case I'd be interested to know what they are (I'd love to go back to the golang people and tell them to re-open my bug because there's nothing wrong with git). Thanks for your time, and please let me know if you'd like any additional information. - Dakota Hawkins -- To u