* [PATCH/RFC 5/4] Redefine core.bare in multiple working tree setting
From: Nguyễn Thái Ngọc Duy @ 2017-01-10 11:33 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <20170110112524.12870-1-pclouds@gmail.com>
When core.bare was added, time was simpler, we only had one worktree
associated to one repository. The situation gets a bit complicated when
multiple worktrees are added. If core.bare is set in the per-repo config
file, should all worktrees see this variable?
Since core.bare affects worktree-related commands (e.g. you are not
supposed to run "git status" when core.bare is true because no worktree
is supposed to link to the repository), when multi worktree is added,
core.bare is evaluated true by the main worktree only. Other worktrees
simply do not see core.bare even if it's there.
With per-worktree configuration in place, core.bare is moved to main
worktree's private config file. But it does not really make sense
because this is about _repository_. Instead we could leave core.bare in
the per-repo config and change/extend its definition from:
If true this repository is assumed to be 'bare' and has no working
directory associated with it.
to
If true this repository is assumed to be 'bare' and has no _main_
working directory associated with it.
In other words, linked worktrees are not covered by core.bare. This
definition is the same as before when it comes to single worktree setup.
A plus of this definition is, it allows a setup where we only have
linked worktrees (e.g. core.bare set to true, and the main repo is
tucked somewhere safe), which makes all worktrees equal again because
"the special one" is gone.
This patch is incomplete. I need to go through all is_bare_repository()
calls and adjust their behavior. But I wanted to run the idea through
the community first..
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 2 +-
Documentation/git-worktree.txt | 7 +++----
t/t2029-worktree-config.sh | 4 ++--
worktree.c | 6 ------
4 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c508386..ff146be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -484,7 +484,7 @@ core.preferSymlinkRefs::
expect HEAD to be a symbolic link.
core.bare::
- If true this repository is assumed to be 'bare' and has no
+ If true this repository is assumed to be 'bare' and has no main
working directory associated with it. If this is the case a
number of commands that require a working directory will be
disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index f5aad0a..a331d0a 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -161,7 +161,7 @@ them to the `config.worktree` of the main working directory. You may
also take this opportunity to move other configuration that you do not
want to share to all working directories:
- - `core.worktree` and `core.bare` should never be shared
+ - `core.worktree` should never be shared
- `core.sparseCheckout` is recommended per working directory, unless
you are sure you always use sparse checkout for all working
@@ -169,9 +169,8 @@ want to share to all working directories:
When `git config --worktree` is used to set a configuration variable
in multiple working directory setup, `extensions.worktreeConfig` will
-be automatically set. The two variables `core.worktree` and
-`core.bare` if present will be moved to `config.worktree` of the main
-working tree.
+be automatically set. The variable `core.worktree` if present will be
+moved to `config.worktree` of the main working tree.
DETAILS
-------
diff --git a/t/t2029-worktree-config.sh b/t/t2029-worktree-config.sh
index 4ebdf13..dc84c94 100755
--- a/t/t2029-worktree-config.sh
+++ b/t/t2029-worktree-config.sh
@@ -70,13 +70,13 @@ test_expect_success 'config.worktree no longer read without extension' '
cmp_config -C wt2 shared this.is
'
-test_expect_success 'config --worktree migrate core.bare and core.worktree' '
+test_expect_success 'config --worktree migrate core.worktree' '
git config core.bare true &&
git config --worktree foo.bar true &&
cmp_config true extensions.worktreeConfig &&
cmp_config true foo.bar &&
cmp_config true core.bare &&
- ! git -C wt1 config core.bare
+ cmp_config -C wt1 true core.bare
'
test_done
diff --git a/worktree.c b/worktree.c
index d8c9d85..c07cc50 100644
--- a/worktree.c
+++ b/worktree.c
@@ -395,12 +395,6 @@ void migrate_worktree_config(void)
read_repository_format(&format, main_path.buf);
assert(format.worktree_config == 0);
- if (format.is_bare >= 0) {
- git_config_set_in_file(worktree_path.buf,
- "core.bare", "true");
- git_config_set_in_file(main_path.buf,
- "core.bare", NULL);
- }
if (format.work_tree) {
git_config_set_in_file(worktree_path.buf,
"core.worktree",
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* Re: [PATCH v5 0/4] Per-worktree config file support
From: Duy Nguyen @ 2017-01-10 11:41 UTC (permalink / raw)
To: Git Mailing List
Cc: Junio C Hamano, Michael J Gruber, Jens Lehmann, Lars Schneider,
Stefan Beller, Michael Haggerty, Max Kirillov,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20170110112524.12870-1-pclouds@gmail.com>
On Tue, Jan 10, 2017 at 6:25 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Not much has changed from v4, except that the migration to new config
> layout is done automatically _update_ a config variable with "git
> config --worktree".
I accidentally two words that may make it hard to understand this
sentence. It should be "... is done automatically when you update.."
--
Duy
^ permalink raw reply
* Re: [musl] Re: Test failures when Git is built with libpcre and grep is built without it
From: Szabolcs Nagy @ 2017-01-10 11:40 UTC (permalink / raw)
To: musl; +Cc: Jeff King, Andreas Schwab, git, A. Wilcox
In-Reply-To: <5874B942.7070402@adelielinux.org>
* A. Wilcox <awilfox@adelielinux.org> [2017-01-10 04:36:50 -0600]:
> On 09/01/17 15:33, Jeff King wrote:
> > The problem is that we are expecting the regex "\x{2b}" to complain
> > in regcomp() (as an ERE), but it doesn't. And that probably _is_
> > related to musl, which is providing the libc regex (I know this
> > looks like a pcre test, but it's checking that "-P -E" overrides
> > the pcre option with "-E").
> >
> > I'm not sure if musl is wrong for failing to complain about a
> > bogus regex. Generally making something that would break into
> > something that works is an OK way to extend the standard. So our
> > test is at fault for assuming that the regex will fail. I guess
\x is undefined in posix and musl is based on tre which
supports \x{hexdigits} in ere.
(i think some bsd platforms use tre as libc regex so
i'm surprised musl is the first to run into this.)
> > we'd need to find some more exotic syntax that pcre supports, but
> > that ERE doesn't. Maybe "(?:)" or something.
i think you would have to use something that's invalid
in posix ere, ? after empty expression is undefined,
not an error so "(?:)" is a valid ere extension.
since most syntax is either defined or undefined in ere
instead of being invalid, distinguishing pcre using
syntax is not easy.
there are semantic differences in subexpression matching:
leftmost match has higher priority in pcre, longest match
has higher priority in ere.
$ echo ab | grep -o -E '(a|ab)'
ab
$ echo ab | grep -o -P '(a|ab)'
a
unfortunately grep -o is not portable.
^ permalink raw reply
* Re: Refreshing index timestamps without reading content
From: Quentin Casasnovas @ 2017-01-10 14:17 UTC (permalink / raw)
To: Quentin Casasnovas
Cc: Vegard Nossum, Junio C Hamano, Duy Nguyen, Git Mailing List
In-Reply-To: <20170109155537.GG7000@chrystal.oracle.com>
[-- Attachment #1: Type: text/plain, Size: 5131 bytes --]
On Mon, Jan 09, 2017 at 04:55:37PM +0100, Quentin Casasnovas wrote:
> On Mon, Jan 09, 2017 at 07:01:36AM -0800, Junio C Hamano wrote:
> > Duy Nguyen <pclouds@gmail.com> writes:
> >
> > > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> > > <quentin.casasnovas@oracle.com> 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 changed, as to avoid any useless file read (though it will obviously
> > >> will have to stat all of them, but that's not something we can really
> > >> avoid)
> > >
> > > I don't think there's any way to do that, unfortunately.
> >
> > Lose "unfortunately".
> >
> > >> If not, I am willing to implement a --assume-content-unchanged to the git
> > >> update-index if you guys don't see something fundamentally wrong with this
> > >> approach.
> > >
> > > If you do that, I think you should go with either of the following options
> > >
> > > - Extend git-update-index --index-info to take stat info as well (or
> > > maybe make a new option instead). Then you can feed stat info directly
> > > to git without a use-case-specific "assume-content-unchanged".
> > >
> > > - Add "git update-index --touch" that does what "touch" does. In this
> > > case, it blindly updates stat info to latest. But like touch, we can
> > > also specify mtime from command line if we need to. It's a bit less
> > > generic than the above option, but easier to use.
> >
> > Even if we assume that it is a good idea to let people muck with the
> > index like this, either of the above would be a usable addition,
> > because the cached stat information does not consist solely of
> > mtime.
> >
> > "git update-index --index-info" was invented for the case where a
> > user or a script _knows_ the object ID of the blob that _would_
> > result if a contents of a file on the filesystem were run through
> > hash-object. So from the interface's point of view, it may make
> > sense to teach it to take an extra/optional argument that is the
> > path to the file and take the stat info out of the named file when
> > the extra/optional argument was given.
> >
> > But that assumes that it is a good idea to do this in the first
> > place. It was deliberate design decision that setting the cached
> > stat info for the entry was protected behind actual content
> > comparison, and removing that protection will open the index to
> > abuse.
> >
>
> Hi Junio,
>
> Thanks for your feedback, appreciated :)
>
> I do understand how it would be possible for someone to shoot themselves in
> the feet with such option, but it solves real life use cases and improved
> build times very signficantly here.
>
> Another use case we have is setting up very lightweight linux work trees,
> by reflinking from a base work-tree. This allows for a completely
> different work-tree taking up almost no size at first, whereas using a
> shared clone or the recent worktree subcommand would "waste" ~500MB*:
>
> # linux-2.6 is a shared clone of a bare clone residing locally
> ~ $ cp --reflink -a linux-2.6 linux-2.6-reflinked
>
> # At this point, the mtime inside linux-2.6-reflinked are matching the
> # mtime of the source linux-2.6 (since we used the '-a' option of 'cp)
> ~ $ diff -u <(stat linux-2.6/README) <(stat linux-2.6-reflinked/README)
> --- /proc/self/fd/11 2017-01-09 16:34:04.523438942 +0100
> +++ /proc/self/fd/12 2017-01-09 16:34:04.523438942 +0100
> @@ -1,8 +1,8 @@
> - File: 'linux-2.6/README'
> + File: 'linux-2.6-reflinked/README'
> Size: 18372 Blocks: 40 IO Block: 4096 regular file
> -Device: fd00h/64768d Inode: 268467090 Links: 1
> +Device: fd00h/64768d Inode: 805970606 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 1000/ quentin) Gid: ( 1000/ quentin)
> Access: 2017-01-09 12:04:15.317758718 +0100
> Modify: 2017-01-09 12:04:12.566758772 +0100
> -Change: 2017-01-09 12:04:12.566758772 +0100
> +Change: 2017-01-09 16:29:48.305444003 +0100
> Birth:
>
> # Now let's check how long it takes to refresh the index from the source
> # and destination..
> ~/linux-2.6 $ time git update-index --refresh
> git update-index --refresh 0.04s user 0.08s system 204% cpu 0.058 total
> ~~~~~~~~~~~
> ~/linux-2.6-reflinked $ time git update-index --refresh
> git update-index --refresh 2.40s user 1.43s system 38% cpu 10.003 total
> ~~~~~~~~~~~~
>
After discussing this with my friend Vegard, he found the core.checkStat
config which, if set to 'minimal', ignores the inode number which is enough
for the above use case to work just fine - so please excuse my ignorance!
For the initial problem I had when changing the mtime of all the files in
the tree, I should be able to change the mtime of the object files instead,
hence I don't really need the patch I sent earlier.
Sorry for the wasted time! :)
Q
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/4] config: --worktree for manipulating per-worktree config file
From: Stefan Beller @ 2017-01-10 16:52 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git@vger.kernel.org, Junio C Hamano, Michael J Gruber,
Jens Lehmann, Lars Schneider, Michael Haggerty, Max Kirillov
In-Reply-To: <20170110112524.12870-3-pclouds@gmail.com>
> + if (repository_format_worktree_config)
> + given_config_source.file = git_pathdup("config.worktree");
> + else if (worktrees[0] && worktrees[1]) {
> + die("BUG: migration is not supported yet");
> + } else
> + given_config_source.file = git_pathdup("config");
nit: inconsistent use uf braces for single statements here.
I mean the braces are needed in the BUG case, as otherwise we'd
have a dangling else, but then you could put the brace in the else case as well.
This nit doesn't warrant a reroll on its own.
> + free_worktrees(worktrees);
> + } else if (given_config_source.file) {
> if (!is_absolute_path(given_config_source.file) && prefix)
> given_config_source.file =
> xstrdup(prefix_filename(prefix,
> --
> 2.8.2.524.g6ff3d78
>
^ permalink raw reply
* Re: [PATCH v5 0/4] Per-worktree config file support
From: Stefan Beller @ 2017-01-10 17:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git@vger.kernel.org, Junio C Hamano, Michael J Gruber,
Jens Lehmann, Lars Schneider, Michael Haggerty, Max Kirillov
In-Reply-To: <20170110112524.12870-1-pclouds@gmail.com>
On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Let's get this rolling again. To refresh your memory because it's half
> a year since v4 [1], this is about letting each worktree in multi
> worktree setup has their own config settings. The most prominent ones
> are core.worktree, used by submodules, and core.sparseCheckout.
Thanks for getting this rolling again.
>
> This time I'm not touching submodules at all. I'm leaving it in the
> good hands of "submodule people". All I'm providing is mechanism. How
> you use it is up to you. So the series benefits sparse checkout users
> only.
As one of the "submodule people", I have no complaints here.
>
> Not much has changed from v4, except that the migration to new config
> layout is done automatically _update_ a config variable with "git
> config --worktree".
>
> I think this one is more or less ready. I have an RFC follow-up patch
> about core.bare, but that could be handled separately.
I have read through the series and think the design is sound for worktrees
(though I have little knowledge about them).
---
Now even further:
So to build on top of this series, I'd like to make submodules usable
with worktrees (i.e. shared object store, only clone/fetch once and
all worktrees
benefit from it), the big question is how to get the underlying data
model right.
Would a submodule go into the superprojects
.git/worktrees/<worktree-name>/modules/<submodule-name>/
or rather
.git/modules<submodule-name>/worktrees/<worktree-name>
Or both (one of them being a gitlink file pointing at the other?)
I have not made up my mind, as I haven't laid out all cases that are
relevant here.
Thanks,
Stefan
>
> [1] http://public-inbox.org/git/20160720172419.25473-1-pclouds@gmail.com/
>
> Nguyễn Thái Ngọc Duy (4):
> config: read per-worktree config files
> config: --worktree for manipulating per-worktree config file
> config: automatically migrate to new config layout when --worktree is used
> t2029: add tests for per-worktree config
>
> Documentation/config.txt | 11 ++++-
> Documentation/git-config.txt | 26 ++++++++---
> Documentation/git-worktree.txt | 37 +++++++++++++++
> Documentation/gitrepository-layout.txt | 8 ++++
> builtin/config.c | 16 ++++++-
> cache.h | 2 +
> config.c | 7 +++
> environment.c | 1 +
> setup.c | 5 ++-
> t/t2029-worktree-config.sh (new +x) | 82 ++++++++++++++++++++++++++++++++++
> worktree.c | 40 +++++++++++++++++
> worktree.h | 6 +++
> 12 files changed, 230 insertions(+), 11 deletions(-)
> create mode 100755 t/t2029-worktree-config.sh
>
> --
> 2.8.2.524.g6ff3d78
>
^ permalink raw reply
* Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled
From: Richard Hansen @ 2017-01-10 17:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, davvid, sbeller, simon, gitster
In-Reply-To: <3a09e318-f14b-5f14-a992-3bd045f0a4c6@kdbg.org>
[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]
On 2017-01-10 01:17, Johannes Sixt wrote:
> 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 running 'git diff
>> --name-only' and adjust any relative pathnames so that 'git mergetool'
>> does not fail when run from a subdirectory with rerere enabled.
>>
>> This fixes a regression introduced in
>> 57937f70a09c12ef484c290865dac4066d207c9c (v2.11.0).
>>
>> Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
>> Signed-off-by: Richard Hansen <hansenr@google.com>
>> ---
>> git-mergetool.sh | 16 ++++++++++++++--
>> t/t7610-mergetool.sh | 7 ++++++-
>> 2 files changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/git-mergetool.sh b/git-mergetool.sh
>> index b506896dc..cba6bbd05 100755
>> --- a/git-mergetool.sh
>> +++ b/git-mergetool.sh
>> @@ -454,6 +454,15 @@ main () {
>> merge_keep_backup="$(git config --bool mergetool.keepBackup || echo true)"
>> merge_keep_temporaries="$(git config --bool mergetool.keepTemporaries || echo false)"
>>
>> + prefix=$(git rev-parse --show-prefix) || exit 1
>> + cd_to_toplevel
>> +
>> + if test -n "$orderfile"
>> + then
>> + orderfile=$(git rev-parse --prefix "$prefix" -- "$orderfile") || exit 1
>> + orderfile=$(printf %s\\n "$orderfile" | sed -e 1d)
>
> Is the purpose of this complication only to detect errors of the git
> invocation?
Yes. I've been burned so many times by the shell not stopping when
there's an error that I always like to do things one step at a time with
error checking, even if it is less efficient.
> IMHO, we could dispense with that, but others might
> disagree. I am arguing because this adds yet another process; but it is
> only paid when -O is used, so...
>
>> + fi
>> +
>> if test $# -eq 0 && test -e "$GIT_DIR/MERGE_RR"
>> then
>> set -- $(git rerere remaining)
>> @@ -461,14 +470,17 @@ main () {
>> then
>> print_noop_and_exit
>> fi
>> + elif test $# -ge 0
>> + then
>> + files_quoted=$(git rev-parse --sq --prefix "$prefix" -- "$@") || exit 1
>> + eval "set -- $files_quoted"
>
> BTW, the --sq and eval business is not required here. At this point,
> $IFS = $'\n',
Whoa, really? That's surprising and feels wrong.
(BTW, I just noticed that guess_merge_tool sets IFS to a space without
resetting it afterward. That function is always run in a subshell so
there's no problem at the moment, but it's still a bit risky.)
> so
>
> set -- $(git rev-parse --sq --prefix "$prefix" -- "$@")
>
> will do. (Except that it would not detect errors.)
I think I would prefer to leave it as-is in case IFS is ever changed
back to the default.
>
>> + shift
>> fi
>
> As I don't see anything wrong with what you have written, these comments
> alone do not warrant another re-roll.
I'll reroll if I hear other votes in favor of changing. Thanks for
reviewing!
-Richard
>
> -- Hannes
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4845 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile
From: Richard Hansen @ 2017-01-10 17:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170110065816.pu325sxajbyuqpj6@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
On 2017-01-10 01:58, Jeff King wrote:
> 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 <hansenr@google.com>
>> ---
>> Documentation/diff-config.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
>> index 58f4bd6af..875212045 100644
>> --- a/Documentation/diff-config.txt
>> +++ b/Documentation/diff-config.txt
>> @@ -101,6 +101,8 @@ diff.noprefix::
>> diff.orderFile::
>> File indicating how to order files within a diff, using
>> one shell glob pattern per line.
>> + If `diff.orderFile` is a relative pathname, it is treated as
>> + relative to the top of the work tree.
>> Can be overridden by the '-O' option to linkgit:git-diff[1].
>
> What happens in a bare repository?
I didn't know which is why this patch is silent on that topic. :)
>
> I'm guessing it's relative to the top-level of the repository,
I just tried it out and it's relative to $PWD.
> but we should probably spell it out.
Do we want it to be relative to $PWD? I think relative to $GIT_DIR is
more useful. If we want it to be relative to $GIT_DIR, then I think we
should stay silent regarding bare repositories so that the behavior
remains unspecified until we update the logic.
>
> The other case is --no-index when we are not in a repository at all, but
> that should just be relative to the current directory,
It is.
> which isn't really worth mentioning.
Agreed.
I'll post a re-roll if people prefer the current behavior over relative
to $GIT_DIR.
Thanks for reviewing,
Richard
>
> -Peff
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4845 bytes --]
^ permalink raw reply
* Re: [PATCHv8] pathspec: give better message for submodule related pathspec error
From: Junio C Hamano @ 2017-01-10 18:13 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, bmwill, peff
In-Reply-To: <20170109231650.9043-1-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> This comes as a single patch again, replacing sb/pathspec-errors.
> It goes directly on top of bw/pathspec-cleanup.
>
> v8:
> cleaned white spaces in commit message
> removed TEST_CREATE_SUBMODULE=yes
> : > instead of touch.
>
> v7:
> do not rely on "test_commit -C" being there, nor the infrastructure
> to request a "good" submodule upstream. Just create a submodule outselves
> to test in.
>
> Thanks,
> Stefan
Thanks, queued.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Localise error headers
From: Stefan Beller @ 2017-01-10 18:28 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git@vger.kernel.org
In-Reply-To: <20170110090418.4egk4oflblshmjon@sigill.intra.peff.net>
On Tue, Jan 10, 2017 at 1:04 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 09, 2017 at 01:43:15PM +0100, Michael J Gruber wrote:
>
>> > I can't say I'm excited about having matching "_" variants for each
>> > function. Are we sure that they are necessary? I.e., would it be
>> > acceptable to just translate them always?
>>
>> We would still need to mark the strings, e.g.
>>
>> die(N_("oopsie"));
>>
>> and would not be able to opt out of translating in the code (only in the
>> po file, by not providing a translation).
>
> I meant more along the lines of: would it be OK to just always translate
> the prefix, even if the message itself is not translated? I.e.,
>
> diff --git a/usage.c b/usage.c
> index 82ff13163..8e5400f57 100644
> --- a/usage.c
> +++ b/usage.c
> @@ -32,7 +32,7 @@ static NORETURN void usage_builtin(const char *err, va_list params)
>
> static NORETURN void die_builtin(const char *err, va_list params)
> {
> - vreportf("fatal: ", err, params);
> + vreportf(_("fatal: "), err, params);
> exit(128);
> }
>
>> In any case, the question is whether we want to tell the user
>>
>> A: B
>>
>> where A is in English and B is localised, or rather localise both A and
>> B (for A in "error", "fatal", "warning"...).
>>
>> For localising A and B, we'd need this series or something similar. For
>> keeping the mix, we don't need to do anything ;)
>
> What I wrote above would keep the mix, but switch it in the other
> direction.
>
> And then presumably that mix would gradually move to 100% consistency as
> more messages are translated. But the implicit question is: are there
> die() messages that should never be translated? I'm not sure.
I would assume any plumbing command is not localizing?
Because in plumbing land, (easily scriptable) you may find
a grep on the output/stderr for a certain condition?
To find a good example, "git grep die" giving me some food of though:
die_errno(..) should always take a string marked up for translation,
because the errno string is translated?
(-> we'd have to fix up any occurrence of git grep "die_errno(\"")
apply.c: die(_("internal error"));
That is funny, too. I think we should substitute that with
die("BUG: untranslated, but what went wrong instead")
>
> -Peff
^ permalink raw reply
* git-mergetool to be used for rebases as well?
From: Stefan Beller @ 2017-01-10 18:54 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
An internal user report running on origin/next:
$ git pull
From .
* branch ... -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: ...
Applying: ...
Using index info to reconstruct a base tree...
CONFLICT (content): ....
error: Failed to merge in the changes.
Patch failed at 0002...
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
$ git status
rebase in progress; onto ...
You are currently rebasing branch '...' on '...'.
Changes to be committed:
modified: ...
Unmerged paths:
both modified: ...
$ git mergetool
No files need merging
$ git diff <file name>
diff --cc <file name>
index ...
--- a/file
+++ b/file
@@@ ...
content
++<<<<<<< HEAD
+ content
++=======
+ content
++>>>>>>> other commit
content
The mergetool used to work apparently, but stopped for rebases.
I noticed in neither t7610-mergetool.sh nor any rebase test the combination of
rebase and mergetool is tested.
Stefan
^ permalink raw reply
* Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled
From: Junio C Hamano @ 2017-01-10 19:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Richard Hansen, git, davvid, sbeller, simon
In-Reply-To: <3a09e318-f14b-5f14-a992-3bd045f0a4c6@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
>> + prefix=$(git rev-parse --show-prefix) || exit 1
>> + cd_to_toplevel
>> +
>> + if test -n "$orderfile"
>> + then
>> + orderfile=$(git rev-parse --prefix "$prefix" -- "$orderfile") || exit 1
>> + orderfile=$(printf %s\\n "$orderfile" | sed -e 1d)
>
> Is the purpose of this complication only to detect errors of the git
> invocation? IMHO, we could dispense with that, but others might
> disagree. I am arguing because this adds yet another process; but it
> is only paid when -O is used, so...
I do not terribly mind an added process, but this change makes it
harder to read and also forces the readers to wonder if the quoting
around printf is correct.
>> @@ -461,14 +470,17 @@ main () {
>> then
>> print_noop_and_exit
>> fi
>> + elif test $# -ge 0
>> + then
>> + files_quoted=$(git rev-parse --sq --prefix "$prefix" -- "$@") || exit 1
>> + eval "set -- $files_quoted"
>
> BTW, the --sq and eval business is not required here. At this point,
> $IFS = $'\n', so
>
> set -- $(git rev-parse --sq --prefix "$prefix" -- "$@")
>
> will do. (Except that it would not detect errors.)
I thought you are suggesting not to use --sq but it is still there.
I think the original is written in such a way that any letter in
each of "$@" is preserved, even an LF in the filename.
Such a pathname probably won't correctly be given from the "rerere
remaining" side (i.e. when you are lazy and run mergetool without
pathname), so it may appear not to matter, but being able to give an
explicit pathname from the command line is a workaround for that, so
in that sense, it has value to prepare this side of the codepath to
be able to cope with such a pathname.
Unrelated, but I notice that in this:
eval "set -- $(git rev-parse --sq --prefix "$prefix" -- "$@")"
shift
"set" will get one "--" from its direct command line argument,
followed by "--" that comes out of rev-parse, and then the first
pathname (i.e. "$prefix/$1", if "$1" is relative). Then the first
"--" is discarded and the second "--" that came out of rev-parse
becomes "$1", and the first pathname becomes "$2", etc. We use
"shift" to get rid of "--" and move everything down by one.
It is my fault but it is a roundabout way to say:
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
I would think, and we should probably want to write this like so.
[PATCH v4 02/14] would probably want to be updated as well.
I can locally update them if everybody agrees it is a good idea.
^ permalink raw reply
* Re: [PATCHv2 2/5] unpack-trees: remove unneeded continue
From: Junio C Hamano @ 2017-01-10 19:55 UTC (permalink / raw)
To: Stefan Beller; +Cc: peff, l.s.r, git
In-Reply-To: <20170109194621.17013-3-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> 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 <sbeller@google.com>
> ---
Thanks for digging the history to find the culprit.
This is an unrelated tangent, but I do not think of a way other than
"log -L" to find it; conceptually, "blame" ought to be usable for
it, but it is not useful for finding deleted lines.
> unpack-trees.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 8e6768f283..d443decb23 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -253,7 +253,6 @@ static int check_updates(struct unpack_trees_options *o)
> display_progress(progress, ++cnt);
> if (o->update && !o->dry_run)
> unlink_entry(ce);
> - continue;
> }
> }
> remove_marked_cache_entries(index);
^ permalink raw reply
* Re: [PATCHv2 4/5] unpack-trees: factor file removal out of check_updates
From: Junio C Hamano @ 2017-01-10 20:05 UTC (permalink / raw)
To: Stefan Beller; +Cc: peff, l.s.r, git
In-Reply-To: <20170109194621.17013-5-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> This makes check_updates shorter and easier to understand.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
I agree that 3/5 made it easier to understand by ejecting a block
that is not essential to the functionality of the function out of
it, making the remainder of the fuction about "removing gone files
and then write out the modified files".
The ejecting of the first half of these two operations, both are
what this function is about, done by this step feels backwards. If
anything, the "only do the actual working tree manipulation when not
doing a dry-run and told to update" logic that must be in both are
spread in two helper functions after step 5/5, and with the added
boilerplate for these two helpers, the end result becomes _longer_
to understand what is really going on when check_updates() is
called.
Is the original after step 3/5 too long and hard to understand?
> 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
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -218,6 +218,26 @@ static void unlink_entry(const struct cache_entry *ce)
> schedule_dir_for_removal(ce->name, ce_namelen(ce));
> }
>
> +static unsigned remove_workingtree_files(struct unpack_trees_options *o,
> + struct progress *progress)
> +{
> + int i;
> + unsigned cnt = 0;
> + struct index_state *index = &o->result;
> +
> + for (i = 0; i < index->cache_nr; i++) {
> + const struct cache_entry *ce = index->cache[i];
> +
> + if (ce->ce_flags & CE_WT_REMOVE) {
> + display_progress(progress, ++cnt);
> + if (o->update && !o->dry_run)
> + unlink_entry(ce);
> + }
> + }
> +
> + return cnt;
> +}
> +
> static struct progress *get_progress(struct unpack_trees_options *o)
> {
> unsigned cnt = 0, total = 0;
> @@ -254,15 +274,8 @@ static int check_updates(struct unpack_trees_options *o)
>
> if (o->update)
> git_attr_set_direction(GIT_ATTR_CHECKOUT, index);
> - for (i = 0; i < index->cache_nr; i++) {
> - const struct cache_entry *ce = index->cache[i];
>
> - if (ce->ce_flags & CE_WT_REMOVE) {
> - display_progress(progress, ++cnt);
> - if (o->update && !o->dry_run)
> - unlink_entry(ce);
> - }
> - }
> + cnt = remove_workingtree_files(o, progress);
> remove_marked_cache_entries(index);
> remove_scheduled_dirs();
^ permalink raw reply
* [PATCH] index: improve constness for reading blob data
From: Brandon Williams @ 2017-01-10 20:06 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
Improve constness of the index_state parameter to the
'read_blob_data_from_index' function.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
cache.h | 2 +-
read-cache.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index a50a61a19..363953c1a 100644
--- a/cache.h
+++ b/cache.h
@@ -599,7 +599,7 @@ extern int chmod_index_entry(struct index_state *, struct cache_entry *ce, char
extern int ce_same_name(const struct cache_entry *a, const struct cache_entry *b);
extern void set_object_name_for_intent_to_add_entry(struct cache_entry *ce);
extern int index_name_is_other(const struct index_state *, const char *, int);
-extern void *read_blob_data_from_index(struct index_state *, const char *, unsigned long *);
+extern void *read_blob_data_from_index(const struct index_state *, const char *, unsigned long *);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index f92a912dc..6ee044442 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2292,7 +2292,8 @@ int index_name_is_other(const struct index_state *istate, const char *name,
return 1;
}
-void *read_blob_data_from_index(struct index_state *istate, const char *path, unsigned long *size)
+void *read_blob_data_from_index(const struct index_state *istate,
+ const char *path, unsigned long *size)
{
int pos, len;
unsigned long sz;
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* Re: [PATCH 2/2] diff: document the pattern format for diff.orderFile
From: Junio C Hamano @ 2017-01-10 20:14 UTC (permalink / raw)
To: Richard Hansen; +Cc: git
In-Reply-To: <20170110004031.57985-3-hansenr@google.com>
Richard Hansen <hansenr@google.com> writes:
> 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 <hansenr@google.com>
> ---
> Documentation/diff-config.txt | 3 ++-
> Documentation/diff-options.txt | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
> index 875212045..a35ecdd6b 100644
> --- a/Documentation/diff-config.txt
> +++ b/Documentation/diff-config.txt
> @@ -100,7 +100,8 @@ diff.noprefix::
>
> diff.orderFile::
> File indicating how to order files within a diff, using
> - one shell glob pattern per line.
> + one glob pattern per line.
> + See linkgit:gitignore[5] for the pattern format.
I do not think it is wise to suggest referring to gitignore, as the
logic of matching is quite different, other than the fact that they
both use wildmatch() internally. Also, unlike gitignore, orderfile
does not allow any negative matching i.e. "!<pattern>".
> If `diff.orderFile` is a relative pathname, it is treated as
> relative to the top of the work tree.
> Can be overridden by the '-O' option to linkgit:git-diff[1].
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index e6215c372..dc6b1af71 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -467,7 +467,8 @@ endif::git-format-patch[]
>
> -O<orderfile>::
> Output the patch in the order specified in the
> - <orderfile>, which has one shell glob pattern per line.
> + <orderfile>, which has one glob pattern per line.
> + See linkgit:gitignore[5] for the pattern format.
> This overrides the `diff.orderFile` configuration variable
> (see linkgit:git-config[1]). To cancel `diff.orderFile`,
> use `-O/dev/null`.
^ permalink raw reply
* Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile
From: Junio C Hamano @ 2017-01-10 20:19 UTC (permalink / raw)
To: Richard Hansen; +Cc: Jeff King, git
In-Reply-To: <e100d30a-5ee8-8485-5012-f9b1c6961ffa@google.com>
Richard Hansen <hansenr@google.com> writes:
> On 2017-01-10 01:58, Jeff King wrote:
> ...
>> What happens in a bare repository?
>>
>> I'm guessing it's relative to the top-level of the repository,
>
> I just tried it out and it's relative to $PWD.
That is understandable. When the user says
$ cmd -O $file
with any option -O that takes a filename, it is most natural if we
used $PWD/$file when $file is not absolute path.
^ permalink raw reply
* Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile
From: Junio C Hamano @ 2017-01-10 20:23 UTC (permalink / raw)
To: Richard Hansen; +Cc: Jeff King, git
In-Reply-To: <xmqq4m16sm5v.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Richard Hansen <hansenr@google.com> writes:
>
>> On 2017-01-10 01:58, Jeff King wrote:
>> ...
>>> What happens in a bare repository?
>>>
>>> I'm guessing it's relative to the top-level of the repository,
>>
>> I just tried it out and it's relative to $PWD.
>
> That is understandable. When the user says
>
> $ cmd -O $file
>
> with any option -O that takes a filename, it is most natural if we
> used $PWD/$file when $file is not absolute path.
Ahh, ignore me in the above. The discussion is about the
configuration variable, and I agree that being relative to GIT_DIR
would have made more sense. In fact taking it as relative to PWD
does not make any sense.
We should have been a lot more careful when we added 6d8940b562
("diff: add diff.orderfile configuration variable", 2013-12-18), but
it is too late to complain now.
A related tangent.
I wonder if anything that uses git_config_pathname() should be
relative to GIT_DIR when it is not absolute.
^ permalink raw reply
* Re: git-mergetool to be used for rebases as well?
From: Junio C Hamano @ 2017-01-10 20:26 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
In-Reply-To: <20170110185421.2638-1-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> $ git status
> rebase in progress; onto ...
> You are currently rebasing branch '...' on '...'.
>
> Changes to be committed:
> modified: ...
>
> Unmerged paths:
> both modified: ...
>
> $ git mergetool
> No files need merging
> $ git diff <file name>
> diff --cc <file name>
> index ...
> --- a/file
> +++ b/file
> @@@ ...
> content
> ++<<<<<<< HEAD
> + content
> ++=======
> + content
> ++>>>>>>> other commit
> content
>
>
> The mergetool used to work apparently, but stopped for rebases.
> I noticed in neither t7610-mergetool.sh nor any rebase test the combination of
> rebase and mergetool is tested.
The above redacts too much to be useful for guessing, but are you by
any chance being hit by a recent regression, i.e. have rerere enabled
and running mergetool from a subdirectory?
See <20170109232941.43637-15-hansenr@google.com> (and previous
rounds).
^ permalink raw reply
* Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled
From: Johannes Sixt @ 2017-01-10 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Richard Hansen, git, davvid, sbeller, simon
In-Reply-To: <xmqqmveyson3.fsf@gitster.mtv.corp.google.com>
Am 10.01.2017 um 20:25 schrieb Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> writes:
>> BTW, the --sq and eval business is not required here. At this point,
>> $IFS = $'\n', so
>>
>> set -- $(git rev-parse --sq --prefix "$prefix" -- "$@")
>>
>> will do. (Except that it would not detect errors.)
>
> I thought you are suggesting not to use --sq but it is still there.
A copy-paste-p. Of course, I want to suggest not to use --sq.
> Unrelated, but I notice that in this:
>
> eval "set -- $(git rev-parse --sq --prefix "$prefix" -- "$@")"
> shift
>
> It is my fault but it is a roundabout way to say:
>
> eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
Clever! But I fear that half a year down the road we will appreciate a
comment like
# rev-parse provides the -- needed for `set`
and then we are back at two lines, so I dunno...
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/4] t1000: modernize style
From: Junio C Hamano @ 2017-01-10 20:37 UTC (permalink / raw)
To: Stefan Beller; +Cc: bmwill, novalis, git
In-Reply-To: <20170110014542.19352-3-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> The preferred style in tests seems to be
s/seems to be/is/;
>
> test_expect_success 'short description, ended by 2 single quotes' '
> here comes the test &&
> and chains over many lines &&
> ended by a quote
> '
Thanks. This is way overdue. During the time the script has been
dormant for more than two years, we should have done this.
^ permalink raw reply
* Re: [PATCH 1/4] read-tree: use OPT_BOOL instead of OPT_SET_INT
From: Junio C Hamano @ 2017-01-10 20:41 UTC (permalink / raw)
To: Stefan Beller; +Cc: bmwill, novalis, git
In-Reply-To: <20170110014542.19352-2-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> All occurrences of OPT_SET_INT were setting the value to 1;
> internally OPT_BOOL is just that.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> builtin/read-tree.c | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
The result is much easier to read, partly because the "1" (true) is
at the very end of the line when OPT_SET_INT() is used for the
reader to notice that this is merely a boolean.
More importantly, as OPT_SET_INT() can be used multiple times on the
same variable (or field) to set it to different values, it is easier
to read if OPT_BOOL() is used when OPT_SET_INT() to 1 is not used
for that purpose.
Thanks.
>> diff --git a/builtin/read-tree.c b/builtin/read-tree.c
> index fa6edb35b2..8ba64bc785 100644
> --- a/builtin/read-tree.c
> +++ b/builtin/read-tree.c
> @@ -109,34 +109,34 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
> { OPTION_CALLBACK, 0, "index-output", NULL, N_("file"),
> N_("write resulting index to <file>"),
> PARSE_OPT_NONEG, index_output_cb },
> - OPT_SET_INT(0, "empty", &read_empty,
> - N_("only empty the index"), 1),
> + OPT_BOOL(0, "empty", &read_empty,
> + N_("only empty the index")),
> OPT__VERBOSE(&opts.verbose_update, N_("be verbose")),
> OPT_GROUP(N_("Merging")),
> - OPT_SET_INT('m', NULL, &opts.merge,
> - N_("perform a merge in addition to a read"), 1),
> - OPT_SET_INT(0, "trivial", &opts.trivial_merges_only,
> - N_("3-way merge if no file level merging required"), 1),
> - OPT_SET_INT(0, "aggressive", &opts.aggressive,
> - N_("3-way merge in presence of adds and removes"), 1),
> - OPT_SET_INT(0, "reset", &opts.reset,
> - N_("same as -m, but discard unmerged entries"), 1),
> + OPT_BOOL('m', NULL, &opts.merge,
> + N_("perform a merge in addition to a read")),
> + OPT_BOOL(0, "trivial", &opts.trivial_merges_only,
> + N_("3-way merge if no file level merging required")),
> + OPT_BOOL(0, "aggressive", &opts.aggressive,
> + N_("3-way merge in presence of adds and removes")),
> + OPT_BOOL(0, "reset", &opts.reset,
> + N_("same as -m, but discard unmerged entries")),
> { OPTION_STRING, 0, "prefix", &opts.prefix, N_("<subdirectory>/"),
> N_("read the tree into the index under <subdirectory>/"),
> PARSE_OPT_NONEG | PARSE_OPT_LITERAL_ARGHELP },
> - OPT_SET_INT('u', NULL, &opts.update,
> - N_("update working tree with merge result"), 1),
> + OPT_BOOL('u', NULL, &opts.update,
> + N_("update working tree with merge result")),
> { OPTION_CALLBACK, 0, "exclude-per-directory", &opts,
> N_("gitignore"),
> N_("allow explicitly ignored files to be overwritten"),
> PARSE_OPT_NONEG, exclude_per_directory_cb },
> - OPT_SET_INT('i', NULL, &opts.index_only,
> - N_("don't check the working tree after merging"), 1),
> + OPT_BOOL('i', NULL, &opts.index_only,
> + N_("don't check the working tree after merging")),
> OPT__DRY_RUN(&opts.dry_run, N_("don't update the index or the work tree")),
> - OPT_SET_INT(0, "no-sparse-checkout", &opts.skip_sparse_checkout,
> - N_("skip applying sparse checkout filter"), 1),
> - OPT_SET_INT(0, "debug-unpack", &opts.debug_unpack,
> - N_("debug unpack-trees"), 1),
> + OPT_BOOL(0, "no-sparse-checkout", &opts.skip_sparse_checkout,
> + N_("skip applying sparse checkout filter")),
> + OPT_BOOL(0, "debug-unpack", &opts.debug_unpack,
> + N_("debug unpack-trees")),
> OPT_END()
> };
^ permalink raw reply
* [PATCH v5 01/14] .mailmap: Use my personal email address as my canonical
From: Richard Hansen @ 2017-01-10 20:41 UTC (permalink / raw)
To: git; +Cc: davvid, j6t, hansenr, sbeller, simon, gitster
In-Reply-To: <20170110204202.21779-1-hansenr@google.com>
When I changed employers my work address changed from rhansen@bbn.com
to hansenr@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.)
Signed-off-by: Richard Hansen <hansenr@google.com>
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap b/.mailmap
index 9cc33e925..9c87a3840 100644
--- a/.mailmap
+++ b/.mailmap
@@ -192,6 +192,8 @@ Philippe Bruhat <book@cpan.org>
Ralf Thielow <ralf.thielow@gmail.com> <ralf.thielow@googlemail.com>
Ramsay Jones <ramsay@ramsayjones.plus.com> <ramsay@ramsay1.demon.co.uk>
René Scharfe <l.s.r@web.de> <rene.scharfe@lsrfire.ath.cx>
+Richard Hansen <rhansen@rhansen.org> <hansenr@google.com>
+Richard Hansen <rhansen@rhansen.org> <rhansen@bbn.com>
Robert Fitzsimons <robfitz@273k.net>
Robert Shearman <robertshearman@gmail.com> <rob@codeweavers.com>
Robert Zeh <robert.a.zeh@gmail.com>
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* [PATCH v5 00/14] fix mergetool+rerere+subdir regression
From: Richard Hansen @ 2017-01-10 20:41 UTC (permalink / raw)
To: git; +Cc: davvid, j6t, hansenr, sbeller, simon, gitster
In-Reply-To: <20170109232941.43637-1-hansenr@google.com>
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 v4:
* Revert to Junio's original proposal for 14/14. (Junio: Please
feel free to take author credit on 14/4; it's now 100% your code.)
* Do:
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq -- "$@")"
instead of:
eval "set -- $(git rev-parse --sq -- "$@")"
shift
for both 02/14 and 14/14.
Richard Hansen (14):
.mailmap: Use my personal email address as my canonical
rev-parse doc: pass "--" to rev-parse in the --prefix example
t7610: update branch names to match test number
t7610: Move setup code to the 'setup' test case.
t7610: use test_when_finished for cleanup tasks
t7610: don't rely on state from previous test
t7610: run 'git reset --hard' after each test to clean up
t7610: delete some now-unnecessary 'git reset --hard' lines
t7610: always work on a test-specific branch
t7610: don't assume the checked-out commit
t7610: spell 'git reset --hard' consistently
t7610: add test case for rerere+mergetool+subdir bug
mergetool: take the "-O" out of $orderfile
mergetool: fix running in subdir when rerere enabled
.mailmap | 2 +
Documentation/git-rev-parse.txt | 3 +-
git-mergetool.sh | 21 ++-
t/t7610-mergetool.sh | 281 ++++++++++++++++++++++++----------------
4 files changed, 187 insertions(+), 120 deletions(-)
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply
* [PATCH v5 09/14] t7610: always work on a test-specific branch
From: Richard Hansen @ 2017-01-10 20:41 UTC (permalink / raw)
To: git; +Cc: davvid, j6t, hansenr, sbeller, simon, gitster
In-Reply-To: <20170110204202.21779-1-hansenr@google.com>
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 <hansenr@google.com>
---
t/t7610-mergetool.sh | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 7d5e1df88..efcf5c3f1 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -184,6 +184,7 @@ test_expect_success 'mergetool in subdir' '
test_expect_success 'mergetool on file in parent dir' '
test_when_finished "git reset --hard" &&
+ git checkout -b test$test_count &&
git submodule update -N &&
(
cd subdir &&
@@ -217,6 +218,7 @@ test_expect_success 'mergetool skips autoresolved' '
test_expect_success 'mergetool merges all from subdir' '
test_when_finished "git reset --hard" &&
+ git checkout -b test$test_count &&
test_config rerere.enabled false &&
(
cd subdir &&
@@ -288,7 +290,7 @@ test_expect_success 'mergetool takes partial path' '
test_expect_success 'mergetool delete/delete conflict' '
test_when_finished "git reset --hard HEAD" &&
- git checkout move-to-c &&
+ git checkout -b test$test_count move-to-c &&
test_must_fail git merge move-to-b &&
echo d | git mergetool a/a/file.txt &&
! test -f a/a/file.txt &&
@@ -304,6 +306,7 @@ test_expect_success 'mergetool delete/delete conflict' '
test_expect_success 'mergetool produces no errors when keepBackup is used' '
test_when_finished "git reset --hard HEAD" &&
+ git checkout -b test$test_count &&
test_config mergetool.keepBackup true &&
test_must_fail git merge move-to-b &&
: >expect &&
@@ -314,6 +317,7 @@ test_expect_success 'mergetool produces no errors when keepBackup is used' '
test_expect_success 'mergetool honors tempfile config for deleted files' '
test_when_finished "git reset --hard HEAD" &&
+ git checkout -b test$test_count &&
test_config mergetool.keepTemporaries false &&
test_must_fail git merge move-to-b &&
echo d | git mergetool a/a/file.txt &&
@@ -323,6 +327,7 @@ test_expect_success 'mergetool honors tempfile config for deleted files' '
test_expect_success 'mergetool keeps tempfiles when aborting delete/delete' '
test_when_finished "git reset --hard HEAD" &&
test_when_finished "git clean -fdx" &&
+ git checkout -b test$test_count &&
test_config mergetool.keepTemporaries true &&
test_must_fail git merge move-to-b &&
! (echo a; echo n) | git mergetool a/a/file.txt &&
@@ -640,7 +645,7 @@ test_expect_success MKTEMP 'temporary filenames are used with mergetool.writeToT
test_expect_success 'diff.orderFile configuration is honored' '
test_when_finished "git reset --hard >/dev/null" &&
- git checkout order-file-side2 &&
+ git checkout -b test$test_count order-file-side2 &&
test_config diff.orderFile order-file &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
@@ -658,6 +663,7 @@ test_expect_success 'diff.orderFile configuration is honored' '
'
test_expect_success 'mergetool -Oorder-file is honored' '
test_when_finished "git reset --hard >/dev/null 2>&1" &&
+ git checkout -b test$test_count &&
test_config diff.orderFile order-file &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox