he specified "bottom"
commit. It may be that's part of what's happening here.
Kevin
now there were quite a few changes later in the series to try to
reconcile the simple and full history, for the cases where the simple
history takes a weird path because of its love of TREESAME parents,
hiding evil merges. But I believe the simple history behaviour was
supposed to remain as-is - take first TREESAME always.
Kevin
On 24/05/2018 23:26, Kevin Bracey wrote:
On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:
$ git log --oneline master..ba95710a3b -- ci/
ea44c0a594 Merge branch 'bw/protocol-v2' into
jt/partial-clone-proto-v2
In this case, we're hitting a merge commit
without naming them
- so name a child of one.
And then we need to think about whether we want it displayed in each of
the other modes for each of those queries...
Kevin
he initial scan when all
parents are relevant and we matched one, the commit became TREESAME as
per the new definition immediately because of the rewrite. This applies
the equivalent rewrite when no relevant parents, consistent with the
general concept, and without changing the TREESAME definition.
Kevin
ite short
window of investigation a long time ago, and I've not looked at it
since. Would like input from someone with more active knowledge.
Kevin
This change passes the progress option of format-patch by
default and passes the -q --quiet option through to the
format-patch call so that it is respected as well.
Signed-off-by: Kevin Willford
---
git-rebase--am.sh | 5 +++--
git-rebase.sh | 2 ++
2 files changed, 5 insertions(+), 2
makes it the default when running rebase.
It will also respect the -q[uiet] flag and not show when it
is present.
Kevin Willford (2):
format-patch: have progress option while generating patches
rebase: turn on progress option by default for format-patch
Documentation/git-format-patch.txt | 8
informed the progress of generating the
patch. This option will then be used by the rebase command when
calling format-patch.
Signed-off-by: Kevin Willford
---
Documentation/git-format-patch.txt | 8
builtin/log.c | 10 ++
2 files changed, 18 insertions
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Stefan Beller
> Sent: Wednesday, May 31, 2017 12:40 PM
> To: Kevin Willford
> Cc: git@vger.kernel.org; Junio C Hamano ; Kevin
> Willford
> Subject: Re: [PATCH
> -Original Message-
> From: Stefan Beller [mailto:sbel...@google.com]
> Sent: Wednesday, May 31, 2017 1:09 PM
> To: Kevin Willford
> Cc: git@vger.kernel.org; Junio C Hamano ; Kevin
> Willford
> Subject: Re: [PATCH 2/2] rebase: turn on progress option by defau
On Thu, Jun 01, 2017 at 01:16:11PM +0200, SJR wrote:
> W dniu 1 czerwca 2017 09:43 użytkownik SJR napisał:
> >
> > Hi,
> >
> > https://git-scm.com/book/pl/v1/Dostosowywanie-Gita-Konfiguracja-Gita
> >
> > part in polish part in english.
> >
> > Can You repair translation?
> >
> > Regards,
> > JanR
On Sun, Jun 04, 2017 at 11:24:17AM +0100, Philip Oakley wrote:
> While looking at the recent .gitignore issue (the need to use `**`) I came
> up against a comment in
> https://public-inbox.org/git/cagz79kzqsaubfotjyqm+-+ljyyec2ykj5exuy5kderezfh0...@mail.gmail.com/
> noting that the Git Merge 2017 v
On Wed, Jun 07, 2017 at 10:46:08AM +0100, pedro rijo wrote:
> Recently I've updated a bunch of stuff, including git and gpg. I'm using
>
> - mac OS 10.10.5
> - git 2.13.1
> - gpg (GnuPG) 2.1.21 / libgcrypt 1.7.7
>
> When I do
>
> $ git commit --allow-empty -v -m "lol"
> error: gpg failed to sign
From: Junio C Hamano
Signed-off-by: Junio C Hamano
Signed-off-by: Kevin Daudt
---
Documentation/RelNotes/2.14.0.txt | 55 +++
1 file changed, 55 insertions(+)
diff --git a/Documentation/RelNotes/2.14.0.txt
b/Documentation/RelNotes/2.14.0.txt
index
On Wed, Jun 07, 2017 at 12:33:41PM +0200, Kevin Daudt wrote:
> From: Junio C Hamano
>
sorry for the noise, please ignore this.
On Sat, Jun 10, 2017 at 03:07:01PM +0900, Junio C Hamano wrote:
> I didn't check where it goes wrong. Here is a list of suspects,
> taken by
>
> $ git shortlog --no-merges pu@{8.hours}..pu
>
> i.e. patches that weren't in pu before today's integration cycle.
>
> Andreas Heiduk (1):
>
On Sat, Jun 10, 2017 at 02:48:36PM +0200, Kevin Daudt wrote:
> On Sat, Jun 10, 2017 at 03:07:01PM +0900, Junio C Hamano wrote:
> > I didn't check where it goes wrong. Here is a list of suspects,
> > taken by
> >
> > $ git shortlog --no-merges pu@{8.hours
On Wed, Jun 21, 2017 at 08:25:26AM +0530, Kaartic Sivaraam wrote:
>
> I tried applying the patch and building it locally. For some reason I
> couldn't see the change in effect. What could I be missing?
>
Did you make sure you used the git you built, and also the relevant
subcommands?
What does
y whitespace and
> + * Signed-off-by lines.
> + *
> + * This function is the "rest_is_space" function of "commit" with the
> unwanted
> + * parameter removed.
The function is called "rest_is_empty".
But isn't it better that commit and merge use the same code, instead of
duplicating it again? Otherwise one may be updated, and the other
forgotten, getting differences in behaviur, which is what you want to
solve.
Kevin
o get this fixed is to make a pull-request on the German
translation team repo[0].
Kind regards, Kevin
[0]: https://github.com/ralfth/git-po-de
On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>
> > On 08 Feb 2018, at 12:13, Lars Schneider wrote:
> >
> >
> >> On 08 Feb 2018, at 09:50, Jeff King wrote:
> >>
> >> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> >>
> 1. You have $LESS in your enviro
Update the file when there is a conflict with a modify/delete scenario
when using the sparse-checkout feature since the file might not be on disk
because the skip-worktree bit is on and the user will need the file and
content to determine how to resolve the conflict.
Signed-off-by: Kevin Willford
directory and if it will be missing with the new index entry
or was not missing in the previous version, we create the previous index
version of the file in the working directory so that status will report
correctly and the files will be availble for the user to deal with.
Signed-off-by: Kevin
While using the sparse-checkout feature there are scenarios where
the working directory should and should not be updated. This patch
series addresses issues found in reset, apply, and merge conflicts.
Kevin Willford (3):
merge-recursive.c: conflict using sparse should update file
apply.c
a file
in the working directory, then update the index but not keep the
working directory up to date with the changes that happened in the index.
Signed-off-by: Kevin Willford
---
apply.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/apply.c b/apply.c
index 0e2caeab9c..0da5
meter.
This patch allows a progress option to be passed to format-patch
so that the user can be informed the progress of generating the
patch. This option is then used by the rebase command when
calling format-patch.
Signed-off-by: Kevin Willford
---
Documentation/git-format-patch.txt | 4
This change passes the progress option of format-patch checking
that stderr is attached and rebase is not being run in quiet mode.
Signed-off-by: Kevin Willford
---
git-rebase--am.sh | 1 +
git-rebase.sh | 6 ++
2 files changed, 7 insertions(+)
diff --git a/git-rebase--am.sh b/git
n is not
set before propagating the progress flag to format-patch
Kevin Willford (2):
format-patch: have progress option while generating patches
rebase: turn on progress option by default for format-patch
Documentation/git-format-patch.txt | 4
builtin/log.c
through that
are not a known one for git.
Signed-off-by: Kevin Willford
---
cache-tree.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/cache-tree.c b/cache-tree.c
index 2440d1dc89..41744b3db7 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -390,7
If there is not a pre-commit hook, there is no reason to discard
the index and reread it.
This change checks to presence of a pre-commit hook and then only
discards the index if there was one.
Signed-off-by: Kevin Willford
---
builtin/commit.c | 29 +
1 file changed
On 8/10/2017 3:03 PM, Jeff King wrote:
On Thu, Aug 10, 2017 at 11:58:34AM -0700, Stefan Beller wrote:
On Thu, Aug 10, 2017 at 11:47 AM, Kevin Willford wrote:
String formatting can be a performance issue when there are
hundreds of thousands of trees.
When changing this for the sake of
am
>
> PS Sorry for the lack of formatting - I'm sending this as plain text
> as my original HTML emails was rejected as possible spam by your
> mailserver.
>
> Sam Partington
> Senior Developer
>
Hello Sam,
Is it the case that you did not commit the addition of '!bin/mynewfile'
yet? I suspect that by running git stash save -u, you also are stashing
this addition to the .gitigore file. Can you confirm this?
Kevin
emove null bytes from the
input.
This warning is triggered when running git stash save -u resulting in
two warnings:
git-stash: line 43: warning: command substitution: ignored null byte
in input
Signed-off-by: Kevin Daudt
---
git-stash.sh | 2 +-
1 file changed, 1 insertion(+),
On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > The no_changes function calls the untracked_files function through
> > command substitution. untracked_files will return null bytes because it
> > runs ls-files with the '-
:
git-stash: line 43: warning: command substitution: ignored null byte
in input
Signed-off-by: Kevin Daudt
---
git-stash.sh | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 9b6c2da7b..5f09a47f0 100755
--- a/git-stash.sh
If there is not a pre-commit hook, there is no reason to discard
the index and reread it.
This change checks to presence of a pre-commit hook and then only
discards the index if there was one.
Signed-off-by: Kevin Willford
---
builtin/commit.c | 15 +--
1 file changed, 9 insertions
> On Mon, Aug 14, 2017 at 03:54:25PM -0600, Kevin Willford wrote:
>
> > If there is not a pre-commit hook, there is no reason to discard
> > the index and reread it.
> >
> > This change checks to presence of a pre-commit hook and then only
> > discards the in
On Tue, Aug 15, 2017 at 08:45:20PM +0200, Kim Birkelund wrote:
> Hi
>
> I hope this is gonna sound as weird to you as it does to me.
>
> The link below is a zip of a small git repository that I can reproduce
> the bug in on 2 machines.
>
> Repo: https://www.dropbox.com/s/fz4d0i5ko7s7ktr/test.zip
On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > # no tags, we just populate FETCH_HEAD because of the bare URL
> > git fetch ../parent
> >
> > # this does fetch tags, because we're storing the result according to
> > # the configured refspec ("ref
On Thu, Aug 17, 2017 at 01:38:36PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:
> >> Jeff King writes:
> >>
> >> > # no tags, we just populate FETCH_HEAD because of
)
5.86(0.01+0.03) -5.5%
0007.2: write_locked_index 3 times (4394531 files) 10.29(0.04+0.03)
9.75(0.04+0.01) -5.2%
0007.2: write_locked_index 3 times (4394531 files) 10.52(0.00+0.04)
9.79(0.03+0.03) -6.9%
Kevin Willford (3):
perf: add test for writing the index
read-cache: fix memory
The previous_name_buf was never getting released when there
was an error in ce_write_entry or allow was false and execution
was returned to the caller.
Signed-off-by: Kevin Willford
---
read-cache.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b
fill the buffer before flushing to disk,
we don't have to worry about doing multiple ce_write calls.
Running the p0007-write-cache.sh tests would save anywhere
between 3-7% when the index had over a million entries with no
performance degradation on small repos.
Signed-off-by: Kevin Wil
A performance test for writing the index to be able to
determine if changes to allocating ondisk structure help.
Signed-off-by: Kevin Willford
---
Makefile| 1 +
t/helper/test-write-cache.c | 23 +++
t/perf/p0007-write-cache.sh | 29
o be carefull when you use a force push.
Additionally, I can recommend using separate branches for things that
might turn up as dead ends (or even for every development). That way,
you can just throw away the branch if you want to discard it.
Hope this helps, Kevin.
ch and HEAD was
> performed before attempting to move HEAD (so that HEAD followed to the
> new branch name, I believe). That change was dropped, though and perhaps
> the new check in replace_each_worktree_head_symref of
>
> strcmp(oldref, worktrees[i]->head_ref)
>
> does not work for orphaned branches? I am unfamiliar with all the
> details of the git internals, so please correct me if I'm wrong!
>
> Thanks,
> Nish
>
> --
> Nishanth Aravamudan
> Ubuntu Server
> Canonical Ltd
Thanks for this report. I've bisected it down to
fa099d232 (worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe(),
2017-04-24)
I've CC'ed Duy, who made that commit.
Kevin
e):
When you are not interested in changes older than version v2.6.18,
or changes older than 3 weeks, *you can use revision range
specifiers similar to git rev-list*:
So these options are not documented under git blame, but git rev-list.
Perhaps the synopsis of man git-blame could be expanded so that that
it's clear it accepts rev-list options.
Kevin
save some time when there are
millions of paths that will be checked.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 48 +---
merge-recursive.h | 3 +--
2 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/merge-recursive.c b/merge
er if
read_tree_recursive gets an error.
Since the debug output has been removed and the caller isn't
checking the return value there is no reason to keep calulating
and returning a value.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 8 ++--
1 file changed, 2 insertions(+), 6
some time when there are
millions of paths that will be checked.
Also cleaned up a memory leak and method where the return was not
being used.
Kevin Willford (3):
merge-recursive: fix memory leak
merge-recursive: remove return value from get_files_dirs
merge-recursive: change current file dir
In merge_trees if process_renames or process_entry returns less
than zero, the method will just return and not free re_merge,
re_head, or entries.
This change cleans up the allocated variables before returning
to the caller.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 12
>
> On Mon, Aug 28, 2017 at 02:28:28PM -0600, Kevin Willford wrote:
>
> > The return value of the get_files_dirs call is never being used.
> > Looking at the history of the file and it was originally only
> > being used for debug output statements. Also when
> >
On Thu, Aug 24, 2017 at 03:53:26PM -0700, Brandon Williams wrote:
> Tell a serve that protocol v2 can be used by sending an http header
> indicating this.
s/serve/server/
On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
> I have a file
>
> app/Controller/CustomerCardVerificationController.php
>
> And when I take a look at changes log, I get this (no matter which tool I
> use):
>
> 2017-07-31 19:41 dule o membership renew payment ema
For count, sort and format, only the argument names were listed under
OPTIONS, not the option names.
Add the option names to make it clear the options exist
Signed-off-by: Kevin Daudt
---
Documentation/git-for-each-ref.txt | 18 +-
1 file changed, 9 insertions(+), 9 deletions
l which is used in the < version 4
ce_write.
>
> strbuf_splice(previous_name, common, to_remove,
> ce->name + common, ce_namelen(ce) - common);
> --
> 2.14.1.480.gb18f417b89
While looking at the code I was wondering if we could get around the
whole setting ce->ce_namelen to zero bit but that would be much bigger
patch and possibly introduce other bugs so this seems the appropriate
fix for now.
Thanks for finding this!
Kevin
save some time when there are
millions of paths that will be checked.
Also cleaned up a memory leak and method where the return was not
being used.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 76 ---
merge-recursive.h | 3 +--
2 files
In merge_trees if process_renames or process_entry returns less
than zero, the method will just return and not free re_merge,
re_head, or entries.
This change cleans up the allocated variables before returning
to the caller.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 12
er if
read_tree_recursive gets an error.
Since the debug output has been removed and the caller isn't
checking the return value there is no reason to keep calculating
and returning a value.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 8 ++--
1 file changed, 2 insertions(+), 6
hashmap and why it is getting initialized
and freed but not a local.
3. Use hashmap_get_from_hash and remove the dummy entry
Kevin Willford (3):
merge-recursive: fix memory leak
merge-recursive: remove return value from get_files_dirs
merge-recursive: change current file dir string_lists to
save some time when there are
millions of paths that will be checked.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 56 ---
merge-recursive.h | 3 +--
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/merge-recursive.c b
directory and if it will be missing with the new index entry or was not
missing in the previous version, we create the previous index version of
the file in the working directory so that status will report correctly
and the files will be availble for the user to deal with.
Signed-off-by: Kevin
skip-wortree
bit so that the file contents before the reset is preserved on disk and
status will reports the correct results.
Kevin Willford (1):
reset: fix reset when using the sparse-checkout feature.
builtin/reset.c | 25 +
t/t7114-reset-sparse-checkout.sh
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Friday, September 8, 2017 1:12 PM
> Kevin Willford writes:
>
> > When using the sparse checkout feature the git reset command will add
> > entries to the index that will have the skip-worktree bit off but will
> > lea
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Friday, September 8, 2017 1:02 PM
> Kevin Willford writes:
>
> > diff --git a/builtin/reset.c b/builtin/reset.c
> > index d72c7d1c96..1b8bb45989 100644
> > --- a/builtin/reset.c
> > +++ b/builtin/reset.c
>
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Friday, September 8, 2017 9:18 PM
>
> Kevin Willford writes:
>
> > 1. reset mixed when there were files that were added
> >
> > In this case the index will no longer have the entry at all because
>
u like
me to do?
The reroll for read-cache fix was submitted here
https://public-inbox.org/git/20170907192412.8085-1-t.gumme...@gmail.com/
- Kevin
The synopsis and description inconsistently add a '=' between the
argument name and it's value. Make this consistent.
Signed-off-by: Kevin Daudt
---
Documentation/git-for-each-ref.txt | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentati
For count, sort and format, only the argument names were listed under
OPTIONS, not the option names.
Add the option names to make it clear the options exist
Signed-off-by: Kevin Daudt
---
Documentation/git-for-each-ref.txt | 18 +-
1 file changed, 9 insertions(+), 9 deletions
On Tue, Sep 12, 2017 at 11:28:00AM +0900, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > The synopsis and description inconsistently add a '=' between the
> > argument name and it's value. Make this consistent.
> >
> > Signed-off-by: Kevin D
uite the opposite of it,
> then my answer to the second question (are we solving the problem
> with the right approach?) is no. And at that point, it is moot to
> ask if the code correctly and/or efficiently implements that wrong
> solution, isn't it?
I agree that we must determine if there is a problem, which I hope
we can agree that there is a valid problem to be addressed. Determining
if I used the right approach depends on how you see reset working
correctly using the sparse feature. Should it match a reset when not
using sparse or should it reset only sparse files? I saw issues
if only the sparse files are the ones reset, which is the reason that
I went with this approach.
Thanks,
Kevin
> From: Jacob Keller [mailto:jacob.kel...@gmail.com]
> Sent: Tuesday, September 12, 2017 4:29 PM
>
> On Tue, Sep 12, 2017 at 1:20 PM, Kevin Willford wrote:
> >
> > I think this is where I need to do a better job of explaining so here is a
> > simple example.
>
On Tue, Sep 12, 2017 at 04:25:36PM +0530, Kaartic Sivaraam wrote:
> It's not possible to 'touch' the cut-line that is shown when the
> user requests a patch in his commit template.
>
Touching something can also mean to disturb or change something, which
is the meaning being used here, so it is no
> From: Jacob Keller [mailto:jacob.kel...@gmail.com]
> Sent: Tuesday, September 12, 2017 7:39 PM
>
> On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford wrote:
> >
> > Sorry. It was not in the sparse-checkout file.
> > $ git config core.sparsecheckout true
> > $
out when there is a merge conflict with a file that is outside
the sparse checkout? Should there not be a conflict because
git shouldn't be trying to merge the file since it is outside the sparse
checkout area? Should the conflicted file get written outside the
sparse checkout so the user can resolve it?
Thanks,
Kevin
On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi there,
>
> While bumping Git's version for our Linux distribution to 2.14.1, I've
> run in to a new test failure in t6500-gc.sh. This is the output of
> the failing test with deb
On Fri, Sep 15, 2017 at 08:37:40AM +0200, Kevin Daudt wrote:
> On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hi there,
> >
> > While bumping Git's version for our Linux dist
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Thursday, September 14, 2017 11:00 PM
>
> Kevin Willford writes:
>
> > 1. Does this statement, "I only care about the files in this
> > sparse checkout, and do not concern me with anything else", mean
>
t; git checkout -B branch1-scratch &&
> -
> setup_dirty_mergeable &&
> git checkout -B branch1-scratch initial &&
> test_dirty_mergeable
>
> --
> https://github.com/git/git/pull/403
Why is this empty line unwanted? This kind of whitespace can help
separate logical sections, just like paragraphs would.
Kevin.
On Mon, Sep 25, 2017 at 04:31:10PM +0900, Sanggyu Nam wrote:
> I’ve found that some subcommands such as git-clone, git-fetch, and
> git-pull support an option named ‘--shallow-since’, as of Git version
> 2.11. This option is documented in the man page of each subcommand. In
> Git 2.14.1, I’ve check
The last section under description explains that
mode.
Do you feel this distinction needs to be made more clear?
Kevin.
ld look to git like you created F', and someone else
had pushed F and G. It will reject the push, saying you would need to
merge these changes first (but you don't want this, because you are
merging the same changes together).
To solve this, you can use git push --force-with-lease=master or
On Mon, Oct 02, 2017 at 12:06:38AM +0800, Yubin Ruan wrote:
> 2017-10-01 22:17 GMT+08:00 Kevin Daudt :
> > Forgot to cc the mailing list.
> >
> > On Sun, Oct 01, 2017 at 09:23:23PM +0800, Yubin Ruan wrote:
> >> Suppose that I have such a history of commit locally:
ing the value to auto should
fix it (setting it to always does not make much sense in your config
file).
Kevin.
[0}:https://public-inbox.org/git/20171003093157.gq7za2fwcqsou...@sigill.intra.peff.net/T/
On Wed, Oct 04, 2017 at 07:10:46AM -0400, rpj...@crashcourse.ca wrote:
>
> couple (admittedly trivial) questions about stashing. first, can i
> clarify that when one stashes content, a stash *always* distinguishes
> between what was staged, and what was unstaged? that is, when one is
> stashing,
ith the color codes. Setting it
to 'auto' would make more sense.
The thread I posted to discusses some changes that might get introduced
to improve the situation though.
Kevin.
[0}:https://public-inbox.org/git/20171003093157.gq7za2fwcqsou...@sigill.intra.peff.net/T/
the pathname.
So that seems to indicate '*.c' should only match .c files in the
current dir. I'm not sure why that's not the case.
I hope this clears up what's happening a bit, and perhaps can lead to
improvements to the documentation so that it's not so surprising.
Kind regards, Kevin.
t to autol. Also check
if the pager is active.
Helped-by: Rafael Ascensão
Signed-off-by: Kevin Daudt
---
This came to light when someone wondered on irc why
column.tag=[auto|always] did not work on Mac OS. Testing it myself, I
found it to work with always, but not with auto.
I could not get the te
> > --mode=auto actual &&
> > test_cmp expected actual
> > '
> > test_done
>
> Makes sense. FWIW, I don't see the flakyness with this.
>
> > All that said, I think I'd just as soon test a real command like "git
> > tag
On Tue, Oct 10, 2017 at 07:02:00PM +0200, Martin Ågren wrote:
> On 10 October 2017 at 16:01, Jeff King wrote:
> > On Tue, Oct 10, 2017 at 12:30:49PM +0200, Martin Ågren wrote:
> >> On 9 October 2017 at 23:45, Kevin Daudt wrote:
> >> > Since ff1e72483 (tag: change
auto. Also check
if the pager is active.
Helped-by: Rafael Ascensão
Signed-off-by: Kevin Daudt
---
column.c | 3 ++-
t/t7006-pager.sh | 14 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/column.c b/column.c
index ff7bdab1a..ded50337f 100644
--- a/colu
On Wed, Oct 11, 2017 at 08:12:35PM +0200, Martin Ågren wrote:
> On 11 October 2017 at 19:23, Kevin Daudt wrote:
> > finalize_colopts in column.c only checks whether the output is a TTY to
> > determine if columns should be enabled with columns set to auto. Also check
> > i
lly
This is a known 'breakage' because people have set color.ui to always
(which should not be used anyway).
Kind regards, Kevin
On Thu, Oct 12, 2017 at 02:02:17AM -0700, W. Trevor King wrote:
> Pull has supported these since ea230d8 (pull: add the --gpg-sign
> option, 2014-02-10). Insert in long-option alphabetical order
> following 7c85d274 (Documentation/merge-options.txt: order options in
> alphabetical groups, 2009-10-
On Thu, Oct 12, 2017 at 12:44:59PM +0200, Kevin Daudt wrote:
> On Thu, Oct 12, 2017 at 02:02:17AM -0700, W. Trevor King wrote:
> > Pull has supported these since ea230d8 (pull: add the --gpg-sign
> > option, 2014-02-10). Insert in long-option alphabetical order
> &g
On Thu, Oct 05, 2017 at 02:19:15PM +0200, Johannes Schindelin wrote:
> From: J Wyman
> [..]
>
> diff --git a/Documentation/git-for-each-ref.txt
> b/Documentation/git-for-each-ref.txt
> index 39f50bd53eb..22767025850 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for
On Fri, Oct 13, 2017 at 01:35:22PM -0400, Jeff King wrote:
> On Fri, Oct 13, 2017 at 11:58:12AM +0900, 小川恭史 wrote:
>
> You can also just do:
>
> for i in 1 2 3; do
> git stash drop $i
> done
>
Doesn't stash 2 become stash 1 after the first drop, and the same for 3,
resulting in droppin
ce that was the original motivation
for this patch.
Helped-by: Rafael Ascensão
Signed-off-by: Kevin Daudt
---
Changes since v1:
- Remove redundant -p flag in tests
- Explain why git tag is being tested instead of the more obvious git
column
column.c | 3 ++-
t/t7006-pager.sh | 14 ++
On Mon, Oct 16, 2017 at 10:55:24AM -0700, Brandon Williams wrote:
> Create protocol.{c,h} and provide functions which future servers and
> clients can use to determine which protocol to use or is being used.
>
> Also introduce the 'GIT_PROTOCOL' environment variable which will be
> used to communi
201 - 300 of 494 matches
Mail list logo
