* Draft of Git Rev News edition 22
From: Christian Couder @ 2016-12-11 22:24 UTC (permalink / raw)
To: git
Cc: Thomas Ferris Nicolaisen, Jakub Narebski, Markus Jansen,
Johannes Schindelin, Junio C Hamano, Jeff King, Michael Haggerty,
David Aguilar, Dun Peal, Stefan Beller, Robert Dailey,
Jacob Keller
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-22.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:
https://github.com/git/git.github.io/issues/208
You can also reply to this email.
I tried to cc everyone who appears in this edition but maybe I missed
some people, sorry about that.
Thomas, Jakub, Markus (who is now part of the team, welcome Markus!)
and myself plan to publish this edition on Wednesday December 14.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 0/1] Fix a long-standing isatty() problem on Windows
From: Junio C Hamano @ 2016-12-11 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Pranit Bauva
In-Reply-To: <cover.1481454992.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> I finally got a chance to debug the problems with the ever-timing-out
> test runs of `pu` on Windows. Turns out that pb/bisect uncovered a
> really old, really bad bug: on Windows, isatty() does not do what Git
> expects, at least not completely: it detects interactive terminals *and
> character devices*.
Sounds as if somebody who did Windows at Microsoft had a good sense
of humor to mimick the misnamed ENOTTY gotcha ;-)
This is a great find, and a very impactful fix, as redirecting from
/dev/null is how we try to force a "go interactive if talking to
tty" program to realize that it is not talking to a tty.
Thanks.
^ permalink raw reply
* Re: [BUG] Colon in remote urls
From: Philip Oakley @ 2016-12-11 14:51 UTC (permalink / raw)
To: Klaus Ethgen, git
In-Reply-To: <20161211110208.642unp7c2i653sav@ikki.ethgen.ch>
From: "Klaus Ethgen" <Klaus@Ethgen.ch>
To: <git@vger.kernel.org>
> Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:
>> On Sat, 10 Dec 2016, Klaus Ethgen wrote:
>> > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:
>> > > There are too many systems out there that use a backslash in path
>> > > names. I
>> > > don't think it is wise to use it also as the quoting character.
>> > Well, the minority, I believe. And only the minority where the command
>> > line git is used anywhere.
>>
>> Please provide evidence for such bold assumptions.
>
> How is it "bold" to see that the majority of widows users does not use
> or even like command line tools. And as git is command line tool (most
> of them), users does use third party tools instead of the original.
>
> I know companies where the "developers" doesn't even know of the
> existent of a git command line use. They look with owe when they see
> that I use a shell to use git.
>
Hasn't this drifted a little off topic. The issue was typeable characters in
URLs and how that affects the accessibility of various paths.
We (Git) should be avoiding lock-in to particular systems where possible.
--
Philip
^ permalink raw reply
* Re: [PATCH 4/4] doc: omit needless "for"
From: Philip Oakley @ 2016-12-11 14:08 UTC (permalink / raw)
To: Kristoffer Haugsbakk, Git List; +Cc: Kristoffer Haugsbakk
In-Reply-To: <2645548666054ED5BD30436E9DA41C14@PhilipOakley>
From: "Philip Oakley" <philipoakley@iee.org>
>> diff --git a/Documentation/gitcore-tutorial.txt
>> b/Documentation/gitcore-tutorial.txt
>> index 72ca9c1ef..22309cfb4 100644
>> --- a/Documentation/gitcore-tutorial.txt
>> +++ b/Documentation/gitcore-tutorial.txt
>> @@ -25,7 +25,7 @@ you want to understand Git's internals.
>> The core Git is often called "plumbing", with the prettier user
>
> If we are tidying up here, then perhaps
> s/core Git is often/Git commands are often/
> to better clarify what aspects are plumbing / porcelain.
>
accidentally dropped a word. Should have said
s/core Git is often/core Git commands are often/
^ permalink raw reply
* Re: [BUG] git crash for git remote update tip tip
From: Jiri Olsa @ 2016-12-11 13:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161211125116.xsabnud5tfwadndt@sigill.intra.peff.net>
On Sun, Dec 11, 2016 at 07:51:16AM -0500, Jeff King wrote:
> On Sun, Dec 11, 2016 at 01:17:44PM +0100, Jiri Olsa wrote:
>
> > I accidentaly added 2 remotes and git remote update
> > crashed, see the attached output.
> >
> > [jolsa@krava perf]$ git --version
> > git version 2.7.4
>
> This is fixed already by b7410f616 (builtin/fetch.c: don't free
> remote->name after fetch, 2016-06-14), which is in v2.9.1.
ugh, time to update my fedora ;-)
thanks,
jirka
^ permalink raw reply
* Re: [PATCH 4/4] doc: omit needless "for"
From: Philip Oakley @ 2016-12-11 13:04 UTC (permalink / raw)
To: Kristoffer Haugsbakk, Git List; +Cc: Kristoffer Haugsbakk
In-Reply-To: <20161209155112.2112-5-kristoffer.haugsbakk@gmail.com>
From: "Kristoffer Haugsbakk" <kristoffer.haugsbakk@gmail.com>
Sent: Friday, December 09, 2016 3:51 PM
> What was intended was perhaps "... plumbing does for you" ("you" added),
> but
> simply omitting the word "for" is more terse and gets the intended point
> across
> just as well, if not more so.
After some thought, I think the original is more 'right'.
Without the 'for' it suggests that understanding individual plumbing
commands would explain some issue being seen with a fancy porcelain command
which they probably don't. Rather the 'for' is forward looking toward using
the plumbing commands as tools to investigate and then re-plumb the
aestehetics to the desired output.
The whole porcelain euphemism makes for some awkward phrasing.
>
> I originally went with the approach of writing "for you", but Junio C
> Hamano suggested this approach instead.
>
> Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com>
> ---
>
> Notes (kristoffers):
> The original patch was sent to the mailing list on 2016-11-04, and
> Junio
> replied with his suggested correction on 2016-11-10; see the cover
> letter.
>
> Documentation/gitcore-tutorial.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitcore-tutorial.txt
> b/Documentation/gitcore-tutorial.txt
> index 72ca9c1ef..22309cfb4 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -25,7 +25,7 @@ you want to understand Git's internals.
> The core Git is often called "plumbing", with the prettier user
If we are tidying up here, then perhaps
s/core Git is often/Git commands are often/
to better clarify what aspects are plumbing / porcelain.
> interfaces on top of it called "porcelain". You may not want to use the
> plumbing directly very often, but it can be good to know what the
> -plumbing does for when the porcelain isn't flushing.
> +plumbing does when the porcelain isn't flushing.
I'm not so sure that the direct allusion to 'flushing' is exactly the right
tone. Part of the issue is the 'porcelain' is the initial euphemism. The
other part is that both porcelain and plumbing commands have the same level
of CLI un-prettiness, so the distinction isn't there.
In the end I strung together:
"
The core Git commands are often called "plumbing",
while those with the prettier user friendly
output are called "porcelain".
You may not want to use the plumbing directly very often,
but it can be good to know what the plumbing does
when either the porcelain isn't flushing, or different output aethetics are
desired.
"
Though having both prettier and friendly in the same phrase maybe overkill.
>
> Back when this document was originally written, many porcelain
> commands were shell scripts. For simplicity, it still uses them as
> --
> 2.11.0
>
--
Philip
^ permalink raw reply
* Re: git add -p with new file
From: Jeff King @ 2016-12-11 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ariel, git
In-Reply-To: <xmqq37hvphji.fsf@gitster.mtv.corp.google.com>
On Sat, Dec 10, 2016 at 02:04:33PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:
> > ...
> >> But it doesn't have to be that way. You could make add -p identical to add
> >> without options, except the -p prompts to review diffs first.
> >
> > The question is whether you would annoy people using "-p" if you started
> > including untracked files by default. I agree because it's inherently an
> > interactive process that we can be looser with backwards compatibility.
>
> It might be interactive, but it will be irritating that we suddenly
> have to see hundreds of lines in an untracked file before we are
> asked to say "no I do not want to add this file" and have to do so
> for all the untracked files that happen to match the given pathspec.
>
> It might make it less irritating if one of the interactive choices
> offered in the first prompt were N that tells the command: "No,
> ignore all the untracked paths", though. I dunno.
Yeah, I agree dumping the contents automatically is annoying. Ariel
suggested asking twice about each path, which sounds clunky to me. I'd
probably give a simple question, with an option to dump the contents.
Like:
$ echo foo >untracked
$ git add -p
New file: untracked
Stage this file [y,n,v,q,a,d,/,e,?]? v <-- user types 'v' for "view"
diff --git a/untracked b/untracked
index e69de29..257cc56 100644
--- a/untracked
+++ b/untracked
@@ -0,0 +1 @@
+foo
Stage this file [y,n,v,q,a,d,/,e?]? y
Alternatively, "v" could just run "$GIT_PAGER <file>". The point is to
refresh your memory on what is in it before making a decision.
I'd also probably add interactive.showUntracked to make the whole thing
optional (but I think it would be OK to default it to on).
Some thought would have to be given handling binary files, as we
wouldn't want to dump their contents (but maybe showing them in a pager
would be OK).. We skip them entirely right now. So a related feature may
be asking "Stage this file" for binary files, with an option to somehow
view the contents.
I don't have plans to work on any of this myself. Just dumping thoughts
on what I'd expect an implementation to deal with.
-Peff
^ permalink raw reply
* Re: [BUG] git crash for git remote update tip tip
From: Jeff King @ 2016-12-11 12:51 UTC (permalink / raw)
To: Jiri Olsa; +Cc: git
In-Reply-To: <20161211121744.GA1973@krava>
On Sun, Dec 11, 2016 at 01:17:44PM +0100, Jiri Olsa wrote:
> I accidentaly added 2 remotes and git remote update
> crashed, see the attached output.
>
> [jolsa@krava perf]$ git --version
> git version 2.7.4
This is fixed already by b7410f616 (builtin/fetch.c: don't free
remote->name after fetch, 2016-06-14), which is in v2.9.1.
-Peff
^ permalink raw reply
* [BUG] git crash for git remote update tip tip
From: Jiri Olsa @ 2016-12-11 12:17 UTC (permalink / raw)
To: git
hi,
I accidentaly added 2 remotes and git remote update
crashed, see the attached output.
[jolsa@krava perf]$ git --version
git version 2.7.4
thanks,
jirka
[jolsa@krava perf]$ git remote update tip tip
Fetching tip
Fetching tip
*** Error in `git': double free or corruption (fasttop): 0x000055afef92c560 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7570b)[0x7f1ff79b170b]
/lib64/libc.so.6(+0x7deaa)[0x7f1ff79b9eaa]
/lib64/libc.so.6(cfree+0x4c)[0x7f1ff79bd40c]
git(+0x13aa30)[0x55afed553a30]
git(+0x44936)[0x55afed45d936]
git(+0x1189f)[0x55afed42a89f]
git(+0x10970)[0x55afed429970]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f1ff795c731]
git(+0x10e59)[0x55afed429e59]
======= Memory map: ========
55afed419000-55afed5ed000 r-xp 00000000 fd:01 1321939 /usr/libexec/git-core/git
55afed7ec000-55afed7f0000 r--p 001d3000 fd:01 1321939 /usr/libexec/git-core/git
55afed7f0000-55afed7f8000 rw-p 001d7000 fd:01 1321939 /usr/libexec/git-core/git
55afed7f8000-55afed824000 rw-p 00000000 00:00 0
55afef106000-55afef946000 rw-p 00000000 00:00 0 [heap]
7f1fec000000-7f1fec021000 rw-p 00000000 00:00 0
7f1fec021000-7f1ff0000000 ---p 00000000 00:00 0
7f1ff0c61000-7f1ff0c77000 r-xp 00000000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0c77000-7f1ff0e76000 ---p 00016000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0e76000-7f1ff0e77000 r--p 00015000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0e77000-7f1ff0e78000 rw-p 00016000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0e78000-7f1ff793c000 r--p 00000000 fd:01 1588307 /usr/lib/locale/locale-archive
7f1ff793c000-7f1ff7af5000 r-xp 00000000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7af5000-7f1ff7cf4000 ---p 001b9000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7cf4000-7f1ff7cf8000 r--p 001b8000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7cf8000-7f1ff7cfa000 rw-p 001bc000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7cfa000-7f1ff7cfe000 rw-p 00000000 00:00 0
7f1ff7cfe000-7f1ff7d05000 r-xp 00000000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7d05000-7f1ff7f04000 ---p 00007000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7f04000-7f1ff7f05000 r--p 00006000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7f05000-7f1ff7f06000 rw-p 00007000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7f06000-7f1ff7f1d000 r-xp 00000000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff7f1d000-7f1ff811c000 ---p 00017000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff811c000-7f1ff811d000 r--p 00016000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff811d000-7f1ff811e000 rw-p 00017000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff811e000-7f1ff8122000 rw-p 00000000 00:00 0
7f1ff8122000-7f1ff8137000 r-xp 00000000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8137000-7f1ff8336000 ---p 00015000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8336000-7f1ff8337000 r--p 00014000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8337000-7f1ff8338000 rw-p 00015000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8338000-7f1ff83aa000 r-xp 00000000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff83aa000-7f1ff85a9000 ---p 00072000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff85a9000-7f1ff85aa000 r--p 00071000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff85aa000-7f1ff85ab000 rw-p 00072000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff85ab000-7f1ff85cf000 r-xp 00000000 fd:01 1311836 /usr/lib64/ld-2.23.so
7f1ff8705000-7f1ff87af000 rw-p 00000000 00:00 0
7f1ff87cc000-7f1ff87ce000 rw-p 00000000 00:00 0
7f1ff87ce000-7f1ff87cf000 r--p 00023000 fd:01 1311836 /usr/lib64/ld-2.23.so
7f1ff87cf000-7f1ff87d0000 rw-p 00024000 fd:01 1311836 /usr/lib64/ld-2.23.so
7f1ff87d0000-7f1ff87d1000 rw-p 00000000 00:00 0
7ffe37593000-7ffe375b4000 rw-p 00000000 00:00 0 [stack]
7ffe375e4000-7ffe375e6000 r--p 00000000 00:00 0 [vvar]
7ffe375e6000-7ffe375e8000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
error: fetch died of signal 6
^ permalink raw reply
* [PATCH 1/1] mingw: intercept isatty() to handle /dev/null as Git expects it
From: Johannes Schindelin @ 2016-12-11 11:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pranit Bauva
In-Reply-To: <cover.1481454992.git.johannes.schindelin@gmx.de>
When Git's source code calls isatty(), it really asks whether the
respective file descriptor is connected to an interactive terminal.
Windows' _isatty() function, however, determines whether the file
descriptor is associated with a character device. And NUL, Windows'
equivalent of /dev/null, is a character device.
Which means that for years, Git mistakenly detected an associated
interactive terminal when being run through the test suite, which
almost always redirects stdin, stdout and stderr to /dev/null.
This bug only became obvious, and painfully so, when the new
bisect--helper entered the `pu` branch and made the automatic build & test
time out because t6030 was waiting for an answer.
For details, see
https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
compat/mingw.h | 3 +++
compat/winansi.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index 034fff9479..3350169555 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -384,6 +384,9 @@ int mingw_raise(int sig);
* ANSI emulation wrappers
*/
+int winansi_isatty(int fd);
+#define isatty winansi_isatty
+
void winansi_init(void);
HANDLE winansi_get_osfhandle(int fd);
diff --git a/compat/winansi.c b/compat/winansi.c
index db4a5b0a37..cb725fb02f 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -7,6 +7,9 @@
#include <wingdi.h>
#include <winreg.h>
+/* In this file, we actually want to use Windows' own isatty(). */
+#undef isatty
+
/*
ANSI codes used by git: m, K
@@ -570,6 +573,36 @@ static void detect_msys_tty(int fd)
#endif
+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;
+}
+
void winansi_init(void)
{
int con1, con2;
--
2.11.0.rc3.windows.1
^ permalink raw reply related
* [PATCH 0/1] Fix a long-standing isatty() problem on Windows
From: Johannes Schindelin @ 2016-12-11 11:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pranit Bauva
I finally got a chance to debug the problems with the ever-timing-out
test runs of `pu` on Windows. Turns out that pb/bisect uncovered a
really old, really bad bug: on Windows, isatty() does not do what Git
expects, at least not completely: it detects interactive terminals *and
character devices*.
Why is this such a big deal?
One such character device is NUL, Windows' equivalent of /dev/null. And
guess what happens when the new tests of the bisect--helper run, with
stdin redirected from /dev/null? Precisely. Git asks "the user" for
reassurance that it may really continue, waiting forever. Or for Ctrl+C.
As we know what Git's source code wants, we have to make extra certain
to test whether isatty() reports success for a Console. The common way
to do this is to run GetConsoleMode() for input file descriptors, and
GetConsoleScreenBufferInfo() for output file descriptors.
One additional note: the new winansi_isatty() function was put into this
particular spot not only because it vaguely makes sense to put
tty-related stuff into compat/winansi.c, but with required future
changes in mind:
The current way in which Git for Windows makes sure that isatty()
returns non-zero for Git Bash (which runs in a terminal emulator called
MinTTY that does *not* have any Windows Console associated with it, and
therefore Windows' _isatty() would actually return 0 if it was not for
our detect_msys_tty() function) is hacky and needs to be fixed properly.
It is hacky because it relies on internals of the MSVC runtime that do
not hold true for the new Universal runtimes, which are used when
compiling with Visual C.
We already have experimental code to future-proof this method, and we
use that already when compiling Git for Windows in Visual Studio.
The place in which winansi_isatty() now lives will hopefully make it
possible to unify the code paths again, so that both GCC and Visual C
use detect_msys_tty() through winansi_isatty().
This will also fix a bug where current Visual C-built Git may misdetect
a reopened stdin to be connected to an interactive terminal.
Johannes Schindelin (1):
mingw: intercept isatty() to handle /dev/null as Git expects it
compat/mingw.h | 3 +++
compat/winansi.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+)
base-commit: 8d7a455ed52e2a96debc080dfc011b6bb00db5d2
Published-As: https://github.com/dscho/git/releases/tag/mingw-isatty-v1
Fetch-It-Via: git fetch https://github.com/dscho/git mingw-isatty-v1
--
2.11.0.rc3.windows.1
^ permalink raw reply
* Re: [BUG] Colon in remote urls
From: Klaus Ethgen @ 2016-12-11 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.20.1612101918040.23160@virtualbox>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:
> On Sat, 10 Dec 2016, Klaus Ethgen wrote:
> > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:
> > > There are too many systems out there that use a backslash in path names. I
> > > don't think it is wise to use it also as the quoting character.
> > Well, the minority, I believe. And only the minority where the command
> > line git is used anywhere.
>
> Please provide evidence for such bold assumptions.
How is it "bold" to see that the majority of widows users does not use
or even like command line tools. And as git is command line tool (most
of them), users does use third party tools instead of the original.
I know companies where the "developers" doesn't even know of the
existent of a git command line use. They look with owe when they see
that I use a shell to use git.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Comment: Charset: ISO-8859-1
iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhNMioACgkQpnwKsYAZ
9qzPygv/ZZr+qW4y/JoTWP6BVu+qDFhean7mHoj5vCSgXwCPzZHSvWIDLdqcrboR
UR7K3oTz9yMaoMRiNq7pu/QBJlwRSJ8ByqSde8mzXOVTqvEC5kvLugU3Ehc1fs0u
ZpoQvXBy0SrpKcuNApMdTFMO9OmCwRNAt2JecCQqyQi6hs6Ws5xTCReOEry00wb/
RdLKOpXwOn5n3ESRAQcqLWhWGs9aUVrfQRCHR2rIYsjx1s/tt+NVWa0hzTnJZt3T
wcQDlGjgeXsu8gJHPNSxAJv5paiNK4JG5x6UUOUuAzmvIYmwd6kEiyNQctTRd0JM
ZCBEYnmZQhHbvrkyKsVvUYJhE9FT0hKMAJO791ZiLCN696EJR4BCOZ9I+7GePFtY
dxb3RNsI9imCXqAHyaguY5tQImzc7P5eQfvH4CdmI9DOmwMUlirvt7pjT94pLFNQ
pxFphD+gd5tUL6QL5fmoUFQVQacQ9Vfs2riTiHerWnBq8P1Hw4KWVYd6ImFo8u3o
aWvUfXFg
=1Yj3
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCHv2] git-p4: support git worktrees
From: Luke Diamand @ 2016-12-11 7:19 UTC (permalink / raw)
To: Git Users
Cc: Vinicius Kursancew, Lars Schneider, Junio C Hamano, Luke Diamand
In-Reply-To: <20161210215734.7468-2-luke@diamand.org>
On 10 December 2016 at 21:57, Luke Diamand <luke@diamand.org> wrote:
> git-p4 would attempt to find the git directory using
> its own specific code, which did not know about git
> worktrees. This caused git operations to fail needlessly.
>
> Rework it to use "git rev-parse --git-dir" instead, which
> knows about worktrees.
Actually this doesn't work as well as the original version. "git
rev-parse --git-dir" won't go and find the ".git" subdirectory. The
previous version would go looking for it, so this would introduce a
regression.
Luke
>
> Signed-off-by: Luke Diamand <luke@diamand.org>
> ---
> git-p4.py | 47 ++++++++++++++++++++++++++---------------------
> t/t9800-git-p4-basic.sh | 20 ++++++++++++++++++++
> 2 files changed, 46 insertions(+), 21 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index fd5ca52..6aa8957 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -49,6 +49,13 @@ defaultLabelRegexp = r'[a-zA-Z0-9_\-.]+$'
> # Grab changes in blocks of this many revisions, unless otherwise requested
> defaultBlockSize = 512
>
> +def gitdir():
> + d = read_pipe("git rev-parse --git-dir").strip()
> + if not d or len(d) == 0:
> + return None
> + else:
> + return d
> +
> def p4_build_cmd(cmd):
> """Build a suitable p4 command line.
>
> @@ -562,12 +569,6 @@ def currentGitBranch():
> else:
> return read_pipe(["git", "name-rev", "HEAD"]).split(" ")[1].strip()
>
> -def isValidGitDir(path):
> - if (os.path.exists(path + "/HEAD")
> - and os.path.exists(path + "/refs") and os.path.exists(path + "/objects")):
> - return True;
> - return False
> -
> def parseRevision(ref):
> return read_pipe("git rev-parse %s" % ref).strip()
>
> @@ -3462,7 +3463,7 @@ class P4Sync(Command, P4UserMap):
> if self.tempBranches != []:
> for branch in self.tempBranches:
> read_pipe("git update-ref -d %s" % branch)
> - os.rmdir(os.path.join(os.environ.get("GIT_DIR", ".git"), self.tempBranchLocation))
> + os.rmdir(os.path.join(gitdir(), self.tempBranchLocation))
>
> # Create a symbolic ref p4/HEAD pointing to p4/<branch> to allow
> # a convenient shortcut refname "p4".
> @@ -3678,23 +3679,27 @@ def main():
> (cmd, args) = parser.parse_args(sys.argv[2:], cmd);
> global verbose
> verbose = cmd.verbose
> +
> if cmd.needsGit:
> - if cmd.gitdir == None:
> - cmd.gitdir = os.path.abspath(".git")
> - if not isValidGitDir(cmd.gitdir):
> - cmd.gitdir = read_pipe("git rev-parse --git-dir").strip()
> - if os.path.exists(cmd.gitdir):
> - cdup = read_pipe("git rev-parse --show-cdup").strip()
> - if len(cdup) > 0:
> - chdir(cdup);
> -
> - if not isValidGitDir(cmd.gitdir):
> - if isValidGitDir(cmd.gitdir + "/.git"):
> - cmd.gitdir += "/.git"
> - else:
> + if cmd.gitdir:
> + os.environ["GIT_DIR"] = cmd.gitdir
> +
> + # did we get a valid git dir on the command line or via $GIT_DIR?
> + if not gitdir():
> die("fatal: cannot locate git repository at %s" % cmd.gitdir)
>
> - os.environ["GIT_DIR"] = cmd.gitdir
> + else:
> + # already in a git directory?
> + if not gitdir():
> + die("fatal: not in a valid git repository")
> +
> + cdup = read_pipe("git rev-parse --show-cdup").strip()
> + if len(cdup) > 0:
> + chdir(cdup);
> +
> + # ensure subshells spawned in the p4 repo directory
> + # get the correct GIT_DIR
> + os.environ["GIT_DIR"] = os.path.abspath(gitdir())
>
> if not cmd.run(args):
> parser.print_help()
> diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
> index 0730f18..093e9bd 100755
> --- a/t/t9800-git-p4-basic.sh
> +++ b/t/t9800-git-p4-basic.sh
> @@ -257,6 +257,26 @@ test_expect_success 'submit from detached head' '
> )
> '
>
> +test_expect_success 'submit from worktree' '
> + test_when_finished cleanup_git &&
> + git p4 clone --dest="$git" //depot &&
> + (
> + cd "$git" &&
> + git worktree add ../worktree-test
> + ) &&
> + (
> + cd "$git/../worktree-test" &&
> + test_commit "worktree-commit" &&
> + git config git-p4.skipSubmitEdit true &&
> + git p4 submit
> + ) &&
> + (
> + cd "$cli" &&
> + p4 sync &&
> + test_path_is_file worktree-commit.t
> + )
> +'
> +
> test_expect_success 'kill p4d' '
> kill_p4d
> '
> --
> 2.8.2.703.g78b384c.dirty
>
^ permalink raw reply
* [PATCH] git-svn: document useLogAuthor and addAuthorFrom config keys
From: Eric Wong @ 2016-12-11 0:06 UTC (permalink / raw)
To: Juergen Kosel; +Cc: git
In-Reply-To: <6160a58b-5f86-384f-30b5-2a3826019157@gmx.de>
Juergen Kosel <juergen.kosel@gmx.de> wrote:
> Am 05.12.2016 um 23:54 schrieb Eric Wong:
> > So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor
> > config keys work and can be documented?
>
> yes, I can confirm, that adding this configuration keys works with git
> 2.1.4 work.
> I have added the config keys as follows:
>
> git config --add --bool svn.useLogAuthor true
> git config --add --bool svn.addAuthorFrom true
Thanks for testing, patch below.
> > Even better would be for you to provide a patch to the
> > documentation :) Otherwise, I can write one up sometime this week.
>
> My English is not that well. So I prefer, if you update the
> documentation :-)
No problem, my asciidoc is a bit rusty, but I think
the formatted result will be fine.
(Btw, list convention here is to reply-to-all;
it prevents vger from being a single-point-of-failure)
-------8<-------
Subject: [PATCH] git-svn: document useLogAuthor and addAuthorFrom config keys
We've always supported these config keys in git-svn,
so document them so users won't have to respecify them
on every invocation.
Reported-by: Juergen Kosel <juergen.kosel@gmx.de>
Signed-off-by: Eric Wong <e@80x24.org>
---
Documentation/git-svn.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5f9e65b0c..9bee9b0c4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -664,13 +664,19 @@ creating the branch or tag.
When retrieving svn commits into Git (as part of 'fetch', 'rebase', or
'dcommit' operations), look for the first `From:` or `Signed-off-by:` line
in the log message and use that as the author string.
++
+[verse]
+config key: svn.useLogAuthor
+
--add-author-from::
When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit'
operations), if the existing log message doesn't already have a
`From:` or `Signed-off-by:` line, append a `From:` line based on the
Git commit's author string. If you use this, then `--use-log-author`
will retrieve a valid author string for all commits.
-
++
+[verse]
+config key: svn.addAuthorFrom
ADVANCED OPTIONS
----------------
--
EW
^ permalink raw reply related
* Re: [RFC PATCH] send-email: allow a custom hook to prevent sending email
From: Junio C Hamano @ 2016-12-10 22:11 UTC (permalink / raw)
To: Stefan Beller; +Cc: Brandon Williams, Jeff King, git@vger.kernel.org
In-Reply-To: <CAGZ79kZKify7VLfNp3FXXvc4UOGjdXfUaspNaeW0t5+hWc+cpw@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> On Fri, Dec 9, 2016 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> So you are suggesting to
>>> * have the check later in the game (e.g. just after asking
>>> "Send this email? ([y]es|[n]o|[q]uit|[a]ll): " as then other information
>>> such as additional @to @cc are available.
>>
>> Yeah, probably before the loop starts asking that question for each
>> message. And hook does not necessarily need to cause the program to
>> die. The question can be reworded to "Your hook says no, but do you
>> really want to send it?",
>
> You could, but...
Yes, "does not necessarily need to die" is different from "hence you
must avoid dying". Running the hook before you start the loop to
ask for each message merely makes it possible to avoid dying.
^ permalink raw reply
* Re: [PATCH v6 01/16] Git.pm: add subroutines for commenting lines
From: Junio C Hamano @ 2016-12-10 22:09 UTC (permalink / raw)
To: Vasco Almeida
Cc: Johannes Schindelin, git, Jiang Xin,
Ævar Arnfjörð Bjarmason, Jean-Noël AVILA,
Jakub Narębski, David Aguilar
In-Reply-To: <1481364496.1993.14.camel@sapo.pt>
Vasco Almeida <vascomalmeida@sapo.pt> writes:
> I wonder why this is important when Git errors out when
> core.commentChar is set to more than 1 characters or 0 characters.
I think it should be consistent with the way core.commentchar is
treated in the rest of the system, namely this bit from config.c:
if (!strcmp(var, "core.commentchar")) {
if (!value)
return config_error_nonbool(var);
else if (!strcasecmp(value, "auto"))
auto_comment_line_char = 1;
else if (value[0] && !value[1]) {
comment_line_char = value[0];
auto_comment_line_char = 0;
} else
return error("core.commentChar should only be one character");
return 0;
}
And I think I misread this piece of code.
We only update comment_line_char from the default "#" when the
configured value is a single-byte character and we ignore incorrect
values in the configuration file. So I think the patch you sent is
correct after all.
^ permalink raw reply
* Re: git add -p with new file
From: Junio C Hamano @ 2016-12-10 22:04 UTC (permalink / raw)
To: Jeff King; +Cc: Ariel, git
In-Reply-To: <20161210085556.nwg3pbay367jqin5@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:
> ...
>> But it doesn't have to be that way. You could make add -p identical to add
>> without options, except the -p prompts to review diffs first.
>
> The question is whether you would annoy people using "-p" if you started
> including untracked files by default. I agree because it's inherently an
> interactive process that we can be looser with backwards compatibility.
It might be interactive, but it will be irritating that we suddenly
have to see hundreds of lines in an untracked file before we are
asked to say "no I do not want to add this file" and have to do so
for all the untracked files that happen to match the given pathspec.
It might make it less irritating if one of the interactive choices
offered in the first prompt were N that tells the command: "No,
ignore all the untracked paths", though. I dunno.
Also, because "git add -p" (no pathspec) is NOT a no-op, the
similarity Ariel sees with "git add" (no other options) does not
hold. As you kept explaining (but perhaps not successfully being
understood yet), "add -p" works like "add -u", and it will make the
command incoherent if we allowed "git add -p <path>" to add new
paths, exactly because "git add -u <path>" does not do so. Of
course that can be fixed by allowing "git add -u" to also add new
paths that match pathspec.
Of course, Ariel can vote for making "add -p" more like "add" (with
no options) than "add -u". I _think_ it is a better way to solve
the incoherence than making "add -u" to add new paths. But what it
means is that "add -p <paths>" works on both tracked and untracked
paths that match the given pathspec <paths>, and also "add -p" (no
pathspec) must become a no-op (because "add" without option and
pathspec is).
^ permalink raw reply
* [PATCHv2] git-p4: support git worktrees
From: Luke Diamand @ 2016-12-10 21:57 UTC (permalink / raw)
To: git; +Cc: viniciusalexandre, Lars Schneider, Junio C Hamano, Luke Diamand
In-Reply-To: <20161210215734.7468-1-luke@diamand.org>
git-p4 would attempt to find the git directory using
its own specific code, which did not know about git
worktrees. This caused git operations to fail needlessly.
Rework it to use "git rev-parse --git-dir" instead, which
knows about worktrees.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
git-p4.py | 47 ++++++++++++++++++++++++++---------------------
t/t9800-git-p4-basic.sh | 20 ++++++++++++++++++++
2 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index fd5ca52..6aa8957 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -49,6 +49,13 @@ defaultLabelRegexp = r'[a-zA-Z0-9_\-.]+$'
# Grab changes in blocks of this many revisions, unless otherwise requested
defaultBlockSize = 512
+def gitdir():
+ d = read_pipe("git rev-parse --git-dir").strip()
+ if not d or len(d) == 0:
+ return None
+ else:
+ return d
+
def p4_build_cmd(cmd):
"""Build a suitable p4 command line.
@@ -562,12 +569,6 @@ def currentGitBranch():
else:
return read_pipe(["git", "name-rev", "HEAD"]).split(" ")[1].strip()
-def isValidGitDir(path):
- if (os.path.exists(path + "/HEAD")
- and os.path.exists(path + "/refs") and os.path.exists(path + "/objects")):
- return True;
- return False
-
def parseRevision(ref):
return read_pipe("git rev-parse %s" % ref).strip()
@@ -3462,7 +3463,7 @@ class P4Sync(Command, P4UserMap):
if self.tempBranches != []:
for branch in self.tempBranches:
read_pipe("git update-ref -d %s" % branch)
- os.rmdir(os.path.join(os.environ.get("GIT_DIR", ".git"), self.tempBranchLocation))
+ os.rmdir(os.path.join(gitdir(), self.tempBranchLocation))
# Create a symbolic ref p4/HEAD pointing to p4/<branch> to allow
# a convenient shortcut refname "p4".
@@ -3678,23 +3679,27 @@ def main():
(cmd, args) = parser.parse_args(sys.argv[2:], cmd);
global verbose
verbose = cmd.verbose
+
if cmd.needsGit:
- if cmd.gitdir == None:
- cmd.gitdir = os.path.abspath(".git")
- if not isValidGitDir(cmd.gitdir):
- cmd.gitdir = read_pipe("git rev-parse --git-dir").strip()
- if os.path.exists(cmd.gitdir):
- cdup = read_pipe("git rev-parse --show-cdup").strip()
- if len(cdup) > 0:
- chdir(cdup);
-
- if not isValidGitDir(cmd.gitdir):
- if isValidGitDir(cmd.gitdir + "/.git"):
- cmd.gitdir += "/.git"
- else:
+ if cmd.gitdir:
+ os.environ["GIT_DIR"] = cmd.gitdir
+
+ # did we get a valid git dir on the command line or via $GIT_DIR?
+ if not gitdir():
die("fatal: cannot locate git repository at %s" % cmd.gitdir)
- os.environ["GIT_DIR"] = cmd.gitdir
+ else:
+ # already in a git directory?
+ if not gitdir():
+ die("fatal: not in a valid git repository")
+
+ cdup = read_pipe("git rev-parse --show-cdup").strip()
+ if len(cdup) > 0:
+ chdir(cdup);
+
+ # ensure subshells spawned in the p4 repo directory
+ # get the correct GIT_DIR
+ os.environ["GIT_DIR"] = os.path.abspath(gitdir())
if not cmd.run(args):
parser.print_help()
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 0730f18..093e9bd 100755
--- a/t/t9800-git-p4-basic.sh
+++ b/t/t9800-git-p4-basic.sh
@@ -257,6 +257,26 @@ test_expect_success 'submit from detached head' '
)
'
+test_expect_success 'submit from worktree' '
+ test_when_finished cleanup_git &&
+ git p4 clone --dest="$git" //depot &&
+ (
+ cd "$git" &&
+ git worktree add ../worktree-test
+ ) &&
+ (
+ cd "$git/../worktree-test" &&
+ test_commit "worktree-commit" &&
+ git config git-p4.skipSubmitEdit true &&
+ git p4 submit
+ ) &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ test_path_is_file worktree-commit.t
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
2.8.2.703.g78b384c.dirty
^ permalink raw reply related
* [PATCHv2] git-p4 worktree support
From: Luke Diamand @ 2016-12-10 21:57 UTC (permalink / raw)
To: git; +Cc: viniciusalexandre, Lars Schneider, Junio C Hamano, Luke Diamand
Second attempt at teaching git-p4 about worktrees.
Earlier discussion here:
http://marc.info/?l=git&m=148097985622294
Git-p4 exports GIT_DIR so that when it chdirs into the
P4 client area to apply the change, git commands called
from there will work correctly.
Luke Diamand (1):
git-p4: support git worktrees
git-p4.py | 47 ++++++++++++++++++++++++++---------------------
t/t9800-git-p4-basic.sh | 20 ++++++++++++++++++++
2 files changed, 46 insertions(+), 21 deletions(-)
--
2.8.2.703.g78b384c.dirty
^ permalink raw reply
* [PATCH] branch: mark a file-local symbol with static
From: Ramsay Jones @ 2016-12-10 21:46 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Junio C Hamano, GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---
Hi Karthik,
If you need to re-roll your 'kn/ref-filter-branch-list' branch, could
you please squash this into the relevant patch (commit 715a4826ab,
"branch: use ref-filter printing APIs", 07-12-2016).
Thanks!
ATB,
Ramsay Jones
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 2c9aa2b29..4386273ce 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -306,7 +306,7 @@ static int calc_maxwidth(struct ref_array *refs, int remote_bonus)
return max;
}
-const char *quote_literal_for_format(const char *s)
+static const char *quote_literal_for_format(const char *s)
{
struct strbuf buf = STRBUF_INIT;
--
2.11.0
^ permalink raw reply related
* Re: BUG: "cherry-pick A..B || git reset --hard OTHER"
From: Junio C Hamano @ 2016-12-10 21:23 UTC (permalink / raw)
To: Duy Nguyen
Cc: Stephan Beyer, Git Mailing List, Christian Couder,
SZEDER Gábor
In-Reply-To: <CACsJy8Div=Baenn7c-1wxgvrOh5PG=naeDrEYC8gs+AvJE7wZA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> rebase and cherry-pick/revert are not exactly in the same situation.
> When cherry-pick/revert in "continue/abort" mode, there's usually some
> conflicted files and it's easy to notice.
>
> But an interactive rebase could stop at some commit with clean
> worktree (the 'edit' command). Then I could even add some more commits
> on top. I don't see how 'rebase --abort' can know my intention in this
> case, whether I tried (with some new commits) and failed, and want to
> revert/abort the whole thing, moving HEAD back to the original; or
> whether I forgot I was in the middle of rebase and started to do
> something else, and --abort needs to keep HEAD where it is.
OK.
^ permalink raw reply
* Re: [PATCH 3/4] doc: make the intent of sentence clearer
From: Philip Oakley @ 2016-12-10 20:52 UTC (permalink / raw)
To: Kristoffer Haugsbakk, git; +Cc: Kristoffer Haugsbakk
In-Reply-To: <20161209155112.2112-4-kristoffer.haugsbakk@gmail.com>
From: "Kristoffer Haugsbakk" <kristoffer.haugsbakk@gmail.com>
Sent: Friday, December 09, 2016 3:51 PM
> By adding the word "just", which might have been accidentally omitted.
>
> Adding the word "just" makes it clear that the point is to *not* do an
> octopus merge simply because you *can* do it. In other words, you
> should have a reason for doing it beyond simply having two (seemingly)
> independent commits that you need to merge into another branch, since
> it's not always the best approach.
>
> The previous sentence made it look more like it was trying to say that
> you shouldn't do an octopus merge *because* you can do an octopus merge.
> Although this interpretation doesn't make sense and the rest of the
> paragraph makes the intended meaning clear, this adjustment should make
> the intent of the sentence more immediately clear to the reader.
>
> Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com>
> ---
> Documentation/gitcore-tutorial.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitcore-tutorial.txt
> b/Documentation/gitcore-tutorial.txt
> index 72ed90ca3..72ca9c1ef 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -1635,7 +1635,7 @@ $ git show-branch
> ++* [master~2] Pretty-print messages.
> ------------
>
> -Note that you should not do Octopus because you can. An octopus
> +Note that you should not do Octopus just because you can. An octopus
> is a valid thing to do and often makes it easier to view the
> commit history if you are merging more than two independent
> changes at the same time. However, if you have merge conflicts
> --
> 2.11.0
>
Looks like a reasonable emphasis to me
--
Philip (UK)
^ permalink raw reply
* Re: [PATCH 2/4] doc: add verb in front of command to run
From: Philip Oakley @ 2016-12-10 20:48 UTC (permalink / raw)
To: Kristoffer Haugsbakk, git; +Cc: Kristoffer Haugsbakk
In-Reply-To: <20161209155112.2112-3-kristoffer.haugsbakk@gmail.com>
From: "Kristoffer Haugsbakk" <kristoffer.haugsbakk@gmail.com>
Sent: Friday, December 09, 2016 3:51 PM
> Instead of using the command 'git clone' as a verb, use "run" as the
> verb indicating the action of executing the command 'git clone'.
I would expect 'cloning' as the commonly in use verb here, with the command
then quoted.
>
> Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com>
> ---
> Documentation/gitcore-tutorial.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitcore-tutorial.txt
> b/Documentation/gitcore-tutorial.txt
> index 6c434aff3..72ed90ca3 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -1478,7 +1478,7 @@ You can repack this private repository whenever you
> feel like.
> A recommended work cycle for a "subsystem maintainer" who works
> on that project and has an own "public repository" goes like this:
>
> -1. Prepare your work repository, by 'git clone' the public
> +1. Prepare your work repository, by running 'git clone' on the public
Perhaps ?
... by cloning ('git clone <URL>') the public
The full command is shown using the same terminology as the following line.
> repository of the "project lead". The URL used for the
> initial cloning is stored in the remote.origin.url
> configuration variable.
> --
> 2.11.0
>
>
--
Philip
^ permalink raw reply
* Re: [PATCH 1/4] doc: add articles (grammar)
From: Philip Oakley @ 2016-12-10 20:28 UTC (permalink / raw)
To: Kristoffer Haugsbakk, git; +Cc: Kristoffer Haugsbakk
In-Reply-To: <20161209155112.2112-2-kristoffer.haugsbakk@gmail.com>
From: "Kristoffer Haugsbakk" <kristoffer.haugsbakk@gmail.com>
Sent: Friday, December 09, 2016 3:51 PM
> Add definite and indefinite articles in three places where they were
> missing.
>
> - Use "the" in front of a directory name
> - Use "the" in front of "style of cooperation"
> - Use an indefinite article in front of "CVS background"
>
> Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com>
> ---
> Documentation/gitcore-tutorial.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gitcore-tutorial.txt
> b/Documentation/gitcore-tutorial.txt
> index 4546fa0d7..6c434aff3 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -1368,7 +1368,7 @@ $ git repack
> will do it for you. If you followed the tutorial examples, you
> would have accumulated about 17 objects in `.git/objects/??/`
> directories by now. 'git repack' tells you how many objects it
> -packed, and stores the packed file in `.git/objects/pack`
> +packed, and stores the packed file in the `.git/objects/pack`
> directory.
>
> [NOTE]
> @@ -1543,9 +1543,9 @@ like this:
> Working with Others, Shared Repository Style
> --------------------------------------------
>
> -If you are coming from CVS background, the style of cooperation
> +If you are coming from a CVS background, the style of cooperation
> suggested in the previous section may be new to you. You do not
> -have to worry. Git supports "shared public repository" style of
> +have to worry. Git supports the "shared public repository" style of
> cooperation you are probably more familiar with as well.
>
> See linkgit:gitcvs-migration[7] for the details.
> --
> 2.11.0
This looks good to me.
--
Philip (UK)
^ permalink raw reply
* Re: [PATCH v2 4/5] Make sequencer abort safer
From: Stephan Beyer @ 2016-12-10 20:20 UTC (permalink / raw)
To: Jeff King, Christian Couder; +Cc: git, Junio C Hamano, SZEDER Gábor
In-Reply-To: <20161210200437.ijmahia6e6xifhk6@sigill.intra.peff.net>
On 12/10/2016 09:04 PM, Jeff King wrote:
> On Sat, Dec 10, 2016 at 08:56:26PM +0100, Christian Couder wrote:
>
>>> +static int rollback_is_safe(void)
>>> +{
>>> + struct strbuf sb = STRBUF_INIT;
>>> + struct object_id expected_head, actual_head;
>>> +
>>> + if (strbuf_read_file(&sb, git_path_abort_safety_file(), 0) >= 0) {
>>> + strbuf_trim(&sb);
>>> + if (get_oid_hex(sb.buf, &expected_head)) {
>>> + strbuf_release(&sb);
>>> + die(_("could not parse %s"), git_path_abort_safety_file());
>>> + }
>>> + strbuf_release(&sb);
>>> + }
>>
>> Maybe the following is a bit simpler:
>>
>> if (strbuf_read_file(&sb, git_path_abort_safety_file(), 0) >= 0) {
>> int res;
>> strbuf_trim(&sb);
>> res = get_oid_hex(sb.buf, &expected_head);
>> strbuf_release(&sb);
>> if (res)
>> die(_("could not parse %s"), git_path_abort_safety_file());
>> }
>
> Is there any point in calling strbuf_release() if we're about to die
> anyway? I could see it if it were "return error()", but it's normal in
> our code base for die() to be abrupt.
The point is that someone "libifies" the function some day; then "die()"
becomes "return error()" almost automatically. Chances are high that the
resulting memory leak is forgotten. That's one of the reasons why I like
being strict about memory leaks.
However, I cannot tell if mine or Christian's variant is really
"simpler" (with whatever measure) and I also don't care much.
~Stephan
^ 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