One extra note:
I was burned by this just a few hours ago in a new repo (but because
of this discussion I realized what the problem was pretty quickly).
In the top-level .gitignore I had
build/
...
!alpine/build/
where `build/` was a stock ignore line among hundreds that I blindly
> 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
On Tue, Mar 20, 2018 at 11:22:02PM -0400, Dakota Hawkins wrote:
> Thinking about this a little more, I'm now attracted to the idea that
> its .gitignore that's weird.
>
> As I understand it, .gitignore stops recursion when there's a
> directory match (`somedir/`) but also explicitly allows
On Tue, Mar 20, 2018 at 05:41:52PM +0100, Duy Nguyen wrote:
> > +The rules by which the pattern matches paths are the same as in
> > +`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions:
> > +
> > + - negative patterns are forbidden
>
> After 8b1bd02415 (Make !pattern in
Hi Johannes,
Thanks for the feedback. Thanks to you, I realized my proposal was
a bit ambitious. Both git-stash and git-rebase are big
commitment. After much analyzing, I found out I cannot complete
both in the given time frame. So, I decided to stick to one and
complete it. I decided to stick
On Tue, Mar 20, 2018 at 10:52:16PM +, Ramsay Jones wrote:
> > Maybe too clever, but I think you could just do:
> >
> > unsigned int saved_namelen = 0;
> > ...
> > saved_namelen = ce_namelen(ce);
> > ...
> > if (saved_namelen)
> > ce->ce_namelen = saved_namelen;
> >
101 - 106 of 106 matches
Mail list logo
