[PATCH 2/2] mergetools/vimdiff: trust Vim's exit code
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
Signed-off-by: David Aguilar
---
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
[PATCH 1/2] mergetool: honor mergetool.$tool.trustExitCode for built-in tools
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
Signed-off-by: David Aguilar
---
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
---
gitk crashes on RHEL
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
[PATCH] RelNotes: typo fix in 2.11.0 notes
s/paht/path/ in the "Backwards compatibility notes" section of the 2.11.0 release notes. Signed-off-by: Tobias Klauser --- 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
git-gui paste not working
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.
re
Did you get my request?
Re: [PATCH v2 00/11] git worktree (re)move
On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano wrote: > Junio C Hamano 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
Re: [PATCH v2 00/11] git worktree (re)move
On Tue, Nov 29, 2016 at 4:25 AM, Johannes Sixt wrote: > Am 28.11.2016 um 21:20 schrieb Junio C Hamano: >> >> Junio C Hamano 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
Re: [PATCH] allow git-p4 to create shelved changelists
On 28 November 2016 at 19:06, Junio C Hamano wrote: > Vinicius Kursancew 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. > >
[GIT PULL] l10n updates for 2.11.0 round 3 with ru and ca translations
Hi Junio, Final l10n updates for this release cycle, please pull. The following changes since commit 6366c34b895613482fa32f1abe1c3ca043905ad2: l10n: de.po: translate 210 new messages (2016-11-28 18:49:25 +0100) are available in the git repository at: git://github.com/git-l10n/git-po tags/l10n-2.11.0-rnd3.1 for you to fetch changes up to 082ed8f8706bdb0645ceb13f8ba3cb8ccfb58d5d: Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru (2016-11-29 21:19:43 +0800) l10n-2.11.0-rnd3.1: update ru and ca translations Alex Henrie (1): l10n: ca.po: update translation Dimitriy Ryazantcev (1): l10n: ru.po: update Russian translation Jiang Xin (1): Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru po/ca.po | 8907 ++ po/ru.po | 8340 -- 2 files changed, 9473 insertions(+), 7774 deletions(-) -- Jiang Xin
Re: [PATCH v2 00/11] git worktree (re)move
On Tue, Nov 29, 2016 at 07:08:16PM +0700, Duy Nguyen wrote:
> On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano wrote:
> > Junio C Hamano 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...
Another way, as pointed out by j6t, is go with "move within filesystem
only", at least at the first step. Which is probably a good idea
anyway so we can concentrate on git-specific stuff before going to
minor and complicated copy/move details.
If you drop all the "copy.c: " patches and squash this to "worktree
move: new command", and if Windows rename() can move directories, then
git should build and new tests pass.
-- 8< --
diff --git a/builtin/worktree.c b/builtin/worktree.c
index f114965..d8d0127 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -569,9 +569,9 @@ static int move_worktree(int ac, const char **av, const
char *prefix)
wt->path, dst.buf);
/* second try.. */
- if (copy_dir_recursively(wt->path, dst.buf))
- die(_("failed to copy '%s' to '%s'"),
- wt->path, dst.buf);
+ if (copy_dir_recursively(dst.buf, wt->path))
+ die_errno(_("failed to copy '%s' to '%s'"),
+ wt->path, dst.buf);
else {
struct strbuf sb = STRBUF_INIT;
diff --git a/cache.h b/cache.h
index a50a61a..2d4edf6 100644
--- a/cache.h
+++ b/cache.h
@@ -1857,6 +1857,7 @@ extern void fprintf_or_die(FILE *, const char *fmt, ...);
extern int copy_fd(int ifd, int ofd);
extern int copy_file(const char *dst, const char *src, int mode);
extern int copy_file_with_time(const char *dst, const char *src, int mode);
+extern int copy_dir_recursively(const char *dst, const char *src);
extern void write_or_die(int fd, const void *buf, size_t count);
extern void fsync_or_die(int fd, const char *);
diff --git a/copy.c b/copy.c
index 4de6a11..b232aec 100644
--- a/copy.c
+++ b/copy.c
@@ -65,3 +65,9 @@ int copy_file_with_time(const char *dst, const char *src, int
mode)
return copy_times(dst, src);
return status;
}
+
+int copy_dir_recursively(const char *dst, const char *src)
+{
+ errno = ENOSYS;
+ return -1;
+}
-- 8< --
[PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
From: Torsten Bögershausen
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize
fatal: CRLF would be replaced by LF in [path]
Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE.
Reported-by: Eevee (Lexy Munroe)
Signed-off-by: Torsten Bögershausen
---
Thanks for reporting.
Here is a less invasive patch.
Please let me know, if the patch is OK for you
(email address, does it work..)
convert.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/convert.c b/convert.c
index be91358..526ec1d 100644
--- a/convert.c
+++ b/convert.c
@@ -286,7 +286,9 @@ static int crlf_to_git(const char *path, const char *src,
size_t len,
checksafe = SAFE_CRLF_FALSE;
else if (has_cr_in_index(path))
convert_crlf_into_lf = 0;
- }
+ } else if (checksafe == SAFE_CRLF_RENORMALIZE)
+ checksafe = SAFE_CRLF_FALSE;
+
if (checksafe && len) {
struct text_stat new_stats;
memcpy(&new_stats, &stats, sizeof(new_stats));
--
2.10.0
[PATCH] difftool.c: mark a file-local symbol with static
Signed-off-by: Ramsay Jones
---
Hi Johannes,
If you need to re-roll your 'js/difftool-builtin' branch, could
you please squash this into the relevant patch.
Thanks!
Also, due to a problem in my config.mak file on Linux (a commented
out line that had a line continuation '\', gr!), gcc issued a
warning, thus:
builtin/difftool.c: In function ‘run_dir_diff’:
builtin/difftool.c:568:13: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
warning("");
^
I am not sure why -Wno-format-zero-length is set in DEVELOPER_CFLAGS,
but do you really need to space the output with an an 'empty'
"warning:" line? (Just curious).
ATB,
Ramsay Jones
builtin/difftool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/difftool.c b/builtin/difftool.c
index 3480920..830369c 100644
--- a/builtin/difftool.c
+++ b/builtin/difftool.c
@@ -170,7 +170,7 @@ struct path_entry {
char path[FLEX_ARRAY];
};
-int path_entry_cmp(struct path_entry *a, struct path_entry *b, void *key)
+static int path_entry_cmp(struct path_entry *a, struct path_entry *b, void
*key)
{
return strcmp(a->path, key ? key : b->path);
}
--
2.9.0
Re: [PATCH 31/35] pathspec: allow querying for attributes
On Mon, Nov 28, 2016 at 2:11 PM, Brandon Williams wrote:
> 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.
>
Thanks for the review comments, I'll plan on resending this series after the
submodule checkout series (which is nowhere near done, but the foundation
is set with sb/submodule-intern-gitdir as a preparation.)
After discussion with Jonathan Nieder, I think it may be possible to make
this new pathspec magic work without the need for thread safety. This is
archived by constructing all relevant attr_check stacks before the preload_index
functionality (which is threaded) and then use the preconstructed attr_checks
to get attr_results just like in this series.
That approach would come with the benefit of not needing mutexes
at all inside the attr code.
Re: gitk crashes on RHEL
On Tue, Nov 29, 2016 at 1:51 AM, Alessandro Renieri wrote:
> 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
+cc Paul Mackeras, and people involved in the last bug report
See discussion at
https://public-inbox.org/git/caaozyynnwk-ye9tg_fpxxs-orn-yesm_yfs+ej7muq+5ycw...@mail.gmail.com/#t
Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
Jeff King writes: > 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. Hmph, that's a thought.
Re: [PATCH] RelNotes: typo fix in 2.11.0 notes
Tobias Klauser writes: > s/paht/path/ in the "Backwards compatibility notes" section of the > 2.11.0 release notes. > > Signed-off-by: Tobias Klauser > --- This looks somewhat familiar. Perhaps https://public-inbox.org/git/1477668782.1869.4.ca...@seestieto.com/ > 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
Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
On Tue, Nov 29, 2016 at 10:31:51AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > 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. > > Hmph, that's a thought. I was resistant to it at first because we'll have to deal with all of the headaches of matching case-folding, but if we just match ".git*" and not ".gitmodules", ".gitattributes", etc, it actually gets easier. I think we can basically build off of the existing is_hfs_dotgit() and is_ntfs_dotgit() functions. I haven't written the code yet, though, so there may be complications. -Peff
Re: [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> Working with a repo that used to be all CRLF. At some point it
> was changed to all LF, with `text=auto` in .gitattributes.
> Trying to cherry-pick a commit from before the switchover fails:
>
> $ git cherry-pick -Xrenormalize
> fatal: CRLF would be replaced by LF in [path]
OK. That's a very clear description of the symptom that can be
observed from the surface.
> Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
> SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE.
Aside from needing s/CRLF_SAFE/SAFE_CRLF/, this however lacks
"Otherwise, because of X and Y, Z ends up doing W" to explain
the "must be" part. Care to explain it a bit more?
Thanks.
> Reported-by: Eevee (Lexy Munroe)
> Signed-off-by: Torsten Bögershausen
> ---
>
> Thanks for reporting.
> Here is a less invasive patch.
> Please let me know, if the patch is OK for you
> (email address, does it work..)
>
> convert.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/convert.c b/convert.c
> index be91358..526ec1d 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -286,7 +286,9 @@ static int crlf_to_git(const char *path, const char *src,
> size_t len,
> checksafe = SAFE_CRLF_FALSE;
> else if (has_cr_in_index(path))
> convert_crlf_into_lf = 0;
> - }
> + } else if (checksafe == SAFE_CRLF_RENORMALIZE)
> + checksafe = SAFE_CRLF_FALSE;
> +
> if (checksafe && len) {
> struct text_stat new_stats;
> memcpy(&new_stats, &stats, sizeof(new_stats));
Re: [PATCH 0/2] add format specifiers to display trailers
On Mon, 2016-11-21 at 09:23 -0800, Junio C Hamano wrote: > Jacob Keller writes: > > > > We have %s and %b so that we can reconstruct the whole thing by > > > using both. It is unclear how %bT fits in this picture. I > > > wonder > > > if we also need another placeholder that expands to the body of > > > the > > > message without the trailer---otherwise the whole set would > > > become > > > incoherent, no? > > > > I'm not entirely sure what to do here. I just wanted a way to > > easily > > format "just the trailers" of a message. We could add something > > that > > formats just the non-trailers, that's not too difficult. Not really > > sure what I'd call it though. > > I was wondering if %(log:) was a better way to go. > > %(log:title) and %(log:body) would be equivalents of traditional %s > and %b, and %(log:body) in turn would be a shorter way to write > %(log:description)%+(log:trailer), i.e. show the message body, and > if there is a trailer block, add it after adding a blank line. > > Or something like that? That would work for me. Thanks, Jake
Re: [PATCH] RelNotes: typo fix in 2.11.0 notes
On 2016-11-29 at 19:35:38 +0100, Junio C Hamano wrote: > Tobias Klauser writes: > > > s/paht/path/ in the "Backwards compatibility notes" section of the > > 2.11.0 release notes. > > > > Signed-off-by: Tobias Klauser > > --- > > This looks somewhat familiar. Perhaps > > https://public-inbox.org/git/1477668782.1869.4.ca...@seestieto.com/ Oops, certainly didn't read carefiul enough. Sorry for the noise and thanks for the reference. > > 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 >
Re: [PATCH 1/2] mergetool: honor mergetool.$tool.trustExitCode for built-in tools
David Aguilar writes:
> 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
> Signed-off-by: David Aguilar
> ---
> 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(-)
OK, so the idea is that the backends that used to touch $BACKUP and
used to call check_unchanged stop doing these two things, while
other backends override exit_code_trustable(). That makes the
change to the backends very straightforward to understand.
> # 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
> }
Looks sensible. Thanks. Will queue.
Re: [PATCH] allow git-p4 to create shelved changelists
Luke Diamand writes: > On 28 November 2016 at 19:06, Junio C Hamano wrote: >> Vinicius Kursancew 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. Thanks.
Re: [PATCH/RFC v1 1/1] New way to normalize the line endings
tbo...@web.de writes: > From: Torsten Bögershausen > > Sincec commit 6523728499e7 'convert: unify the "auto" handling of CRLF' > the normalization instruction in Documentation/gitattributes.txt > doesn't work any more. Aside from s/Sincec/Since/, the above made it sound as if the named commit was a regression that wants to be reverted, at least to my first reading. I think you want to be a bit more clear that we updated the world order and made it a better place with that commit, and examples in the doc need to be updated. To convince readers that, I think you would need to explain things like why the old way illustrated in the example was bad, and why the new way is better. > Update the documentation and add a test case. > > Reported by Kristian Adrup > https://github.com/git-for-windows/git/issues/954 > > Signed-off-by: Torsten Bögershausen > --- > Documentation/gitattributes.txt | 7 +++ > t/t0025-crlf-auto.sh| 29 + > 2 files changed, 32 insertions(+), 4 deletions(-) > > diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt > index 976243a..1f7529a 100644 > --- a/Documentation/gitattributes.txt > +++ b/Documentation/gitattributes.txt > @@ -227,11 +227,10 @@ From a clean working directory: > > - > $ echo "* text=auto" >.gitattributes > -$ rm .git/index # Remove the index to force Git to > -$ git reset # re-scan the working directory > +$ git ls-files --eol | egrep "i/(crlf|mixed)" # find not normalized files Does this step help anything? I do not see anything in the later steps that the user uses the finding from the output of this step to affect the end result. > +$ rm .git/index # Remove the index to re-scan the working directory > +$ git add . "A clean working directory" usually means all paths in the index match what's in the working tree but this requires a bit more than that, as this step ends up adding untracked and unignored paths. > $ git status# Show files that will be normalized > -$ git add -u > -$ git add .gitattributes > $ git commit -m "Introduce end-of-line normalization" > - > > diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh > index d0bee08..4ad4d02 100755 > --- a/t/t0025-crlf-auto.sh > +++ b/t/t0025-crlf-auto.sh > @@ -152,4 +152,33 @@ test_expect_success 'eol=crlf _does_ normalize binary > files' ' > test -z "$LFwithNULdiff" > ' > > +test_expect_success 'prepare unnormalized' ' > + > + > .gitattributes && Lose SP before ".gitattributes". > + git config core.autocrlf false && > + printf "LINEONE\nLINETWO\r\n" >mixed && > + git add mixed .gitattributes && > + git commit -m "Add mixed" && > + git ls-files --eol | egrep "i/crlf" && > + git ls-files --eol | egrep "i/mixed" > + > +' Any particular reason why we must use egrep not grep here? > + > +test_expect_success 'normalize unnormalized' ' > + echo "* text=auto" >.gitattributes && > + rm .git/index && > + git add . && > + git commit -m "Introduce end-of-line normalization" && > + git ls-files --eol | tr "\\t" " " | sort >act && > +cat >exp < +i/-text w/-text attr/text=auto LFwithNUL > +i/lfw/crlf attr/text=auto CRLFonly > +i/lfw/crlf attr/text=auto LFonly > +i/lfw/lfattr/text=auto .gitattributes > +i/lfw/mixed attr/text=auto mixed > +EOF Use <<-EOF to indent the above 7 lines? > + test_cmp exp act > + > +' > + > test_done
Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano wrote: > > * 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'. The rebase is without merge conflicts, so I assume there is no work needed by me here. > * sb/submodule-intern-gitdir (2016-11-22) 5 commits > - SQUASH > - submodule: add embed-git-dir function > - test-lib-functions.sh: teach test_commit -C > - 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. Ok, I looked over it again and I may see some issues: * it is applicable to all submodules recursive by default, i.e. really "all submodules reachable from this superproject". I anticipate this to be the most relevant use case (i.e. as a preparatory step for having e.g. git-checkout work), but there are no other commands yet that are recursing into submodules recursively by default. So a discussion/disagreement on the default may come up. (We also may want to see a --[no-]recursive flag) * The output is okay-ish, but could be better as it is a mix of relative and absolute path: Migrating git directory of plugins/cookbook from '/absolute/path/here/gerrit/plugins/cookbook/.git' to '/absolute/path/here/gerrit/.git/modules/plugins/cookbook/' On the other hand this seems like what the user may need, as it is the maximum for trouble shooting * As this is a subcommand we do not need to add it to command-list.txt However we may want to discuss if some submodule commands are porcelain (all except for the new embedgitdirs?) and if this new command is plumbing. We could also argue the submodule--helper (which needs listing in command-list.txt as a plumbing command?) is the plumbing equivalent and the "submodule embedgitdirs" is the porcelain. * any other part where we need to add documentation for a new command? FYI: I have a series cooking internally that adds a new page in Documentation/submodules that introduces the concept of submodules, which then allows Documentation/git-submodule.txt to be focused on the actual command and its options. > > * dt/empty-submodule-in-merge (2016-11-17) 1 commit > - submodules: allow empty working-tree dirs in merge/cherry-pick > > Waiting for review That slipped by me. Will review. > * sb/attr (2016-11-11) 35 commits > - completion: clone can initialize specific submodules > - clone: add --init-submodule= switch > - submodule update: add `--init-default-path` switch I may end up rerolling these top three patches as its own series again without the underlying pathspec support. I will investigate if we need the mutex at all for the attribute code or if we can initialize all attrs (in the pathspecs) before the threaded preload_index takes place. That sounds cleaner to me, but I do not prioritize it as high. > Waiting for review. There was some review by Duy and Brandon, I may reroll with just their issues addressed. Thanks, Stefan
Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
Stefan Beller writes: > On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano wrote: >> >> * 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'. > > The rebase is without merge conflicts, so I assume there is no > work needed by me here. Correct. >> * sb/submodule-intern-gitdir (2016-11-22) 5 commits >> - SQUASH >> - submodule: add embed-git-dir function >> - test-lib-functions.sh: teach test_commit -C >> - 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. > > Ok, I looked over it again and I may see some issues: OK then I'll procrastinate on this. > That slipped by me. Will review. > >> * sb/attr (2016-11-11) 35 commits >> - completion: clone can initialize specific submodules >> - clone: add --init-submodule= switch >> - submodule update: add `--init-default-path` switch > > I may end up rerolling these top three patches as its own series > again without the underlying pathspec support. > > I will investigate if we need the mutex at all for the attribute > code or if we can initialize all attrs (in the pathspecs) before the > threaded preload_index takes place. That sounds cleaner to me, > but I do not prioritize it as high. OK. Thanks.
Re: [PATCH v2 00/11] git worktree (re)move
Duy Nguyen writes: > Another way, as pointed out by j6t, is go with "move within filesystem > only", at least at the first step. Which is probably a good idea > anyway so we can concentrate on git-specific stuff before going to > minor and complicated copy/move details. Yup, that is a very sensible approach.
Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
On Tue, Nov 29, 2016 at 11:26 AM, Junio C Hamano wrote: >>> Need to read it over again, deal with SQUASH, and may ask for a >>> reroll. >> >> Ok, I looked over it again and I may see some issues: > > OK then I'll procrastinate on this. This is not what I had in mind when typing out the issues. I'd rather wanted to hear "these issues are all non-issues, your design is actually correct as a first solution". ;)
Re: [GIT PULL] l10n updates for 2.11.0 round 3 with ru and ca translations
Jiang Xin writes: > Final l10n updates for this release cycle, please pull. Thanks!
gitconfig includes
I just noticed something weird: if I have this in my ~/.gitconfig: [x] x = global [include] path = .gitconfig.more and .gitconfig.more has [x] x = more then I get: 1. git config x.x => more 2. git config --global x.x => global 3. git config --global --includes x.x => more The first works as I expected. The second surprised me, since I took "--global" to mean "the global file and stuff it includes" (that's my understanding of the description of `include`). The third is fine, but it made me even more surprised at the second, especially since the man blurb on --includes says "Defaults to on."... So this is at least a documentation issue, though I hope that #2 is a bug and that it *should* return "more"...? -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
Re: gitconfig includes
Eli Barzilay writes: > So this is at least a documentation issue,... This already is documented, and I think it is clear enough. --[no-]includes Respect include.* directives in config files when looking up values. Defaults to off when a specific file is given (e.g., using --file, --global, etc) and on when searching all config files.
Re: gitconfig includes
On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano wrote: > Eli Barzilay writes: > >> So this is at least a documentation issue,... > > This already is documented, and I think it is clear enough. > >--[no-]includes > Respect include.* directives in config files when > looking up values. Defaults to off when a specific > file is given (e.g., using --file, --global, etc) > and on when searching all config files. Yeah, that's clear, sorry for not checking the latest. [I'd expect/wish it to be on by default though... Any reason for the default being off in these cases?] -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
Re: [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
On Tue, Nov 29, 2016 at 10:42:18AM -0800, Junio C Hamano wrote: > tbo...@web.de writes: > > > From: Torsten Bögershausen > > > > Working with a repo that used to be all CRLF. At some point it > > was changed to all LF, with `text=auto` in .gitattributes. > > Trying to cherry-pick a commit from before the switchover fails: > > > > $ git cherry-pick -Xrenormalize > > fatal: CRLF would be replaced by LF in [path] > > OK. That's a very clear description of the symptom that can be > observed from the surface. > > > Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX, > > SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE. > > Aside from needing s/CRLF_SAFE/SAFE_CRLF/, this however lacks > "Otherwise, because of X and Y, Z ends up doing W" to explain > the "must be" part. Care to explain it a bit more? Thanks for the review - how about this: convert: git cherry-pick -Xrenormalize did not work Working with a repo that used to be all CRLF. At some point it was changed to all LF, with `text=auto` in .gitattributes. Trying to cherry-pick a commit from before the switchover fails: $ git cherry-pick -Xrenormalize fatal: CRLF would be replaced by LF in [path] Commit 65237284 "unify the "auto" handling of CRLF" introduced a regression: Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX, SAFE_CRLF_RENORMALIZE was feed into check_safe_crlf(). This is wrong because here everything else than SAFE_CRLF_WARN is treated as SAFE_CRLF_FAIL. Solution: Turn SAFE_CRLF_RENORMALIZE into SAFE_CRLF_FALSE before calling check_safe_crlf(). Reported-by: Eevee (Lexy Munroe) Signed-off-by: Torsten Bögershausen
Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin
Hi Junio, On Mon, 28 Nov 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > However, I have been bitten time and again by problems that occurred only > > in production, our test suite (despite taking already waay too long to > > be truly useful in my daily development) was simply not good enough. > > > > So my plan was different: to let end users opt-in to test this new beast > > thoroughly, more thoroughly than any review would. > > I agree with that 100%. > > [...] > > > And for that, environment variables are just not an option. I need > > something that can be configured in a portable application, so that the > > main Git for Windows installation is unaffected. > > I am not sure I follow here. > > Are you saying that the users who are opting into the experiment > will keep two installations, one for daily use that avoids getting > hit by the experimental code and the other that is used for testing? I have obviously done a real bad job at explaining the Windows situation well enough. Many, many users have multiple installations of Git for Windows. If you have GitHub for Windows and installed the command-line tools: you got one. If you installed Git for Windows, you got another one. If you installed Visual Studio, chances are you have another one. If you got any number of third-party tools requiring Git functionality, you have another one. They all live in separate directories that are their own little pseudo Unix root directory structures, complete with etc/, usr/, var/. Users do not necessarily keep track, or for that matter, are aware of, the multiple different installations. Obviously, I do not want any installation other than the one the user just installed to pick up on the configuration. So the suggestion by both you and Peff, to use an environment variable, which is either global, or requires the user to set it manually per session, is simply not a good idea at all. > > My original "create a file in libexec/git-core/" was simple, did the job > > reliably, and worked also for testing. > > It may have been OK for quick-and-dirty hack during development, but > I do not think it was good in anything released. Well, you say that it is quick and dirty. I say it is the only viable solution I saw so far. All proposed alternative solutions fall flat on their bellies, simply by not working in all the cases I need them to work. As I said elsewhere: I look for a correct solution first, and then I thrive to make it pretty. You start the other way round, and I do not have time for that right now. Ciao, Dscho
Re: [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
Torsten Bögershausen writes:
> Thanks for the review - how about this:
>
>
> convert: git cherry-pick -Xrenormalize did not work
>
> Working with a repo that used to be all CRLF. At some point it
> was changed to all LF, with `text=auto` in .gitattributes.
> Trying to cherry-pick a commit from before the switchover fails:
>
> $ git cherry-pick -Xrenormalize
> fatal: CRLF would be replaced by LF in [path]
>
> Commit 65237284 "unify the "auto" handling of CRLF" introduced
> a regression:
>
> Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
> SAFE_CRLF_RENORMALIZE was feed into check_safe_crlf().
> This is wrong because here everything else than SAFE_CRLF_WARN is
> treated as SAFE_CRLF_FAIL.
What is still left unsaid is that we shouldn't even bother seeing if
it is safe to do crlf conversion when renormalizing. Perhaps that
is too obvious to state?
In any case, when you put the rationale that way, the impression I
get from it is that the root cause of the problem is that "here"
(aka "check_safe_crlf()") considers anything other than CRLF_WARN as
a failure, when a newer choice other than CRLF_WARN and CRLF_FAIL
(namely, CRLF_RENORMALIZE) exists. Which hints me that a sensible
change may be to fix that function.
The patch you sent has the effect of not entering this whole block,
not just "don't call check_safe_crlf() because it misbehaves":
if (checksafe && len) {
struct text_stat new_stats;
memcpy(&new_stats, &stats, sizeof(new_stats));
/* simulate "git add" */
if (convert_crlf_into_lf) {
new_stats.lonelf += new_stats.crlf;
new_stats.crlf = 0;
}
/* simulate "git checkout" */
if (will_convert_lf_to_crlf(len, &new_stats, crlf_action)) {
new_stats.crlf += new_stats.lonelf;
new_stats.lonelf = 0;
}
check_safe_crlf(path, crlf_action, &stats, &new_stats,
checksafe);
}
And it is a sensible thing to do, because all the computation that
happens in the block before check_safe_crlf() is called is done ONLY
to prepare the parameter passed to check_safe_crlf(); if we are to
make the function no-op for CRLF_RENORMALIZE, preparing new_stats is
a wasted effort.
However, futzing with the value of checksafe in the function is
ugly. It is not even unclear if it is safe to do so without reading
the remainder of the function (i.e. later parts of the function may
care--or start caring in the future--what the caller passed in the
variable). Yes, the function already modifies the variable, but
that can also be fixed.
In other words, I would have expected that a fix that matches your
description to look more like below. The condition for the "if"
statement may even want to become
if ((checksafe == SAFE_CRLF_WARN ||
(checksafe == SAFE_CRLF_FAIL)) && len)
to clarify it further.
Thanks.
convert.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/convert.c b/convert.c
index f9f7f5e436..d72e0bf0d7 100644
--- a/convert.c
+++ b/convert.c
@@ -282,12 +282,11 @@ static int crlf_to_git(const char *path, const char *src,
size_t len,
* If the file in the index has any CR in it, do not convert.
* This is the new safer autocrlf handling.
*/
- if (checksafe == SAFE_CRLF_RENORMALIZE)
- checksafe = SAFE_CRLF_FALSE;
- else if (has_cr_in_index(path))
+ if (checksafe != SAFE_CRLF_RENORMALIZE &&
+ has_cr_in_index(path))
convert_crlf_into_lf = 0;
}
- if (checksafe && len) {
+ if (checksafe && checksafe != SAFE_CRLF_RENORMALIZE && len) {
struct text_stat new_stats;
memcpy(&new_stats, &stats, sizeof(new_stats));
/* simulate "git add" */
Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin
On Tue, Nov 29, 2016 at 09:36:55PM +0100, Johannes Schindelin wrote: > So the suggestion by both you and Peff, to use an environment variable, > which is either global, or requires the user to set it manually per > session, is simply not a good idea at all. No, my suggestion was to use config and have the test suite use an environment variable to test both cases (preferably automatically, without the user having to do anything). I do not see how that fails to cover all of your use cases. -Peff
Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin
Johannes Schindelin writes: > So the suggestion by both you and Peff, to use an environment variable, > which is either global, or requires the user to set it manually per > session, is simply not a good idea at all. As I already said, I do not have a strong preference between config and env. I raised the env as a possible alternative that you can think about its pros and cons, and as I already said, if you thought and your concluded that config would work better for your needs, that is fine by me.
Re: [PATCH v2 00/11] git worktree (re)move
Am 29.11.2016 um 14:56 schrieb Duy Nguyen:
If you drop all the "copy.c: " patches and squash this to "worktree
move: new command", and if Windows rename() can move directories, then
git should build and new tests pass.
Thanks! rename() can move directories on Windows, provided that
*nothing* inside the directory is in any form of use by any process,
particularly also not as the "current working directory" (as per getcwd()).
diff --git a/copy.c b/copy.c
index 4de6a11..b232aec 100644
--- a/copy.c
+++ b/copy.c
@@ -65,3 +65,9 @@ int copy_file_with_time(const char *dst, const char *src, int
mode)
return copy_times(dst, src);
return status;
}
+
+int copy_dir_recursively(const char *dst, const char *src)
+{
+ errno = ENOSYS;
+ return -1;
+}
An error message "cannot move directories across devices" or something
would be preferable over "Function not implemented", of course. Or did
you mean to set errno = EXDEV?
-- Hannes
[ANNOUNCE] Git v2.11.0
The latest feature release Git v2.11.0 is now available at the
usual places. It is comprised of 673 non-merge commits since
v2.10.0, contributed by 74 people, 15 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.11.0'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.10.0 are as follows.
Welcome to the Git development community!
Aaron M Watson, Brandon Williams, Brian Henderson, Emily Xie,
Gavin Lambert, Ian Kelling, Jeff Hostetler, jfbu, Mantas
Mikulėnas, Petr Stodulka, Satoshi Yasushima, Stefan Christ,
Vegard Nossum, yaras, and Younes Khoudli.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Ævar Arnfjörð Bjarmason, Alexander Shopov, Alex Henrie,
Alex Riesen, Anders Kaseorg, Andreas Schwab, Beat Bolli, Ben
North, brian m. carlson, Changwoo Ryu, Chris Packham, Christian
Couder, David Aguilar, David Turner, Dennis Kaarsemaker,
Dimitriy Ryazantcev, Elia Pinto, Eric Wong, Jacob Keller,
Jakub Narębski, Jean-Noel Avila, Jean-Noël AVILA, Jeff King,
Jiang Xin, Johannes Schindelin, Johannes Sixt, Jonathan Nieder,
Jonathan Tan, Josh Triplett, Junio C Hamano, Karsten Blees,
Kevin Daudt, Kirill Smelkov, Lars Schneider, Linus Torvalds,
Marc Branchaud, Matthieu Moy, Michael Haggerty, Michael J
Gruber, Mike Ralphson, Nguyễn Thái Ngọc Duy, Olaf Hering,
Orgad Shaneh, Patrick Steinhardt, Pat Thoyts, Peter Krefting,
Philip Oakley, Pranit Bauva, Ralf Thielow, Ray Chen, René
Scharfe, Ronnie Sahlberg, Stefan Beller, SZEDER Gábor, Thomas
Gummerer, Tobias Klauser, Trần Ngọc Quân, Vasco Almeida,
and Дилян Палаузов.
Git 2.11 Release Notes
==
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
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
asks users to use a more explicit '.' for that instead.
The hope is that existing users will not mind this change, and
eventually the warning can be turned into a hard error, upgrading
the deprecation into removal of this (mis)feature.
* The historical argument order "git merge HEAD ..."
has been deprecated for quite some time, and will be removed in the
next release (not this one).
* The default abbreviation length, which has historically been 7, now
scales as the repository grows, using the approximate number of
objects in the repository and a bit of math around the birthday
paradox. The logic suggests to use 12 hexdigits for the Linux
kernel, and 9 to 10 for Git itself.
Updates since v2.10
---
UI, Workflows & Features
* Comes with new version of git-gui, now at its 0.21.0 tag.
* "git format-patch --cover-letter HEAD^" to format a single patch
with a separate cover letter now numbers the output as [PATCH 0/1]
and [PATCH 1/1] by default.
* An incoming "git push" that attempts to push too many bytes can now
be rejected by setting a new configuration variable at the receiving
end.
* "git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
which was not intuitive, given that "git nosuchcommand" said "git:
'nosuchcommand' is not a git command".
* "git clone --recurse-submodules --reference $path $URL" is a way to
reduce network transfer cost by borrowing objects in an existing
$path repository when cloning the superproject from $URL; it
learned to also peek into $path for presence of corresponding
repositories of submodules and borrow objects from there when able.
* The "git diff --submodule={short,log}" mechanism has been enhanced
to allow "--submodule=diff" to show the patch between the submodule
commits bound to the superproject.
* Even though "git hash-objects", which is a tool to take an
on-filesystem data stream and put it into the Git object store,
can perform "outside-world-to-Git" conversions (e.g.
end-of-line conversions and application of the clean-filter), and
it has had this feature on by default from very early days, its reverse
operation "git cat-file", which takes an object from the Git object
store and externalizes it for consumption by the outside world,
lacked an equivalent mechanism to run the "Git-to-outside-world"
conversio
A note from the maintainer
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address . You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://public-inbox.org/git/
http://marc.info/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.public-inbox.org/inbox.comp.version-control.git
nntp://news.gmane.org/gmane.comp.version-control.git
are available.
When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:
http://public-inbox.org/git/pine.lnx.4.58.0504150753440.7...@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel
There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).
Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at .
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list . This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:
- people triaging and fixing reported vulnerabilities
- people operating major git hosting sites with many users
- people packaging and distributing git to large numbers of people
where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.
* Repositories and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/cgit/git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:
https://git.github.io/htmldocs/git.html
* How various branches are used.
There are four branches in git.git repository that track the source tree
of git: "master", "maint
Re: [ANNOUNCE] Git v2.11.0
On Tue, Nov 29, 2016 at 01:21:51PM -0800, Junio C Hamano wrote: > The latest feature release Git v2.11.0 is now available at the > usual places. It is comprised of 673 non-merge commits since > v2.10.0, contributed by 74 people, 15 of which are new faces. > [...] > Jeff King (117): > [...] > common-main: stop munging argv[0] path Oh, I didn't expect this to go in at the last minute. The regression was actually in 2.10.0, so I figured it would just end up as part of 2.11.1. I think it's an obviously correct patch, though (famous last words). :) -Peff
Re: gitconfig includes
On Tue, Nov 29, 2016 at 02:53:08PM -0500, Eli Barzilay wrote: > > This already is documented, and I think it is clear enough. > > > >--[no-]includes > > Respect include.* directives in config files when > > looking up values. Defaults to off when a specific > > file is given (e.g., using --file, --global, etc) > > and on when searching all config files. > > Yeah, that's clear, sorry for not checking the latest. > > [I'd expect/wish it to be on by default though... Any reason for the > default being off in these cases?] It definitely needs to default to off for "-f", as we would not want surprises when accessing files like ".gitmodules" that come from untrusted sources. I think it's arguable whether "--global" should behave the same. It makes the rule simple: "if you specify a single file, includes default to off". But I don't think there would be any particular harm. The existing default was mostly chosen for simplicity and least-surprise with respect to backwards compatibility. There's a little more discussion in 9b25a0b52 (config: add include directive, 2012-02-06). -Peff
Re: gitconfig includes
Jeff King writes: > I think it's arguable whether "--global" should behave the same. I know you know this and I am writing this message for others. I admit that I wondered if "a single file" ought to cover these short-hand notations like --global and --local while re-reading the log message of 9b25a0b52 (config: add include directive, 2012-02-06). In other words, I agree that it used to be arguable before we released v1.7.10. It no longer is arguable simply due to backward compatibilty. The ship has long sailed.
Re: Partial fetch?
On Mon, Nov 28, 2016 at 10:34:51PM +0200, Dāvis Mosāns wrote: > I'm trying to fetch a remote repository over https but sadly it > timeouts too soon. > > $ git fetch -v upstream > POST git-upload-pack (gzip 1148 to 641 bytes) > POST git-upload-pack (gzip 1148 to 644 bytes) > [...] > Is there some way to fetch partially by smaller chunks and then repeat > that again till everything is fetched? Not an easy one. The series of POSTs is an indication that the fetch negotiation is going on for a long time, which probably means you have a lot of commits in your local repository that aren't in the remote, or vice versa. Here are the things I might try: - git v2.10.2 has commit 06b3d386e (fetch-pack: do not reset in_vain on non-novel acks, 2016-09-23), which may help with this. - HTTP, because the server is stateless, performs less well than other protocols. If you can fetch over ssh or git://, it will probably just work. - If this is a one-time thing to fetch unrelated history from another repository, you can "clone --mirror" instead of fetching, then fetch from the mirror locally. Subsequent fetches should be fast. If you do try v2.10.2 and it improves things, I'd be interested to hear about it as a data point. -Peff
Re: [ANNOUNCE] Git v2.11.0
Jeff King writes: > On Tue, Nov 29, 2016 at 01:21:51PM -0800, Junio C Hamano wrote: > >> The latest feature release Git v2.11.0 is now available at the >> usual places. It is comprised of 673 non-merge commits since >> v2.10.0, contributed by 74 people, 15 of which are new faces. >> [...] >> Jeff King (117): >> [...] >> common-main: stop munging argv[0] path > > Oh, I didn't expect this to go in at the last minute. The regression was > actually in 2.10.0, so I figured it would just end up as part of 2.11.1. To be honest, inclusion of this was a screw-up ;-) I couldn't count between 2.10 and 2.11-rc.
GIT by github 2.10.2.1 is listed on Software Informer
Good day! Software.informer.com would like to inform you that your product GIT by github 2.10.2.1 has been reviewed by our editors and your program got "100% Clean Award" http://git.software.informer.com/. We would be grateful if you place our award with a link to our review on your website. On our part, we can offer featuring your program in our Today's Highlight block. This block is shown in the rotator at the top of the main page and also on every page of our website in the upper right corner. We also offer you to take advantage of our free storage by hosting your installation package on our servers and listing us as one of the mirror downloads for your application. There is a selection of predesigned buttons available to fit the look of your website. Please let me know if you're interested in any of these offers. We are on the list of the world's 500 most visited websites with over 700,000 unique visitors every day, so this could get your application some extra exposure. Kind regards, Kasey Bloome
Re: [PATCH v2 00/11] git worktree (re)move
On Wed, Nov 30, 2016 at 4:14 AM, Johannes Sixt wrote:
>> diff --git a/copy.c b/copy.c
>> index 4de6a11..b232aec 100644
>> --- a/copy.c
>> +++ b/copy.c
>> @@ -65,3 +65,9 @@ int copy_file_with_time(const char *dst, const char
>> *src, int mode)
>> return copy_times(dst, src);
>> return status;
>> }
>> +
>> +int copy_dir_recursively(const char *dst, const char *src)
>> +{
>> + errno = ENOSYS;
>> + return -1;
>> +}
>
>
> An error message "cannot move directories across devices" or something would
> be preferable over "Function not implemented", of course. Or did you mean to
> set errno = EXDEV?
The exact message is not super important right now. Though I'm
thinking of adding move_directory() that is a wrapper of rename(). We
can die("cannot move directories across devices") then and hopefully
be able to move across devices at some point.
--
Duy
Re: [PATCH v2 00/11] git worktree (re)move
On Tue, Nov 29, 2016 at 11:28 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Another way, as pointed out by j6t, is go with "move within filesystem >> only", at least at the first step. Which is probably a good idea >> anyway so we can concentrate on git-specific stuff before going to >> minor and complicated copy/move details. > > Yup, that is a very sensible approach. In case you decided to go another way than a plain rename, please make it easy to reuse (e.g. move_directory_safely exposed to the rest of the codebase). I'd find use for that in the series currently queued as: sb/submodule-intern-gitdir which moves git directories of submodules around (from inside the submodule/.git to the superprojects .git/modules/) Thanks, Stefan
Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
On Tue, Nov 29, 2016 at 11:21 AM, Stefan Beller wrote: > >> >> * dt/empty-submodule-in-merge (2016-11-17) 1 commit >> - submodules: allow empty working-tree dirs in merge/cherry-pick >> >> Waiting for review > > That slipped by me. Will review. > I reviewed what you have queued and it still looks good to me.
Re: Partial fetch?
2016-11-29 23:55 GMT+02:00 Jeff King : > On Mon, Nov 28, 2016 at 10:34:51PM +0200, Dāvis Mosāns wrote: > >> I'm trying to fetch a remote repository over https but sadly it >> timeouts too soon. >> >> $ git fetch -v upstream >> POST git-upload-pack (gzip 1148 to 641 bytes) >> POST git-upload-pack (gzip 1148 to 644 bytes) >> [...] >> Is there some way to fetch partially by smaller chunks and then repeat >> that again till everything is fetched? > > Not an easy one. The series of POSTs is an indication that the fetch > negotiation is going on for a long time, which probably means you have a > lot of commits in your local repository that aren't in the remote, or > vice versa. > > Here are the things I might try: > > - git v2.10.2 has commit 06b3d386e (fetch-pack: do not reset in_vain > on non-novel acks, 2016-09-23), which may help with this. > That output and this is already with git v2.10.2 > - HTTP, because the server is stateless, performs less well than other > protocols. If you can fetch over ssh or git://, it will probably > just work. > It's only available under https://git.replicant.us/replicant/frameworks_base.git > - If this is a one-time thing to fetch unrelated history from another > repository, you can "clone --mirror" instead of fetching, > then fetch from the mirror locally. Subsequent fetches should be > fast. > Looks like something is wrong with their server/setup since currently even clone doesn't work for me. Cloning into bare repository 'frameworks_base.git'... remote: Counting objects: 739930, done. remote: Compressing objects: 100% (196567/196567), done. error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed But someone have made a mirror for it and there clone works only still same issue with fetch. Once I will have this cloned I will try local fetch. Thanks!
