* Re: [PATCH] allow git-p4 to create shelved changelists
From: Luke Diamand @ 2016-11-29 12:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vinicius Kursancew, Lars Schneider, Git Users
In-Reply-To: <xmqqeg1vjug2.fsf@gitster.mtv.corp.google.com>
On 28 November 2016 at 19:06, Junio C Hamano <gitster@pobox.com> wrote:
> Vinicius Kursancew <viniciusalexandre@gmail.com> writes:
>
>> This patch adds a "--shelve" option to the submit subcommand, it will
>> save the changes to a perforce shelve instead of commiting them.
Looks good to me, thanks!
Works a treat.
Ack.
>>
>> Vinicius Kursancew (1):
>> git-p4: allow submit to create shelved changelists.
>>
>> Documentation/git-p4.txt | 5 +++++
>> git-p4.py | 36 ++++++++++++++++++++++--------------
>> t/t9807-git-p4-submit.sh | 31 +++++++++++++++++++++++++++++++
>> 3 files changed, 58 insertions(+), 14 deletions(-)
>
> Thanks, but I am a wrong person to review this change, so I'll
> summon two people who appear in "git shortlog --since=18.months"
> output to help review it.
>
>
^ permalink raw reply
* Re: [PATCH v2 00/11] git worktree (re)move
From: Duy Nguyen @ 2016-11-29 12:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <73836804-a581-85a4-b0c0-2aa46a7f9b8d@kdbg.org>
On Tue, Nov 29, 2016 at 4:25 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 28.11.2016 um 21:20 schrieb Junio C Hamano:
>>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Does this round address the issue raised in
>>>
>>>
>>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>>
>>> by Dscho?
>>>
>>> Even if you are not tracking a fifo, for example, your working tree
>>> may have one created in t/trash* directory during testing, and
>>> letting platform "cp -r" taking care of it (if that is possible---I
>>> didn't look at the code that calls busybox copy to see if you are
>>> doing something exotic or just blindly copying everything in the
>>> directory) may turn out to be a more portable way to do this, and I
>>> suspect that the cost of copying one whole-tree would dominate the
>>> run_command() overhead.
>>
>>
>> Please do not take the above as me saying "you must spawn the
>> platform cp -r".
>
>
> copy_dir_recursively is used in 'worktree move' when the move is across file
> systems. My stance on it is to punt in this case. *I* would not trust Git,
> or any other program that is not *specifically* made to copy a whole
> directory structure, to get all cases right when a simple rename() is not
> sufficent.
This is why I did not write new copy code. The code was from busybox,
probably battle tested for many years now. Of course bugs can slip in
when I integrated it to git.
> And, uh, oh, it does a remove_dir_recursively() after it has
> finshed copying. No, Git is not a tool to move directories, thank you very
> much!
I guess you won't like my (unsent) patch for moving .git dir either
;-) which does make me nervous. The thing is, these operations require
some more modification in .git. We can't ask the user to "move this
directory yourself, then come back to me and I will fix up the rest in
.git". First step "only support moving within the same filesystem"
works for me. But I don't know how rename() works on Windows...
--
Duy
^ permalink raw reply
* Re: [PATCH v2 00/11] git worktree (re)move
From: Duy Nguyen @ 2016-11-29 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <xmqqshqbicga.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Does this round address the issue raised in
>>
>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>
>> by Dscho?
It does not (and is sort of expected), quoting from the commit message
copy.c: convert copy_file() to copy_dir_recursively()
This finally enables busybox's copy_file() code under a new name
(because "copy_file" is already taken in Git code base). Because this
comes from busybox, POSIXy (or even Linuxy) behavior is expected. More
changes may be needed for Windows support.
I could "#ifdef WINDOWS return -ENOSYS" for now, which would make it
build. "git worktree move" won't work on Windows of course...
>> Even if you are not tracking a fifo, for example, your working tree
>> may have one created in t/trash* directory during testing, and
>> letting platform "cp -r" taking care of it (if that is possible---I
>> didn't look at the code that calls busybox copy to see if you are
>> doing something exotic or just blindly copying everything in the
>> directory) may turn out to be a more portable way to do this, and I
>> suspect that the cost of copying one whole-tree would dominate the
>> run_command() overhead.
>
> Please do not take the above as me saying "you must spawn the
> platform cp -r".
For the the record this was my first move but it will make it much
harder to handle errors, and there's no native "cp" on Windows.
--
Duy
^ permalink raw reply
* git-gui paste not working
From: Peter Flood @ 2016-11-29 10:13 UTC (permalink / raw)
To: git
I've just upgraded to macOS 10.12.1 and now I can't paste into git-gui
(the commit message box).
It seems to work if the text is copied from within git-gui but not from
outside. I've tried using the latest dmg from
https://git-scm.com/download/mac (2.10.1) but it doesn't fix the problem.
^ permalink raw reply
* [PATCH] RelNotes: typo fix in 2.11.0 notes
From: Tobias Klauser @ 2016-11-29 9:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqinrdlr3o.fsf@gitster.mtv.corp.google.com>
s/paht/path/ in the "Backwards compatibility notes" section of the
2.11.0 release notes.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
Documentation/RelNotes/2.11.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.11.0.txt b/Documentation/RelNotes/2.11.0.txt
index b7b7dd361ef0..4c8a9be60f52 100644
--- a/Documentation/RelNotes/2.11.0.txt
+++ b/Documentation/RelNotes/2.11.0.txt
@@ -5,7 +5,7 @@ Backward compatibility notes.
* An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
- finds a path to remove in $path and run 'git rm "$paht"' by
+ finds a path to remove in $path and run 'git rm "$path"' by
mistake (when the user meant to give "$path"), which ends up
removing everything. This release starts warning about the
use of an empty string that is used for 'everything matches' and
--
2.11.0.rc3.5.g7cdf2ab.dirty
^ permalink raw reply related
* gitk crashes on RHEL
From: Alessandro Renieri @ 2016-11-29 9:51 UTC (permalink / raw)
To: git
On Redhat Enterprise gitk returns the following error when launched:
Error in startup script: unknown color name "lime"
(processing "-fill" option)
invoked from within
"$progresscanv create rect -1 0 0 $h -fill lime"
(procedure "makewindow" line 201)
invoked from within
"makewindow"
(file "/..../bin/git-exe/bin/gitk" line 12434)
The fix is to change lime with {lime green}
Regards
^ permalink raw reply
* [PATCH 1/2] mergetool: honor mergetool.$tool.trustExitCode for built-in tools
From: David Aguilar @ 2016-11-29 9:38 UTC (permalink / raw)
To: Git ML; +Cc: Junio C Hamano, Dun Peal
Built-in merge tools contain a hard-coded assumption about
whether or not a tool's exit code can be trusted to determine
the success or failure of a merge. Tools whose exit codes are
not trusted contain calls to check_unchanged() in their
merge_cmd() functions.
A problem with this is that the trustExitCode configuration is
not honored for built-in tools.
Teach built-in tools to honor the trustExitCode configuration.
Extend run_merge_cmd() so that it is responsible for calling
check_unchanged() when a tool's exit code cannot be trusted.
Remove check_unchanged() calls from scriptlets since they are no
longer responsible for calling it.
When no configuration is present, exit_code_trustable() is
checked to see whether the exit code should be trusted.
The default implementation returns false.
Tools whose exit codes can be trusted override
exit_code_trustable() to true.
Reported-by: Dun Peal <dunpealer@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-mergetool--lib.sh | 56 ++++++++++++++++++++++++++++++++++++++----------
mergetools/araxis | 2 --
mergetools/bc | 2 --
mergetools/codecompare | 2 --
mergetools/deltawalker | 6 +++++-
mergetools/diffmerge | 4 ++++
mergetools/diffuse | 2 --
mergetools/ecmerge | 2 --
mergetools/emerge | 4 ++++
mergetools/examdiff | 2 --
mergetools/kdiff3 | 4 ++++
mergetools/kompare | 4 ++++
mergetools/meld | 3 +--
mergetools/opendiff | 2 --
mergetools/p4merge | 2 --
mergetools/tkdiff | 4 ++++
mergetools/tortoisemerge | 2 --
mergetools/vimdiff | 2 --
mergetools/winmerge | 2 --
mergetools/xxdiff | 2 --
20 files changed, 71 insertions(+), 38 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 9abd00be2..9a8b97a2a 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -125,16 +125,7 @@ setup_user_tool () {
}
merge_cmd () {
- trust_exit_code=$(git config --bool \
- "mergetool.$1.trustExitCode" || echo false)
- if test "$trust_exit_code" = "false"
- then
- touch "$BACKUP"
- ( eval $merge_tool_cmd )
- check_unchanged
- else
- ( eval $merge_tool_cmd )
- fi
+ ( eval $merge_tool_cmd )
}
}
@@ -162,6 +153,28 @@ setup_tool () {
echo "$1"
}
+ # Most tools' exit codes cannot be trusted, so By default we ignore
+ # their exit code and check the merged file's modification time in
+ # check_unchanged() to determine whether or not the merge was
+ # successful. The return value from run_merge_cmd, by default, is
+ # determined by check_unchanged().
+ #
+ # When a tool's exit code can be trusted then the return value from
+ # run_merge_cmd is simply the tool's exit code, and check_unchanged()
+ # is not called.
+ #
+ # The return value of exit_code_trustable() tells us whether or not we
+ # can trust the tool's exit code.
+ #
+ # User-defined and built-in tools default to false.
+ # Built-in tools advertise that their exit code is trustable by
+ # redefining exit_code_trustable() to true.
+
+ exit_code_trustable () {
+ false
+ }
+
+
if ! test -f "$MERGE_TOOLS_DIR/$tool"
then
setup_user_tool
@@ -197,6 +210,19 @@ get_merge_tool_cmd () {
fi
}
+trust_exit_code () {
+ if git config --bool "mergetool.$1.trustExitCode"
+ then
+ :; # OK
+ elif exit_code_trustable
+ then
+ echo true
+ else
+ echo false
+ fi
+}
+
+
# Entry point for running tools
run_merge_tool () {
# If GIT_PREFIX is empty then we cannot use it in tools
@@ -225,7 +251,15 @@ run_diff_cmd () {
# Run a either a configured or built-in merge tool
run_merge_cmd () {
- merge_cmd "$1"
+ mergetool_trust_exit_code=$(trust_exit_code "$1")
+ if test "$mergetool_trust_exit_code" = "true"
+ then
+ merge_cmd "$1"
+ else
+ touch "$BACKUP"
+ merge_cmd "$1"
+ check_unchanged
+ fi
}
list_merge_tool_candidates () {
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5e9..e2407b65b 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -3,7 +3,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" -wait -merge -3 -a1 \
@@ -12,7 +11,6 @@ merge_cmd () {
"$merge_tool_path" -wait -2 \
"$LOCAL" "$REMOTE" "$MERGED" >/dev/null 2>&1
fi
- check_unchanged
}
translate_merge_tool_path() {
diff --git a/mergetools/bc b/mergetools/bc
index b6319d206..3a69e60fa 100644
--- a/mergetools/bc
+++ b/mergetools/bc
@@ -3,7 +3,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" "$LOCAL" "$REMOTE" "$BASE" \
@@ -12,7 +11,6 @@ merge_cmd () {
"$merge_tool_path" "$LOCAL" "$REMOTE" \
-mergeoutput="$MERGED"
fi
- check_unchanged
}
translate_merge_tool_path() {
diff --git a/mergetools/codecompare b/mergetools/codecompare
index 3f0486bc8..9f60e8da6 100644
--- a/mergetools/codecompare
+++ b/mergetools/codecompare
@@ -3,7 +3,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" -MF="$LOCAL" -TF="$REMOTE" -BF="$BASE" \
@@ -12,7 +11,6 @@ merge_cmd () {
"$merge_tool_path" -MF="$LOCAL" -TF="$REMOTE" \
-RF="$MERGED"
fi
- check_unchanged
}
translate_merge_tool_path() {
diff --git a/mergetools/deltawalker b/mergetools/deltawalker
index b3c71b623..ee6f374bc 100644
--- a/mergetools/deltawalker
+++ b/mergetools/deltawalker
@@ -16,6 +16,10 @@ merge_cmd () {
fi >/dev/null 2>&1
}
-translate_merge_tool_path() {
+translate_merge_tool_path () {
echo DeltaWalker
}
+
+exit_code_trustable () {
+ true
+}
diff --git a/mergetools/diffmerge b/mergetools/diffmerge
index f138cb4e7..9b6355b98 100644
--- a/mergetools/diffmerge
+++ b/mergetools/diffmerge
@@ -12,3 +12,7 @@ merge_cmd () {
--result="$MERGED" "$LOCAL" "$REMOTE"
fi
}
+
+exit_code_trustable () {
+ true
+}
diff --git a/mergetools/diffuse b/mergetools/diffuse
index 02e0843f4..5a3ae8b56 100644
--- a/mergetools/diffuse
+++ b/mergetools/diffuse
@@ -3,7 +3,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" \
@@ -13,5 +12,4 @@ merge_cmd () {
"$merge_tool_path" \
"$LOCAL" "$MERGED" "$REMOTE" | cat
fi
- check_unchanged
}
diff --git a/mergetools/ecmerge b/mergetools/ecmerge
index 13c2e439d..6c5101c4f 100644
--- a/mergetools/ecmerge
+++ b/mergetools/ecmerge
@@ -3,7 +3,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" \
@@ -12,5 +11,4 @@ merge_cmd () {
"$merge_tool_path" "$LOCAL" "$REMOTE" \
--default --mode=merge2 --to="$MERGED"
fi
- check_unchanged
}
diff --git a/mergetools/emerge b/mergetools/emerge
index 7b895fdb1..d1ce513ff 100644
--- a/mergetools/emerge
+++ b/mergetools/emerge
@@ -20,3 +20,7 @@ merge_cmd () {
translate_merge_tool_path() {
echo emacs
}
+
+exit_code_trustable () {
+ true
+}
diff --git a/mergetools/examdiff b/mergetools/examdiff
index 7b524d408..e72b06fc4 100644
--- a/mergetools/examdiff
+++ b/mergetools/examdiff
@@ -3,14 +3,12 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" -merge "$LOCAL" "$BASE" "$REMOTE" -o:"$MERGED" -nh
else
"$merge_tool_path" -merge "$LOCAL" "$REMOTE" -o:"$MERGED" -nh
fi
- check_unchanged
}
translate_merge_tool_path() {
diff --git a/mergetools/kdiff3 b/mergetools/kdiff3
index 793d1293b..0264ed5b2 100644
--- a/mergetools/kdiff3
+++ b/mergetools/kdiff3
@@ -21,3 +21,7 @@ merge_cmd () {
>/dev/null 2>&1
fi
}
+
+exit_code_trustable () {
+ true
+}
diff --git a/mergetools/kompare b/mergetools/kompare
index 433686c12..e8c0bfa67 100644
--- a/mergetools/kompare
+++ b/mergetools/kompare
@@ -5,3 +5,7 @@ can_merge () {
diff_cmd () {
"$merge_tool_path" "$LOCAL" "$REMOTE"
}
+
+exit_code_trustable () {
+ true
+}
diff --git a/mergetools/meld b/mergetools/meld
index 83ebdfb4c..bc178e888 100644
--- a/mergetools/meld
+++ b/mergetools/meld
@@ -7,7 +7,7 @@ merge_cmd () {
then
check_meld_for_output_version
fi
- touch "$BACKUP"
+
if test "$meld_has_output_option" = true
then
"$merge_tool_path" --output "$MERGED" \
@@ -15,7 +15,6 @@ merge_cmd () {
else
"$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
fi
- check_unchanged
}
# Check whether we should use 'meld --output <file>'
diff --git a/mergetools/opendiff b/mergetools/opendiff
index 0942b2a73..b608dd6de 100644
--- a/mergetools/opendiff
+++ b/mergetools/opendiff
@@ -3,7 +3,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" "$LOCAL" "$REMOTE" \
@@ -12,5 +11,4 @@ merge_cmd () {
"$merge_tool_path" "$LOCAL" "$REMOTE" \
-merge "$MERGED" | cat
fi
- check_unchanged
}
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 5a608abf9..7a5b291dd 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -20,14 +20,12 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if ! $base_present
then
cp -- "$LOCAL" "$BASE"
create_virtual_base "$BASE" "$REMOTE"
fi
"$merge_tool_path" "$BASE" "$REMOTE" "$LOCAL" "$MERGED"
- check_unchanged
}
create_empty_file () {
diff --git a/mergetools/tkdiff b/mergetools/tkdiff
index 618c438e8..eee5cb57e 100644
--- a/mergetools/tkdiff
+++ b/mergetools/tkdiff
@@ -10,3 +10,7 @@ merge_cmd () {
"$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
fi
}
+
+exit_code_trustable () {
+ true
+}
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 3b89f1c82..d7ab666a5 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -5,7 +5,6 @@ can_diff () {
merge_cmd () {
if $base_present
then
- touch "$BACKUP"
basename="$(basename "$merge_tool_path" .exe)"
if test "$basename" = "tortoisegitmerge"
then
@@ -17,7 +16,6 @@ merge_cmd () {
-base:"$BASE" -mine:"$LOCAL" \
-theirs:"$REMOTE" -merged:"$MERGED"
fi
- check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
return 1
diff --git a/mergetools/vimdiff b/mergetools/vimdiff
index 74ea6d547..a841ffdb4 100644
--- a/mergetools/vimdiff
+++ b/mergetools/vimdiff
@@ -4,7 +4,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
case "$1" in
gvimdiff|vimdiff)
if $base_present
@@ -31,7 +30,6 @@ merge_cmd () {
fi
;;
esac
- check_unchanged
}
translate_merge_tool_path() {
diff --git a/mergetools/winmerge b/mergetools/winmerge
index f3819d316..74d03259f 100644
--- a/mergetools/winmerge
+++ b/mergetools/winmerge
@@ -6,10 +6,8 @@ diff_cmd () {
merge_cmd () {
# mergetool.winmerge.trustExitCode is implicitly false.
# touch $BACKUP so that we can check_unchanged.
- touch "$BACKUP"
"$merge_tool_path" -u -e -dl Local -dr Remote \
"$LOCAL" "$REMOTE" "$MERGED"
- check_unchanged
}
translate_merge_tool_path() {
diff --git a/mergetools/xxdiff b/mergetools/xxdiff
index 05b443394..e284811ff 100644
--- a/mergetools/xxdiff
+++ b/mergetools/xxdiff
@@ -6,7 +6,6 @@ diff_cmd () {
}
merge_cmd () {
- touch "$BACKUP"
if $base_present
then
"$merge_tool_path" -X --show-merged-pane \
@@ -21,5 +20,4 @@ merge_cmd () {
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$MERGED" "$LOCAL" "$REMOTE"
fi
- check_unchanged
}
--
2.11.0.rc3.6.g2e567fd
^ permalink raw reply related
* [PATCH 2/2] mergetools/vimdiff: trust Vim's exit code
From: David Aguilar @ 2016-11-29 9:38 UTC (permalink / raw)
To: Git ML
Cc: Junio C Hamano, Dun Peal, Charles Bailey, Dickson Wong,
Michael J Gruber, Dan McGee, Markus Heidelberg, SZEDER Gábor,
James Bowes
Allow vimdiff users to signal that they do not want to use the
result of a merge by exiting with ":cquit", which tells Vim to
exit with an error code.
This is better than the current behavior because it allows users
to directly flag that the merge is bad, using a standard Vim
feature, rather than relying on a timestamp heuristic that is
unforgiving to users that save in-progress merge files.
The original behavior can be restored by configuring
mergetool.vimdiff.trustExitCode to false.
Reported-by: Dun Peal <dunpealer@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
I've included anyone that has ever touched the vimdiff feature on the Cc:
list since I'm assuming that you use vimdiff.
This change is a slight change in default behavior when using
mergetool with vimdiff, but I think it's a better default overall.
mergetools/vimdiff | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mergetools/vimdiff b/mergetools/vimdiff
index a841ffdb4..10d86f3e1 100644
--- a/mergetools/vimdiff
+++ b/mergetools/vimdiff
@@ -42,3 +42,7 @@ translate_merge_tool_path() {
;;
esac
}
+
+exit_code_trustable () {
+ true
+}
--
2.11.0.rc3.6.g2e567fd
^ permalink raw reply related
* Re: [PATCH] diff: handle --no-abbrev outside of repository
From: Jeff King @ 2016-11-29 7:06 UTC (permalink / raw)
To: Jack Bates; +Cc: git, Jack Bates
In-Reply-To: <20161128182508.10570-1-jack@nottheoilrig.com>
On Mon, Nov 28, 2016 at 11:25:08AM -0700, Jack Bates wrote:
> diff --git a/diff.c b/diff.c
> index ec87283..0447eff 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
> abbrev = FALLBACK_DEFAULT_ABBREV;
> if (abbrev > GIT_SHA1_HEXSZ)
> die("BUG: oid abbreviation out of range: %d", abbrev);
> - hex[abbrev] = '\0';
> + if (abbrev)
> + hex[abbrev] = '\0';
> return hex;
> }
This hunk made me wonder if there is a regression in v2.11, as this
fallback code is new in that version. But I don't think so.
This new code doesn't handle abbrev==0 the same as find_unique_abbrev()
does, and that's clearly a bug. But I couldn't find any way to trigger
it with the existing code.
The obvious way is with --no-abbrev, but that doesn't work without yet
without your patch.
A less obvious way is --abbrev=0, but that gets munged internally to
MINIMUM_ABBREV.
The most obscure is "git -c core.abbrev=0", but that barfs completely on
a too-small abbreviation (without even giving a good error message,
which is something we might want to fix).
So I think there is no regression, and we only have to worry about it as
part of the feature you are adding here (it might be worth calling out
the bug fix specifically in the commit message, though, or even putting
it in its own patch).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Jeff King @ 2016-11-29 6:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqk2bngn03.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 28, 2016 at 04:15:08PM -0800, Junio C Hamano wrote:
> * jk/nofollow-attr-ignore (2016-11-02) 5 commits
> - exclude: do not respect symlinks for in-tree .gitignore
> - attr: do not respect symlinks for in-tree .gitattributes
> - exclude: convert "check_index" into a flags field
> - attr: convert "macro_ok" into a flags field
> - add open_nofollow() helper
>
> As we do not follow symbolic links when reading control files like
> .gitignore and .gitattributes from the index, match the behaviour
> and not follow symbolic links when reading them from the working
> tree. This also tightens security a bit by not leaking contents of
> an unrelated file in the error messages when it is pointed at by
> one of these files that is a symbolic link.
>
> Perhaps we want to cover .gitmodules too with the same mechanism?
Yes, sorry I haven't pushed that forward. I started on covering
.gitmodules, too, but it's much more complicated than the other two,
because we sometimes read them via "git config -f". So we have to
somehow teach git-config to start using O_NOFOLLOW in those cases.
I'm actually considering scrapping the approach you've queued above, and
just teaching verify_path() to reject any index entry starting with
".git" that is a symlink.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Jeff King @ 2016-11-29 6:51 UTC (permalink / raw)
To: Brandon Williams; +Cc: Junio C Hamano, git
In-Reply-To: <20161129063759.6mgmpqx3kbyuqjwi@sigill.intra.peff.net>
On Tue, Nov 29, 2016 at 01:37:59AM -0500, Jeff King wrote:
> 2. Grep threads doing more complicated stuff that needs to take a
> lock. You might try building with -fsanitize=thread to see if it
> turns up anything.
I tried this and it didn't find anything useful. It complains about
multiple threads calling want_color() at the same time, which you can
silence with something like:
diff --git a/builtin/grep.c b/builtin/grep.c
index 2c727ef49..d48846f40 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -207,6 +207,12 @@ static void start_threads(struct grep_opt *opt)
{
int i;
+ /*
+ * trigger want_color() for its side effect of caching the result;
+ * otherwise the threads will fight over setting the cache
+ */
+ want_color(GIT_COLOR_AUTO);
+
pthread_mutex_init(&grep_mutex, NULL);
pthread_mutex_init(&grep_read_mutex, NULL);
pthread_mutex_init(&grep_attr_mutex, NULL);
But the problem persists even with that patch, so it is something else.
It may still be a threading problem; -fsanitize=thread isn't perfect. I
also couldn't get the stress-test to fail when compiled with it. But
that may simply mean that the timing of the resulting binary is changed
enough not to trigger the issue.
-Peff
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Jeff King @ 2016-11-29 6:37 UTC (permalink / raw)
To: Brandon Williams; +Cc: Junio C Hamano, git
In-Reply-To: <20161129010538.GA121643@google.com>
On Mon, Nov 28, 2016 at 05:05:38PM -0800, Brandon Williams wrote:
> On 11/28, Junio C Hamano wrote:
> > * bw/grep-recurse-submodules (2016-11-22) 6 commits
> > - grep: search history of moved submodules
> > - grep: enable recurse-submodules to work on <tree> objects
> > - grep: optionally recurse into submodules
> > - grep: add submodules as a grep source type
> > - submodules: load gitmodules file from commit sha1
> > - submodules: add helper functions to determine presence of submodules
> >
> > "git grep" learns to optionally recurse into submodules
> >
> > Has anybody else seen t7814 being flakey with this series?
>
> Which tests in particular are you seeing issues with? I can't see any
> issues running it locally.
It looks like tests 14 and 15 are racy. The whole script usually passes,
but if I run it under my stress script[1], it fails within 5-10 seconds
on one of those two.
The failures always look like (this one is from test 15, but the one in
test 14 is similar):
--- expect 2016-11-29 06:26:37.874664486 +0000
+++ actual 2016-11-29 06:26:37.878664486 +0000
@@ -1,2 +1 @@
-file:foobar
sub-moved/file:foobar
I haven't dug into it, but I don't see anything obviously racy-looking
in the test, so presumably it's in the code. Without looking, but
knowing the nature of the code, I'd guess the probable avenues are:
1. A read() or write() that gets split under load (just because
there's processes piping to other processes here).
2. Grep threads doing more complicated stuff that needs to take a
lock. You might try building with -fsanitize=thread to see if it
turns up anything.
-Peff
[1] https://github.com/peff/git/blob/meta/stress
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
From: Jonathan Tan @ 2016-11-29 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stefan Beller
In-Reply-To: <xmqqpolfgndq.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 28, 2016 at 4:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> On 11/23/2016 03:21 PM, Junio C Hamano wrote:
>>> * jt/use-trailer-api-in-commands (2016-11-02) 6 commits
>>> - sequencer: use trailer's trailer layout
>>> - trailer: have function to describe trailer layout
>>> - trailer: avoid unnecessary splitting on lines
>>> - commit: make ignore_non_trailer take buf/len
>>> - SQUASH???
>>> - trailer: be stricter in parsing separators
>>>
>>> Commands that operate on a log message and add lines to the trailer
>>> blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
>>> "commit -s", have been taught to use the logic of and share the
>>> code with "git interpret-trailer".
>>>
>>> What's the doneness of this topic?
>>
>> Stefan Beller mentioned [1] that this seemed OK to him from a cursory
>> read. Do I need to look for another reviewer (or a more thorough
>> review)?
>
> I gave it a cursory review when it was queued, too, so another
> cursory read does not help very much ;) If I recall correctly, I
> got an impression that it was reasonably well done.
>
> I haven't had a chance to look at the series again to see if the
> SQUASH is just the simple matter of squashing it into the one
> previous, which is the main reason why I haven't decided if it is
> ready to be in 'next'.
>
> Thanks.
Sorry, I'm not sure what you mean by this. The SQUASH is an update in
documentation (for a C function) (reproduced below [1]) which can be
squashed cleanly (just to confirm, I tried it using "git rebase -i").
It can also be rebased cleanly onto master or next (at least, as of
now).
If you are asking about whether I think the contents of your SQUASH
commit is reasonable, I think that it is.
[1]
$ git show 7e7587d
commit 7e7587d563ddb540875075e5a84359a8a96a5188
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Nov 2 19:28:53 2016 -0700
SQUASH???
diff --git a/trailer.c b/trailer.c
index dc525e3..eefe91d 100644
--- a/trailer.c
+++ b/trailer.c
@@ -565,7 +565,9 @@ static int token_matches_item(const char *tok,
struct arg_item *item, int tok_le
/*
* If the given line is of the form
* "<token><optional whitespace><separator>..." or "<separator>...", return the
- * location of the separator. Otherwise, return -1.
+ * location of the separator. Otherwise, return -1. The optional whitespace
+ * is allowed there primarily to allow things like "Bug #43" where <token> is
+ * "Bug" and <separator> is "#".
*
* The separator-starts-line case (in which this function returns 0) is
* distinguished from the non-well-formed-line case (in which this function
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Brandon Williams @ 2016-11-29 1:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqk2bngn03.fsf@gitster.mtv.corp.google.com>
On 11/28, Junio C Hamano wrote:
> * bw/grep-recurse-submodules (2016-11-22) 6 commits
> - grep: search history of moved submodules
> - grep: enable recurse-submodules to work on <tree> objects
> - grep: optionally recurse into submodules
> - grep: add submodules as a grep source type
> - submodules: load gitmodules file from commit sha1
> - submodules: add helper functions to determine presence of submodules
>
> "git grep" learns to optionally recurse into submodules
>
> Has anybody else seen t7814 being flakey with this series?
Which tests in particular are you seeing issues with? I can't see any
issues running it locally.
--
Brandon Williams
^ permalink raw reply
* [ANNOUNCE] git-cinnabar 0.4.0 release candidate
From: Mike Hommey @ 2016-11-29 0:22 UTC (permalink / raw)
To: git
Hi,
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0rc
[ Previous announcements:
http://marc.info/?l=git&m=146943537220142
http://marc.info/?l=git&m=146762932928309
http://marc.info/?l=git&m=146179749105388 (...)]
What's new since 0.4.0b3?
- Updated git to 2.10.2 for cinnabar-helper.
- Added a new `git cinnabar download` command to download a helper on
platforms where one is available.
- Fixed some corner cases with pack windows in the helper. This prevented
cloning mozilla-central with the helper.
- Fixed bundle2 support that broke cloning from a mercurial 4.0 server in
some cases.
- Fixed some corner cases involving empty files. This prevented cloning
Mozilla's stylo incubator repository.
- Fixed some correctness issues in file parenting when pushing changesets
pulled from one mercurial repository to another.
- Various improvements to the rules to build the helper.
- Experimental (and slow) support for pushing merges, with caveats. See
https://github.com/glandium/git-cinnabar/issues/20 for details about
the current status.
And since I realize I didn't announce beta 3:
What's new since 0.4.0b2?
- Properly handle bundle2 errors, avoiding git to believe a push
happened when it didn't. (0.3.x is unaffected)
Mike
^ permalink raw reply
* Re: cherry-pick -Xrenormalize fails with formerly CRLF files
From: Eevee (Lexy Munroe) @ 2016-11-29 0:27 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <20161128155415.GA9966@tb-raspi>
On 11/28/2016 07:54 AM, Torsten Bögershausen wrote:
> On Sun, Nov 27, 2016 at 10:19:35PM -0800, Eevee (Lexy Munroe) wrote:
>> I'm working with a repo that used to be all CRLF. At some point it
>> was changed to all LF, with `text=auto` in .gitattributes for the
>> sake of Windows devs. I'm on Linux and have never touched any
>> twiddles relating to line endings. I'm trying to cherry-pick some
>> commits from before the switchover.
>>
>> Straightforward cherry-picking causes entire files at a time to
>> conflict, which I've seen before when switching from tabs to spaces.
>> So I tried -Xrenormalize and got:
>>
>> fatal: CRLF would be replaced by LF in [path]
>>
>
> Which version of Git are you using, what does
> git --version
> say?
Oh, sorry. 2.10.2, but I also tried building next (c8190e7) with the
same result.
>> The error comes from check_safe_crlf, which warns if checksafe is
>> CRLF_SAFE_WARN and dies if it's (presumably) CRLF_SAFE_FAIL. The
>> funny thing is that it's CRLF_SAFE_RENORMALIZE.
>>
>> I don't know what the semantics of this value are, but the caller
>> (crlf_to_git) explicitly checks for CRLF_SAFE_RENORMALIZE and
>> changes it to CRLF_SAFE_FALSE instead. But that check only happens
>> if crlf_action is CRLF_AUTO*, and for me it's CRLF_TEXT_INPUT.
>>
>> I moved the check to happen regardless of the value of crlf_action,
>> and at least in this case, git appears to happily do the right
>> thing. So I think this is a bug, but line endings are such a tangle
>> that I'm really not sure. :)
>>
> I am not sure either.
> Could you send me the diff you made ?
> git diff
>
> I am happy to look into it, (in the amount of time I have).
It's pretty straightforward:
diff --git a/convert.c b/convert.c
index be91358..f9ff6a5 100644
--- a/convert.c
+++ b/convert.c
@@ -275,6 +275,8 @@ static int crlf_to_git(const char *path, const char
*src, size_t len,
/* Optimization: No CRLF? Nothing to convert, regardless. */
convert_crlf_into_lf = !!stats.crlf;
+ if (checksafe == SAFE_CRLF_RENORMALIZE)
+ checksafe = SAFE_CRLF_FALSE;
if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_INPUT
|| crlf_action == CRLF_AUTO_CRLF) {
if (convert_is_binary(len, &stats))
return 0;
(The new lines are copied from the block immediately following, just
past where the context ends.)
>> The repository in question is ZDoom: https://github.com/rheit/zdoom
>> I'm trying to cherry-pick commits from the 3dfloors3 branch (e.g.,
>> 9fb2daf58e9d512170859302a1ac0ea9c2ec5993) onto a slightly outdated
>> master, 6384e81d0f135a2c292ac3e874f6fe26093f45b1.
>
> This is what I tried:
>
> ...
>
> The patch did not apply, but for different reasons.
>
> Could you send us, what exactly you did, to help me out ?
I did notice it works when there's a conflict, but I thought I
specifically named a commit that applied cleanly. Apparently not,
sorry. Try ddba3dd325054e71d48634cb19708cb7bcd8f20b:
eevee@perushian ~/dev-foreign/zdoom.git/src ⚘ git checkout -b
git-renormalize-test 6384e81d0f135a2c292ac3e874f6fe26093f45b1
Switched to a new branch 'git-renormalize-test'
eevee@perushian ~/dev-foreign/zdoom.git/src ⚘ git cherry-pick
-Xrenormalize ddba3dd325054e71d48634cb19708cb7bcd8f20b
fatal: CRLF would be replaced by LF in src/r_plane.cpp.
^ permalink raw reply related
* What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Junio C Hamano @ 2016-11-29 0:15 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jc/renormalize-merge-kill-safer-crlf (2016-11-28) 2 commits
- merge-recursive: handle NULL in add_cacheinfo() correctly
- cherry-pick: demonstrate a segmentation fault
Fix a corner case in merge-recursive regression that crept in
during 2.10 development cycle.
Will merge to 'next'.
* js/difftool-builtin (2016-11-28) 2 commits
- difftool: implement the functionality in the builtin
- difftool: add a skeleton for the upcoming builtin
Rewrite a scripted porcelain "git difftool" in C.
Under discussion.
* nd/qsort-in-merge-recursive (2016-11-28) 1 commit
- merge-recursive.c: use string_list_sort instead of qsort
Code simplification.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jc/retire-compaction-heuristics (2016-11-02) 3 commits
- SQUASH???
- SQUASH???
- diff: retire the original experimental "compaction" heuristics
Waiting for a reroll.
* jc/abbrev-autoscale-config (2016-11-01) 1 commit
- config.abbrev: document the new default that auto-scales
Waiting for a reroll.
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
- exclude: do not respect symlinks for in-tree .gitignore
- attr: do not respect symlinks for in-tree .gitattributes
- exclude: convert "check_index" into a flags field
- attr: convert "macro_ok" into a flags field
- add open_nofollow() helper
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
* nd/worktree-move (2016-11-28) 11 commits
. worktree remove: new command
. worktree move: refuse to move worktrees with submodules
. worktree move: accept destination as directory
. worktree move: new command
. worktree.c: add update_worktree_location()
. worktree.c: add validate_worktree()
. copy.c: convert copy_file() to copy_dir_recursively()
. copy.c: style fix
. copy.c: convert bb_(p)error_msg to error(_errno)
. copy.c: delete unused code in copy_file()
. copy.c: import copy_file() from busybox
(this branch uses nd/worktree-list-fixup.)
"git worktree" learned move and remove subcommands.
Reported to break builds on Windows.
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* bw/push-dry-run (2016-11-23) 2 commits
- push: fix --dry-run to not push submodules
- push: --dry-run updates submodules when --recurse-submodules=on-demand
(this branch uses hv/submodule-not-yet-pushed-fix.)
"git push --dry-run --recurse-submodule=on-demand" wasn't
"--dry-run" in the submodules.
Will merge to 'next'.
* sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
- push: change submodule default to check when submodules exist
- submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Need to rebase on hv/submodule-not-yet-pushed-fix and then consider
merging to 'next'.
* jk/rev-parse-symbolic-parents-fix (2016-11-16) 1 commit
- rev-parse: fix parent shorthands with --symbolic
"git rev-parse --symbolic" failed with a more recent notation like
"HEAD^-1" and "HEAD^!".
Will merge to 'next'.
* nd/worktree-list-fixup (2016-11-28) 5 commits
- worktree list: keep the list sorted
- worktree.c: get_worktrees() takes a new flag argument
- get_worktrees() must return main worktree as first item even on error
- worktree: reorder an if statement
- worktree.c: zero new 'struct worktree' on allocation
(this branch is used by nd/worktree-move.)
The output from "git worktree list" was made in readdir() order,
and was unstable.
Will merge to 'next'.
* jk/trailers-placeholder-in-pretty (2016-11-21) 2 commits
- ref-filter: add support to display trailers as part of contents
- pretty: add %(trailers) format for displaying trailers of a commit message
In addition to %(subject), %(body), "log --pretty=format:..."
learned a new placeholder %(trailers).
Will merge to 'next'.
* sb/submodule-intern-gitdir (2016-11-22) 5 commits
- SQUASH
- submodule: add embed-git-dir function
- test-lib-functions.sh: teach test_commit -C <dir>
- submodule helper: support super prefix
- submodule: use absolute path for computing relative path connecting
A new submodule helper "git submodule embedgitdirs" to make it
easier to move embedded .git/ directory for submodules in a
superproject to .git/modules/ (and point the latter with the former
that is turned into a "gitdir:" file) has been added.
Need to read it over again, deal with SQUASH, and may ask for a
reroll.
* dt/empty-submodule-in-merge (2016-11-17) 1 commit
- submodules: allow empty working-tree dirs in merge/cherry-pick
An empty directory in a working tree that can simply be nuked used
to interfere while merging or cherry-picking a change to create a
submodule directory there, which has been fixed..
Waiting for review.
* bw/grep-recurse-submodules (2016-11-22) 6 commits
- grep: search history of moved submodules
- grep: enable recurse-submodules to work on <tree> objects
- grep: optionally recurse into submodules
- grep: add submodules as a grep source type
- submodules: load gitmodules file from commit sha1
- submodules: add helper functions to determine presence of submodules
"git grep" learns to optionally recurse into submodules
Has anybody else seen t7814 being flakey with this series?
* dt/smart-http-detect-server-going-away (2016-11-18) 2 commits
(merged to 'next' on 2016-11-21 at d502523347)
+ upload-pack: optionally allow fetching any sha1
+ remote-curl: don't hang when a server dies before any output
When the http server gives an incomplete response to a smart-http
rpc call, it could lead to client waiting for a full response that
will never come. Teach the client side to notice this condition
and abort the transfer.
An improvement counterproposal has failed.
cf. <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
Will cook in 'next'.
* mm/push-social-engineering-attack-doc (2016-11-14) 1 commit
(merged to 'next' on 2016-11-16 at b7c1b27563)
+ doc: mention transfer data leaks in more places
Doc update on fetching and pushing.
Will cook in 'next'.
* jc/compression-config (2016-11-15) 1 commit
(merged to 'next' on 2016-11-23 at b3c9254897)
+ compression: unify pack.compression configuration parsing
Compression setting for producing packfiles were spread across
three codepaths, one of which did not honor any configuration.
Unify these so that all of them honor core.compression and
pack.compression variables the same way.
Will cook in 'next'.
* mm/gc-safety-doc (2016-11-16) 1 commit
(merged to 'next' on 2016-11-17 at fc0d225b6b)
+ git-gc.txt: expand discussion of races with other processes
Doc update.
Will cook in 'next'.
* hv/submodule-not-yet-pushed-fix (2016-11-16) 4 commits
(merged to 'next' on 2016-11-21 at 1a599af962)
+ submodule_needs_pushing(): explain the behaviour when we cannot answer
+ batch check whether submodule needs pushing into one call
+ serialize collection of refs that contain submodule changes
+ serialize collection of changed submodules
(this branch is used by bw/push-dry-run.)
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
Will cook in 'next'.
* kn/ref-filter-branch-list (2016-11-15) 18 commits
- for-each-ref: do not segv with %(HEAD) on an unborn branch
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled, reviewed, looking good.
Expecting a reroll.
cf. <20161108201211.25213-1-Karthik.188@gmail.com>
cf. <CAOLa=ZQqe3vEj_428d41vd_4kfjzsm87Wam6Zm2dhXWkPdJ8Rw@mail.gmail.com>
cf. <xmqq7f84tqa7.fsf_-_@gitster.mtv.corp.google.com>
* bw/transport-protocol-policy (2016-11-09) 2 commits
(merged to 'next' on 2016-11-16 at 1391d3eeed)
+ transport: add protocol policy config option
+ lib-proto-disable: variable name fix
Finer-grained control of what protocols are allowed for transports
during clone/fetch/push have been enabled via a new configuration
mechanism.
Will cook in 'next'.
* jt/fetch-no-redundant-tag-fetch-map (2016-11-11) 1 commit
(merged to 'next' on 2016-11-16 at 5846c27cc5)
+ fetch: do not redundantly calculate tag refmap
Code cleanup to avoid using redundant refspecs while fetching with
the --tags option.
Will cook in 'next'.
* sb/submodule-config-cleanup (2016-11-22) 3 commits
(merged to 'next' on 2016-11-23 at c02e578b49)
+ submodule-config: clarify parsing of null_sha1 element
+ submodule-config: rename commit_sha1 to treeish_name
+ submodule config: inline config_from_{name, path}
Minor code clean-up.
Will cook in 'next'.
* jc/push-default-explicit (2016-10-31) 2 commits
(merged to 'next' on 2016-11-01 at 8dc3a6cf25)
+ push: test pushing ambiguously named branches
+ push: do not use potentially ambiguous default refspec
A lazy "git push" without refspec did not internally use a fully
specified refspec to perform 'current', 'simple', or 'upstream'
push, causing unnecessary "ambiguous ref" errors.
Will cook in 'next'.
* jt/use-trailer-api-in-commands (2016-11-02) 6 commits
- sequencer: use trailer's trailer layout
- trailer: have function to describe trailer layout
- trailer: avoid unnecessary splitting on lines
- commit: make ignore_non_trailer take buf/len
- SQUASH???
- trailer: be stricter in parsing separators
Commands that operate on a log message and add lines to the trailer
blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
"commit -s", have been taught to use the logic of and share the
code with "git interpret-trailer".
Will merge to 'next' after dealing with the SQUASH???
* nd/rebase-forget (2016-11-28) 1 commit
- rebase: add --forget to cleanup rebase, leave everything else untouched
"git rebase" learned "--forget" option, which allows a user to
remove the metadata left by an earlier "git rebase" that was
manually aborted without using "git rebase --abort".
Will merge to 'next'.
* jc/git-open-cloexec (2016-11-02) 3 commits
- sha1_file: stop opening files with O_NOATIME
- git_open_cloexec(): use fcntl(2) w/ FD_CLOEXEC fallback
- git_open(): untangle possible NOATIME and CLOEXEC interactions
The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
We may want to drop the tip one.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-10-26 at 220e160451)
+ setup_git_env: avoid blind fall-back to ".git"
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* jc/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
Will discard.
This may not be needed, given that update-index has a similar
option.
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
Will discard.
The whole premise feels wrong.
* tb/convert-stream-check (2016-10-27) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Will discard.
Retracted.
cf. <20161102071646.GA5094@tb-raspi>
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Waiting for review.
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for a reroll.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* sb/attr (2016-11-11) 35 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
- attr: keep attr stack for each check
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
Waiting for review.
* va/i18n-perl-scripts (2016-11-11) 16 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark composing message for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark status words for translation
- i18n: add--interactive: remove %patch_modes entries
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark patch prompt for translation
- i18n: add--interactive: mark plural strings
- i18n: clean.c: match string with git-add--interactive.perl
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here-documents for translation
- i18n: add--interactive: mark strings for translation
- Git.pm: add subroutines for commenting lines
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will cook in 'next'.
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-10-11 at 8928c8b9b3)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
Will cook in 'next'.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
From: Junio C Hamano @ 2016-11-29 0:06 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, Stefan Beller
In-Reply-To: <732c0e78-74b5-befa-e3c5-5ed9f221fa3a@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> On 11/23/2016 03:21 PM, Junio C Hamano wrote:
>> * jt/use-trailer-api-in-commands (2016-11-02) 6 commits
>> - sequencer: use trailer's trailer layout
>> - trailer: have function to describe trailer layout
>> - trailer: avoid unnecessary splitting on lines
>> - commit: make ignore_non_trailer take buf/len
>> - SQUASH???
>> - trailer: be stricter in parsing separators
>>
>> Commands that operate on a log message and add lines to the trailer
>> blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
>> "commit -s", have been taught to use the logic of and share the
>> code with "git interpret-trailer".
>>
>> What's the doneness of this topic?
>
> Stefan Beller mentioned [1] that this seemed OK to him from a cursory
> read. Do I need to look for another reviewer (or a more thorough
> review)?
I gave it a cursory review when it was queued, too, so another
cursory read does not help very much ;) If I recall correctly, I
got an impression that it was reasonably well done.
I haven't had a chance to look at the series again to see if the
SQUASH is just the simple matter of squashing it into the one
previous, which is the main reason why I haven't decided if it is
ready to be in 'next'.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
From: Jonathan Tan @ 2016-11-29 0:01 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Stefan Beller
In-Reply-To: <xmqqk2btlr3x.fsf@gitster.mtv.corp.google.com>
On 11/23/2016 03:21 PM, Junio C Hamano wrote:
> * jt/use-trailer-api-in-commands (2016-11-02) 6 commits
> - sequencer: use trailer's trailer layout
> - trailer: have function to describe trailer layout
> - trailer: avoid unnecessary splitting on lines
> - commit: make ignore_non_trailer take buf/len
> - SQUASH???
> - trailer: be stricter in parsing separators
>
> Commands that operate on a log message and add lines to the trailer
> blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
> "commit -s", have been taught to use the logic of and share the
> code with "git interpret-trailer".
>
> What's the doneness of this topic?
Stefan Beller mentioned [1] that this seemed OK to him from a cursory
read. Do I need to look for another reviewer (or a more thorough review)?
[1] <CAGZ79kY8AUwOYAQX=PEHU3H+AhLAuxtC9+hb42da6TrSdz4BzA@mail.gmail.com>
^ permalink raw reply
* Re: [PATCH] Release note spelling and phrasing fixups.
From: Junio C Hamano @ 2016-11-28 23:56 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <20161124165900.30605-1-marcnarc@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
> ---
>
> Mostly just missing words and what I feel are clarifications.
>
> The biggest change is to the "git add -N" item. Not 100% sure
> I got it right.
>
> M.
> - * When new paths were added by "git add -N" to the index, it was
> - enough to circumvent the check by "git commit" to refrain from
> - making an empty commit without "--allow-empty". The same logic
> - prevented "git status" to show such a path as "new file" in the
> + * "git commit" created an empty commit when invoked with an index
> + consisting solely of intend-to-add paths (added with "git add -N").
> + It now requires the "--allow-empty" option to create such a commit.
> + The same logic prevented "git status" from showing such paths as "new files" in the
> "Changes not staged for commit" section.
Yes this is much easier to read. Greatly appreciated.
> * Codepaths that read from an on-disk loose object were too loose in
> - validating what they are reading is a proper object file and
> + validating that they are reading a proper object file and
> sometimes read past the data they read from the disk, which has
> been corrected. H/t to Gustavo Grieco for reporting.
> ...
> - * An author name, that spelled a backslash-quoted double quote in the
> - human readable part "My \"double quoted\" name", was not unquoted
> + * An author name that has a backslash-quoted double quote in the
> + human readable part ("My \"double quoted\" name"), was not unquoted
> correctly while applying a patch from a piece of e-mail.
> ...
> - * It is a common mistake to say "git blame --reverse OLD path",
> - expecting that the command line is dwimmed as if asking how lines
> + * "git blame --reverse OLD path" is now DWIMmed to show how lines
> in path in an old revision OLD have survived up to the current
> commit.
> (merge e1d09701a4 jc/blame-reverse later to maint).
> ...
> * The "submodule.<name>.path" stored in .gitmodules is never copied
> to .git/config and such a key in .git/config has no meaning, but
> - the documentation described it and submodule.<name>.url next to
> - each other as if both belong to .git/config. This has been fixed.
> + the documentation described it next to submodule.<name>.url
> + as if both belong to .git/config. This has been fixed.
These, too.
> - * In a worktree connected to a repository elsewhere, created via "git
> + * In a worktree created via "git
> worktree", "git checkout" attempts to protect users from confusion
> by refusing to check out a branch that is already checked out in
> another worktree. However, this also prevented checking out a
> - branch, which is designated as the primary branch of a bare
> + branch which is designated as the primary branch of a bare
> reopsitory, in a worktree that is connected to the bare
> repository. The check has been corrected to allow it.
This 'reopsitory' may already have been fixed ;-)
... goes and looks ...
Oops, no it hasn't. I'll patch it up while queuing this.
> - * A hot-fix for a test added by a recent topic that went to both
> + * Hot-fixed a test added by a recent topic that went to both
> 'master' and 'maint' already.
Oops; an entry like this shouldn't have been in the release notes in
the first place, because those who are seeing the released versions
would have never seen such breakages. Will try to remember removing
it.
Thanks, I missed this one completely even though you sent it out
last week and didn't have a chance to read it over before starting
today's integration cycle.
^ permalink raw reply
* Re: [PATCH] diff: handle --no-abbrev outside of repository
From: Junio C Hamano @ 2016-11-28 23:03 UTC (permalink / raw)
To: Jack Bates; +Cc: git, Jack Bates
In-Reply-To: <20161128182508.10570-1-jack@nottheoilrig.com>
Jack Bates <bk874k@nottheoilrig.com> writes:
> The "git diff --no-index" codepath doesn't handle the --no-abbrev
> option.
>
> Signed-off-by: Jack Bates <jack@nottheoilrig.com>
> ---
This patch also needs a new test to protect the fix from future
breakages.
It is unfortunate that parsing of these options that are done in
diff_opt_parse() are not used by most of the codepaths; they instead
rely on revision.c parser to parse them into revs->abbrev and then
copied to revs->diffopt.abbrev in setup_revisions(). We would want
to rethink the structure of the code around this, and possibly move
towards using setup_revisions() more when appropriate and removing
diff_opt_parse() or something like that; the three-way fallback
codepath in builtin/am.c is the only other caller of this function
and it uses it to parse a fixed "--diff-filter=AM" option into
rev_info.diffopt and manually sets up rev_info as if revision parser
was given "diff --cached HEAD", which we should be able to replace
with a call to setup_revisions() of "--diff-filter=AM --cached HEAD",
I would suspect. But that is a much larger change.
In any case, for now, the fix in this patch is a single best step
that moves us forward.
Thanks.
> diff.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index ec87283..0447eff 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
> abbrev = FALLBACK_DEFAULT_ABBREV;
> if (abbrev > GIT_SHA1_HEXSZ)
> die("BUG: oid abbreviation out of range: %d", abbrev);
> - hex[abbrev] = '\0';
> + if (abbrev)
> + hex[abbrev] = '\0';
> return hex;
> }
> }
> @@ -4024,6 +4025,8 @@ int diff_opt_parse(struct diff_options *options,
> offending, optarg);
> return argcount;
> }
> + else if (!strcmp(arg, "--no-abbrev"))
> + options->abbrev = 0;
> else if (!strcmp(arg, "--abbrev"))
> options->abbrev = DEFAULT_ABBREV;
> else if (skip_prefix(arg, "--abbrev=", &arg)) {
^ permalink raw reply
* Re: [PATCH 31/35] pathspec: allow querying for attributes
From: Brandon Williams @ 2016-11-28 22:11 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, pclouds, git
In-Reply-To: <20161110203428.30512-32-sbeller@google.com>
On 11/10, Stefan Beller wrote:
> @@ -500,6 +586,18 @@ void copy_pathspec(struct pathspec *dst, const struct pathspec *src)
>
> void clear_pathspec(struct pathspec *pathspec)
> {
> + int i, j;
> + for (i = 0; i < pathspec->nr; i++) {
> + if (!pathspec->items[i].attr_match_nr)
> + continue;
> + for (j = 0; j < pathspec->items[j].attr_match_nr; j++)
> + free(pathspec->items[i].attr_match[j].value);
> + free(pathspec->items[i].attr_match);
> + if (pathspec->items[i].attr_check)
> + git_attr_check_clear(pathspec->items[i].attr_check);
> + free(pathspec->items[i].attr_check);
> + }
> +
> free(pathspec->items);
> pathspec->items = NULL;
You may also want to add logic like this to the 'copy_pathspec' function
so that when a pathspec struct is copied, the destination also has
ownership of its own attribute items.
--
Brandon Williams
^ permalink raw reply
* [GIT PULL] l10n updates for 2.11.0 round 3
From: Jiang Xin @ 2016-11-28 21:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git List, Changwoo Ryu, Dimitriy Ryazantcev, Jean-Noel Avila,
Jiang Xin, Peter Krefting, Ralf Thielow, Tran Ngoc Quan,
Vasco Almeida, jfbu
Hi Junio,
The following changes since commit e2b2d6a172b76d44cb7b1ddb12ea5bfac9613a44:
Git 2.11-rc3 (2016-11-23 11:24:59 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.11.0-rnd3
for you to fetch changes up to 6366c34b895613482fa32f1abe1c3ca043905ad2:
l10n: de.po: translate 210 new messages (2016-11-28 18:49:25 +0100)
----------------------------------------------------------------
l10n-2.11.0-rnd3
----------------------------------------------------------------
Jiang Xin (1):
l10n: fix unmatched single quote in error message
Ralf Thielow (1):
l10n: de.po: translate 210 new messages
po/de.po | 9112 +++++++++++++++++++++++++++++++++--------------------------
po/fr.po | 6 +-
po/git.pot | 128 +-
po/ko.po | 6 +-
po/pt_PT.po | 6 +-
po/sv.po | 6 +-
po/vi.po | 6 +-
po/zh_CN.po | 6 +-
8 files changed, 5125 insertions(+), 4151 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Junio C Hamano @ 2016-11-28 21:48 UTC (permalink / raw)
To: Lars Schneider; +Cc: Eric Wong, git
In-Reply-To: <249EE7A4-F297-4537-92A9-0EF75A3B1AEE@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
> What way do you think is better from a maintenance point of view?
> I prefer option 2 but I fear that these "special" values could confuse
> future readers of the code.
I recall getting confused by the redefinition of the meaning of
return value from the grep_directory() function when we started
threading the working-tree grep codepath at around 5b594f457a;
compared to that, as long as the "special" (and "normal") values are
made symbolic constants, I do not think it is too bad.
^ permalink raw reply
* Re: [PATCH v2 0/5] nd/worktree-list-fixup
From: Junio C Hamano @ 2016-11-28 21:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, rappazzo
In-Reply-To: <20161128093656.15744-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This version
>
> * changes get_worktrees() to take a flag, and adds one flag for
> sorting.
>
> * adds tests for both the 'main worktree always present' and the
> sorting problems.
>
> * reworks 3/5 a bit, keep changes closer, easier to see the cause and
> consequence.
>
> Nguyễn Thái Ngọc Duy (5):
> worktree.c: zero new 'struct worktree' on allocation
> worktree: reorder an if statement
> get_worktrees() must return main worktree as first item even on error
> worktree.c: get_worktrees() takes a new flag argument
> worktree list: keep the list sorted
>
> branch.c | 2 +-
> builtin/branch.c | 2 +-
> builtin/worktree.c | 14 ++++++++------
> t/t2027-worktree-list.sh | 40 ++++++++++++++++++++++++++++++++++++++++
> worktree.c | 42 +++++++++++++++++++++---------------------
> worktree.h | 4 +++-
> 6 files changed, 74 insertions(+), 30 deletions(-)
Thanks for a pleasant read. Will replace what has been queued.
^ 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