* Re: [PATCH bw/realpath-wo-chdir] real_path: canonicalize directory separators in root parts
From: Brandon Williams @ 2016-12-22 17:33 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, sbeller, peff, jacob.keller, gitster, ramsay, tboegi,
pclouds
In-Reply-To: <0c9aa347-d64e-b7d7-9b07-52d844d76252@kdbg.org>
On 12/22, Johannes Sixt wrote:
> Am 21.12.2016 um 23:33 schrieb Brandon Williams:
> >On 12/21, Johannes Sixt wrote:
> >>+/* copies root part from remaining to resolved, canonicalizing it on the way */
> >>+static void get_root_part(struct strbuf *resolved, struct strbuf *remaining)
> >>+{
> >>+ int offset = offset_1st_component(remaining->buf);
> >>+
> >>+ strbuf_reset(resolved);
> >>+ strbuf_add(resolved, remaining->buf, offset);
> >>+#ifdef GIT_WINDOWS_NATIVE
> >>+ convert_slashes(resolved->buf);
> >>+#endif
> >
> >So then the only extra cononicalization that is happening here is
> >converting '\\server\share' to '//server/share'? (or 'c:\' to 'c:/')
>
> Correct. All other directory separators are canonicalized by the
> primary function, strbuf_realpath.
Sounds good. Logically everything looks good to me. And I like that
setting 'resolved' to the root of an abs path is pulled out into a
helper function. It took me a couple extra seconds to realize that
offset_1st_component returns 0 with a relative path, which makes causes
the call to get_root_part to essentially be a noop (ie nothing is
resolved).
Thanks for helping get this to work on windows!
--
Brandon Williams
^ permalink raw reply
* [PATCH v2 1/3] mingw: adjust is_console() to work with stdin
From: Johannes Schindelin @ 2016-12-22 17:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pranit Bauva, Johannes Sixt, Beat Bolli
In-Reply-To: <cover.1482426497.git.johannes.schindelin@gmx.de>
When determining whether a handle corresponds to a *real* Win32 Console
(as opposed to, say, a character device such as /dev/null), we use the
GetConsoleOutputBufferInfo() function as a tell-tale.
However, that does not work for *input* handles associated with a
console. Let's just use the GetConsoleMode() function for input handles,
and since it does not work on output handles fall back to the previous
method for those.
This patch prepares for using is_console() instead of my previous
misguided attempt in cbb3f3c9b1 (mingw: intercept isatty() to handle
/dev/null as Git expects it, 2016-12-11) that broke everything on
Windows.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
compat/winansi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index cb725fb02f..590d61cb1b 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -84,6 +84,7 @@ static void warn_if_raster_font(void)
static int is_console(int fd)
{
CONSOLE_SCREEN_BUFFER_INFO sbi;
+ DWORD mode;
HANDLE hcon;
static int initialized = 0;
@@ -98,7 +99,10 @@ static int is_console(int fd)
return 0;
/* check if its a handle to a console output screen buffer */
- if (!GetConsoleScreenBufferInfo(hcon, &sbi))
+ if (!fd) {
+ if (!GetConsoleMode(hcon, &mode))
+ return 0;
+ } else if (!GetConsoleScreenBufferInfo(hcon, &sbi))
return 0;
/* initialize attributes */
--
2.11.0.rc3.windows.1
^ permalink raw reply related
* [PATCH v2 3/3] mingw: replace isatty() hack
From: Johannes Schindelin @ 2016-12-22 17:09 UTC (permalink / raw)
To: git; +Cc: Jeff Hostetler, Junio C Hamano, Pranit Bauva, Johannes Sixt,
Beat Bolli
In-Reply-To: <cover.1482426497.git.johannes.schindelin@gmx.de>
From: Jeff Hostetler <jeffhost@microsoft.com>
Git for Windows has carried a patch that depended on internals
of MSVC runtime, but it does not work correctly with recent MSVC
runtime. A replacement was written originally for compiling
with VC++. The patch in this message is a backport of that
replacement, and it also fixes the previous attempt to make
isatty() tell that /dev/null is *not* an interactive terminal.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Tested-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
compat/winansi.c | 176 ++++++++++++++++++++++---------------------------------
1 file changed, 69 insertions(+), 107 deletions(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index fa37695fca..477209fce7 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -6,9 +6,12 @@
#include "../git-compat-util.h"
#include <wingdi.h>
#include <winreg.h>
+#include "win32.h"
-/* In this file, we actually want to use Windows' own isatty(). */
-#undef isatty
+static int fd_is_interactive[3] = { 0, 0, 0 };
+#define FD_CONSOLE 0x1
+#define FD_SWAPPED 0x2
+#define FD_MSYS 0x4
/*
ANSI codes used by git: m, K
@@ -105,6 +108,9 @@ static int is_console(int fd)
} else if (!GetConsoleScreenBufferInfo(hcon, &sbi))
return 0;
+ if (fd >= 0 && fd <= 2)
+ fd_is_interactive[fd] |= FD_CONSOLE;
+
/* initialize attributes */
if (!initialized) {
console = hcon;
@@ -466,76 +472,50 @@ static HANDLE duplicate_handle(HANDLE hnd)
return hresult;
}
+static HANDLE swap_osfhnd(int fd, HANDLE new_handle)
+{
+ /*
+ * Create a copy of the original handle associated with fd
+ * because the original will get closed when we dup2().
+ */
+ HANDLE handle = (HANDLE)_get_osfhandle(fd);
+ HANDLE duplicate = duplicate_handle(handle);
-/*
- * Make MSVCRT's internal file descriptor control structure accessible
- * so that we can tweak OS handles and flags directly (we need MSVCRT
- * to treat our pipe handle as if it were a console).
- *
- * We assume that the ioinfo structure (exposed by MSVCRT.dll via
- * __pioinfo) starts with the OS handle and the flags. The exact size
- * varies between MSVCRT versions, so we try different sizes until
- * toggling the FDEV bit of _pioinfo(1)->osflags is reflected in
- * isatty(1).
- */
-typedef struct {
- HANDLE osfhnd;
- char osflags;
-} ioinfo;
-
-extern __declspec(dllimport) ioinfo *__pioinfo[];
-
-static size_t sizeof_ioinfo = 0;
+ /* Create a temp fd associated with the already open "new_handle". */
+ int new_fd = _open_osfhandle((intptr_t)new_handle, O_BINARY);
-#define IOINFO_L2E 5
-#define IOINFO_ARRAY_ELTS (1 << IOINFO_L2E)
+ assert((fd == 1) || (fd == 2));
-#define FPIPE 0x08
-#define FDEV 0x40
+ /*
+ * Use stock dup2() to re-bind fd to the new handle. Note that
+ * this will implicitly close(1) and close both fd=1 and the
+ * originally associated handle. It will open a new fd=1 and
+ * call DuplicateHandle() on the handle associated with new_fd.
+ * It is because of this implicit close() that we created the
+ * copy of the original.
+ *
+ * Note that the OS can recycle HANDLE (numbers) just like it
+ * recycles fd (numbers), so we must update the cached value
+ * of "console". You can use GetFileType() to see that
+ * handle and _get_osfhandle(fd) may have the same number
+ * value, but they refer to different actual files now.
+ *
+ * Note that dup2() when given target := {0,1,2} will also
+ * call SetStdHandle(), so we don't need to worry about that.
+ */
+ dup2(new_fd, fd);
+ if (console == handle)
+ console = duplicate;
+ handle = INVALID_HANDLE_VALUE;
-static inline ioinfo* _pioinfo(int fd)
-{
- return (ioinfo*)((char*)__pioinfo[fd >> IOINFO_L2E] +
- (fd & (IOINFO_ARRAY_ELTS - 1)) * sizeof_ioinfo);
-}
+ /* Close the temp fd. This explicitly closes "new_handle"
+ * (because it has been associated with it).
+ */
+ close(new_fd);
-static int init_sizeof_ioinfo(void)
-{
- int istty, wastty;
- /* don't init twice */
- if (sizeof_ioinfo)
- return sizeof_ioinfo >= 256;
-
- sizeof_ioinfo = sizeof(ioinfo);
- wastty = isatty(1);
- while (sizeof_ioinfo < 256) {
- /* toggle FDEV flag, check isatty, then toggle back */
- _pioinfo(1)->osflags ^= FDEV;
- istty = isatty(1);
- _pioinfo(1)->osflags ^= FDEV;
- /* return if we found the correct size */
- if (istty != wastty)
- return 0;
- sizeof_ioinfo += sizeof(void*);
- }
- error("Tweaking file descriptors doesn't work with this MSVCRT.dll");
- return 1;
-}
+ fd_is_interactive[fd] |= FD_SWAPPED;
-static HANDLE swap_osfhnd(int fd, HANDLE new_handle)
-{
- ioinfo *pioinfo;
- HANDLE old_handle;
-
- /* init ioinfo size if we haven't done so */
- if (init_sizeof_ioinfo())
- return INVALID_HANDLE_VALUE;
-
- /* get ioinfo pointer and change the handles */
- pioinfo = _pioinfo(fd);
- old_handle = pioinfo->osfhnd;
- pioinfo->osfhnd = new_handle;
- return old_handle;
+ return duplicate;
}
#ifdef DETECT_MSYS_TTY
@@ -570,45 +550,25 @@ static void detect_msys_tty(int fd)
!wcsstr(name, L"-pty"))
return;
- /* init ioinfo size if we haven't done so */
- if (init_sizeof_ioinfo())
- return;
-
- /* set FDEV flag, reset FPIPE flag */
- _pioinfo(fd)->osflags &= ~FPIPE;
- _pioinfo(fd)->osflags |= FDEV;
+ fd_is_interactive[fd] |= FD_MSYS;
}
#endif
+/*
+ * Wrapper for isatty(). Most calls in the main git code
+ * call isatty(1 or 2) to see if the instance is interactive
+ * and should: be colored, show progress, paginate output.
+ * We lie and give results for what the descriptor WAS at
+ * startup (and ignore any pipe redirection we internally
+ * do).
+ */
+#undef isatty
int winansi_isatty(int fd)
{
- int res = isatty(fd);
-
- if (res) {
- /*
- * Make sure that /dev/null is not fooling Git into believing
- * that we are connected to a terminal, as "_isatty() returns a
- * nonzero value if the descriptor is associated with a
- * character device."; for more information, see
- *
- * https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
- */
- HANDLE handle = (HANDLE)_get_osfhandle(fd);
- if (fd == STDIN_FILENO) {
- DWORD dummy;
-
- if (!GetConsoleMode(handle, &dummy))
- res = 0;
- } else if (fd == STDOUT_FILENO || fd == STDERR_FILENO) {
- CONSOLE_SCREEN_BUFFER_INFO dummy;
-
- if (!GetConsoleScreenBufferInfo(handle, &dummy))
- res = 0;
- }
- }
-
- return res;
+ if (fd >= 0 && fd <= 2)
+ return fd_is_interactive[fd] != 0;
+ return isatty(fd);
}
void winansi_init(void)
@@ -619,6 +579,10 @@ void winansi_init(void)
/* check if either stdout or stderr is a console output screen buffer */
con1 = is_console(1);
con2 = is_console(2);
+
+ /* Also compute console bit for fd 0 even though we don't need the result here. */
+ is_console(0);
+
if (!con1 && !con2) {
#ifdef DETECT_MSYS_TTY
/* check if stdin / stdout / stderr are MSYS2 pty pipes */
@@ -662,12 +626,10 @@ void winansi_init(void)
*/
HANDLE winansi_get_osfhandle(int fd)
{
- HANDLE hnd = (HANDLE) _get_osfhandle(fd);
- if (isatty(fd) && GetFileType(hnd) == FILE_TYPE_PIPE) {
- if (fd == 1 && hconsole1)
- return hconsole1;
- else if (fd == 2 && hconsole2)
- return hconsole2;
- }
- return hnd;
+ if (fd == 1 && (fd_is_interactive[1] & FD_SWAPPED))
+ return hconsole1;
+ if (fd == 2 && (fd_is_interactive[2] & FD_SWAPPED))
+ return hconsole2;
+
+ return (HANDLE)_get_osfhandle(fd);
}
--
2.11.0.rc3.windows.1
^ permalink raw reply related
* [PATCH v2 2/3] mingw: fix colourization on Cygwin pseudo terminals
From: Johannes Schindelin @ 2016-12-22 17:09 UTC (permalink / raw)
To: git; +Cc: Alan Davies, Junio C Hamano, Pranit Bauva, Johannes Sixt,
Beat Bolli
In-Reply-To: <cover.1482426497.git.johannes.schindelin@gmx.de>
From: Alan Davies <alan.n.davies@gmail.com>
Git only colours the output and uses pagination if isatty() returns 1.
MSYS2 and Cygwin emulate pseudo terminals via named pipes, meaning that
isatty() returns 0.
f7f90e0f4f (mingw: make isatty() recognize MSYS2's pseudo terminals
(/dev/pty*), 2016-04-27) fixed this for MSYS2 terminals, but not for
Cygwin.
The named pipes that Cygwin and MSYS2 use are very similar. MSYS2 PTY pipes
are called 'msys-*-pty*' and Cygwin uses 'cygwin-*-pty*'. This commit
modifies the existing check to allow both MSYS2 and Cygwin PTY pipes to be
identified as TTYs.
Note that pagination is still broken when running Git for Windows from
within Cygwin, as MSYS2's less.exe is spawned (and does not like to
interact with Cygwin's PTY).
This partially fixes https://github.com/git-for-windows/git/issues/267
Signed-off-by: Alan Davies <alan.n.davies@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
compat/winansi.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index 590d61cb1b..fa37695fca 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -562,8 +562,12 @@ static void detect_msys_tty(int fd)
name = nameinfo->Name.Buffer;
name[nameinfo->Name.Length] = 0;
- /* check if this could be a MSYS2 pty pipe ('msys-XXXX-ptyN-XX') */
- if (!wcsstr(name, L"msys-") || !wcsstr(name, L"-pty"))
+ /*
+ * Check if this could be a MSYS2 pty pipe ('msys-XXXX-ptyN-XX')
+ * or a cygwin pty pipe ('cygwin-XXXX-ptyN-XX')
+ */
+ if ((!wcsstr(name, L"msys-") && !wcsstr(name, L"cygwin-")) ||
+ !wcsstr(name, L"-pty"))
return;
/* init ioinfo size if we haven't done so */
--
2.11.0.rc3.windows.1
^ permalink raw reply related
* [PATCH v2 0/3] Really fix the isatty() problem on Windows
From: Johannes Schindelin @ 2016-12-22 17:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pranit Bauva, Johannes Sixt, Beat Bolli
In-Reply-To: <cover.1482342791.git.johannes.schindelin@gmx.de>
My previous fix may have fixed running the new
t/t6030-bisect-porcelain.sh script that tested the new bisect--helper,
which in turn used isatty() to determine whether it was running
interactively and was fooled by being redirected to /dev/null.
But it not only broke paging when running in a CMD window, due to
testing in the wrong worktree I also missed that it broke paging in Git
for Windows 2.x' Git Bash (i.e. a MinTTY terminal emulator).
Let's use this opportunity to actually clean up the entire isatty() mess
once and for all, as part of the problem was introduced by a clever hack
that messes with internals of the Microsoft C runtime, and which changed
recently, so it was not such a clever hack to begin with.
Happily, one of my colleagues had to address that latter problem
recently when he was tasked to make Git compile with Microsoft Visual C
(the rationale: debugging facilities of Visual Studio are really
outstanding, try them if you get a chance).
And incidentally, replacing the previous hack with the clean, new
solution, which specifies explicitly for the file descriptors 0, 1 and 2
whether we detected an MSYS2 pseudo-tty, whether we detected a real
Win32 Console, and whether we had to swap out a real Win32 Console for a
pipe to allow child processes to inherit it.
While at it (or, actually, more like: as I already made this part of v1
by mistake), upstream the patch carried in Git for Windows that supports
color when running Git for Windows in Cygwin terminals.
Changes since v1:
- rebased onto master
- unsquashed 2/3 which was improperly snuck in before,
- noted that Beat Bolli tested this (see
https://github.com/git-for-windows/git/issues/997#issuecomment-268764693)
- fixed the confusing commit message by using Junio's suggested
replacement
- added the missing white space between ">=" and "0"
Alan Davies (1):
mingw: fix colourization on Cygwin pseudo terminals
Jeff Hostetler (1):
mingw: replace isatty() hack
Johannes Schindelin (1):
mingw: adjust is_console() to work with stdin
compat/winansi.c | 198 +++++++++++++++++++++++--------------------------------
1 file changed, 84 insertions(+), 114 deletions(-)
base-commit: 1d1bdafd64266e5ee3bd46c6965228f32e4022ea
Published-As: https://github.com/dscho/git/releases/tag/mingw-isatty-fixup-v2
Fetch-It-Via: git fetch https://github.com/dscho/git mingw-isatty-fixup-v2
Interdiff vs v1:
diff --git a/compat/winansi.c b/compat/winansi.c
index f51a2856d2..477209fce7 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -108,7 +108,7 @@ static int is_console(int fd)
} else if (!GetConsoleScreenBufferInfo(hcon, &sbi))
return 0;
- if (fd >=0 && fd <= 2)
+ if (fd >= 0 && fd <= 2)
fd_is_interactive[fd] |= FD_CONSOLE;
/* initialize attributes */
@@ -555,7 +555,8 @@ static void detect_msys_tty(int fd)
#endif
-/* Wrapper for isatty(). Most calls in the main git code
+/*
+ * Wrapper for isatty(). Most calls in the main git code
* call isatty(1 or 2) to see if the instance is interactive
* and should: be colored, show progress, paginate output.
* We lie and give results for what the descriptor WAS at
@@ -565,7 +566,7 @@ static void detect_msys_tty(int fd)
#undef isatty
int winansi_isatty(int fd)
{
- if (fd >=0 && fd <= 2)
+ if (fd >= 0 && fd <= 2)
return fd_is_interactive[fd] != 0;
return isatty(fd);
}
--
2.11.0.rc3.windows.1
^ permalink raw reply
* Bug-Report: git-svn and backslash in SVN branch name
From: Michael Fladischer @ 2016-12-22 10:12 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]
Hi,
I'm trying to clone a SVN repo in order to migrate it to git but i hit
a wall with SVN branch names that contain a backslash, which seems to be
allowed in SVN but prohibited in git refs:
r289 = c4cb1f0c34e741a07de9673515c853d49c5522b9
(refs/remotes/origin/dicomBaseClass)
Found possible branch point: file:///path.repo/trunk/dicomBaseClass =>
file:///path.repo/tags/dicomBaseClass%5Cv0.1, 181
Initializing parent: refs/remotes/origin/tags/dicomBaseClass\v0.1@181
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 101, path
'/trunk/dicomBaseClass'
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
Found possible branch point: file:///path.repo/dicomBaseClass =>
file:///path.repo/trunk/dicomBaseClass, 172
Initializing parent: refs/remotes/origin/tags/dicomBaseClass\v0.1@172
fatal: update_ref failed for ref
'refs/remotes/origin/tags/dicomBaseClass\v0.1@172': refusing to update
ref with bad name
'refs/remotes/origin/tags/dicomBaseClass\v0.1@172'
update-ref -m r75 refs/remotes/origin/tags/dicomBaseClass\v0.1@172
1fe0cc23e3cd56a1087562f8ca3d2e40cd2b30d4: command returned error: 128
The tag in case is "dicomBaseClass\v0.1@172".
Is there a way to mangle those names on the fly to get rid of the
backslashes or can they be handled in any other way to be compatible
with git?
Cheers,
--
Michael Fladischer
Fladi.at
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] log: support 256 colors with --graph=256colors
From: Duy Nguyen @ 2016-12-22 9:48 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20161220165754.hkmnsxiwbcgn6uin@sigill.intra.peff.net>
On Tue, Dec 20, 2016 at 11:57 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 20, 2016 at 07:39:29PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> I got mad after tracing two consecutive red history lines in `git log
>> --graph --oneline` back to their merge points, far far away. Yeah
>> probably should fire up tig, or gitk or something.
>>
>> This may sound like a good thing to add, but I don't know how good it
>> is compared to the good old 16 color palette, yet as I haven't tried it
>> for long since it's just written.
>
> Hmm. At some point the colors become too close together to be easily
> distinguishable. In your code you have:
>
>> + if (arg && !strcmp(arg, "256colors")) {
>> + int i, start = 17, stop = 232;
>> + column_colors_max = stop - start;
>> + column_colors =
>> + xmalloc((column_colors_max + 1) * sizeof(*column_colors));
>> + for (i = start; i < stop; i++) {
>> + struct strbuf sb = STRBUF_INIT;
>> + strbuf_addf(&sb, "\033[38;5;%dm", i);
>> + column_colors[i - start] = strbuf_detach(&sb, NULL);
>> + }
>> + column_colors[column_colors_max] = xstrdup(GIT_COLOR_RESET);
>> + /* ignore the closet 16 colors on either side for the next line */
>> + column_colors_step = 16;
>> + }
>
> So you step by 16, over a set of 215 colors. That seems to give only 13
> colors, versus the original 16. :)
>
> I know that is a simplification. If you wrap around, then you get your
> 13 colors, and then another 13 colors that aren't _quite_ the same, and
> so on, until you've used all 256. I'm just not sure if the 1st and 14th
> color would be visually different enough for it to matter (I admit I
> didn't do any experiments, though).
Yep. If the jump sequence is a random one, we're less likely to run
into this. But I think Junio's "run git-log in 2 terminals with the
same coloring" convinces me randomization here is not the best thing.
The best solution would be select colors per text line, so we can pick
different colors. But I think that's a lot of computation (and
probably an NP problem too). The second best option is have a good,
predefined color palette. We don't need a red of all shades, we need
something that look distinct enough from the rest. I googled for this
first and failed. But I think I could approach it a different way:
collect colors that have names. That reduces the number of colors so
we can go back to "step 1 at a time" and still don't run into two
similar colors often.
>> ---graph::
>> +--graph[=<options>]::
>> Draw a text-based graphical representation of the commit history
>> on the left hand side of the output. This may cause extra lines
>> to be printed in between commits, in order for the graph history
>
> I wonder if we would ever want another use for "--graph=foo"
I do. See the screenshot in [1] from the original mail. I have to
stare at --graph so often lately that it might get my attention before
other things.
> I guess any such thing could fall under the name of "graph options", and we'd
> end up with "--graph=256colors,unicode" or something like that.
Exactly.
> I do suspect people would want a config option for this, though. I.e.,
> you'd want to enable it all the time if you have a terminal which can
> handle 256 colors, not just for a particular invocation.
Yeah. That also means we need the ability to override/negate config
options, perhaps something like --graph=-256colors.
--
Duy
^ permalink raw reply
* Re: [PATCH] log: support 256 colors with --graph=256colors
From: Duy Nguyen @ 2016-12-22 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqh95yldg4.fsf@gitster.mtv.corp.google.com>
On Wed, Dec 21, 2016 at 12:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> diff --git a/graph.c b/graph.c
>> index d4e8519..75375a1 100644
>> --- a/graph.c
>> +++ b/graph.c
>> @@ -78,6 +78,7 @@ static void graph_show_line_prefix(const struct diff_options *diffopt)
>>
>> static const char **column_colors;
>> static unsigned short column_colors_max;
>> +static int column_colors_step;
>>
>> void graph_set_column_colors(const char **colors, unsigned short colors_max)
>> {
>> @@ -234,10 +235,24 @@ void graph_setup_line_prefix(struct diff_options *diffopt)
>> }
>>
>>
>> -struct git_graph *graph_init(struct rev_info *opt)
>> +struct git_graph *graph_init_with_options(struct rev_info *opt, const char *arg)
>> {
>> struct git_graph *graph = xmalloc(sizeof(struct git_graph));
>>
>> + if (arg && !strcmp(arg, "256colors")) {
>> + int i, start = 17, stop = 232;
>> + column_colors_max = stop - start;
>> + column_colors =
>> + xmalloc((column_colors_max + 1) * sizeof(*column_colors));
>> + for (i = start; i < stop; i++) {
>> + struct strbuf sb = STRBUF_INIT;
>> + strbuf_addf(&sb, "\033[38;5;%dm", i);
>> + column_colors[i - start] = strbuf_detach(&sb, NULL);
>> + }
>> + column_colors[column_colors_max] = xstrdup(GIT_COLOR_RESET);
>> + /* ignore the closet 16 colors on either side for the next line */
>> + column_colors_step = 16;
>> + }
>
> So you pre-fill a table of colors with 232-17=215 slots. Is the
> idea that it is a co-prime with column_colors_step which is set to
> 16 so that going over the table with wraparound will cover all its
> elements?
Originally yes (because the next color would be more or less the same,
maybe brighter or darker a bit), then I went fancy with the rand()
thing...
>
>> @@ -382,6 +397,20 @@ static unsigned short graph_get_current_column_color(const struct git_graph *gra
>> */
>> static void graph_increment_column_color(struct git_graph *graph)
>> {
>> + if (column_colors_step) {
>> + static int random_initialized;
>> + int v;
>> +
>> + if (!random_initialized) {
>> + srand((unsigned int)getpid());
>> + random_initialized = 1;
>> + }
>> + v = rand() % (column_colors_max - column_colors_step * 2);
>> + graph->default_column_color += column_colors_step + v;
>> + graph->default_column_color %= column_colors_max;
>> + return;
>> + }
>> +
>> graph->default_column_color = (graph->default_column_color + 1) %
>> column_colors_max;
>> }
>
> This is too ugly to live as-is for two reasons.
>
> - Do you really need rand()? Doesn't this frustrate somebody who
> runs the same "git log" in two terminals in order to view an
> overly tall graph, expecting both commands that were started with
> the same set of arguments to paint the same line in the same
> color?
No we probably don't need rand(). The thinking was.. now that we have
a lot more colors to choose from, let's add some randomness, maybe
it'll reduce the chance of showing the same colors in the same line.
There was another concern with a fixed number of steps too, that we
could get into a stable jump sequence and never use all the colors
(e.g. step 3 with 6 colors total, to simplify). But I verify that
we'll use all the colors (at least until we allow people to customize
step and the number colors)
--
Duy
^ permalink raw reply
* Re: [PATCH] winansi_isatty(): fix when Git is used from CMD
From: Johannes Schindelin @ 2016-12-22 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Pranit Bauva
In-Reply-To: <xmqqlgv9i04z.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Wed, 21 Dec 2016, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I prepared a patch series based on `pu`, on top of Hannes' patch, and
> > I also prepared a branch that is based on `master`, obviously without
> > Hannes' patch.
>
> I think the latter is what you have at
>
> $ git fetch https://github.com/dscho/git mingw-isatty-fixup-master
Correct.
> If that is correct, I am inclined to fetch that and queue it on 'pu',
> replacing Hannes's patch, and then to ask him to Test/Ack it.
Okay, I will prepare v2 based on master and addressing your feedback.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
From: Michael Haggerty @ 2016-12-22 8:15 UTC (permalink / raw)
To: Marc Branchaud, Paul Mackerras; +Cc: git
In-Reply-To: <bfbd5992-da30-b1f0-59e5-a2f36d2e3062@xiplink.com>
On 12/21/2016 08:07 PM, Marc Branchaud wrote:
> On 2016-12-20 07:05 PM, Michael Haggerty wrote:
>> On 12/20/2016 04:01 PM, Marc Branchaud wrote:
>>> [...]
>>> Please don't change the remotebgcolor default.
>>>
>>> Also, perhaps the default remoterefbgcolor should be
>>> set remoterefbgcolor $headbgcolor
>>> ?
>>>
>>> I say this because when I applied the series, without the last patch, I
>>> was miffed that the remote/ref colour had changed.
>>
>> This is a one-time inconvenience that gitk developers will experience. I
>> doubt that users jump backwards and forwards in gitk versions very often.
>
> In what way do you mean it's restricted to gitk developers?
Maybe I misunderstood your objection.
While developing this, I realized that the very first time your run gitk
(i.e., when you don't already have a configuration file), it writes the
then-current default colors into your configuration file. If you later
switch gitk versions to a version with different default colors, the
colors from the first-run version are preserved (unless the names of the
variables used to hold the colors are changed).
So if you would run the tip version of my branch first, then the parent
of that version, you would continue to see the colors as modified by the
final commit. If you then switch to the master version, the remote
branch names go back to green (because it goes back to using
`headbgcolor` again), but the remote prefix stays light brown. I thought
you were unhappy about some form of this unexpected persistence problem.
But this problem will mostly be experienced by gitk developers who jump
back and forth between versions.
A normal user probably mostly moves forward through version numbers, and
only occasionally. Such a user, jumping from master to the tip of my
branch (assuming they haven't customized anything), would see
* local branches stay lime
* remote branch prefixes stay pale orange (they don't change to light
brown because the pale orange color from master is stored in their
configuration file)
* remote branch names change from lime to brown (because the
`remoterefbgcolor` configuration setting didn't exist before)
> Patch 12 introduces remoterefbgcolor, with a specific default value.
> Prior to that, the "ref part" of remote refs was rendered with
> headbgcolor. Users who changed their headbgcolor are used to seeing the
> "ref part" of remote refs in the same color as their local heads.
> Applying patch 12 changes the "ref part" color of remote refs, for such
> users.
>
> All I'm saying is that make the remoterefbgcolor default be $headbgcolor
> avoids this.
For somebody who thinks that most people will want local and
remote-tracking branch names to be rendered in the same color, your
suggestion would be an improvement.
But for somebody like me who thinks it is a good idea to render
remote-tracking branch names in a different color than local branch
names, this is a feature, not a bug. Even a user who explicitly
configured `headbgcolor` to, say, purple, wasn't necessarily expressing
a wish to have remote-tracking branch names rendered in purple. Until
now they had no choice to set these colors separately!
So even for somebody who configured this setting before, I think that
having the remote-tracking branch names change color when the user
upgrades to this version is a good thing, because it lets the user know
that these two things can now be colored independently. If they don't
like the new default brown color, such a user knows where to change it
(even to make it agree with `headbgcolor` if they want that).
But I understand that this is a matter of personal preference. I have
but one "vote" :-)
Michael
^ permalink raw reply
* Re: config for `format-patch --notes`?
From: Norbert Kiesel @ 2016-12-22 7:08 UTC (permalink / raw)
To: johan; +Cc: git, nkiesel
Thanks for the reply. I did not knew that branch descriptions
automatically make it in the cover letter.
Learned something new!
Unfortunately this would still mean I have to manually add the branch
name to the branch description.
I will try to create a patch for adding a config option for the
--notes command line option over the upcoming
free days.
^ permalink raw reply
* Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows
From: Johannes Sixt @ 2016-12-22 6:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Klaus Ethgen, git
In-Reply-To: <20161221224222.6fn6irefmd6li6oa@sigill.intra.peff.net>
Am 21.12.2016 um 23:42 schrieb Jeff King:
> On Wed, Dec 21, 2016 at 10:33:43PM +0100, Johannes Sixt wrote:
>
>> Protect a recently added test case with !MINGW.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> ---
>> I don't remember why I did not notice this failure sooner.
>> Perhaps I did, but then ran out of time to debug it...
>>
>> The patch should go on top of jk/quote-env-path-list-component.
>> [...]
>> -test_expect_success 'broken quoting falls back to interpreting raw' '
>> +test_expect_success !MINGW 'broken quoting falls back to interpreting raw' '
>> mv one.git \"one.git &&
>> check_obj \"one.git/objects <<-EOF
>> $one blob
>
> Hmph. I explicitly avoided a colon in the filename so that it would run
> on MINGW. Is a double-quote also not allowed?
It is not allowed; that was my conclusion. But now that you ask, I'll
double-check.
-- Hannes
^ permalink raw reply
* Re: [PATCH bw/realpath-wo-chdir] real_path: canonicalize directory separators in root parts
From: Johannes Sixt @ 2016-12-22 6:07 UTC (permalink / raw)
To: Brandon Williams
Cc: git, sbeller, peff, jacob.keller, gitster, ramsay, tboegi,
pclouds
In-Reply-To: <20161221223304.GA119874@google.com>
Am 21.12.2016 um 23:33 schrieb Brandon Williams:
> On 12/21, Johannes Sixt wrote:
>> +/* copies root part from remaining to resolved, canonicalizing it on the way */
>> +static void get_root_part(struct strbuf *resolved, struct strbuf *remaining)
>> +{
>> + int offset = offset_1st_component(remaining->buf);
>> +
>> + strbuf_reset(resolved);
>> + strbuf_add(resolved, remaining->buf, offset);
>> +#ifdef GIT_WINDOWS_NATIVE
>> + convert_slashes(resolved->buf);
>> +#endif
>
> So then the only extra cononicalization that is happening here is
> converting '\\server\share' to '//server/share'? (or 'c:\' to 'c:/')
Correct. All other directory separators are canonicalized by the primary
function, strbuf_realpath.
-- Hannes
^ permalink raw reply
* builtin difftool parsing issue
From: Paul Sbarra @ 2016-12-22 4:53 UTC (permalink / raw)
To: johannes.schindelin; +Cc: davvid, dennis, git, gitster
Sadly, I haven't been able to figure out how to get the mbox file from
this tread into gmail, but wanted to report a parsing issue I've found
with the builtin difftool.
Original Patch:
https://public-inbox.org/git/ac91e4818cfb5c5af6b5874662dbeb61cde1f69d.1480019834.git.johannes.schindelin@gmx.de/#t
> + *status = *++p;
> + if (!status || p[1])
> + return error("unexpected trailer: '%s'", p);
> + return 0;
The p[1] null check assumes the status is only one character long, but
git-diff's raw output format shows that a numeric value can follow in
the copy-edit and rename-edit cases.
I'm looking forward to seeing the builtin difftool land. I came across it
while investigating adding --submodule=diff (expanding on diff's
recent addition) support and this looks more promising then the perl
script. Hopefully I will make some progress. Any tips/pointers would
be greatly appreciated.
Thanks
^ permalink raw reply
* Re: [PATCH] mailinfo.c: move side-effects outside of assert
From: Jeff King @ 2016-12-22 3:59 UTC (permalink / raw)
To: Kyle J. McKay
Cc: Johannes Schindelin, Jonathan Tan, Junio C Hamano,
Git mailing list
In-Reply-To: <99C4A905-D66B-4609-9E55-06F9BC301C74@gmail.com>
On Wed, Dec 21, 2016 at 07:53:15PM -0800, Kyle J. McKay wrote:
> It seems to me what you are saying is that Git's "assert" calls are
> DIAGNOSTIC and therefore belong in a release build -- well, except for the
> nedmalloc "assert" calls which do not.
Yes, I think that is a good way of thinking about it (modulo that I
really can't say one way or the other about nedmalloc's uses).
There _are_ some DEBUG-type things in Git that are protected by #ifdefs
that default to "off" (grep for DIFF_DEBUG, for instance). I'm actually
of the opinion that debugging code like that should be in all builds and
triggerable at run-time, provided it carries no significant performance
penalty when the run-time switch is not enabled. But I do agree that's a
totally separate question than from your DEBUG/DIAGNOSTIC distinction.
-Peff
^ permalink raw reply
* Re: [PATCH] mailinfo.c: move side-effects outside of assert
From: Kyle J. McKay @ 2016-12-22 3:53 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Jonathan Tan, Junio C Hamano,
Git mailing list
In-Reply-To: <F5001DF2-20C2-4757-997F-9D40BD48E1D9@gmail.com>
On Dec 21, 2016, at 18:21, Kyle J. McKay wrote:
> On Dec 21, 2016, at 07:55, Jeff King wrote:
>
>> On Tue, Dec 20, 2016 at 09:54:15PM -0800, Kyle J. McKay wrote:
>>
>>>> I wasn't aware anybody actually built with NDEBUG at all. You'd
>>>> have to
>>>> explicitly ask for it via CFLAGS, so I assume most people don't.
>>>
>>> Not a good assumption. You know what happens when you assume[1],
>>> right? ;)
>>
>> Kind of. If it's a configuration that nobody[1] in the Git
>> development
>> community intended to support or test, then isn't the person
>> triggering
>> it the one making assumptions?
>
> No, I don't think so. NDEBUG is very clearly specified in POSIX [1].
>
> If NDEBUG is defined then "assert(...)" disappears (and in a nice
> way so as not to precipitate "unused variable" warnings). "N" being
> "No" or "Not" or "Negated" or "bar over the top" + "DEBUG" meaning
> Not DEBUG. So the code that goes away when NDEBUG is defined is
> clearly debug code.
I think there is a useful distinction here that I make that's worth
sharing. Perhaps it's splitting hairs, but I categorize this "extra"
code that we've been discussing ("assert(...)" or "if (!...) die(...)"
or "verify(...)" into two groups:
1) DEBUG code
This is code that developers use when creating new features. Or
helpful code that's needed when stepping through a program with the
debugger to debug a problem. Or even code that's only used by some
kind of external "test". It may be expensive, it may do things that
should never be done in a build for wider consumption (such as write
information to special log files, write special syslog messages
etc.). Often this code is used in combination with a "-g" debug
symbols build and possibly even a "-O0" or "-O1" option.
Code like this has no place in a release executable meant for general
use by an end user.
2) DIAGNOSTIC code
This is near zero overhead code that is intended to be left in a
release build meant for general use and normally sits there not doing
anything and NOT leaching any performance out of the build either.
Its sole purpose in life is to provide a trail of "bread crumbs" if
the executable goes ***BOOM***. These "bread crumbs" should be just
enough when combined with feedback from the unfortunate user who
experienced the meltdown to re-create the issue in a real DEBUG build
and find and fix the problem.
It seems to me what you are saying is that Git's "assert" calls are
DIAGNOSTIC and therefore belong in a release build -- well, except for
the nedmalloc "assert" calls which do not.
What I'm saying is if they are diagnostic and not debug (and I'm not
arguing one way or the other, but you've already indicated they are
near zero overhead which suggests they are indeed diagnostic in
nature), then they do not belong inside an "assert" which can be
disabled with "NDEBUG". I'm arguing that "assert" is not intended for
diagnostic code, but only debug code as used by nedmalloc. Having Git
treat "NDEBUG" one way -- "no, no, do NOT define NDEBUG because that
disables Git diagnostics and I promise you there's no performance
penalty" -- versus nedmalloc -- "yes, yes please DO define NDEBUG
unless you really need our slow debugging code to be present for
debugging purposes" -- just creates needless unnecessary confusion.
--Kyle
^ permalink raw reply
* Re: [PATCH] mailinfo.c: move side-effects outside of assert
From: Jeff King @ 2016-12-22 3:34 UTC (permalink / raw)
To: Kyle J. McKay
Cc: Johannes Schindelin, Jonathan Tan, Junio C Hamano,
Git mailing list
In-Reply-To: <F5001DF2-20C2-4757-997F-9D40BD48E1D9@gmail.com>
On Wed, Dec 21, 2016 at 06:21:37PM -0800, Kyle J. McKay wrote:
> > Kind of. If it's a configuration that nobody[1] in the Git development
> > community intended to support or test, then isn't the person triggering
> > it the one making assumptions?
>
> No, I don't think so. NDEBUG is very clearly specified in POSIX [1].
I know what NDEBUG is, and I know it is widely used in other projects.
My claim is only that I do not think that the use of NDEBUG was
generally considered when people wrote assert() in git. That is
certainly true of me. I don't know about other developers.
> > I think here you are getting into superstition. Is there any single
> > assert() in Git that will actually have an impact on performance?
>
> You have suggested there is and that Git is enabling NDEBUG for exactly that
> reason -- to increase performance:
Sorry if I wasn't clear, but I meant in Git itself, not in the nedmalloc
compat code. I think it's worth considering them separately because the
latter is not part of most Git builds in the first place, and certainly
it is written in a different style, and may have different assumptions
about how people might build it.
I do not know the nedmalloc code well at all. I gave a brief read of the
results of "git grep 'assert('" and it looked like some of its
assertions are more involved than simple comparisons. So I guessed that
perhaps the reason that NDEBUG was added there when the code was
imported is that there is a performance difference there. But that's
just a guess. It may or may not be borne out by measurements.
I'd be surprised if any of the assertions in the rest of git have a
noticeable impact (and I could not detect one by running t/perf).
> > What would be the advantage of that over `if(...) die("BUG: ...")`? It
> > does not require you to write a reason in the die(), but I am not sure
> > that is a good thing.
>
> You have stated that you believe the current "assert" calls in Git
> (excluding nedmalloc) should not magically disappear when NDEBUG is defined.
Well, no, I mostly just said that I do not think there is any point in
defining NDEBUG in the first place, as there is little or no benefit to
removing those asserts from the built product.
> So precluding a more labor intensive approach where all currently existing
> "assert(...)" calls are replaced with an "if (!...) die(...)" combination,
> providing a "verify" macro is a quick way to make that happen. Consider
> this, was the value that Jonathan provided for the "die" string immediately
> obvious to you? It sure wasn't to me. That means that whoever does the
> "assert(...)" -> "if(!...)die" swap out may need to be intimately familiar
> with that particular piece of code or the result will be no better than
> using a "verify" macro.
Sure, if you want to mass-convert them, doing so with a macro similar to
assert is the simplest way. I don't think we are in a huge hurry to do
that conversion though. I'm not complaining that NDEBUG works as
advertised by disabling asserts. I'm just claiming that it's largely
pointless in our code base, and I'd consider die("BUG") to be our
"usual" style. If any change is to be made, it would be to suggest
people prefer die("BUG") as a style guideline for future patches. But I
haven't seen anybody agree (or disagree) with the notion, so I'd
hesitate to impose my style suggestion without more discussion in that
area.
If we _did_ accept that as a style guideline, then we could move over
existing assert() calls over time (either as janitorial projects, or as
people touch the related code). But there's not a pressing need to do it
quickly.
-Peff
^ permalink raw reply
* Re: [PATCH] mailinfo.c: move side-effects outside of assert
From: Kyle J. McKay @ 2016-12-22 2:21 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Jonathan Tan, Junio C Hamano,
Git mailing list
In-Reply-To: <20161221155539.aykcmkuzqvq733ri@sigill.intra.peff.net>
On Dec 21, 2016, at 07:55, Jeff King wrote:
> On Tue, Dec 20, 2016 at 09:54:15PM -0800, Kyle J. McKay wrote:
>
>>> I wasn't aware anybody actually built with NDEBUG at all. You'd
>>> have to
>>> explicitly ask for it via CFLAGS, so I assume most people don't.
>>
>> Not a good assumption. You know what happens when you assume[1],
>> right? ;)
>
> Kind of. If it's a configuration that nobody[1] in the Git development
> community intended to support or test, then isn't the person
> triggering
> it the one making assumptions?
No, I don't think so. NDEBUG is very clearly specified in POSIX [1].
If NDEBUG is defined then "assert(...)" disappears (and in a nice way
so as not to precipitate "unused variable" warnings). "N" being "No"
or "Not" or "Negated" or "bar over the top" + "DEBUG" meaning Not
DEBUG. So the code that goes away when NDEBUG is defined is clearly
debug code.
Considering the wide deployment and use of Git at this point I think
rather the opposite to be true that "Git does Not require DEBUGging
code to be enabled for everyday use." The alternative that it does
suggests it's not ready for prime time and quite clearly that's not
the case.
>> I've been defining NDEBUG whenever I make a release build for quite
>> some
>> time (not just for Git) in order to squeeze every last possible
>> drop of
>> performance out of it.
>
> I think here you are getting into superstition. Is there any single
> assert() in Git that will actually have an impact on performance?
You have suggested there is and that Git is enabling NDEBUG for
exactly that reason -- to increase performance:
>> On Dec 20, 2016, at 08:45, Jeff King wrote:
>>
>>> I do notice that we set NDEBUG for nedmalloc, though if I am
>>> reading the
>>> Makefile right, it is just for compiling those files. It looks like
>>> there are a ton of asserts there that _are_ potentially expensive
>> Perhaps Git should provide a "verify" macro. Works like "assert"
>> except
>> that it doesn't go away when NDEBUG is defined. Being Git-provided
>> it could
>> also use Git's die function. Then Git could do a global replace of
>> assert
>> with verify and institute a no-assert policy.
>
> What would be the advantage of that over `if(...) die("BUG: ...")`? It
> does not require you to write a reason in the die(), but I am not sure
> that is a good thing.
You have stated that you believe the current "assert" calls in Git
(excluding nedmalloc) should not magically disappear when NDEBUG is
defined. So precluding a more labor intensive approach where all
currently existing "assert(...)" calls are replaced with an "if (!...)
die(...)" combination, providing a "verify" macro is a quick way to
make that happen. Consider this, was the value that Jonathan provided
for the "die" string immediately obvious to you? It sure wasn't to
me. That means that whoever does the "assert(...)" -> "if(!...)die"
swap out may need to be intimately familiar with that particular piece
of code or the result will be no better than using a "verify" macro.
I'm just trying to find a quick and easy way to accommodate your
wishes without redefining the semantics of NDEBUG. ;)
--Kyle
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/assert.h.html
^ permalink raw reply
* Re: References to old messages
From: Eric Wong @ 2016-12-22 1:00 UTC (permalink / raw)
To: Stephen & Linda Smith; +Cc: git
In-Reply-To: <2284357.IWoC4bU66L@thunderbird>
Stephen & Linda Smith <ischis2@cox.net> wrote:
> I had been told to reference (i.e. footnote) a gmane URL. With that service
> no longer being being online, what is the preferred method footnoting?
What the others said about Message-IDs and public-inbox :)
If you only have old URLs pointing to gmane and no NNTP access,
you can also search for "gmane:$ARTICLE_NUMBER" via public-inbox
(at least up to messages around this summer):
https://public-inbox.org/git/?q=gmane:12345
https://public-inbox.org/git/_/text/help documents other
search prefixes you can use, too.
^ permalink raw reply
* Re: config for `format-patch --notes`?
From: Johan Herland @ 2016-12-22 0:00 UTC (permalink / raw)
To: Norbert Kiesel; +Cc: Git mailing list
In-Reply-To: <CAM+g_NtsSaiZdy2Pq0gR9AaO6xiNnGSUbj5yd-uW3S80roEGCg@mail.gmail.com>
On Wed, Dec 21, 2016 at 1:18 AM, Norbert Kiesel <nkiesel@gmail.com> wrote:
> Hi,
>
> I use `git format-patch master..myBranch` quite a bit to send patches
> to other developers. I also add notes to the commits
> so that I e.g. remember which patches were emailed to whom. `git log`
> has an option to automatically include the notes in
> the output. However, I can't find such an option for `git
> format-patch`. Am I missing something?
I assume you mean _config_ option here (format-patch has had a --notes
command-line option since v1.8.1). AFAICS, there's no config option
that corresponds to the format-patch --notes command-line option.
You can easily alias or script your way around this, e.g.:
git config alias.fp 'format-patch --notes'
This creates a 'git fp' command that does what you want, I believe.
Alternatively, if you need more control/automation of the resulting
patches, you can write a script to edit the output files from
format-patch. Currently, I don't believe there is any format-patch
hook available to automatically trigger such a script, but, again,
that can be achieved with an alias.
If you believe a config option would be a useful addition for more
users than yourself, I am sure the community welcomes patches adding
a format.notes config option.
> Another nice option would to to somehow include the branch name in the
> resulting output. Right now I use either notes
> or abuse the `--subject` option for this.
From git-config(1):
branch.<name>.description
Branch description, can be edited with git branch
--edit-description. Branch description is automatically added
in the format-patch cover letter or request-pull summary.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* What's cooking in git.git (Dec 2016, #06; Wed, 21)
From: Junio C Hamano @ 2016-12-21 23:25 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
--------------------------------------------------
[Graduated to "master"]
* jk/index-pack-wo-repo-from-stdin (2016-12-16) 4 commits
(merged to 'next' on 2016-12-19 at 9a88221347)
+ index-pack: skip collision check when not in repository
+ t: use nongit() function where applicable
+ index-pack: complain when --stdin is used outside of a repo
+ t5000: extract nongit function to test-lib-functions.sh
"git index-pack --stdin" needs an access to an existing repository,
but "git index-pack file.pack" to generate an .idx file that
corresponds to a packfile does not.
* jk/parseopt-usage-msg-opt (2016-12-14) 1 commit
(merged to 'next' on 2016-12-19 at c488c7c6e1)
+ parse-options: print "fatal:" before usage_msg_opt()
The function usage_msg_opt() has been updated to say "fatal:"
before the custom message programs give, when they want to die
with a message about wrong command line options followed by the
standard usage string.
* jk/quote-env-path-list-component (2016-12-21) 5 commits
(merged to 'next' on 2016-12-21 at 729971d31e)
+ t5615-alternate-env: double-quotes in file names do not work on Windows
(merged to 'next' on 2016-12-16 at d2cd6008b9)
+ t5547-push-quarantine: run the path separator test on Windows, too
+ tmp-objdir: quote paths we add to alternates
+ alternates: accept double-quoted paths
+ Merge branch 'jk/alt-odb-cleanup' into jk/quote-env-path-list-component
A recent update to receive-pack to make it easier to drop garbage
objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot
have a pathname with a colon in it (no surprise!), and this in turn
made it impossible to push into a repository at such a path. This
has been fixed by introducing a quoting mechanism used when
appending such a path to the colon-separated list.
* jt/mailinfo-fold-in-body-headers (2016-12-20) 1 commit
(merged to 'next' on 2016-12-20 at ec9ae616aa)
+ mailinfo.c: move side-effects outside of assert
Fix for NDEBUG builds.
* nd/shallow-fixup (2016-12-07) 6 commits
(merged to 'next' on 2016-12-13 at 1a3edb8bce)
+ shallow.c: remove useless code
+ shallow.c: bit manipulation tweaks
+ shallow.c: avoid theoretical pointer wrap-around
+ shallow.c: make paint_alloc slightly more robust
+ shallow.c: stop abusing COMMIT_SLAB_SIZE for paint_info's memory pools
+ shallow.c: rename fields in paint_info to better express their purposes
Code cleanup in shallow boundary computation.
* sb/sequencer-abort-safety (2016-12-14) 6 commits
(merged to 'next' on 2016-12-16 at ec71fb1217)
+ Revert "sequencer: remove useless get_dir() function"
(merged to 'next' on 2016-12-13 at 6107e43d65)
+ sequencer: remove useless get_dir() function
+ sequencer: make sequencer abort safer
+ t3510: test that cherry-pick --abort does not unsafely change HEAD
+ am: change safe_to_abort()'s not rewinding error into a warning
+ am: fix filename in safe_to_abort() error message
Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back
to where cherry-pick started while picking multiple changes, when
the cherry-pick stopped to ask for help from the user, and the user
did "git reset --hard" to a different commit in order to re-attempt
the operation.
* vs/submodule-clone-nested-submodules-alternates (2016-12-12) 1 commit
(merged to 'next' on 2016-12-13 at 8a317ab745)
+ submodule--helper: set alternateLocation for cloned submodules
"git clone --reference $there --recurse-submodules $super" has been
taught to guess repositories usable as references for submodules of
$super that are embedded in $there while making a clone of the
superproject borrow objects from $there; extend the mechanism to
also allow submodules of these submodules to borrow repositories
embedded in these clones of the submodules embedded in the clone of
the superproject.
--------------------------------------------------
[New Topics]
* bw/push-submodule-only (2016-12-20) 3 commits
- push: add option to push only submodules
- submodules: add RECURSE_SUBMODULES_ONLY value
- transport: reformat flag #defines to be more readable
"git submodule push" learned "--recurse-submodules=only option to
push submodules out without pushing the top-level superproject.
* mk/mingw-winansi-ttyname-termination-fix (2016-12-20) 1 commit
(merged to 'next' on 2016-12-21 at 1e8e994605)
+ mingw: consider that UNICODE_STRING::Length counts bytes
A potential but unlikely buffer overflow in Windows port has been
fixed.
Will merge to 'master'.
* nd/config-misc-fixes (2016-12-20) 4 commits
- SQUASH???
- config.c: handle lock file in error case in git_config_rename_...
- config.c: rename label unlock_and_out
- config.c: handle error case for fstat() calls
Leakage of lockfiles in the config subsystem has been fixed.
* va/i18n-even-more (2016-12-20) 1 commit
- i18n: fix misconversion in shell scripts
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
"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]
* gv/p4-multi-path-commit-fix (2016-12-19) 1 commit
(merged to 'next' on 2016-12-21 at f7ba714387)
+ git-p4: fix multi-path changelist empty commits
"git p4" that tracks multile p4 paths imported a single changelist
that touches files in these multiple paths as one commit, followed
by many empty commits. This has been fixed.
Will merge to 'master'.
* js/mingw-isatty (2016-12-21) 2 commits
- mingw: replace isatty() hack
- mingw: adjust is_console() to work with stdin
Update the isatty() emulation for Windows by updating the previous
hack that depended on internals of (older) MSVC runtime.
Waiting for review to conclude.
* ls/p4-lfs (2016-12-20) 1 commit
- git-p4: add diff/merge properties to .gitattributes for GitLFS files
Update GitLFS integration with "git p4".
Will merge to 'next'.
* ls/p4-path-encoding (2016-12-18) 1 commit
- git-p4: fix git-p4.pathEncoding for removed files
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
Waiting for review to conclude.
* mh/fast-import-notes-fix-new (2016-12-20) 1 commit
- fast-import: properly fanout notes when tree is imported
"git fast-import" sometimes mishandled while rebalancing notes
tree, which has been fixed.
Will merge to 'next'.
* bw/pathspec-cleanup (2016-12-14) 16 commits
- pathspec: rename prefix_pathspec to init_pathspec_item
- pathspec: small readability changes
- pathspec: create strip submodule slash helpers
- pathspec: create parse_element_magic helper
- pathspec: create parse_long_magic function
- pathspec: create parse_short_magic function
- pathspec: factor global magic into its own function
- pathspec: simpler logic to prefix original pathspec elements
- pathspec: always show mnemonic and name in unsupported_magic
- pathspec: remove unused variable from unsupported_magic
- pathspec: copy and free owned memory
- pathspec: remove the deprecated get_pathspec function
- ls-tree: convert show_recursive to use the pathspec struct interface
- dir: convert fill_directory to use the pathspec struct interface
- dir: remove struct path_simplify
- mv: remove use of deprecated 'get_pathspec()'
Code clean-up in the pathspec API.
Waiting for the (hopefully) final round of review before 'next'.
* cp/merge-continue (2016-12-15) 4 commits
(merged to 'next' on 2016-12-19 at 8ba0094f45)
+ merge: mark usage error strings for translation
+ merge: ensure '--abort' option takes no arguments
+ completion: add --continue option for merge
+ merge: add '--continue' option as a synonym for 'git commit'
"git merge --continue" has been added as a synonym to "git commit"
to conclude a merge that has stopped due to conflicts.
Will merge to 'master'.
* ld/p4-compare-dir-vs-symlink (2016-12-18) 1 commit
(merged to 'next' on 2016-12-20 at f58fed9ef8)
+ git-p4: avoid crash adding symlinked directory
"git p4" misbehaved when swapping a directory and a symbolic link.
Will merge to 'master'.
* js/prepare-sequencer-more (2016-12-14) 34 commits
- sequencer (rebase -i): write out the final message
- sequencer (rebase -i): write the progress into files
- sequencer (rebase -i): show the progress
- sequencer (rebase -i): suggest --edit-todo upon unknown command
- sequencer (rebase -i): show only failed cherry-picks' output
- sequencer (rebase -i): show only failed `git commit`'s output
- run_command_opt(): optionally hide stderr when the command succeeds
- sequencer (rebase -i): differentiate between comments and 'noop'
- sequencer (rebase -i): implement the 'drop' command
- sequencer (rebase -i): allow rescheduling commands
- sequencer (rebase -i): respect strategy/strategy_opts settings
- sequencer (rebase -i): respect the rebase.autostash setting
- sequencer (rebase -i): run the post-rewrite hook, if needed
- sequencer (rebase -i): record interrupted commits in rewritten, too
- sequencer (rebase -i): copy commit notes at end
- sequencer (rebase -i): set the reflog message consistently
- sequencer (rebase -i): refactor setting the reflog message
- sequencer (rebase -i): allow fast-forwarding for edit/reword
- sequencer (rebase -i): implement the 'reword' command
- sequencer (rebase -i): leave a patch upon error
- sequencer (rebase -i): update refs after a successful rebase
- sequencer (rebase -i): the todo can be empty when continuing
- sequencer (rebase -i): skip some revert/cherry-pick specific code path
- sequencer (rebase -i): remove CHERRY_PICK_HEAD when no longer needed
- sequencer (rebase -i): allow continuing with staged changes
- sequencer (rebase -i): write an author-script file
- sequencer (rebase -i): implement the short commands
- sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
- sequencer (rebase -i): write the 'done' file
- sequencer (rebase -i): learn about the 'verbose' mode
- sequencer (rebase -i): implement the 'exec' command
- sequencer (rebase -i): implement the 'edit' command
- sequencer (rebase -i): implement the 'noop' command
- sequencer: support a new action: 'interactive rebase'
The sequencer has further been extended in preparation to act as a
back-end for "rebase -i".
Waiting for review to conclude.
* lt/shortlog-by-committer (2016-12-20) 3 commits
(merged to 'next' on 2016-12-21 at c72e6e7f76)
+ t4201: make tests work with and without the MINGW prerequiste
(merged to 'next' on 2016-12-19 at 555976fc0a)
+ shortlog: test and document --committer option
+ shortlog: group by committer information
"git shortlog" learned "--committer" option to group commits by
committer, instead of author.
* bw/realpath-wo-chdir (2016-12-12) 4 commits
- real_path: have callers use real_pathdup and strbuf_realpath
- real_path: create real_pathdup
- real_path: convert real_path_internal to strbuf_realpath
- real_path: resolve symlinks by hand
(this branch is used by bw/grep-recurse-submodules.)
The implementation of "real_path()" was to go there with chdir(2)
and call getcwd(3), but this obviously wouldn't be usable in a
threaded environment. Rewrite it to manually resolve relative
paths including symbolic links in path components.
Will wait for an issue on Windows to be resolved.
cf. <097e3e2e-f46d-b0aa-be9c-68c274c5e3dc@kdbg.org>
* jk/difftool-in-subdir (2016-12-11) 4 commits
(merged to 'next' on 2016-12-21 at c1056e014b)
+ difftool: rename variables for consistency
+ difftool: chdir as early as possible
+ difftool: sanitize $workdir as early as possible
+ difftool: fix dir-diff index creation when in a subdirectory
Even though an fix was attempted in Git 2.9.3 days, but running
"git difftool --dir-diff" from a subdirectory never worked. This
has been fixed.
Will merge to 'master'.
* ls/filter-process (2016-12-18) 2 commits
(merged to 'next' on 2016-12-19 at 5ed29656db)
+ t0021: fix flaky test
(merged to 'next' on 2016-12-12 at 8ed1f9eb02)
+ docs: warn about possible '=' in clean/smudge filter process values
Doc update.
Will merge to 'master'.
* 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.
What's the doneness of this topic?
* sb/push-make-submodule-check-the-default (2016-11-29) 2 commits
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ 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.
Will cook in 'next'.
* sb/submodule-embed-gitdir (2016-12-12) 6 commits
(merged to 'next' on 2016-12-21 at e6cdbcf013)
+ submodule: add absorb-git-dir function
+ move connect_work_tree_and_git_dir to dir.h
+ worktree: check if a submodule uses worktrees
+ 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.
Will merge to 'master'.
* bw/grep-recurse-submodules (2016-12-16) 7 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 to determine if a submodule is initialized
- submodules: add helper to determine if a submodule is populated
(this branch uses bw/realpath-wo-chdir.)
"git grep" learns to optionally recurse into submodules.
Will hold until bw/realpath-wo-chdir settles.
* dt/smart-http-detect-server-going-away (2016-11-18) 2 commits
(merged to 'next' on 2016-12-05 at 3ea70d01af)
+ upload-pack: optionally allow fetching any sha1
+ remote-curl: don't hang when a server dies before any output
Originally merged to 'next' on 2016-11-21
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-12-05 at 9a2b5bd1a9)
+ doc: mention transfer data leaks in more places
Originally merged to 'next' on 2016-11-16
Doc update on fetching and pushing.
Will cook in 'next'.
* jc/compression-config (2016-11-15) 1 commit
(merged to 'next' on 2016-12-05 at 323769ca07)
+ compression: unify pack.compression configuration parsing
Originally merged to 'next' on 2016-11-23
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-12-05 at 031ecc1886)
+ git-gc.txt: expand discussion of races with other processes
Originally merged to 'next' on 2016-11-17
Doc update.
Will cook in 'next'.
* kn/ref-filter-branch-list (2016-12-08) 20 commits
- 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 an 'rstrip=<N>' option to atoms which deal with refnames
- ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
- ref-filter: rename the 'strip' option to 'lstrip'
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce 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
- for-each-ref: do not segv with %(HEAD) on an unborn branch
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
What's the doneness of the topic? I recall discussing die vs empty
and also saw a "squash this in when you reroll", but I lost track.
* bw/transport-protocol-policy (2016-12-15) 6 commits
(merged to 'next' on 2016-12-19 at 166168205c)
+ http: respect protocol.*.allow=user for http-alternates
+ transport: add from_user parameter to is_transport_allowed
+ http: create function to get curl allowed protocols
+ transport: add protocol policy config option
+ http: always warn if libcurl version is too old
+ 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 merge to 'master'.
* jt/fetch-no-redundant-tag-fetch-map (2016-11-11) 1 commit
(merged to 'next' on 2016-12-05 at 432f9469a7)
+ fetch: do not redundantly calculate tag refmap
Originally merged to 'next' on 2016-11-16
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-12-05 at 658b8764bf)
+ submodule-config: clarify parsing of null_sha1 element
+ submodule-config: rename commit_sha1 to treeish_name
+ submodule config: inline config_from_{name, path}
Originally merged to 'next' on 2016-11-23
Minor code clean-up.
Will cook in 'next'.
* jc/push-default-explicit (2016-10-31) 2 commits
(merged to 'next' on 2016-12-05 at d63f3777af)
+ push: test pushing ambiguously named branches
+ push: do not use potentially ambiguous default refspec
Originally merged to 'next' on 2016-11-01
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'.
* 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-12-05 at 0c77e39cd5)
+ setup_git_env: avoid blind fall-back to ".git"
Originally merged to 'next' on 2016-10-26
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 to conclude.
* 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.
The parts near the tip about pathspec would need to work better
with bw/pathspec-cleanup topic and has been dropped for now.
* va/i18n-perl-scripts (2016-12-14) 16 commits
(merged to 'next' on 2016-12-19 at ec800aba9f)
+ 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.
Will merge to 'master'.
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-12-05 at fb549caa12)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Originally merged to 'next' on 2016-09-28
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-12-08) 8 commits
- versioncmp: generalize version sort suffix reordering
- squash! versioncmp: use earliest-longest contained suffix to determine sorting order
- versioncmp: use earliest-longest contained suffix to determine sorting order
- versioncmp: cope with common part overlapping with prerelease suffix
- 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 review to conclude.
cf. <20161208142401.1329-1-szeder.dev@gmail.com>
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-12-05 at 041946dae0)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Originally merged to 'next' on 2016-10-11
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: References to old messages
From: Junio C Hamano @ 2016-12-21 23:20 UTC (permalink / raw)
To: Stephen & Linda Smith; +Cc: Git Mailing List
In-Reply-To: <2284357.IWoC4bU66L@thunderbird>
Stephen & Linda Smith <ischis2@cox.net> writes:
> I want to pick up work on a patch that I was working on previously.
>
> I had been told to reference (i.e. footnote) a gmane URL. With that service
> no longer being being online, what is the preferred method footnoting?
>
> sps
The NNTP interface of GMane is still working, so referring to e.g.
$gmane/286483 _could_ identify a message uniquely, but people who do
not usually talk NNTP to GMane won't be able to find the message
with 286483, so it is not very nice.
The same message is referred to like this around here these days:
https://public-inbox.org/git/1455685597-22445-1-git-send-email-ischis2@cox.net/
The point is people know its message id is <14556855...@cox.net> and
refer to other archives with it, even when public-inbox.org is not
available.
^ permalink raw reply
* Re: References to old messages
From: Stefan Beller @ 2016-12-21 23:15 UTC (permalink / raw)
To: Stephen & Linda Smith; +Cc: Git Mailing List
In-Reply-To: <2284357.IWoC4bU66L@thunderbird>
On Wed, Dec 21, 2016 at 3:12 PM, Stephen & Linda Smith <ischis2@cox.net> wrote:
> I want to pick up work on a patch that I was working on previously.
>
> I had been told to reference (i.e. footnote) a gmane URL. With that service
> no longer being being online, what is the preferred method footnoting?
>
> sps
See https://public-inbox.org/git/
^ permalink raw reply
* References to old messages
From: Stephen & Linda Smith @ 2016-12-21 23:12 UTC (permalink / raw)
To: Git Mailing List
I want to pick up work on a patch that I was working on previously.
I had been told to reference (i.e. footnote) a gmane URL. With that service
no longer being being online, what is the preferred method footnoting?
sps
^ permalink raw reply
* Re: [PATCH 4/2] t5615-alternate-env: double-quotes in file names do not work on Windows
From: Jeff King @ 2016-12-21 22:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Klaus Ethgen, git
In-Reply-To: <00b6235d-c1bc-30c2-6539-6c78c4ce9eb0@kdbg.org>
On Wed, Dec 21, 2016 at 10:33:43PM +0100, Johannes Sixt wrote:
> Protect a recently added test case with !MINGW.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> I don't remember why I did not notice this failure sooner.
> Perhaps I did, but then ran out of time to debug it...
>
> The patch should go on top of jk/quote-env-path-list-component.
> [...]
> -test_expect_success 'broken quoting falls back to interpreting raw' '
> +test_expect_success !MINGW 'broken quoting falls back to interpreting raw' '
> mv one.git \"one.git &&
> check_obj \"one.git/objects <<-EOF
> $one blob
Hmph. I explicitly avoided a colon in the filename so that it would run
on MINGW. Is a double-quote also not allowed?
-Peff
^ 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