On Fri, Oct 28, 2016 at 3:41 AM, Eric Wong wrote:
> Johannes Schindelin wrote:
>> I know you are a fan of testing things thoroughly in the test suite, but I
>> have to say that it is getting out of hand, in particular due to our
>> over-use of shell script idioms (which really only run fast on Li
On Thu, Oct 27, 2016 at 10:55 PM, Johannes Sixt wrote:
> One point is that the DCLP idiom must be implemented correctly. There are
> solutions, of course, and when the initialization is over, we have a
> miniscule overhead at each pthread_mutex_lock call.
>
Right, this I understood, but appeared
Junio C Hamano writes:
> Cc'ed those who touched either "git-bisect.sh" or "builtin/bisect-helper.c"
> in our relatively recent past.
>
> Does any of you (and others on the list) have time and inclination
> to review this series?
Unfortunately, I have essentially zero-bandwidth to do that in the
Am 27.10.2016 um 23:49 schrieb Jacob Keller:
Ok, so I've been reading this thread. I don't understand your
objections to emulating in this way.. Could you clearly spell out why
you believe this solution isn't acceptable? So far all I've understood
was "it's not critical sections" and "it penalize
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Linus Torvalds writes:
> >
> >> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote:
> >>>
> >>> Would the best endgame shape for this function be to open with
> >>> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2)
> >>> b
On Thu, Oct 27, 2016 at 7:50 PM, Junio C Hamano wrote:
>
> Unless you are imagining "git grep" to initialize and checkout a
> submodule that is not checked out on-demand, I do not think you have
> any reason to even look at ".gitmodules" for the purpose of "I want
> to grep both in superproject
--
Are you in need of easy qualifying business or personal loans? We offer all
kinds of loans at 3% contact us today at. Carmona.gomez402@gmail.comFull
Name:Need Loan Amount:Loan Duration:Phone Number:Applied before :?State:Monthly
Income:Country:contact us today at. carmona.gomez402@gmail.co
1. My repo has a branch named 'v1' that is tracking 'origin/v1'.
2. My repo has a tag named 'v1'.
3. I have "push.default" set to "upstream".
I made a commit on branch 'v1' and tried doing a push:
# git push
error: src refspec v1 matches more than one.
error: failed to push some refs
Jeff King writes:
> However, as I said elsewhere, I'm not convinced this feature is all that
> helpful for in-repository .gitignore files, and I think it does
> introduce compatibility complications. People with older git will not
> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely
Stefan Beller writes:
>> Just a few brief comments, before reading the patches carefully.
>>
>> * It is somewhat surprising that [1/5] is even needed (in other
>>words, I would have expected something like this to be already
>>there, and my knee-jerk reaction was "Heh, how does 'git stat
Junio C Hamano writes:
> Linus Torvalds writes:
>
>> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote:
>>>
>>> Would the best endgame shape for this function be to open with
>>> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2)
>>> but ignoring an error from it, I guess? T
Linus Torvalds writes:
> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote:
>>
>> Would the best endgame shape for this function be to open with
>> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2)
>> but ignoring an error from it, I guess? That would be the closest
>> to wh
On Thu, Oct 27, 2016 at 4:26 PM, Junio C Hamano wrote:
> Brandon Williams writes:
>
>> As for the rest of the series, it should be ready for review or comments.
>
> Just a few brief comments, before reading the patches carefully.
>
> * It is somewhat surprising that [1/5] is even needed (in othe
On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote:
>
> Would the best endgame shape for this function be to open with
> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2)
> but ignoring an error from it, I guess? That would be the closest
> to what we historically had, I would
Linus Torvalds writes:
> But the basic issue still remains - I'd really prefer to have NOATIME
> stay around for all those poor misguided souls that for some reason
> don't like "relatime" or run old kernels. But whether it is with
> O_NOATIME at open time or with F_SETFL, I don't care.
Understo
On Thu, 27 Oct 2016, John Rood wrote:
Thanks, I think changing the default for windows is a good idea.
notepad doesn't work well with unix line endings, wordpad handles the files much
more cleanly.
David Lang
Brandon Williams writes:
> As for the rest of the series, it should be ready for review or comments.
Just a few brief comments, before reading the patches carefully.
* It is somewhat surprising that [1/5] is even needed (in other
words, I would have expected something like this to be alread
On Thu, Oct 27, 2016 at 4:09 PM, Linus Torvalds
wrote:
>
> That said, now that I think about it, I should double-check: maybe
> open() doesn't actually set atime at all, and we *could* do NOATIME
> with SETFL after all.
Checked. Yup. O_NOATIME could easily be done with SETFL:, because as
with O_C
Thanks. I wasn't aware of --no-edit, but that is indeed exactly what I
was looking for.
I think your point about encouraging users to make good use of commit
messages is good.
My concern though is that vim isn't encouraging users to leave good
messages as much as it is scaring them away from leavi
On Thu, Oct 27, 2016 at 3:56 PM, Junio C Hamano wrote:
>
> I also thought O_NOATIME shouldn't be an effective fcntl(2) thing,
> for the reasons you stated above, when I was studying the area
> because of the discussion on these patches. I was surprised to see
> that http://man7.org/linux/man-page
On 28/10/16 10:07, Jeff King wrote:
> I think it does
> introduce compatibility complications.
If this is not a show stopper, I am happy to knock out a short
functional spec. I'll give it some hours before I begin.
Linus Torvalds writes:
> Note that you can *not* do the same thing with O_NOATIME, since the
> whole point of O_NOATIME is that it changes the behavior of the open
> itself (unlike O_CLOEXEC which changes _later_ behavior, and can
> always be replaced by FD_CLOEXEC fnclt modulo races that are
> i
John Rood writes:
[administrivia: do not top post]
> What I'm really seeking is not a make-shift solution for myself, but
> an intuitive solution for the novice user-base at large.
Well, there are -m and --no-edit. Recording commits with useless
single liner is a bad habit to get into, and cha
What I'm really seeking is not a make-shift solution for myself, but
an intuitive solution for the novice user-base at large.
On Thu, Oct 27, 2016 at 5:27 PM, Junio C Hamano wrote:
> John Rood writes:
>
>> I suppose I can do git config --global core.editor notepad
>> However, this really only ad
John Rood writes:
> On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller wrote:
>> On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote:
>>> Users should be able to configure Git to not send them into a Vim editor.
>>>
>>> When users pull commits, and a new commit needs to be created for a
>>> merge, Git
Thanks, I think changing the default for windows is a good idea.
The -m indeed accomplishes one-line messages when you are voluntarily
doing a commit. However, the scenario I mentioned is "When users pull
commits, and a new commit needs to be created for the merge" In this
situation, the user isn
Add two helper functions to submodules.c.
`is_submodule_initialized()` checks if a submodule has been initialized
at a given path and `is_submodule_checked_out()` check if a submodule
has been checked out at a given path.
Signed-off-by: Brandon Williams
---
submodule.c | 39 +
Add `GREP_SOURCE_SUBMODULE` as a grep_source type and cases for this new
type in the various switch statements in grep.c.
When initializing a grep_source with type `GREP_SOURCE_SUBMODULE` the
identifier can either be NULL (to indicate that the working tree will be
used) or a SHA1 (the REV of the s
Allow grep to recognize submodules and recursively search for patterns in
each submodule. This is done by forking off a process to recursively
call grep on each submodule. The top level --super-prefix option is
used to pass a path to the submodule which can in turn be used to
prepend to output or
Teach grep to recursively search in submodules when provided with a
object. This allows grep to search a submodule based on the state
of the submodule that is present in a commit of the super project.
When grep is provided with a object, the name of the object is
prefixed to all output. In orde
teach submodules to load a '.gitmodules' file from a commit sha1. This
enables the population of the submodule_cache to be based on the state
of the '.gitmodules' file from a particular commit.
Signed-off-by: Brandon Williams
---
cache.h| 2 ++
config.c | 8
sub
On Thu, Oct 27, 2016 at 3:24 AM, Jeff King wrote:
>
> +cc Linus as the original author of 144bde78e9 in case there is
> something subtle I'm missing, but this really just seems like it's
> an outdated optimization.
I'd *really* like to keep O_NOATIME if at all possible. It made a huge
difference
This patch series adds some basic api functions to the submodule interface as
well as teaching grep to recursively search in submodules.
The additions to the submodule interface allow grep to verify that a submodule
has been initialized and checked out prior to launching a child process. One
issu
On 28/10/16 10:07, Jeff King wrote:
> I think it does
> introduce compatibility complications. People with older git will not
> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local
> matter.
I know. I don't think it's a serious compatibility issue, but more
important people may
On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote:
> Users should be able to configure Git to not send them into a Vim editor.
>
> When users pull commits, and a new commit needs to be created for a
> merge, Git's current way of determining a commit message is to send
> the user into a Vim window s
John Rood writes:
> I suppose I can do git config --global core.editor notepad
> However, this really only addresses my second concern.
>
> My first concern is that using a text editor at all seems like
> overkill in many scenarios.
Nobody stops you from writing a "type whatever you want; I won'
I suppose I can do git config --global core.editor notepad
However, this really only addresses my second concern.
My first concern is that using a text editor at all seems like
overkill in many scenarios.
For that reason, I still think the other two options I mentioned would
be beneficial.
On Thu
This revamps the API of the attr subsystem to be thread safe.
Before we had the question and its results in one struct type.
The typical usage of the API was
static struct git_attr_check *check;
if (!check)
check = git_attr_check_initl("text", NULL);
git_check_attr(path, chec
On 28/10/16 10:55, Aaron Pelly wrote:
> 2) I fetch a repo with a hostile ignore file. It includes files from
> $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay
> attention. Commit. Push. Problems if my test data comes from production.
>
> Is this mitigated currently?
>
> Not that gi
Tests run with --valgrind call git commands through a wrapper script
that invokes valgrind on them. This script (valgrind.sh) is in turn
invoked through symlinks created for each command in t/valgrind/bin/.
Since e6e7530d (test helpers: move test-* to t/helper/ subdirectory)
these symlinks have b
Unfortunately, in my case I'm on windows (my company's choice, not mine).
On Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller wrote:
> On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote:
>> Users should be able to configure Git to not send them into a Vim editor.
>
> See https://git-scm.com/docs/git-va
On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote:
> Users should be able to configure Git to not send them into a Vim editor.
See https://git-scm.com/docs/git-var
GIT_EDITOR
Text editor for use by Git commands. The value is meant to be interpreted
by the shell when it is used. Examples: ~/bin/v
> there isn't really a great place to put a dynamic initialization.
Answering this question specifically (Where to put it?),
I am about to send out a patch that puts it in compat/mingw.c:2232:
diff --git a/compat/mingw.c b/compat/mingw.c
index 3fbfda5..9881c3d 100644
--- a/compat/mingw.c
+++ b/co
On 28/10/16 09:55, Jeff King wrote:
> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
>
>>> - we parse possibly-hostile .gitignore files from cloned repositories.
>>> What happens when I include ask to include /etc/passwd? Probably
>>> nothing, but there are setups where it
Users should be able to configure Git to not send them into a Vim editor.
When users pull commits, and a new commit needs to be created for a
merge, Git's current way of determining a commit message is to send
the user into a Vim window so that they can write a message. There are
2 reasons why thi
On Thu, Oct 27, 2016 at 1:05 PM, Johannes Sixt wrote:
>> The implementation under discussion (well we did not discuss the
>> implementation a
>> whole lot yet) ...
>
>
> There's not a whole lot to discuss: it must be rewritten from scratch (it's
> not just the memory barriers, it is everything els
Jeff King writes:
> +cc Linus as the original author of 144bde78e9 in case there is
> something subtle I'm missing, but this really just seems like it's
> an outdated optimization.
>
> -- >8 --
> Subject: [PATCH] sha1_file: stop opening files with O_NOATIME
>
> When we open object files, we try t
On Thu, Oct 27, 2016 at 2:04 PM, Jeff King wrote:
> I'm not convinced this is needed for in-repo .gitignore files. The point
> is that you are pulling together separate files that may be administered
> independently. But git repositories inherently have a whole-project
> view. I'm not sure that se
On Wed, Oct 26, 2016 at 6:33 AM, Duy Nguyen wrote:
> (sorry if this should have been answered if I went through the series
> patch by patch, I wanted to do a proper review but finally have to
> admit to myself I won't, so I just skim through a single giant diff
> instead)
>
> On Sun, Oct 23, 2016
On 28/10/16 10:04, 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 together, and with no recursion. I
tbo...@web.de writes:
> 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 done, and the first CRLF is found.
>
> Similar when
On Thu, Oct 27, 2016 at 04:55:08PM -0400, Jeff King wrote:
> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
>
> > > - we parse possibly-hostile .gitignore files from cloned repositories.
> > > What happens when I include ask to include /etc/passwd? Probably
> > > nothing,
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 together, and with no recursion. I.e., behave "as if" the
> > user had run
On 28/10/16 08:48, Jacob Keller wrote:
> I would strongly prefer rc.d style directories either with a "if the
> .gitignore is a directory treat it like rc.d" or even "add support for
> .gitignore.d as well as .gitignore"
I think adding .gitignore.d shouldn't break existing systems, is
intuitive, a
On Mon, Oct 24, 2016 at 2:07 PM, Stefan Beller wrote:
> On Sun, Oct 23, 2016 at 8:07 AM, Ramsay Jones
> wrote:
>>
>>
>> On 23/10/16 00:32, Stefan Beller wrote:
>>> From: Junio C Hamano
>>>
>>> Export attr_name_valid() function, and a helper function that
>>> returns the message to be given when
On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
> > - we parse possibly-hostile .gitignore files from cloned repositories.
> > What happens when I include ask to include /etc/passwd? Probably
> > nothing, but there are setups where it might matter (e.g., something
> > li
Junio C Hamano wrote:
> Just peeking from the sideline, but the your squash looks like an
> improvement to me.
Thanks.
> Hopefully the final version after your interaction with Dscho can
> come to me via another "pull this now"?
Not sure if I'll be online the next few days,
but I've preeptively
Johannes Schindelin wrote:
> I know you are a fan of testing things thoroughly in the test suite, but I
> have to say that it is getting out of hand, in particular due to our
> over-use of shell script idioms (which really only run fast on Linux, not
> a good idea for a portable software).
How mu
On 27/10/16 23:50, Jeff King wrote:
> I'd shy away from an actual include directive, as it raises a lot of
> complications:
I'm leaning that way now too.
> - we parse possibly-hostile .gitignore files from cloned repositories.
> What happens when I include ask to include /etc/passwd? Probab
On Thu, Oct 27, 2016 at 6:59 PM, Junio C Hamano wrote:
> Cc'ed those who touched either "git-bisect.sh" or "builtin/bisect-helper.c"
> in our relatively recent past.
>
> Does any of you (and others on the list) have time and inclination
> to review this series?
As part of my mentoring Pranit for
Am 27.10.2016 um 21:08 schrieb Stefan Beller:
On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano wrote:
Johannes Sixt writes:
Am 27.10.2016 um 19:01 schrieb Stefan Beller:
...
It is not possible to mark a mutex uninitialized on Windows without an
extra piece of data. A solution would become qu
tbo...@web.de writes:
> 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 the
> analyze for "text=auto" without slurping the
On Thu, Oct 27, 2016 at 3:50 AM, Jeff King wrote:
> On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:
>
>> The use case for this is where I did not write my own rules, but I want
>> to keep them updated. https://github.com/github/gitignore is a damn good
>> resource, but I want to pull
Eric Wong writes:
> Johannes Schindelin wrote:
>> +++ b/perl/Git/SVN.pm
>> @@ -1658,6 +1658,11 @@ sub tie_for_persistent_memoization {
>> if ($memo_backend > 0) {
>> tie %$hash => 'Git::SVN::Memoize::YAML', "$path.yaml";
>> } else {
>> +# first verify that any
On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Am 27.10.2016 um 19:01 schrieb Stefan Beller:
>> ...
>> It is not possible to mark a mutex uninitialized on Windows without an
>> extra piece of data. A solution would become quite complicated quite
>> quickly, a
Johannes Sixt writes:
> Am 27.10.2016 um 19:01 schrieb Stefan Beller:
> ...
> It is not possible to mark a mutex uninitialized on Windows without an
> extra piece of data. A solution would become quite complicated quite
> quickly, and at the cost of additional operations that are in the same
> ba
From: "Junio C Hamano"
Cody Sehl writes:
The first few paragraphs in the git-rebase.txt documentation lay out the
steps git takes during a rebase:
1. everything from `..HEAD` is saved to a temporary area
2. `HEAD` is set to ``
3. the changes held in the temporary area are applied one by one
Michael J Gruber writes:
> It did not exist, but even at that point in time, "git log A..B" listed
> only commits between the merge base and B, not those which are only in A
> and not in B. Whereas "git diff A B" shows the differences between the
> endpoints A and B.
I think you are speaking wit
Stefan Beller writes:
> The pathspec mechanism is extended via the new
> ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it
> requires paths to not just match the given pattern but also have the
> specified attrs attached for them to be chosen.
I was looking at preload-index.c
Am 27.10.2016 um 19:01 schrieb Stefan Beller:
Johannes Sixt writes:
This is the pessimization that I am talking about. I would not mind at all if
it were only for the attribute subsystem, but the proposed patch would
pessimize *all* uses of pthread_mutex_lock.
It would only pessimize *uninitia
Jeff King writes:
> Commit 3f2e2297b9 (add an extra level of indirection to
> main(), 2016-07-01) added a declaration to git-compat-util.h,
> but it was accidentally placed after the final #endif that
> guards against multiple inclusions.
>
> This doesn't have any actual impact on the code, since
Commit 3f2e2297b9 (add an extra level of indirection to
main(), 2016-07-01) added a declaration to git-compat-util.h,
but it was accidentally placed after the final #endif that
guards against multiple inclusions.
This doesn't have any actual impact on the code, since it's
not incorrect to repeat a
On Thu, Oct 27, 2016 at 10:01:02AM -0700, Stefan Beller wrote:
> > That function can
> > be called from main() of platforms that cannot statically initialize
> > mutices,
>
> By main you mean the main() in common-main.c or cmd_main in git.c ?
Any setup or initialization for library functions ne
> Vasco Almeida (14):
> i18n: add--interactive: mark strings for translation
> i18n: add--interactive: mark simple here-documents for translation
> i18n: add--interactive: mark strings with interpolation for
> translation
> i18n: clean.c: match string with git-add--interactive.perl
>
Cc'ed those who touched convert.c or read-cache.c in our relatively
recent past with a change that affects the eol conversion codepath.
Does any of you (and others on the list) have time and inclination
to review this series?
Thanks.
> Johannes Sixt writes:
> This is the pessimization that I am talking about. I would not mind at all if
> it were only for the attribute subsystem, but the proposed patch would
> pessimize *all* uses of pthread_mutex_lock.
It would only pessimize *uninitialized* mutexes? For initialized mutexes
t
Cc'ed those who touched either "git-bisect.sh" or "builtin/bisect-helper.c"
in our relatively recent past.
Does any of you (and others on the list) have time and inclination
to review this series?
Thanks.
Andreas Schwab writes:
> On Okt 25 2016, Junio C Hamano wrote:
>
>> Somebody with a bright idea decided that vc-git-resolve-conflicts
>> variable should be on by default in Emacs 25.1 X-<
>
> This is consistent with the behaviour of the other VC backends, where it
> isn't even customizable.
The
Duy Nguyen writes:
> Christian, if we assume to go with Junio's suggestion to disable
> split-index on temporary files, the only files left we have to take
> care of are index and index.lock. I believe pruning here in this code
> will have an advantage over in "git gc --auto" because when this is
On Okt 25 2016, Junio C Hamano wrote:
> Somebody with a bright idea decided that vc-git-resolve-conflicts
> variable should be on by default in Emacs 25.1 X-<
This is consistent with the behaviour of the other VC backends, where it
isn't even customizable.
Andreas.
--
Andreas Schwab, sch...@l
Hi Hannes,
On Tue, 25 Oct 2016, Johannes Sixt wrote:
> Am 25.10.2016 um 20:13 schrieb Stefan Beller:
> > On Tue, Oct 25, 2016 at 10:15 AM, Junio C Hamano wrote:
> > > - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
> > >needs to be in the upcoming release but the "trailing
On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:
> The use case for this is where I did not write my own rules, but I want
> to keep them updated. https://github.com/github/gitignore is a damn good
> resource, but I want to pull it and include relevant bits project by
> project and/or
On Tue, Oct 25, 2016 at 5:43 PM, Duy Nguyen wrote:
>> static int write_shared_index(struct index_state *istate,
>> @@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state
>> *istate,
>> }
>> ret = rename_tempfile(&temporary_sharedindex,
>>
On 27/10/16 21:19, Alexei Lozovsky wrote:
>> I'm thinking something like ". path/to/include/file" in an ignore file,
>> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore
>> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent
>> mixture of these things.
>
> I
On Wed, Oct 26, 2016 at 11:51 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> There are occasions when you decide to abort an in-progress rebase and
>> move on to do something else but you forget to do "git rebase --abort"
>> first. Or the rebase has been in progress for so long yo
On Wed, Oct 26, 2016 at 02:15:33PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote:
> >
> >> > I actually wonder if it is worth carrying around the O_NOATIME hack at
> >> > all.
> >>
> >> Yes, I share the thought. We no long
On 27/10/16 15:22, Stefan Beller wrote:
>> The use case for this is where I did not write my own rules, but I want
>> to keep them updated. https://github.com/github/gitignore is a damn good
>> resource, but I want to pull it and include relevant bits project by
>> project and/or system wide. I don
On Thu, Oct 27, 2016 at 12:25 PM, Duy Nguyen wrote:
> On Tue, Oct 25, 2016 at 5:43 PM, Duy Nguyen wrote:
>>> static int write_shared_index(struct index_state *istate,
>>> @@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state
>>> *istate,
>>> }
>>> ret = rename_
> I'm thinking something like ". path/to/include/file" in an ignore file,
> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore
> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent
> mixture of these things.
I think the rc.d-like approach with directories is
Junio C Hamano venit, vidit, dixit 26.10.2016 20:11:
> Michael J Gruber writes:
>
>> That one is difficult to discover but super useful, so document it:
>> Specifying 3 or more commits makes git diff switch to combined diff.
>>
>> Signed-off-by: Michael J Gruber
>> ---
>>
>> Notes:
>> Note t
90 matches
Mail list logo
