* [PATCH 3/3] Remove outdated info in difftool manpage
From: Denton Liu @ 2017-03-03 11:57 UTC (permalink / raw)
To: git; +Cc: davvid, Johannes.Schindelin
When difftool was rewritten in C, it removed the capability to read
fallback configs from mergetool. This changes the documentation to
reflect this.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
Documentation/git-difftool.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 96c26e6aa..a00cb033e 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -105,9 +105,6 @@ See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
----------------
-'git difftool' falls back to 'git mergetool' config variables when the
-difftool equivalents have not been defined.
-
diff.tool::
The default diff tool to use.
--
2.12.0.1.g5415fdfc5.dirty
^ permalink raw reply related
* [PATCH 2/3] Add gui completions for difftool
From: Denton Liu @ 2017-03-03 11:57 UTC (permalink / raw)
To: git; +Cc: davvid, Johannes.Schindelin
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d5f3b9aeb..c94e38a3a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1277,7 +1277,7 @@ _git_difftool ()
--base --ours --theirs
--no-renames --diff-filter= --find-copies-harder
--relative --ignore-submodules
- --tool="
+ --tool= --gui"
return
;;
esac
@@ -2207,6 +2207,7 @@ _git_config ()
diff.submodule
diff.suppressBlankEmpty
diff.tool
+ diff.guitool
diff.wordRegex
diff.algorithm
difftool.
--
2.12.0.1.g5415fdfc5.dirty
^ permalink raw reply related
* Re: [PATCH v2 1/9] t7006: replace dubious test
From: Johannes Schindelin @ 2017-03-03 11:10 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303033623.lfi7jhul6psbdde6@sigill.intra.peff.net>
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:02AM +0100, Johannes Schindelin wrote:
>
> > The intention of that test case, however, was to verify that the
> > setup_git_directory() function has not run, because it changes global
> > state such as the current working directory.
> >
> > To keep that spirit, but fix the incorrect assumption, this patch
> > replaces that test case by a new one that verifies that the pager is
> > run in the subdirectory, i.e. that the current working directory has
> > not been changed at the time the pager is configured and launched,
> > even if the `rev-parse` command requires a .git/ directory and *will*
> > change the working directory.
>
> This is a great solution to the question I had in v1 ("how do we know
> when setup_git_directory() is run?"). It not only checks the
> internal-code case that we care about, but it also shows how real users
> would get bit if we do the wrong thing.
Thanks!
> > +test_expect_failure TTY 'core.pager in repo config works and retains cwd' '
> > + sane_unset GIT_PAGER &&
> > + test_config core.pager "cat >cwd-retained" &&
> > + (
> > + cd sub &&
> > + rm -f cwd-retained &&
> > + test_terminal git -p rev-parse HEAD &&
> > + test -e cwd-retained
> > + )
> > +'
>
> Does this actually need TTY and test_terminal?
Sadly, yes. If git.c sees a --paginate or -p, it sets use_pager to 1 which
is later used as indicator that setup_pager() should be run. And the first
line of that function reads:
const char *pager = git_pager(isatty(1));
i.e. it does *not* turn on the pager unconditionally.
> (Also a minor nit: we usually prefer test_path_is_file to "test -e"
> these days).
Thanks, fixed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts
From: Jeff King @ 2017-03-03 11:21 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <0102015a93d18443-c574aaf8-5656-49e8-8848-810e1fadc87a-000000@eu-west-1.amazonses.com>
On Fri, Mar 03, 2017 at 10:57:46AM +0000, Sebastian Schuberth wrote:
> It does not make sense for these placeholder scripts to depend on Python
> just because the real scripts do. At the example of Git for Windows, we
> would not even be able to see those warnings as it does not ship with
> Python. So just use plain shell scripts instead.
Yeah, this seems like an obvious improvement. I think we got here
because the originals issued a warning but kept working, and then it was
slowly whittled down to remove the "working" part.
At some point these can probably go away. It's been 3 years since they
turned into nothing but warnings, so presumably most people have
upgraded by now (I know people often go a long time on old
distro-packaged versions, but the distro packagers would presumably
figure this out in the meantime).
OTOH, it is not really hurting much, so I do not mind keeping them
around for another 3 years (or more) just to catch any stragglers.
-Peff
^ permalink raw reply
* [RFC PATCH 2/2] completion: add bash completion for 'filter-branch'
From: Denton Liu @ 2017-03-03 12:35 UTC (permalink / raw)
To: git
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
If the last patch (PATCH 1/2) is not included, we can remove the call to
__git_complete_rev_list_command.
---
contrib/completion/git-completion.bash | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 412485369..933dac78b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1307,6 +1307,23 @@ _git_fetch ()
__git_complete_remote_or_refspec
}
+__git_filter_branch_options="
+ --env-filter --tree-filter --index-filter --parent-filter --msg-filter
+ --commit-filter --tag-name-filter --subdirectory-filter --prune-empty
+ --original --force
+"
+_git_filter_branch ()
+{
+ __git_has_doubledash && __git_complete_rev_list_command && return
+
+ case "$cur" in
+ --*)
+ __gitcomp "$__git_filter_branch_options"
+ return
+ ;;
+ esac
+}
+
__git_format_patch_options="
--stdout --attach --no-attach --thread --thread= --no-thread
--numbered --start-number --numbered-files --keep-subject --signoff
--
2.12.0.1.g5415fdfc5.dirty
^ permalink raw reply related
* Re: [PATCH 1/3] Add --gui option to mergetool
From: David Aguilar @ 2017-03-03 12:39 UTC (permalink / raw)
To: Denton Liu; +Cc: git, Johannes.Schindelin
In-Reply-To: <20170303115738.GA13211@arch-attack.localdomain>
On Fri, Mar 03, 2017 at 03:57:38AM -0800, Denton Liu wrote:
> This fixes the discrepancy between difftool and mergetool where the
> former has the --gui flag and the latter does not by adding the
> functionality to mergetool.
>
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
> Documentation/git-mergetool.txt | 8 +++++++-
> contrib/completion/git-completion.bash | 3 ++-
> git-mergetool.sh | 5 ++++-
> t/t7610-mergetool.sh | 28 +++++++++++++++++++++++++++-
> 4 files changed, 40 insertions(+), 4 deletions(-)
Would you mind splitting up this patch so that the
completion part is done separately?
> diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
> index 381b7df45..5683907ab 100755
> --- a/t/t7610-mergetool.sh
> +++ b/t/t7610-mergetool.sh
> @@ -145,6 +147,30 @@ test_expect_success 'custom mergetool' '
> git commit -m "branch1 resolved with mergetool"
> '
>
> +test_expect_success 'gui mergetool' '
> + test_when_finished "git reset --hard" &&
> + test_when_finished "git config merge.tool mytool" &&
> + test_when_finished "git config --unset merge.guitool" &&
> + git config merge.tool badtool &&
> + git config merge.guitool mytool &&
> + git checkout -b test$test_count branch1 &&
> + git submodule update -N &&
> + test_must_fail git merge master >/dev/null 2>&1 &&
It'd probably be better to use test_expect_code instead of
test_must_fail here:
test_expect_code 1 git merge master ...
> + ( yes "" | git mergetool -g both >/dev/null 2>&1 ) &&
> + ( yes "" | git mergetool -g file1 file1 ) &&
> + ( yes "" | git mergetool --gui file2 "spaced name" >/dev/null 2>&1 ) &&
> + ( yes "" | git mergetool --gui subdir/file3 >/dev/null 2>&1 ) &&
I realize that this test is based on an existing one, but I'm curious..
is "yes" used above because it's prompting, and using -y or --no-prompt
here would eliminate the need for the 'yes ""' parts?
Looks good otherwise.
Thanks,
--
David
^ permalink raw reply
* [PATCH v2 1/5] Detect merges specifically in test t7610-mergetool
From: Denton Liu @ 2017-03-03 13:40 UTC (permalink / raw)
To: git; +Cc: davvid, Johannes.Schindelin
Prior to this, the test cases would use 'test_expect_failure' to detect
a merge conflict. This changes the test case to use 'test_expect_code 1'
which is more specific.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
t/t7610-mergetool.sh | 76 ++++++++++++++++++++++++++--------------------------
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 381b7df45..a9e274add 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -130,7 +130,7 @@ test_expect_success 'custom mergetool' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
- test_must_fail git merge master >/dev/null 2>&1 &&
+ test_expect_code 1 git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
( yes "" | git mergetool file1 file1 ) &&
( yes "" | git mergetool file2 "spaced name" >/dev/null 2>&1 ) &&
@@ -153,7 +153,7 @@ test_expect_success 'mergetool crlf' '
# test_when_finished is LIFO.)
test_config core.autocrlf true &&
git checkout -b test$test_count branch1 &&
- test_must_fail git merge master >/dev/null 2>&1 &&
+ test_expect_code 1 git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
( yes "" | git mergetool "spaced name" >/dev/null 2>&1 ) &&
@@ -176,7 +176,7 @@ test_expect_success 'mergetool in subdir' '
git submodule update -N &&
(
cd subdir &&
- test_must_fail git merge master >/dev/null 2>&1 &&
+ test_expect_code 1 git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file3 >/dev/null 2>&1 ) &&
test "$(cat file3)" = "master new sub"
)
@@ -188,7 +188,7 @@ test_expect_success 'mergetool on file in parent dir' '
git submodule update -N &&
(
cd subdir &&
- test_must_fail git merge master >/dev/null 2>&1 &&
+ test_expect_code 1 git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool ../file1 >/dev/null 2>&1 ) &&
( yes "" | git mergetool ../file2 ../spaced\ name >/dev/null 2>&1 ) &&
@@ -207,7 +207,7 @@ test_expect_success 'mergetool skips autoresolved' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
@@ -222,7 +222,7 @@ test_expect_success 'mergetool merges all from subdir (rerere disabled)' '
test_config rerere.enabled false &&
(
cd subdir &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
( yes "r" | git mergetool ../submod ) &&
( yes "d" "d" | git mergetool --no-prompt ) &&
test "$(cat ../file1)" = "master updated" &&
@@ -241,7 +241,7 @@ test_expect_success 'mergetool merges all from subdir (rerere enabled)' '
rm -rf .git/rr-cache &&
(
cd subdir &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
( yes "r" | git mergetool ../submod ) &&
( yes "d" "d" | git mergetool --no-prompt ) &&
test "$(cat ../file1)" = "master updated" &&
@@ -259,7 +259,7 @@ test_expect_success 'mergetool skips resolved paths when rerere is active' '
rm -rf .git/rr-cache &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
- test_must_fail git merge master >/dev/null 2>&1 &&
+ test_expect_code 1 git merge master >/dev/null 2>&1 &&
( yes "l" | git mergetool --no-prompt submod >/dev/null 2>&1 ) &&
( yes "d" "d" | git mergetool --no-prompt >/dev/null 2>&1 ) &&
git submodule update -N &&
@@ -275,7 +275,7 @@ test_expect_success 'conflicted stash sets up rerere' '
git stash &&
git checkout --detach stash2 &&
- test_must_fail git stash apply &&
+ test_expect_code 1 git stash apply &&
test -n "$(git ls-files -u)" &&
conflicts="$(git rerere remaining)" &&
@@ -286,7 +286,7 @@ test_expect_success 'conflicted stash sets up rerere' '
git commit -am "save the stash resolution" &&
git reset --hard stash2 &&
- test_must_fail git stash apply &&
+ test_expect_code 1 git stash apply &&
test -n "$(git ls-files -u)" &&
conflicts="$(git rerere remaining)" &&
@@ -300,7 +300,7 @@ test_expect_success 'mergetool takes partial path' '
test_config rerere.enabled false &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
( yes "" | git mergetool subdir ) &&
@@ -310,15 +310,15 @@ test_expect_success 'mergetool takes partial path' '
test_expect_success 'mergetool delete/delete conflict' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count move-to-c &&
- test_must_fail git merge move-to-b &&
+ test_expect_code 1 git merge move-to-b &&
echo d | git mergetool a/a/file.txt &&
! test -f a/a/file.txt &&
git reset --hard &&
- test_must_fail git merge move-to-b &&
+ test_expect_code 1 git merge move-to-b &&
echo m | git mergetool a/a/file.txt &&
test -f b/b/file.txt &&
git reset --hard &&
- test_must_fail git merge move-to-b &&
+ test_expect_code 1 git merge move-to-b &&
! echo a | git mergetool a/a/file.txt &&
! test -f a/a/file.txt
'
@@ -327,7 +327,7 @@ test_expect_success 'mergetool produces no errors when keepBackup is used' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count move-to-c &&
test_config mergetool.keepBackup true &&
- test_must_fail git merge move-to-b &&
+ test_expect_code 1 git merge move-to-b &&
: >expect &&
echo d | git mergetool a/a/file.txt 2>actual &&
test_cmp expect actual &&
@@ -338,7 +338,7 @@ test_expect_success 'mergetool honors tempfile config for deleted files' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count move-to-c &&
test_config mergetool.keepTemporaries false &&
- test_must_fail git merge move-to-b &&
+ test_expect_code 1 git merge move-to-b &&
echo d | git mergetool a/a/file.txt &&
! test -d a
'
@@ -348,7 +348,7 @@ test_expect_success 'mergetool keeps tempfiles when aborting delete/delete' '
test_when_finished "git clean -fdx" &&
git checkout -b test$test_count move-to-c &&
test_config mergetool.keepTemporaries true &&
- test_must_fail git merge move-to-b &&
+ test_expect_code 1 git merge move-to-b &&
! (echo a; echo n) | git mergetool a/a/file.txt &&
test -d a/a &&
cat >expect <<-\EOF &&
@@ -368,7 +368,7 @@ test_expect_success 'deleted vs modified submodule' '
git rm --cached submod &&
git commit -m "Submodule deleted from branch" &&
git checkout -b test$test_count.a test$test_count &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -385,7 +385,7 @@ test_expect_success 'deleted vs modified submodule' '
mv submod submod-movedaside &&
git checkout -b test$test_count.b test$test_count &&
git submodule update -N &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -399,7 +399,7 @@ test_expect_success 'deleted vs modified submodule' '
mv submod-movedaside submod &&
git checkout -b test$test_count.c master &&
git submodule update -N &&
- test_must_fail git merge test$test_count &&
+ test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -415,7 +415,7 @@ test_expect_success 'deleted vs modified submodule' '
git checkout -b test$test_count.d master &&
git submodule update -N &&
- test_must_fail git merge test$test_count &&
+ test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -439,7 +439,7 @@ test_expect_success 'file vs modified submodule' '
git add submod &&
git commit -m "Submodule path becomes file" &&
git checkout -b test$test_count.a branch1 &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -455,7 +455,7 @@ test_expect_success 'file vs modified submodule' '
mv submod submod-movedaside &&
git checkout -b test$test_count.b test$test_count &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -471,7 +471,7 @@ test_expect_success 'file vs modified submodule' '
rmdir submod && mv submod-movedaside submod &&
test ! -e submod.orig &&
git submodule update -N &&
- test_must_fail git merge test$test_count &&
+ test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both >/dev/null 2>&1 ) &&
@@ -487,7 +487,7 @@ test_expect_success 'file vs modified submodule' '
git checkout -b test$test_count.d master &&
rmdir submod && mv submod.orig submod &&
git submodule update -N &&
- test_must_fail git merge test$test_count &&
+ test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "" | git mergetool both>/dev/null 2>&1 ) &&
@@ -544,7 +544,7 @@ test_expect_success 'submodule in subdirectory' '
git add subdir/subdir_module &&
git commit -m "change submodule in subdirectory on test$test_count.b" &&
- test_must_fail git merge test$test_count.a >/dev/null 2>&1 &&
+ test_expect_code 1 git merge test$test_count.a >/dev/null 2>&1 &&
(
cd subdir &&
( yes "l" | git mergetool subdir_module )
@@ -555,7 +555,7 @@ test_expect_success 'submodule in subdirectory' '
git reset --hard &&
git submodule update -N &&
- test_must_fail git merge test$test_count.a >/dev/null 2>&1 &&
+ test_expect_code 1 git merge test$test_count.a >/dev/null 2>&1 &&
( yes "r" | git mergetool subdir/subdir_module ) &&
test "$(cat subdir/subdir_module/file15)" = "test$test_count.b" &&
git submodule update -N &&
@@ -573,14 +573,14 @@ test_expect_success 'directory vs modified submodule' '
git add submod/file16 &&
git commit -m "Submodule path becomes directory" &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
( yes "l" | git mergetool submod ) &&
test "$(cat submod/file16)" = "not a submodule" &&
rm -rf submod.orig &&
git reset --hard &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
test ! -e submod.orig &&
( yes "r" | git mergetool submod ) &&
@@ -596,7 +596,7 @@ test_expect_success 'directory vs modified submodule' '
git checkout -b test$test_count.c master &&
git submodule update -N &&
- test_must_fail git merge test$test_count &&
+ test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
( yes "l" | git mergetool submod ) &&
git submodule update -N &&
@@ -604,7 +604,7 @@ test_expect_success 'directory vs modified submodule' '
git reset --hard &&
git submodule update -N &&
- test_must_fail git merge test$test_count &&
+ test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
test ! -e submod.orig &&
( yes "r" | git mergetool submod ) &&
@@ -618,7 +618,7 @@ test_expect_success 'directory vs modified submodule' '
test_expect_success 'file with no base' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
git mergetool --no-prompt --tool mybase -- both &&
>expected &&
test_cmp both expected
@@ -629,7 +629,7 @@ test_expect_success 'custom commands override built-ins' '
git checkout -b test$test_count branch1 &&
test_config mergetool.defaults.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
test_config mergetool.defaults.trustExitCode true &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
git mergetool --no-prompt --tool defaults -- both &&
echo master both added >expected &&
test_cmp both expected
@@ -641,7 +641,7 @@ test_expect_success 'filenames seen by tools start with ./' '
test_config mergetool.writeToTemp false &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
git mergetool --no-prompt --tool myecho -- both >actual &&
grep ^\./both_LOCAL_ actual >/dev/null
'
@@ -658,7 +658,7 @@ test_expect_success MKTEMP 'temporary filenames are used with mergetool.writeToT
test_config mergetool.writeToTemp true &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
- test_must_fail git merge master &&
+ test_expect_code 1 git merge master &&
git mergetool --no-prompt --tool myecho -- both >actual &&
! grep ^\./both_LOCAL_ actual >/dev/null &&
grep /both_LOCAL_ actual >/dev/null
@@ -672,7 +672,7 @@ test_expect_success 'diff.orderFile configuration is honored' '
test_config mergetool.myecho.trustExitCode true &&
echo b >order-file &&
echo a >>order-file &&
- test_must_fail git merge order-file-side1 &&
+ test_expect_code 1 git merge order-file-side1 &&
cat >expect <<-\EOF &&
Merging:
b
@@ -695,7 +695,7 @@ test_expect_success 'mergetool -Oorder-file is honored' '
test_config mergetool.myecho.trustExitCode true &&
echo b >order-file &&
echo a >>order-file &&
- test_must_fail git merge order-file-side1 &&
+ test_expect_code 1 git merge order-file-side1 &&
cat >expect <<-\EOF &&
Merging:
a
@@ -707,7 +707,7 @@ test_expect_success 'mergetool -Oorder-file is honored' '
git reset --hard &&
git config --unset diff.orderFile &&
- test_must_fail git merge order-file-side1 &&
+ test_expect_code 1 git merge order-file-side1 &&
cat >expect <<-\EOF &&
Merging:
b
--
2.12.0.5.gfbc750a84
^ permalink raw reply related
* [PATCH v2 2/5] Use -y where possible in test t7610-mergetool
From: Denton Liu @ 2017-03-03 13:40 UTC (permalink / raw)
To: git; +Cc: davvid, Johannes.Schindelin
In these tests, there are many situations where
'echo "" | git mergetool' is used. This replaces all of those
occurrences with 'git mergetool -y' for simplicity and readability.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
t/t7610-mergetool.sh | 62 ++++++++++++++++++++++++++--------------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index a9e274add..01c1d44a9 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -131,10 +131,10 @@ test_expect_success 'custom mergetool' '
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_expect_code 1 git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool file1 file1 ) &&
- ( yes "" | git mergetool file2 "spaced name" >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
+ git mergetool -y both >/dev/null 2>&1 &&
+ git mergetool -y file1 file1 &&
+ git mergetool -y file2 "spaced name" >/dev/null 2>&1 &&
+ git mergetool -y subdir/file3 >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod >/dev/null 2>&1 ) &&
@@ -154,11 +154,11 @@ test_expect_success 'mergetool crlf' '
test_config core.autocrlf true &&
git checkout -b test$test_count branch1 &&
test_expect_code 1 git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool "spaced name" >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
+ git mergetool file1 >/dev/null 2>&1 &&
+ git mergetool file2 >/dev/null 2>&1 &&
+ git mergetool "spaced name" >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
+ git mergetool subdir/file3 >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod >/dev/null 2>&1 ) &&
@@ -177,7 +177,7 @@ test_expect_success 'mergetool in subdir' '
(
cd subdir &&
test_expect_code 1 git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool file3 >/dev/null 2>&1 ) &&
+ git mergetool file3 >/dev/null 2>&1 &&
test "$(cat file3)" = "master new sub"
)
'
@@ -189,10 +189,10 @@ test_expect_success 'mergetool on file in parent dir' '
(
cd subdir &&
test_expect_code 1 git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool ../file1 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool ../file2 ../spaced\ name >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool ../both >/dev/null 2>&1 ) &&
+ git mergetool file3 >/dev/null 2>&1 &&
+ git mergetool ../file1 >/dev/null 2>&1 &&
+ git mergetool ../file2 ../spaced\ name >/dev/null 2>&1 &&
+ git mergetool ../both >/dev/null 2>&1 &&
( yes "d" | git mergetool ../file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool ../file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool ../submod >/dev/null 2>&1 ) &&
@@ -302,7 +302,7 @@ test_expect_success 'mergetool takes partial path' '
git submodule update -N &&
test_expect_code 1 git merge master &&
- ( yes "" | git mergetool subdir ) &&
+ git mergetool subdir &&
test "$(cat subdir/file3)" = "master new sub"
'
@@ -370,8 +370,8 @@ test_expect_success 'deleted vs modified submodule' '
git checkout -b test$test_count.a test$test_count &&
test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
rmdir submod && mv submod-movedaside submod &&
@@ -387,8 +387,8 @@ test_expect_success 'deleted vs modified submodule' '
git submodule update -N &&
test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
test ! -e submod &&
@@ -401,8 +401,8 @@ test_expect_success 'deleted vs modified submodule' '
git submodule update -N &&
test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
test ! -e submod &&
@@ -417,8 +417,8 @@ test_expect_success 'deleted vs modified submodule' '
git submodule update -N &&
test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
test "$(cat submod/bar)" = "master submodule" &&
@@ -441,8 +441,8 @@ test_expect_success 'file vs modified submodule' '
git checkout -b test$test_count.a branch1 &&
test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
rmdir submod && mv submod-movedaside submod &&
@@ -457,8 +457,8 @@ test_expect_success 'file vs modified submodule' '
git checkout -b test$test_count.b test$test_count &&
test_expect_code 1 git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
git submodule update -N &&
@@ -473,8 +473,8 @@ test_expect_success 'file vs modified submodule' '
git submodule update -N &&
test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both >/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
test -d submod.orig &&
@@ -489,8 +489,8 @@ test_expect_success 'file vs modified submodule' '
git submodule update -N &&
test_expect_code 1 git merge test$test_count &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool both>/dev/null 2>&1 ) &&
+ git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 &&
+ git mergetool both>/dev/null 2>&1 &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
test "$(cat submod/bar)" = "master submodule" &&
--
2.12.0.5.gfbc750a84
^ permalink raw reply related
* [PATCH v2 3/5] Add --gui option to mergetool
From: Denton Liu @ 2017-03-03 13:40 UTC (permalink / raw)
To: git; +Cc: davvid, Johannes.Schindelin
This fixes the discrepancy between difftool and mergetool where the
former has the --gui flag and the latter does not by adding the
functionality to mergetool.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
Documentation/git-mergetool.txt | 8 +++++++-
git-mergetool.sh | 5 ++++-
t/t7610-mergetool.sh | 28 +++++++++++++++++++++++++++-
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 3622d6648..2ab56efcf 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -8,7 +8,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
[verse]
-'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
+'git mergetool' [--tool=<tool>] [-g|--gui] [-y | --[no-]prompt] [<file>...]
DESCRIPTION
-----------
@@ -64,6 +64,12 @@ variable `mergetool.<tool>.trustExitCode` can be set to `true`.
Otherwise, 'git mergetool' will prompt the user to indicate the
success of the resolution after the custom tool has exited.
+-g::
+--gui::
+ When 'git-mergetool' is invoked with the `-g` or `--gui` option
+ the default diff tool will be read from the configured
+ `merge.guitool` variable instead of `merge.tool`.
+
--tool-help::
Print a list of merge tools that may be used with `--tool`.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index c062e3de3..f3fce528b 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -9,7 +9,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [-O<orderfile>] [file to merge] ...'
+USAGE='[--tool=tool] [-g|--gui] [--tool-help] [-y|--no-prompt|--prompt] [-O<orderfile>] [file to merge] ...'
SUBDIRECTORY_OK=Yes
NONGIT_OK=Yes
OPTIONS_SPEC=
@@ -414,6 +414,9 @@ main () {
shift ;;
esac
;;
+ -g|--gui)
+ merge_tool=$(git config merge.guitool)
+ ;;
-y|--no-prompt)
prompt=false
;;
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 01c1d44a9..31610f3b0 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -123,7 +123,9 @@ test_expect_success 'setup' '
git config mergetool.mytool.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
git config mergetool.mytool.trustExitCode true &&
git config mergetool.mybase.cmd "cat \"\$BASE\" >\"\$MERGED\"" &&
- git config mergetool.mybase.trustExitCode true
+ git config mergetool.mybase.trustExitCode true &&
+ git config mergetool.badtool.cmd false &&
+ git config mergetool.badtool.trustExitCode true
'
test_expect_success 'custom mergetool' '
@@ -145,6 +147,30 @@ test_expect_success 'custom mergetool' '
git commit -m "branch1 resolved with mergetool"
'
+test_expect_success 'gui mergetool' '
+ test_when_finished "git reset --hard" &&
+ test_when_finished "git config merge.tool mytool" &&
+ test_when_finished "git config --unset merge.guitool" &&
+ git config merge.tool badtool &&
+ git config merge.guitool mytool &&
+ git checkout -b test$test_count branch1 &&
+ git submodule update -N &&
+ test_expect_code 1 git merge master >/dev/null 2>&1 &&
+ git mergetool -g both >/dev/null 2>&1 &&
+ git mergetool -g file1 file1 &&
+ git mergetool --gui file2 "spaced name" >/dev/null 2>&1 &&
+ git mergetool --gui subdir/file3 >/dev/null 2>&1 &&
+ ( yes "d" | git mergetool -g file11 >/dev/null 2>&1 ) &&
+ ( yes "d" | git mergetool --gui file12 >/dev/null 2>&1 ) &&
+ ( yes "l" | git mergetool --gui submod >/dev/null 2>&1 ) &&
+ cat file1 &&
+ test "$(cat file1)" = "master updated" &&
+ test "$(cat file2)" = "master new" &&
+ test "$(cat subdir/file3)" = "master new sub" &&
+ test "$(cat submod/bar)" = "branch1 submodule" &&
+ git commit -m "branch1 resolved with gui mergetool"
+'
+
test_expect_success 'mergetool crlf' '
test_when_finished "git reset --hard" &&
# This test_config line must go after the above reset line so that
--
2.12.0.5.gfbc750a84
^ permalink raw reply related
* Re: [PATCH v2 3/9] setup_git_directory(): avoid changing global state during discovery
From: Johannes Schindelin @ 2017-03-03 13:54 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303042422.s3dnbgbjszhygwqz@sigill.intra.peff.net>
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:11AM +0100, Johannes Schindelin wrote:
>
> > For historical reasons, Git searches for the .git/ directory (or the
> > .git file) by changing the working directory successively to the
> > parent directory of the current directory, until either anything was
> > found or until a ceiling or a mount point is hit.
>
> This is starting to get into the meat of changes we've been putting off
> writing for ages. I'll read with my fingers crossed. :)
Heh.
> > Further global state may be changed, depending on the actual type of
> > discovery, e.g. the global variable
> > `repository_format_precious_objects` is set in the
> > `check_repository_format_gently()` function (which is a bit
> > surprising, given the function name).
>
> It's gentle in the sense that if it does not find a valid repo, it
> touches no state. I do suspect the functions you want are the ones it
> builds on: read_repository_format() and verify_repository_format(),
> which I added not too long ago for the exact purpose of checking repo
> config without touching anything global.
Okay. But I think that my interpretation of the word "gently" is as valid
as Git's source code's.
> > We do have a use case where we would like to find the .git/ directory
> > without having any global state touched, though: when we read the early
> > config e.g. for the pager or for alias expansion.
> >
> > Let's just rename the function `setup_git_directory_gently_1()` to
> > `discover_git_directory()` and move all code that changes any global
> > state back into `setup_git_directory_gently()`.
>
> Given the earlier paragraph, it sounds like you want to move the
> global-state-changing parts out of check_repository_format_gently(). But
> that wouldn't be right; it's triggered separate from the discovery
> process by things like enter_repo().
Oh, right. I really only meant to move the global-state-changing parts out
of the discover_git_directory().
> However, I don't see that happening in the patch, which is good. I just
> wonder if the earlier paragraph should really be complaining about how
> setup_git_directory() (and its callees) touches a lot of global state,
> not check_repository_format_gently(), whose use is but one of multiple
> global-state modifications.
Okay, I'll try my best to rephrase the commit message.
For good measure, I will also keep the name setup_git_directory_gently_1()
because it won't get exported directly (I made up my mind about wrapping
that function to allow for an easier interface that does *not* return the
"cdup").
> > Note: the new loop is a *little* tricky, as we have to handle the root
> > directory specially: we cannot simply strip away the last component
> > including the slash, as the root directory only has that slash. To
> > remedy that, we introduce the `min_offset` variable that holds the
> > minimal length of an absolute path, and using that to special-case the
> > root directory, including an early exit before trying to find the
> > parent of the root directory.
>
> I wondered how t1509 fared with this, as it is the only test of
> repositories at the root directory (and it is not run by default because
> it involves a bunch of flaky and expensive chroot setup).
Oh, thanks. I allowed myself to forget about that test script (and did a
lot of testing by hand, but of course *during* the development of v2, not
when I had finished...).
> Unfortunately it seems to fail with your patch:
>
> expecting success:
> test_cmp_val "foo/" "$(git rev-parse --show-prefix)"
>
> --- expected
> +++ result
> @@ -1 +1 @@
> -foo/
> +oo/
> not ok 66 - auto gitdir, foo: prefix
I can reproduce this failure here.
Side note: it took a while until I realized that the prepare-chroot.sh
script has to be run *every time* I change *anything* in either Git's
source code or in the test script.
> Could the problem be this:
>
> > + int ceil_offset = -1, min_offset = has_dos_drive_prefix(dir->buf) ? 3 : 1;
> > [...]
> > - if (ceil_offset < 0 && has_dos_drive_prefix(cwd.buf))
> > - ceil_offset = 1;
> > + if (ceil_offset < 0)
> > + ceil_offset = min_offset - 2;
Yes. The previous code did not need cwd.buf[0..offset] to be a valid path,
but it needed the offset to point to the trailing slash, if any.
> Interestingly, I don't think this is the bug, though. We still correctly
> find /.git as a repository. The problem seems to happen later, in
> setup_discovered_git_dir(), which does this:
>
> /* Make "offset" point to past the '/', and add a '/' at the end */
> offset++;
> strbuf_addch(cwd, '/');
> return cwd->buf + offset;
I fixed this by ensuring that we only increment the offset if it is not
already pointing at the end of the first offset (which handles Windows
paths correctly, too).
> Other than this bug, I very much like the direction that this patch is
> taking us.
Awesome. I was anxious to hear something like that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2 5/9] Make read_early_config() reusable
From: Johannes Schindelin @ 2017-03-03 14:11 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303044630.tfogzhzbokuoiwh6@sigill.intra.peff.net>
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:20AM +0100, Johannes Schindelin wrote:
>
> > The pager configuration needs to be read early, possibly before
> > discovering any .git/ directory.
> >
> > Let's not hide this function in pager.c, but make it available to other
> > callers.
> > [...]
> > + * Note that this is a really dirty hack that does the wrong thing in
> > + * many cases. The crux of the problem is that we cannot run
>
> Makes sense. I'll assume the words "dirty hack" disappear from this
> now-public function as you fix it up in a future patch. :)
Oops. I did not even think about that.
Fixed,
Dscho
^ permalink raw reply
* Re: [PATCH v5 15/24] refs: move submodule code out of files-backend.c
From: Michael Haggerty @ 2017-03-03 14:32 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, git
Cc: Junio C Hamano, Johannes Schindelin, Ramsay Jones, Stefan Beller,
novalis
In-Reply-To: <20170222140450.30886-16-pclouds@gmail.com>
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> files-backend is now initialized with a $GIT_DIR. Converting a submodule
> path to where real submodule gitdir is located is done in get_ref_store().
>
> This gives a slight performance improvement for submodules since we
> don't convert submodule path to gitdir at every backend call like
> before. We pay that once at ref-store creation.
>
> More cleanup in files_downcast() and files_assert_main_repository()
> follows shortly. It's separate to keep noises from this patch.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> refs.c | 20 ++++++++++++++------
> refs/files-backend.c | 24 ++----------------------
> refs/refs-internal.h | 9 ++++-----
> 3 files changed, 20 insertions(+), 33 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 562834fc0..67acae60c 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -9,6 +9,7 @@
> #include "refs/refs-internal.h"
> #include "object.h"
> #include "tag.h"
> +#include "submodule.h"
>
> /*
> * List of all available backends
> @@ -1413,9 +1414,9 @@ static struct ref_store *lookup_submodule_ref_store(const char *submodule)
>
> /*
> * Create, record, and return a ref_store instance for the specified
> - * submodule (or the main repository if submodule is NULL).
> + * gitdir.
> */
> -static struct ref_store *ref_store_init(const char *submodule)
> +static struct ref_store *ref_store_init(const char *gitdir)
> {
> const char *be_name = "files";
> struct ref_storage_be *be = find_ref_storage_backend(be_name);
> @@ -1424,7 +1425,7 @@ static struct ref_store *ref_store_init(const char *submodule)
> if (!be)
> die("BUG: reference backend %s is unknown", be_name);
>
> - refs = be->init(submodule);
> + refs = be->init(gitdir);
> return refs;
> }
>
> @@ -1435,7 +1436,7 @@ struct ref_store *get_main_ref_store(void)
> if (main_ref_store)
> return main_ref_store;
>
> - refs = ref_store_init(NULL);
> + refs = ref_store_init(get_git_dir());
> if (refs) {
> if (main_ref_store)
> die("BUG: main_ref_store initialized twice");
> @@ -1466,6 +1467,7 @@ struct ref_store *get_ref_store(const char *submodule)
> {
> struct strbuf submodule_sb = STRBUF_INIT;
> struct ref_store *refs;
> + int ret;
>
> if (!submodule || !*submodule) {
> return get_main_ref_store();
> @@ -1476,8 +1478,14 @@ struct ref_store *get_ref_store(const char *submodule)
> return refs;
>
> strbuf_addstr(&submodule_sb, submodule);
> - if (is_nonbare_repository_dir(&submodule_sb))
> - refs = ref_store_init(submodule);
> + ret = is_nonbare_repository_dir(&submodule_sb);
> + strbuf_release(&submodule_sb);
> + if (!ret)
> + return refs;
`refs` is always NULL here, right? Then it would be more transparent to
return NULL. Or maybe use the `goto cleanup` pattern, which makes it
clearer which are error-handling paths (and lets you get avoid the
temporary variable `ret`)).
> +
> + ret = submodule_to_gitdir(&submodule_sb, submodule);
> + if (!ret)
> + refs = ref_store_init(submodule_sb.buf);
> strbuf_release(&submodule_sb);
>
> if (refs)
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index d80c27837..37443369b 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -917,12 +917,6 @@ struct packed_ref_cache {
> struct files_ref_store {
> struct ref_store base;
>
> - /*
> - * The name of the submodule represented by this object, or
> - * NULL if it represents the main repository's reference
> - * store:
> - */
> - const char *submodule;
> char *gitdir;
> char *gitcommondir;
> char *packed_refs_path;
> @@ -982,22 +976,14 @@ static void clear_loose_ref_cache(struct files_ref_store *refs)
> * Create a new submodule ref cache and add it to the internal
> * set of caches.
> */
> -static struct ref_store *files_ref_store_create(const char *submodule)
> +static struct ref_store *files_ref_store_create(const char *gitdir)
> {
> struct files_ref_store *refs = xcalloc(1, sizeof(*refs));
> struct ref_store *ref_store = (struct ref_store *)refs;
> struct strbuf sb = STRBUF_INIT;
> - const char *gitdir = get_git_dir();
>
> base_ref_store_init(ref_store, &refs_be_files);
>
> - if (submodule) {
> - refs->submodule = xstrdup(submodule);
> - refs->packed_refs_path = git_pathdup_submodule(
> - refs->submodule, "packed-refs");
> - return ref_store;
> - }
> -
> refs->gitdir = xstrdup(gitdir);
> get_common_dir_noenv(&sb, gitdir);
> refs->gitcommondir = strbuf_detach(&sb, NULL);
> @@ -1014,8 +1000,7 @@ static struct ref_store *files_ref_store_create(const char *submodule)
> static void files_assert_main_repository(struct files_ref_store *refs,
> const char *caller)
> {
> - if (refs->submodule)
> - die("BUG: %s called for a submodule", caller);
> + /* This function is to be deleted in the next patch */
I don't think the above comment is correct anymore. Possibly the commit
log message is also out of date too, but I haven't read far enough ahead
to know.
> [...]
Michael
^ permalink raw reply
* [PATCH v2 4/5] Add guitool completions for diff and mergetools
From: Denton Liu @ 2017-03-03 13:40 UTC (permalink / raw)
To: git; +Cc: davvid, Johannes.Schindelin
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
contrib/completion/git-completion.bash | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 41ee52991..c94e38a3a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1277,7 +1277,7 @@ _git_difftool ()
--base --ours --theirs
--no-renames --diff-filter= --find-copies-harder
--relative --ignore-submodules
- --tool="
+ --tool= --gui"
return
;;
esac
@@ -1584,7 +1584,7 @@ _git_mergetool ()
return
;;
--*)
- __gitcomp "--tool= --prompt --no-prompt"
+ __gitcomp "--tool= --prompt --no-prompt --gui"
return
;;
esac
@@ -2207,6 +2207,7 @@ _git_config ()
diff.submodule
diff.suppressBlankEmpty
diff.tool
+ diff.guitool
diff.wordRegex
diff.algorithm
difftool.
@@ -2308,6 +2309,7 @@ _git_config ()
merge.renormalize
merge.stat
merge.tool
+ merge.guitool
merge.verbosity
mergetool.
mergetool.keepBackup
--
2.12.0.5.gfbc750a84
^ permalink raw reply related
* Re: [PATCH v2 4/9] Export the discover_git_directory() function
From: Johannes Schindelin @ 2017-03-03 14:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303044518.rdtyvgs7kqe7fkpf@sigill.intra.peff.net>
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:15AM +0100, Johannes Schindelin wrote:
>
> > diff --git a/cache.h b/cache.h
> > index 80b6372cf76..a104b76c02e 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -518,6 +518,7 @@ extern void set_git_work_tree(const char *tree);
> > #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
> >
> > extern void setup_work_tree(void);
> > +extern const char *discover_git_directory(struct strbuf *gitdir);
>
> Perhaps it's worth adding a short docstring describing the function.
Okay.
> > +const char *discover_git_directory(struct strbuf *gitdir)
> > +{
> > + struct strbuf dir = STRBUF_INIT;
> > + int len;
>
> Nit: please use size_t for storing strbuf lengths.
Okay.
> > + if (strbuf_getcwd(&dir))
> > + return NULL;
> > +
> > + len = dir.len;
> > + if (discover_git_directory_1(&dir, gitdir) < 0) {
> > + strbuf_release(&dir);
> > + return NULL;
> > + }
> > +
> > + if (dir.len < len && !is_absolute_path(gitdir->buf)) {
> > + strbuf_addch(&dir, '/');
> > + strbuf_insert(gitdir, 0, dir.buf, dir.len);
> > + }
> > + strbuf_release(&dir);
>
> I was confused by two things here.
>
> One is that because I was wondering whether "gitdir" was supposed to be
> passed empty or not, it wasn't clear that this insert is doing the right
> thing. If there _is_ something in it, then discover_git_directory_1()
> would just append to it, which makes sense. But then this insert blindly
> sticks the absolute-path bit at the front of the string, leaving
> whatever was originally there spliced into the middle of the path.
> Doing:
>
> size_t base = gitdir->len;
> ...
> strbuf_insert(gitdir, base, dir.buf, dir.len);
>
> would solve that.
And of course the is_absolute_path() call also needs to offset `gitdir->buf
+ base`.
> It's probably not that likely for somebody to do:
>
> strbuf_addstr(&buf, "my git dir is ");
> discover_git_directory(&buf);
>
> but since it's not much effort, it might be worth making it work.
Plus, I have no assert()s in place to ensure any expectation to the
contrary. So I fixed it as you suggested.
> The second is that I don't quite understand why we only make the result
> absolute when we walked upwards. In git.git, the result of the function
> in various directories is:
>
> - ".git", when we're at the root of the worktree
> - "/home/peff/git/.git, when we're in "t/"
> - "." when we're already in ".git"
> - "/home/peff/git/.git/." when we're in ".git/objects"
> > I'm not sure if some of those cases are not behaving as intended, or
> there's some reason for the differences that I don't quite understand.
Yes, some of those cases do not behave as intended: it is true that
setup_git_directory() sets git_dir to "/home/peff/git/.git" when we
(actually, you, given that my home directory is different) are in "t/",
but setup_git_directory_gently_1() would set gitdir to ".git" and dir to
"/home/peff/git". But the current directory is still what cwd says it is:
"/home/peff/git/t".
I added a comment:
/*
* The returned gitdir is relative to dir, and if dir does not reflect
* the current working directory, we simply make the gitdir
* absolute.
*/
And thanks: you reminded me of another issue I wanted to address but
forgot: if gitdir is ".", I do not want the resulting absolute path to
have a trailing "/.". I fixed that, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 16/24] files-backend: replace submodule_allowed check in files_downcast()
From: Michael Haggerty @ 2017-03-03 14:49 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, git
Cc: Junio C Hamano, Johannes Schindelin, Ramsay Jones, Stefan Beller,
novalis
In-Reply-To: <20170222140450.30886-17-pclouds@gmail.com>
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> files-backend.c is unlearning submodules. Instead of having a specific
> check for submodules to see what operation is allowed, files backend
> now takes a set of flags at init. Each operation will check if the
> required flags is present before performing.
>
> For now we have four flags: read, write and odb access. Main ref store
> has all flags, obviously, while submodule stores are read-only and have
> access to odb (*).
I'm surprised that you have implemented a "read" flag. Do you expect
ever to support ref-stores that are unreadable? In other words, couldn't
"read" just be assumed for any ref store?
> The "main" flag stays because many functions in the backend calls
> frontend ones without a ref store, so these functions always target the
> main ref store. Ideally the flag should be gone after ref-store-aware
> api is in place and used by backends.
>
> (*) Submodule code needs for_each_ref. Try take REF_STORE_ODB flag
> out. At least t3404 would fail. The "have access to odb" in submodule is
> a bit hacky since we don't know from he whether add_submodule_odb() has
> been called.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> refs.c | 15 ++++++---
> refs/files-backend.c | 86 +++++++++++++++++++++++++++++++++-------------------
> refs/refs-internal.h | 9 +++++-
> 3 files changed, 73 insertions(+), 37 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 67acae60c..2dc97891a 100644
> --- a/refs.c
> +++ b/refs.c
> [...]
> @@ -1821,10 +1829,14 @@ static enum peel_status peel_entry(struct ref_entry *entry, int repeel)
> static int files_peel_ref(struct ref_store *ref_store,
> const char *refname, unsigned char *sha1)
> {
> - struct files_ref_store *refs = files_downcast(ref_store, 0, "peel_ref");
> + struct files_ref_store *refs =
> + files_downcast(ref_store, REF_STORE_READ | REF_STORE_ODB,
> + "peel_ref");
> int flag;
> unsigned char base[20];
>
> + files_assert_main_repository(refs, "peel_ref");
Instead of this call, couldn't you add `REF_STORE_MAIN` to the flags
passed to `files_downcase()`?
> +
> if (current_ref_iter && current_ref_iter->refname == refname) {
> struct object_id peeled;
>
> [...]
Michael
^ permalink raw reply
* Re: [PATCH v2 6/9] read_early_config(): special-case builtins that create a repository
From: Johannes Schindelin @ 2017-03-03 15:11 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303045101.om7qtbcmtuw6kzvr@sigill.intra.peff.net>
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:24AM +0100, Johannes Schindelin wrote:
>
> > When the command we are about to execute wants to create a repository
> > (i.e. the command is `init` or `clone`), we *must not* look for a
> > repository config.
>
> Hmm. I'm not sure if this one is worth the hackery here.
I guess you're right. Let me think about this for a while in the back of
my head while I work on other parts of the patch series.
Ciao,
Dscho
^ permalink raw reply
* Re: SHA1 collisions found
From: Ian Jackson @ 2017-03-03 14:54 UTC (permalink / raw)
To: Jeff King
Cc: Brandon Williams, Jason Cooper, Junio C Hamano, Linus Torvalds,
Joey Hess, Git Mailing List
In-Reply-To: <20170303111347.6uzuhvmpdwr27qjw@sigill.intra.peff.net>
Jeff King writes ("Re: SHA1 collisions found"):
> I think you've read more into my "conversion" than I intended. The old
> history won't get rewritten. It will just be grafted onto the bottom of
> the commit history you've got, and the new trees will all be written
> with the new hash.
>
> So you still have those old objects hanging around that refer to things
> by their sha1 (not to mention bug trackers, commit messages, etc, which
> all use commit ids). And you want to be able to quickly resolve those
> references.
>
> What _does_ get rewritten is what's in your ref files, your pack .idx,
> etc. Those are all sha256 (or whatever), and work as sha1's do now.
This all sounds very similar to my proposal.
> Looking up a sha1 reference from an old object just goes through the
> extra level of indirection.
I don't understand why this is a level of indirection, rather than
simply a retention of the existing SHA-1 object database (in parallel,
but deprecated).
Perhaps I have misunderstood what you mean by "graft". I assume you
don't mean info/grafts, because that is not conveyed by transfer
protocols.
Stepping back a bit, the key question is what the data structure will
look like after the transition.
Specifically, the parent reference in the first post-transition commit
has to refer to something. What does it refer to ? The possibilities
seem to be:
1a. It names the SHA1 hash of an old commit object
1b. It names the BLAKE[1] hash of an old commit object, which
object of course refers to its parents by SHA1.
2. It names the BLAKE hash of a translated version of the
old commit object.
3. It doesn't name the parent, and the old history is not
automatically transferred by clone and not readily accessible.
(1a) and (1b) are different variants of something like my mixed hash
proposal. Old and new hashes live side by side.
(2) involves rewriting all of the old history, to recursively generate
new objects (with BLAKE names, and which in turn refer to other
rewritten old objects by BLAKE names). The first time a particular
tree needs to look up an object by a BLAKE name, it needs to run a
conversion its own entire existing history.
For (2) there would have to be some kind of mapping table in every
tree, which allowed object names to be maped in both directions. The
object content translation would have to be reversible, so that the
actual pre-translation objects would not need to be stored; rather
they would be reconstructed from the post-translation objects, when
someone asks for a pre-translation object. In principle it would be
possible to convert future BLAKE commits to SHA-1 ones, again by
recursive rewriting.
I don't think anyone is seriously suggesting (3).
So there is a choice between:
(1) a unified hash tree containing a mixture of different hashes at
different reference points, where each object has one identity and one
name.
(2) parallel hash tree structures, each using only a single hash, with
at least every old object present in both tree structures.
I think (1) is preferable because it provides, to callers of git, the
existing object naming semantics. Callers need to be taught to accept
an extension to the object name format. Existing object names stored
elsewhere than in git remain valid.
Conversely, (2) requires many object names stored elsewhere than in
git to be updated. It's possible with (2) to do ad-hoc lookups on
object names in mailing list messages or commit messages and so on.
Even if it is possible for the new git to answer questions like "does
this new branch with BLAKE hash X' contain the commit with SHA1 hash
Y" by implicitly looking up the corresponding BLAKE commit Y' and
answering the question with reference to Y', this isn't going to help
if external code does things like "have git compute the merge base of
X and Y' and check that it is equal to Z". Either the external
database's record of Z would have to be changed to refer to Z', or the
external code would have to be taught to apply an object name
normalisation operation to turn Z into Z' each time.
Also, (2) has trouble with shallow clones. This is because it's not
possible to translate old objects to new ones without descending to
the roots of the object tree and recursively translating everything
(or looking up the answer of a previous translation).
Then there is the question of naming syntax.
The distinction between (1) single unified mixed hash tree, and
(2) multiple parallel homogenous hash trees, is mostly orthogonal to
the command-line (and in-commit-object etc.) representation of new
hashes.
The main thing here is that, regardless of the choice between (1) or
(2), we need to choose whether object names specified on the git
command line, and printed by normal git commands, explicitly identify
the hash function.
I think there are roughly three options:
(A) Decorate all new hashes with a hash function indication
(sha256:<hex> or blake_<hex> or H<hex>)
(B) Infer the hash function from the object name length
(and do some kind of bodge for abbreviated object names).
(C) Hash function is implicit from context. (This is compatible with
(2) only, because (1) requires any object to be able to refer to
any hash function.)
I think (A) is best because it means everything is unambiguous, and it
allows future hash function changes without further difficulty.
(B) is a reasonable possibility although the abbreviated object name
bodge would be quite ugly and probably involve thinking about several
annoying edge cases.
I think (C) is really bad, because it instantly makes all existing
application code which calls git to be buggy. Such application code
would need to be adjusted to know for itself which of the object names
it has recorded are what hash function, and explicitly specify this to
its git operations somehow.
All of these options involve updating many callers of git. In any
case any git caller which explicitly checks the object name length
will need to be changed. For (a), many git callers which match object
names using something like [0-9a-f]+ rather than \w+ will need to be
changed - but at least it's a simple change with little semantic
import.
(A) has the additional advantage that it becomes possible to make
object names syntactically distinguishable from ref names.
The final argument I would make is this:
We don't know what hash function research will look like in 10-20
years. We would like to not have a bunch of pain again. So ideally
we would deploy a framework now that would let us switch hash function
again without further history-rewriting.
(1)(A) and perhaps (1)(B) are the only options which support this
well.
Ian.
[1] I'm going to keep assuming that the bikeshed will be blue, because
I think BLAKE2b has is a better choice. It has probably had more
serious people looking at it than SHA-3, at least, and it has good
performance. The web page has an impressive adoption list - probably
wider than SHA-3.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
^ permalink raw reply
* Re: [PATCH v2 9/9] Test read_early_config()
From: Johannes Schindelin @ 2017-03-03 15:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303050745.wv4zsb24ykr34xr7@sigill.intra.peff.net>
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:36AM +0100, Johannes Schindelin wrote:
>
> > So far, we had no explicit tests of that function.
>
> Makes sense. The pager tests fixed in an earlier commit were effectively
> checking those, but I don't mind making it explicit.
Well, TBH I am a bit uncomfortable with t7006 doing those tests. Just
imagine that something breaks in that script, say, when working on
exporting the read_early_config() function. You probably see this coming:
debugging those breakages is half a nightmare. There are multiple levels
of shell script functions, a Perl script, and an isatty() call between the
bug hunter and the bug.
With the new tests, it all becomes much more straight-forward to debug.
And also less surprising (think about the fun you can have with test cases
that fail when running `make t7006-pager.sh` but not when running `bash
t7006-pager.sh -i -v -x`, just because of a forgotten `test_terminal`...).
And yes, you can debug t7006 with the good old "insert debug print
statements here and there, then compile and run, rinse & repeat" method.
But you know, getting to use a real IDE with real debugger/intellisense
integration after years of working on C code in the terminal with vim and
gdb [*1*], I kinda feel a bit pampered and ask myself how I could possibly
have put up with the awkwardness. ;-)
Ciao,
Dscho
Footnote *1*: for some years I developed Java code in Eclipse and already
then did I notice just how much faster development becomes when you have
powerful tools to help you...
^ permalink raw reply
* Re: [PATCH v2 0/9] Fix the early config
From: Johannes Schindelin @ 2017-03-03 15:31 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303051451.elzz2kzumft2iugg@sigill.intra.peff.net>
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:03:56AM +0100, Johannes Schindelin wrote:
>
> > These patches are an attempt to make Git's startup sequence a bit less
> > surprising.
> >
> > The idea here is to discover the .git/ directory gently (i.e. without
> > changing the current working directory, or global variables), and to
> > use it to read the .git/config file early, before we actually called
> > setup_git_directory() (if we ever do that).
>
> Thanks for working on this. I think it's a huge improvement over the
> status quo, and over the earlier attempt. I don't see anything hugely
> wrong with this series, though I did note one bug, along with some minor
> refinements.
Thank you very much for your review. You did point out a couple of things
I overlooked, and while it was a pain in the back to go from v1 to v2
(i.e. avoiding code duplication, which immediately put the changed code to
a huge test by having the very central setup_git_directory() use it), I
really believe that we are better off because the patch series pays off
more technical debt now than it introduces.
> > My dirty little secret is that I actually need this for something else
> > entirely. I need to patch an internal version of Git to gather
> > statistics, and to that end I need to read the config before and after
> > running every Git command. Hence the need for a gentle, and correct
> > early config.
>
> We do something similar at GitHub, but it falls into two categories:
>
> - stat-gathering that's on all the time, so doesn't need to look at
> config (I'm not sure in your case if you want to trigger the
> gathering with config, or if config is just one of the things you
> are gathering).
>
> - logging that is turned on selectively for some repos, but which
> doesn't have to be looked up until we know we are in a repo
You probably guessed what I need to do, anyway: for our GVFS usage, we
need some telemetry (i.e. usage statistics), and I basically want to run a
hook whenever any Git command is called, but only on GVFS-enabled
repositories.
So it is somewhat related, but slightly different from your usage.
> I looked into making something upstream-able, and my approach was to
> allow GIT_TRACE_* variables to be specified in the config. But of course
> that ran into the early-config problem (and I really wanted repo-level
> config there, because I'd like to be able to turn on tracing for just a
> single problematic repo).
>
> So not really something you need to work on, but maybe food for thought
> as you work on your internal project.
Right, GIT_TRACE_* settings in the config should be doable now.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2 2/9] setup_git_directory(): use is_dir_sep() helper
From: Johannes Schindelin @ 2017-03-03 15:35 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git, Junio C Hamano, Duy Nguyen
In-Reply-To: <20170303112610.x6mdh42nd4hmxz2h@sigill.intra.peff.net>
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 12:16:31PM +0100, Johannes Schindelin wrote:
>
> > > What is "dir"? I'm guessing this patch got reordered and it should
> > > stay as cwd.buf?
> >
> > Oh drats. Usually I do a final `git rebase -x "make test"
> > upstream/master` run before submitting, but I was really, really tired
> > by the end of that stretch.
>
> I usually do the same, and have done the "too tired" thing, too, only to
> have it bite me. That's why I so readily recognized the problem. :)
:-)
> I've recently switched to using Michael's "git test" program[1], which
> caches the test results for each tree in a git-note. That makes the
> final "rebase -x" a lot less painful if you've left the early commits
> alone.
Good point. I meant to have a look, but got really overwhelmed with other
things.
> The python dependency might be a blocker for you, but I suspect the
> caching parts would be easy to hack together with shell.
No, personally I have no problem with Python. If you asked me to include
it in Git for Windows' installer, increasing the size noticably, that
would be a totally different matter, of course.
Ciao,
Dscho
^ permalink raw reply
* Finding a tag that introduced a submodule change
From: Robert Dailey @ 2017-03-03 15:40 UTC (permalink / raw)
To: Git
I have a repository with a single submodule in it. Since the parent
repository represents the code base for an actual product, I tag
release versions in the parent repository. I do not put tags in the
submodule since multiple other products may be using it there and I
wanted to avoid ambiguous tags.
Sometimes I run into a situation where I need to find out which
release of the product a submodule change was introduced in. This is
nontrivial, since there are no tags in the submodule itself. This is
one thing I tried:
1. Do a `git log` in the submodule to find the SHA1 representing the
change I want to check for
2. In the parent repository, do a git log with pickaxe to determine
when the submodule itself changed to the value of that SHA1.
3. Based on the result of #2, do a `git tag --contains` to see the
lowest-version tag that contains the SHA1, which will identify the
first release that introduced that change
However, I was not able to get past #2 because apparently there are
cases where when we move the submodule "forward", we skip over
commits, so the value of the submodule itself never was set to that
SHA1.
I'm at a loss here on how to easily do this. Can someone recommend a
way to do this? Obviously the easier the better, as I have to somehow
train my team how to do this on their own.
Thanks in advance.
^ permalink raw reply
* Re: [PATCH v2] Travis: also test on 32-bit Linux
From: Johannes Schindelin @ 2017-03-03 15:42 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, gitster, ramsay, christian.couder
In-Reply-To: <20170303110125.43332-1-larsxschneider@gmail.com>
Hi Lars,
On Fri, 3 Mar 2017, Lars Schneider wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When Git v2.9.1 was released, it had a bug that showed only on Windows
> and on 32-bit systems: our assumption that `unsigned long` can hold
> 64-bit values turned out to be wrong.
>
> This could have been caught earlier if we had a Continuous Testing
> set up that includes a build and test run on 32-bit Linux.
>
> Let's do this (and take care of the Windows build later). This patch
> asks Travis CI to install a Docker image with 32-bit libraries and then
> goes on to build and test Git using this 32-bit setup.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Thanks for keeping the ball rolling! I am totally fine with v2.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts
From: Marc Branchaud @ 2017-03-03 15:32 UTC (permalink / raw)
To: Sebastian Schuberth, git
In-Reply-To: <0102015a93d18443-c574aaf8-5656-49e8-8848-810e1fadc87a-000000@eu-west-1.amazonses.com>
On 2017-03-03 05:57 AM, Sebastian Schuberth wrote:
> It does not make sense for these placeholder scripts to depend on Python
> just because the real scripts do. At the example of Git for Windows, we
> would not even be able to see those warnings as it does not ship with
> Python. So just use plain shell scripts instead.
Just a niggle: This change moves the warning message from stderr to stdout.
M.
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
> ---
> contrib/remote-helpers/git-remote-bzr | 16 +++++++---------
> contrib/remote-helpers/git-remote-hg | 16 +++++++---------
> 2 files changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
> index 712a137..ccc4aea 100755
> --- a/contrib/remote-helpers/git-remote-bzr
> +++ b/contrib/remote-helpers/git-remote-bzr
> @@ -1,13 +1,11 @@
> -#!/usr/bin/env python
> +#!/bin/sh
>
> -import sys
> -
> -sys.stderr.write('WARNING: git-remote-bzr is now maintained independently.\n')
> -sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-bzr\n')
> -
> -sys.stderr.write('''WARNING:
> +cat <<'EOT'
> +WARNING: git-remote-bzr is now maintained independently.
> +WARNING: For more information visit https://github.com/felipec/git-remote-bzr
> +WARNING:
> WARNING: You can pick a directory on your $PATH and download it, e.g.:
> -WARNING: $ wget -O $HOME/bin/git-remote-bzr \\
> +WARNING: $ wget -O $HOME/bin/git-remote-bzr \
> WARNING: https://raw.github.com/felipec/git-remote-bzr/master/git-remote-bzr
> WARNING: $ chmod +x $HOME/bin/git-remote-bzr
> -''')
> +EOT
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index 4255ad6..dfda44f 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -1,13 +1,11 @@
> -#!/usr/bin/env python
> +#!/bin/sh
>
> -import sys
> -
> -sys.stderr.write('WARNING: git-remote-hg is now maintained independently.\n')
> -sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-hg\n')
> -
> -sys.stderr.write('''WARNING:
> +cat <<'EOT'
> +WARNING: git-remote-hg is now maintained independently.
> +WARNING: For more information visit https://github.com/felipec/git-remote-hg
> +WARNING:
> WARNING: You can pick a directory on your $PATH and download it, e.g.:
> -WARNING: $ wget -O $HOME/bin/git-remote-hg \\
> +WARNING: $ wget -O $HOME/bin/git-remote-hg \
> WARNING: https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg
> WARNING: $ chmod +x $HOME/bin/git-remote-hg
> -''')
> +EOT
>
> --
> https://github.com/git/git/pull/333
>
^ permalink raw reply
* Re: [PATCH v5 19/24] refs: new transaction related ref-store api
From: Michael Haggerty @ 2017-03-03 15:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, git
Cc: Junio C Hamano, Johannes Schindelin, Ramsay Jones, Stefan Beller,
novalis
In-Reply-To: <20170222140450.30886-20-pclouds@gmail.com>
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> The transaction struct now takes a ref store at creation and will
> operate on that ref store alone.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> refs.c | 54 ++++++++++++++++++++++++++++++++++++++++------------
> refs.h | 8 ++++++++
> refs/refs-internal.h | 1 +
> 3 files changed, 51 insertions(+), 12 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 9137ac283..851b5e125 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -618,16 +618,19 @@ static int delete_pseudoref(const char *pseudoref, const unsigned char *old_sha1
> return 0;
> }
>
> -int delete_ref(const char *refname, const unsigned char *old_sha1,
> - unsigned int flags)
> +int refs_delete_ref(struct ref_store *refs, const char *refname,
> + const unsigned char *old_sha1,
> + unsigned int flags)
> {
> struct ref_transaction *transaction;
> struct strbuf err = STRBUF_INIT;
>
> - if (ref_type(refname) == REF_TYPE_PSEUDOREF)
> + if (ref_type(refname) == REF_TYPE_PSEUDOREF) {
> + assert(refs == get_main_ref_store());
Hmmm, I would have expected this to be checked via `(refs.flags &
REF_STORE_MAIN)`. I guess this is temporary; once we have compound ref
stores either version will need to be changed again. So I don't see a
strong argument for one vs. the other.
It might be more natural to make `delete_pseudoref()` take a `refs`
argument and do the check internally.
(Same comments below where `write_pseudoref()` is called.)
Michael
> return delete_pseudoref(refname, old_sha1);
> + }
>
> - transaction = ref_transaction_begin(&err);
> + transaction = ref_store_transaction_begin(refs, &err);
> if (!transaction ||
> ref_transaction_delete(transaction, refname, old_sha1,
> flags, NULL, &err) ||
> @@ -642,6 +645,13 @@ int delete_ref(const char *refname, const unsigned char *old_sha1,
> return 0;
> }
>
> +int delete_ref(const char *refname, const unsigned char *old_sha1,
> + unsigned int flags)
> +{
> + return refs_delete_ref(get_main_ref_store(), refname,
> + old_sha1, flags);
> +}
> +
> int copy_reflog_msg(char *buf, const char *msg)
> {
> char *cp = buf;
> @@ -801,11 +811,20 @@ int read_ref_at(const char *refname, unsigned int flags, unsigned long at_time,
> return 1;
> }
>
> -struct ref_transaction *ref_transaction_begin(struct strbuf *err)
> +struct ref_transaction *ref_store_transaction_begin(struct ref_store *refs,
> + struct strbuf *err)
> {
> + struct ref_transaction *tr;
> assert(err);
>
> - return xcalloc(1, sizeof(struct ref_transaction));
> + tr = xcalloc(1, sizeof(struct ref_transaction));
> + tr->ref_store = refs;
> + return tr;
> +}
> +
> +struct ref_transaction *ref_transaction_begin(struct strbuf *err)
> +{
> + return ref_store_transaction_begin(get_main_ref_store(), err);
> }
>
> void ref_transaction_free(struct ref_transaction *transaction)
> @@ -922,18 +941,20 @@ int update_ref_oid(const char *msg, const char *refname,
> old_oid ? old_oid->hash : NULL, flags, onerr);
> }
>
> -int update_ref(const char *msg, const char *refname,
> - const unsigned char *new_sha1, const unsigned char *old_sha1,
> - unsigned int flags, enum action_on_err onerr)
> +int refs_update_ref(struct ref_store *refs, const char *msg,
> + const char *refname, const unsigned char *new_sha1,
> + const unsigned char *old_sha1, unsigned int flags,
> + enum action_on_err onerr)
> {
> struct ref_transaction *t = NULL;
> struct strbuf err = STRBUF_INIT;
> int ret = 0;
>
> if (ref_type(refname) == REF_TYPE_PSEUDOREF) {
> + assert(refs == get_main_ref_store());
> ret = write_pseudoref(refname, new_sha1, old_sha1, &err);
> } else {
> - t = ref_transaction_begin(&err);
> + t = ref_store_transaction_begin(refs, &err);
> if (!t ||
> ref_transaction_update(t, refname, new_sha1, old_sha1,
> flags, msg, &err) ||
> @@ -964,6 +985,15 @@ int update_ref(const char *msg, const char *refname,
> return 0;
> }
>
> +int update_ref(const char *msg, const char *refname,
> + const unsigned char *new_sha1,
> + const unsigned char *old_sha1,
> + unsigned int flags, enum action_on_err onerr)
> +{
> + return refs_update_ref(get_main_ref_store(), msg, refname, new_sha1,
> + old_sha1, flags, onerr);
> +}
> +
> char *shorten_unambiguous_ref(const char *refname, int strict)
> {
> int i;
> @@ -1600,7 +1630,7 @@ int create_symref(const char *ref_target, const char *refs_heads_master,
> int ref_transaction_commit(struct ref_transaction *transaction,
> struct strbuf *err)
> {
> - struct ref_store *refs = get_main_ref_store();
> + struct ref_store *refs = transaction->ref_store;
>
> return refs->be->transaction_commit(refs, transaction, err);
> }
> @@ -1719,7 +1749,7 @@ int reflog_expire(const char *refname, const unsigned char *sha1,
> int initial_ref_transaction_commit(struct ref_transaction *transaction,
> struct strbuf *err)
> {
> - struct ref_store *refs = get_main_ref_store();
> + struct ref_store *refs = transaction->ref_store;
>
> return refs->be->initial_transaction_commit(refs, transaction, err);
> }
> diff --git a/refs.h b/refs.h
> index 70d4eb87c..342cecd23 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -330,6 +330,9 @@ int reflog_exists(const char *refname);
> * exists, regardless of its old value. It is an error for old_sha1 to
> * be NULL_SHA1. flags is passed through to ref_transaction_delete().
> */
> +int refs_delete_ref(struct ref_store *refs, const char *refname,
> + const unsigned char *old_sha1,
> + unsigned int flags);
> int delete_ref(const char *refname, const unsigned char *old_sha1,
> unsigned int flags);
>
> @@ -414,6 +417,8 @@ enum action_on_err {
> * Begin a reference transaction. The reference transaction must
> * be freed by calling ref_transaction_free().
> */
> +struct ref_transaction *ref_store_transaction_begin(struct ref_store *refs,
> + struct strbuf *err);
> struct ref_transaction *ref_transaction_begin(struct strbuf *err);
>
> /*
> @@ -548,6 +553,9 @@ void ref_transaction_free(struct ref_transaction *transaction);
> * ref_transaction_update(). Handle errors as requested by the `onerr`
> * argument.
> */
> +int refs_update_ref(struct ref_store *refs, const char *msg, const char *refname,
> + const unsigned char *new_sha1, const unsigned char *old_sha1,
> + unsigned int flags, enum action_on_err onerr);
> int update_ref(const char *msg, const char *refname,
> const unsigned char *new_sha1, const unsigned char *old_sha1,
> unsigned int flags, enum action_on_err onerr);
> diff --git a/refs/refs-internal.h b/refs/refs-internal.h
> index 5f26208c2..690498698 100644
> --- a/refs/refs-internal.h
> +++ b/refs/refs-internal.h
> @@ -200,6 +200,7 @@ enum ref_transaction_state {
> * as atomically as possible. This structure is opaque to callers.
> */
> struct ref_transaction {
> + struct ref_store *ref_store;
> struct ref_update **updates;
> size_t alloc;
> size_t nr;
>
^ permalink raw reply
* Re: [PATCH 3/3] Remove outdated info in difftool manpage
From: Johannes Schindelin @ 2017-03-03 15:46 UTC (permalink / raw)
To: Denton Liu; +Cc: git, davvid
In-Reply-To: <20170303115751.GA13225@arch-attack.localdomain>
Hi Denton (or should I address you as Liu?),
On Fri, 3 Mar 2017, Denton Liu wrote:
> When difftool was rewritten in C, it removed the capability to read
> fallback configs from mergetool. This changes the documentation to
> reflect this.
Thanks for pointing that out. But that is probably an oversight on my
part, not an intentional change...
Ciao,
Johannes
^ permalink raw reply
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