On Mon, Jan 09, 2017 at 07:40:30PM -0500, Richard Hansen wrote:
> Document that a relative pathname for diff.orderFile is interpreted as
> relative to the top-level work directory.
>
> Signed-off-by: Richard Hansen
> ---
> Documentation/diff-config.txt | 2 ++
> 1 file
Am 10.01.2017 um 00:29 schrieb Richard Hansen:
The pathnames output by the 'git rerere remaining' command are
relative to the top-level directory but the 'git diff --name-only'
command expects its pathname arguments to be relative to the current
working directory. Run cd_to_toplevel before
On Mon, Jan 9, 2017 at 2:07 AM, Duy Nguyen wrote:
> On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller wrote:
>> Why not just update the documentation to be "when you are done with a
>> work tree you can delete it and then run git worktree prune"?
>
> The
On Tue, Jan 03, 2017 at 07:50:38PM -0500, Richard Hansen wrote:
> If rerere is enabled, no pathnames are given, and mergetool is run
> from a subdirectory, mergetool always prints "No files need merging".
> Fix the bug.
>
> This regression was introduced in
>
All occurrences of OPT_SET_INT were setting the value to 1;
internally OPT_BOOL is just that.
Signed-off-by: Stefan Beller
---
builtin/read-tree.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/builtin/read-tree.c
As you may know, I am trying to implement "git checkout --recurse-submodules"
which recurses into submodules and update the submodules to the recorded
state of the superproject. I realized that such a huge change is a big endeavor,
and needs to be broken up into many series.
Currently I plan to
The preferred style in tests seems to be
test_expect_success 'short description, ended by 2 single quotes' '
here comes the test &&
and chains over many lines &&
ended by a quote
'
Or going by the numbers:
$ git -C t/ grep "' '$" | wc -l
9796
$ git -C t/ grep
Add support for the super-prefix option for commands that unpack trees.
For testing purposes enable it in read-tree, which has no other path
related output.
Signed-off-by: Stefan Beller
---
git.c | 2 +-
t/t1001-read-tree-m-2way.sh | 9 +
The preferred style in tests seems to be
test_expect_success 'short description, ended by 2 single quotes' '
here comes the test &&
and chains over many lines &&
ended by a quote
'
Or going by the numbers:
$ git -C t/ grep "' '$" | wc -l
9796
$ git -C t/ grep
Document the format of the patterns used for the diff.orderFile
setting and diff's '-O' option by referring the reader to the
gitignore[5] page.
Signed-off-by: Richard Hansen
---
Documentation/diff-config.txt | 3 ++-
Documentation/diff-options.txt | 3 ++-
2 files changed,
Document that a relative pathname for diff.orderFile is interpreted as
relative to the top-level work directory.
Signed-off-by: Richard Hansen
---
Documentation/diff-config.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/diff-config.txt
Richard Hansen (2):
diff: document behavior of relative diff.orderFile
diff: document the pattern format for diff.orderFile
Documentation/diff-config.txt | 5 -
Documentation/diff-options.txt | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
--
2.11.0.390.gc69c2f50cf-goog
On 2017-01-09 18:29, Junio C Hamano wrote:
Junio C Hamano writes:
Junio C Hamano writes:
I wonder if it makes more sense to always move to toplevel upfront
and consistently use path from the toplevel, perhaps like the patch
s/the patch/the attached
Junio C Hamano writes:
> By the way, I didn't think this through, but how is the orderfile
> that comes from the configuration file handled when it is not an
> absolute path? I think it is _wrong_ to take it as relative to
> where the user started the program.
Answering my
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 54164a320..c031ecd9e 100755
--- a/t/t7610-mergetool.sh
+++
Tests now always run 'git reset --hard' at the end (even if they
fail), so it's no longer necessary to run 'git reset --hard' at the
beginning of a test.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 2 --
1 file changed, 2 deletions(-)
diff --git
The pathnames output by the 'git rerere remaining' command are
relative to the top-level directory but the 'git diff --name-only'
command expects its pathname arguments to be relative to the current
working directory. Run cd_to_toplevel before running 'git diff
--name-only' and adjust any
If rerere is enabled and mergetool is run from a subdirectory,
mergetool always prints "No files need merging". Add an expected
failure test case for this situation.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 21 -
1 file changed, 20
Always check out the required commit at the beginning of the test so
that a failure in a previous test does not cause the test to work off
of the wrong commit.
This is a step toward making the tests more independent so that if one
test fails it doesn't cause subsequent tests to fail.
Rename the testNN branches so that NN matches the test number. This
should make it easier to troubleshoot test issues. Use $test_count to
keep this future-proof.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 82
This is a step toward making the tests more independent so that if one
test fails it doesn't cause subsequent tests to fail.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 71 +++-
1 file changed, 37 insertions(+), 34
This will make it easier for a future commit to convert a relative
orderfile pathname to either absolute or relative to the top-level
directory. It also improves code readability.
Signed-off-by: Richard Hansen
---
git-mergetool.sh | 4 ++--
1 file changed, 2 insertions(+),
Use test_when_finished to run 'git reset --hard' after each test so
that the repository is left in a saner state for the next test.
This is a step toward making the tests more independent so that if one
test fails it doesn't cause subsequent tests to fail.
Signed-off-by: Richard Hansen
If the repository must be in a particular state (beyond what is
already done by the 'setup' test case) before the test can run, make
the necessary repository changes in the test script even if it means
duplicating some lines of code from the previous test case.
This is a step toward making the
Multiple test cases depend on these hunks, so move them to the 'setup'
test case. This is a step toward making the tests more independent so
that if one test fails it doesn't cause subsequent tests to fail.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 65
Create and use a test-specific branch when the test might create a
commit. This is not always necessary for correctness, but it improves
debuggability by ensuring a commit created by test #N shows up on the
testN branch, not the branch for test #N-1.
Signed-off-by: Richard Hansen
The "--" argument avoids "ambiguous argument: unknown revision or
path not in the working tree" errors when a pathname argument refers
to a non-existent file.
Signed-off-by: Richard Hansen
---
Documentation/git-rev-parse.txt | 3 ++-
1 file changed, 2 insertions(+), 1
If rerere is enabled, no pathnames are given, and mergetool is run
from a subdirectory, mergetool always prints "No files need merging".
Fix the bug.
This regression was introduced in
57937f70a09c12ef484c290865dac4066d207c9c (v2.11.0).
Changes since v3:
* Update rev-parse docs to use "--" in
When I changed employers my work address changed from rhan...@bbn.com
to hans...@google.com. Rather than map my old work address to my new,
map them both to my permanent personal email address. (I will still
use my work address in commits I submit so that my employer gets some
credit.)
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> I wonder if it makes more sense to always move to toplevel upfront
>> and consistently use path from the toplevel, perhaps like the patch
>
> s/the patch/the attached patch/ I meant.
>
>> does. The first
Every once in a while someone complains to the mailing list to have
run into this weird assertion[1]. The usual response from the mailing
list is link to old discussions[2], and acknowledging the problem
stating it is known.
This patch accomplishes two things:
1. Switch assert() to die("BUG")
On Mon, Jan 9, 2017 at 2:53 PM, Junio C Hamano wrote:
> Is it only me who sees funny black rectangles in front of these four
> lines instead of blanks, by the way?
I copied this part literally from Jeff. My mail display-client (gmail
at the time)
did mangle it apparently, (it
Junio C Hamano writes:
> I ran out of time for the day and haven't looked at individual
> patches yet. I may find other issues, but from the interdiff, that
> was the only thing that I found even worse than the previous round,
> and everything else was either the same or has
On 2017-01-09 14:05, Junio C Hamano wrote:
Junio C Hamano writes:
I wonder if it makes more sense to always move to toplevel upfront
and consistently use path from the toplevel, perhaps like the patch
s/the patch/the attached patch/ I meant.
does. The first hunk is
Stefan Beller writes:
> Every once in a while someone complains to the mailing list to have
> run into this weird assertion[1]. The usual response from the mailing
> list is link to old discussions[2], and acknowledging the problem
> stating it is known.
>
> This patch
Every once in a while someone complains to the mailing list to have
run into this weird assertion[1]. The usual response from the mailing
list is link to old discussions[2], and acknowledging the problem
stating it is known.
This patch accomplishes two things:
1. Switch assert() to die("BUG")
Johannes Schindelin writes:
> Changes since v2:
>
> - fixed a TRANSLATORS: comment
> ...
> - replaced a spawned `diff-tree` command by code using the diff functions
> directly
I just finished skimming the interdiff (the difference between the
result of merging the
On 2016-12-22 03:15 AM, Michael Haggerty wrote:
On 12/21/2016 08:07 PM, Marc Branchaud wrote:
On 2016-12-20 07:05 PM, Michael Haggerty wrote:
On 12/20/2016 04:01 PM, Marc Branchaud wrote:
[...]
Please don't change the remotebgcolor default.
Also, perhaps the default remoterefbgcolor should
Jeff King writes:
> /*
> + * Write out any suspect information which depends on the path. This must be
> + * handled separately from emit_one_suspect_detail(), because a given commit
> + * may have changes in multiple paths. So this needs to appear each time
> + * we mention a
On Mon, Jan 09, 2017 at 02:05:44PM +0100, Andreas Schwab wrote:
> On Jan 09 2017, "A. Wilcox" wrote:
>
> > Interestingly enough, you seem to be right. The failure is very
> > bizarre and has nothing to do with system /bin/grep:
> >
> > test_must_fail: command
From: "Robert Dailey"
On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley
wrote:
From: "Robert Dailey"
Here's the scenario:
I create a topic branch so one other developer and myself can work on
a feature that takes 2
On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider
wrote:
> Hi,
>
> Git always performs a clean/smudge filter on files in sequential order.
> Sometimes a filter operation can take a noticeable amount of time.
> This blocks the entire Git process.
>
> I would like to give a
On Sun, Jan 8, 2017 at 6:33 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This provides an easier way to have submodules in tests, by just setting
>> TEST_CREATE_SUBMODULE to a non empty string, similar to
>> TEST_NO_CREATE_REPO.
>
> Yuck.
>
> I
On Sun, Jan 8, 2017 at 6:39 PM, Junio C Hamano wrote:
> For future reference, do not bury a useful fix behind unproven new
> things. The main purpose of this two-patch series is this change,
> and it does not have to wait for the change to allow test_commit to
> notice "-C"
Am 09.01.2017 um 09:09 schrieb Johannes Schindelin:
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
Steven Penny writes:
When environment variable POSIXLY_CORRECT is set, the "input -o
output" syntax is not supported.
Am 09.01.2017 um 20:05 schrieb Junio C Hamano:
Junio C Hamano writes:
I wonder if it makes more sense to always move to toplevel upfront
and consistently use path from the toplevel, perhaps like the patch
s/the patch/the attached patch/ I meant.
does. The first hunk is
v2:
* Fixed the return type to be unsigned in patch 4.
This replaces origin/rs/unpack-trees-reduce-file-scope-global,
the first patch has the following diff to that branch
diff --git a/unpack-trees.c b/unpack-trees.c
index edf9fa2f6c..8e6768f283 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
This makes check_updates shorter and easier to understand.
Signed-off-by: Stefan Beller
---
unpack-trees.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index b564024472..ac59510251 100644
The checkout state was introduced via 16da134b1f9
(read-trees: refactor the unpack_trees() part, 2006-07-30). An attempt to
refactor the checkout state was done in b56aa5b268e (unpack-trees: pass
checkout state explicitly to check_updates(), 2016-09-13), but we can
go even further.
The `struct
This makes check_updates shorter and easier to understand.
Signed-off-by: Stefan Beller
---
unpack-trees.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index d443decb23..b564024472
The continue is the last statement in the loop, so not needed.
This situation arose in 700e66d66 (2010-07-30, unpack-trees: let
read-tree -u remove index entries outside sparse area) when statements
after the continue were removed.
Signed-off-by: Stefan Beller
---
This makes check_updates shorter and easier to understand.
Signed-off-by: Stefan Beller
---
unpack-trees.c | 40 ++--
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index
On Fri, Jan 6, 2017 at 5:36 PM, Jeff King wrote:
>> +static int remove_workingtree_files(struct unpack_trees_options *o,
>> + unsigned cnt = 0;
>
> "cnt" is unsigned here, as it is in the caller. Should the return value
> match?
Yes, obviously. :/
Thanks for catching,
Brandon Williams writes:
> On 01/09, Junio C Hamano wrote:
>> Brandon Williams writes:
>>
>> >> How does this relate to the 5-patch real_path: series that has been
>> >> on 'next' since last year?
>> >
>> > The only difference should be in the first patch
On Sun, Jan 8, 2017 at 5:25 PM, Junio C Hamano wrote:
> So with the above, are you saying "Dscho said 'hopefully', and I
> confirm that this change does squelch misdiagnosis by Coverity"?
I could not find the coverity issue any more.
(It really misses easy access to "recently
Junio C Hamano writes:
> I wonder if it makes more sense to always move to toplevel upfront
> and consistently use path from the toplevel, perhaps like the patch
s/the patch/the attached patch/ I meant.
> does. The first hunk is what you wrote but only inside MERGE_RR
>
On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley wrote:
> From: "Robert Dailey"
>>
>> Here's the scenario:
>>
>> I create a topic branch so one other developer and myself can work on
>> a feature that takes 2 weeks to complete. During that 2 week
Set errno to ELOOP when the maximum number of symlinks is exceeded, as
would be done by other symlink-resolving functions.
Signed-off-by: Brandon Williams
---
abspath.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/abspath.c b/abspath.c
index 0393213e5..fce40fddc
The macro 'MAXSYMLINKS' is already defined on macOS and Linux in
. If 'MAXSYMLINKS' has already been defined, use the value
defined by the OS otherwise default to a value of 32 which is more
inline with what is allowed by many systems.
Signed-off-by: Brandon Williams
---
On Sun, Jan 8, 2017 at 9:42 PM, Richard Hansen wrote:
> If rerere is enabled, no pathnames are given, and mergetool is run
> from a subdirectory, mergetool always prints "No files need merging".
> Fix the bug.
>
> This regression was introduced in
>
On 01/09, Junio C Hamano wrote:
> Brandon Williams writes:
>
> >> How does this relate to the 5-patch real_path: series that has been
> >> on 'next' since last year?
> >
> > The only difference should be in the first patch of the series which
> > handles the #define a bit
Brandon Williams writes:
>> How does this relate to the 5-patch real_path: series that has been
>> on 'next' since last year?
>
> The only difference should be in the first patch of the series which
> handles the #define a bit differently due to the discussion that
> happened
Richard Hansen writes:
> If rerere is enabled and no pathnames are given, run cd_to_toplevel
> before running 'git diff --name-only' so that 'git diff --name-only'
> sees the files named by 'git rerere remaining', which outputs
> pathnames relative to the top-level directory.
On 01/07, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > changes in v5:
> > * set errno to ELOOP when MAXSYMLINKS is exceded.
> > * revert to use MAXSYMLINKS instead of MAXDEPTH.
> > * If the OS hasn't defined MAXSYMLINKS, use a fallback value of 32.
> >
> > Brandon
On 01/07, Duy Nguyen wrote:
> On Thu, Jan 5, 2017 at 1:03 AM, Brandon Williams wrote:
> > Changes in v5:
> > * Move GUARD_PATHSPEC to prevent checking if pathspec is null twice.
> > * Mark a string containing 'mnemonic' for translation.
>
> Argh.. I've run out of things to
Nguyễn Thái Ngọc Duy writes:
> This version is the same as nd/worktree-move but with the recursive
> directory copy code removed. We rely on rename() to move directories.
Much simpler ;-)
Will replace; thanks.
> Nguyễn Thái Ngọc Duy (6):
> worktree.c: add
Nguyễn Thái Ngọc Duy writes:
> + end = string + strlen(string);
> + while (start < end) {
> + const char *comma = strchrnul(start, ',');
> + char color[COLOR_MAXLEN];
> +
> + while (start < comma && isspace(*start))
> +
On Monday, January 09, 2017 01:21:37 AM Jeff King wrote:
> On Wed, Jan 04, 2017 at 09:11:55AM -0700, Martin Fick
wrote:
> > I am replying to this email across lists because I
> > wanted to highlight to the git community this jgit
> > change to repacking that we have up for review
> >
> >
On Monday, January 09, 2017 05:55:45 AM Jeff King wrote:
> On Mon, Jan 09, 2017 at 04:01:19PM +0900, Mike Hommey
wrote:
> > > That's _way_ more complicated than your problem, and
> > > as I said, I do not have a finished solution. But it
> > > seems like they touch on a similar concept (a
> > >
On Mon, Jan 09, 2017 at 07:01:36AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> > wrote:
> >> Is there any way to tell git, after the git ls-tree command above, to
> >> refresh its
Johannes Schindelin writes:
> Hi Junio,
>
> On Sun, 8 Jan 2017, Junio C Hamano wrote:
>
>> * js/difftool-builtin (2017-01-08) 4 commits
>> - t7800: run both builtin and scripted difftool, for now
>> - difftool: implement the functionality in the builtin
>> -
Duy Nguyen writes:
> On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> wrote:
>> Is there any way to tell git, after the git ls-tree command above, to
>> refresh its stat cache information and trust us that the file content has
>> not
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> In any case, it does not break things, and it helps Cygwin, so: ACK
>>
>> Ciao,
>> Dscho
>>
>> P.S.: I pushed this to Git for Windows' `master`, too:
>>
Duy Nguyen writes:
> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano wrote:
>> Christian Couder writes:
>>
>>> So what should we do if freshen_file() returns 0 which means that the
>>> freshening failed?
>>
>> You tell me ;-) as
Johannes Schindelin writes:
> In any case, it does not break things, and it helps Cygwin, so: ACK
>
> Ciao,
> Dscho
>
> P.S.: I pushed this to Git for Windows' `master`, too:
> https://github.com/git-for-windows/git/commit/f05a26948b
Hmm, I peeked it hoping that you
Johannes Schindelin writes:
>> > But do we really need to do that?
>>
>> No.
>
> Exactly.
> But since you seem to convinced that a future bug report like this may
> happen (I am not, and it contradicts my conviction that one should cross a
> bridge only when
Duy Nguyen writes:
> On Mon, Jan 9, 2017 at 12:30 PM, Jeff King wrote:
>> I also wonder if it is worth just using argv_array. We do not care about
>> ...
>> It is not much shorter than ALLOC_GROW(), but IMHO it is easier to read.
>
> Indeed. My only complaint
Johannes Schindelin writes:
> ...
> It is a bit curious that -lws2_32 *does* only show up in $(LIBS), but I
> guess it is simply the fact that we use a newer GCC (gcc.exe (Rev2, Built
> by MSYS2 project) 6.2.0) that allows Git for Windows to be built even
> without
Please can i have your attention? I am anessa Coley. I have something to
discuss with you.
I hope to hear from you.
With love
Anessa
On Jan 09 2017, "A. Wilcox" wrote:
> Interestingly enough, you seem to be right. The failure is very
> bizarre and has nothing to do with system /bin/grep:
>
> test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
> not ok 142 - grep -G -F -P -E
Jeff King venit, vidit, dixit 04.01.2017 08:05:
> On Mon, Jan 02, 2017 at 12:14:49PM +0100, Michael J Gruber wrote:
>
>> Currently, the headers "error: ", "warning: " etc. - generated by die(),
>> warning() etc. - are not localized, but we feed many localized error messages
>> into these
On Mon, Jan 09, 2017 at 01:17:24PM +0100, Quentin Casasnovas wrote:
> On Mon, Jan 09, 2017 at 07:02:45PM +0700, Duy Nguyen wrote:
> > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> > wrote:
> >
> > > If not, I am willing to implement a
On Mon, Jan 09, 2017 at 07:02:45PM +0700, Duy Nguyen wrote:
> On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> wrote:
>
> > If not, I am willing to implement a --assume-content-unchanged to the git
> > update-index if you guys don't see something fundamentally
On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
wrote:
> Hi guys,
>
> Apologies if this is documented somewhere, I have fairly bad search vudu
> skills.
>
> I'm looking for a way to cause a full refresh of the index without causing
> any read of the files,
On Mon, Jan 09, 2017 at 04:51:22AM -0600, A. Wilcox wrote:
> Interestingly enough, you seem to be right. The failure is very
> bizarre and has nothing to do with system /bin/grep:
>
> test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
> not ok 142 - grep -G -F -P -E
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> * js/difftool-builtin (2017-01-08) 4 commits
> - t7800: run both builtin and scripted difftool, for now
> - difftool: implement the functionality in the builtin
> - difftool: add a skeleton for the upcoming builtin
> - git_exec_path:
On Sun, Jan 8, 2017 at 4:38 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> It feels strange that when I do things one way, you suggest another
>> way, and the next time in a similar situation when I do things the way
>> you suggested
Hi Junio,
On Mon, 9 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > If you feel strongly about your contrived examples possibly being
> > affected by this patch, we could easily make this conditional on
> >
> > 1) no '&&' or '||' being found on
On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> So what should we do if freshen_file() returns 0 which means that the
>> freshening failed?
>
> You tell me ;-) as you are the one who is proposing this feature.
On Mon, Jan 09, 2017 at 04:01:19PM +0900, Mike Hommey wrote:
> > That's _way_ more complicated than your problem, and as I said, I do not
> > have a finished solution. But it seems like they touch on a similar
> > concept (a post-delete holding area for objects). So I thought I'd
> > mention it
On 02/01/17 00:53, Jeff King wrote:
> On Sat, Dec 31, 2016 at 10:59:11PM -0600, A. Wilcox wrote:
>
>> I'm attempting to package Git for our new Linux distribution and
>> I have run in to a failure on our PowerPC builder while running
>> the test suite.
>>
>> The PowerPC builder runs a tiny
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Sun, 8 Jan 2017, Steven Penny wrote:
> >
> >> On Sun, Jan 8, 2017 at 5:54 AM, Johannes Schindelin wrote:
> >> > I am curious: how do you build Git? I ask because I build Git
If you have a 256 colors terminal (or one with true color support), then
the predefined 12 colors seem limited. On the other hand, you don't want
to draw graph lines with every single color in this mode because the two
colors could look extremely similar. This option allows you to hand pick
the
Jeff King writes:
> On Fri, Jan 06, 2017 at 08:19:53PM -0500, Kyle Meyer wrote:
>
>> > The other option is just "git checkout --detach", which is also used in
>> > the test suite. I tend to prefer it because it's a little more obvious
>> > to a reader.
>>
>> True, that does seem
On Mon, Jan 9, 2017 at 12:30 PM, Jeff King wrote:
> I also wonder if it is worth just using argv_array. We do not care about
> NULL-terminating the list here, but it actually works pretty well as a
> generic string-array class (and keeping a NULL at the end of any
>
On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller wrote:
> Why not just update the documentation to be "when you are done with a
> work tree you can delete it and then run git worktree prune"?
The document does say that (a bit verbose though):
When you are done with a linked
On Mon, Jan 9, 2017 at 12:34 PM, Jeff King wrote:
>> +test_expect_success 'log --graph with merge with log.graphColors' '
>> + test_config log.graphColors " blue , cyan , red " &&
>
> This funny syntax isn't required, right? It should work with the more
> natural:
>
>
Luke Diamand writes:
> On 8 January 2017 at 16:55, Pranit Bauva wrote:
>> The exit code of the upstream in a pipe is ignored thus we should avoid
>> using it. By writing out the output of the git command to a file, we can
>> test the exit codes of both
Johannes Schindelin writes:
>> Who other than cygwin build uses this target? Git for Windows?
>
> Yes, Git for Windows uses this target, as did msysGit (and I suspect
> Hannes' setup).
> ...
> So: ACK
Thanks.
Johannes Schindelin writes:
> And the most important point is that we do all of this only during a
> hopefully brief period in time that is mostly spent on reviewing the code
> and finding serious bugs and fixing them.
You seem to misunderstand the purpose of the
1 - 100 of 105 matches
Mail list logo