n. Update
it now.
Signed-off-by: Elijah Newren
Signed-off-by: Johannes Sixt
---
Documentation/git-rebase.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 41631df6e4..7bea21e8e3 100644
--- a/Documen
Am 05.12.18 um 20:29 schrieb Frank Schäfer:
Am 02.12.18 um 22:22 schrieb Johannes Sixt:
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
With other words:
"If CR comes immediately before a LF, do the following with *all* lines:
after the CR if eol=lf but do not after the CR if
eol=crlf.&q
Am 05.12.18 um 16:37 schrieb Elijah Newren:
On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote:
Johannes Sixt writes:
Please let me deposit my objection. This paragraph is not the right
place to explain what directory renme detection is and how it works
under the hood. "works
Am 05.12.18 um 07:20 schrieb Elijah Newren:
On Tue, Dec 4, 2018 at 7:54 PM Junio C Hamano wrote:
Elijah Newren writes:
Gah, when I was rebasing on your patch I adopted your sentence rewrite
but forgot to remove the "sometimes". Thanks for catching; correction:
-- 8< --
Subject: [PATCH
Am 04.12.18 um 22:24 schrieb Elijah Newren:
+ The am backend sometimes does not because it operates on
+"fake ancestors" that involve trees containing only the files modified
+in the patch. Without accurate tree information, directory rename
+detection cannot safely operate and is thus
Am 03.12.18 um 21:42 schrieb Martin Ågren:
On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
I actually did not test the result, because I don't have the
infrastructure.
I've tested with asciidoc and Asciidoctor, html and man-page. Looks
good.
Thank you so much!
-- Hannes
subsections instead of a list.
Signed-off-by: Johannes Sixt
---
Cf. https://git-scm.com/docs/git-rebase#_behavioral_differences
I actually did not test the result, because I don't have the
infrastructure.
The sentence "The am backend sometimes does not" is not very useful,
but is not
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
This was misspoken a bit. Let's revise it to
When producing a colored output (not limited to whitespace
error coloring of diff output) for contents that are not
marked as
Am 27.11.18 um 00:31 schrieb Junio C Hamano:
Johannes Sixt writes:
Am 26.11.18 um 04:04 schrieb Junio C Hamano:
... this goes too far, IMO. It is the pager's task to decode control
characters.
It was tongue-in-cheek suggestion to split a CR into caret-em on our
end, but we'd get essentially
Am 26.11.18 um 04:04 schrieb Junio C Hamano:
It appears to me that what Frank sees is not "^M highlighted for
whitespace breakage appears only on postimage lines, while ^M is
shown but not highlighted on preimage lines". My reading of the
above is "Not just without highlight, ^M is just *NOT*
Am 25.11.18 um 15:03 schrieb Frank Schäfer:
Am 24.11.18 um 23:07 schrieb Johannes Sixt:
I don't think that there is anything to fix. If you have a file with
CRLF in it, but you did not declare to Git that CRLF is the expected
end-of-line indicator, then the CR *is* trailing whitespace (because
Am 24.11.18 um 15:51 schrieb Frank Schäfer:
Am 23.11.18 um 22:47 schrieb Johannes Sixt:
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending of the removed line
is CR only.
It also always shows up as expected in '+' lines.
Is your
Am 15.11.18 um 12:22 schrieb Johannes Schindelin via GitGitGadget:
From: Johannes Schindelin
The MSDN documentation has been superseded by Microsoft Docs (which is
backed by a repository on GitHub containing many, many files in Markdown
format).
Signed-off-by: Johannes Schindelin
---
Am 07.11.18 um 21:41 schrieb Jeff King:
On Wed, Nov 07, 2018 at 07:52:28PM +0100, Johannes Sixt wrote:
Do I understand correctly, that you use a leading slash as an indicator to
construct a path relative to system_path(). How about a "reserved" user
name? For example,
[htt
Am 07.11.18 um 12:23 schrieb Johannes Schindelin:
On Tue, 6 Nov 2018, Johannes Sixt wrote:
Am 06.11.18 um 15:53 schrieb Johannes Schindelin via GitGitGadget:
Even if a path looks like a POSIX paths, i.e. it starts with a directory
separator, but not with drive-letter-colon, it still has
Am 07.11.18 um 02:32 schrieb Junio C Hamano:
Johannes Sixt writes:
On Linux, when I recompile for a different architecture, CFLAGS would
change, so I would have thought that GIT-CFLAGS were the natural
choice for a dependency. Don't they change in this case on Windows,
too?
Depending on GIT
Am 06.11.18 um 15:55 schrieb Johannes Schindelin via GitGitGadget:
From: Johannes Schindelin
When git.rc is compiled into git.res, the result is actually dependent
on the architecture. That is, you cannot simply link a 32-bit git.res
into a 64-bit git.exe.
Therefore, to allow 32-bit and
Am 06.11.18 um 15:53 schrieb Johannes Schindelin via GitGitGadget:
From: Johannes Schindelin
On Windows, an absolute POSIX path needs to be turned into a Windows
one.
If I were picky, I would say that in a pure Windows application there
cannot be POSIX paths to begin with.
Even if a path
Am 05.11.18 um 08:01 schrieb Johannes Sixt:
Am 05.11.18 um 00:26 schrieb Junio C Hamano:
OK, thanks. It seems that the relative silence after this message
is a sign that the resulting patch after squashing is what everybody
is happey with?
I'm not 100% happy.
I see the patch is already
Am 05.11.18 um 00:26 schrieb Junio C Hamano:
OK, thanks. It seems that the relative silence after this message
is a sign that the resulting patch after squashing is what everybody
is happey with?
I'm not 100% happy. I'll resend a squashed patch, but it has to wait as
I have to catch a train
Am 03.11.18 um 09:14 schrieb Carlo Arenas:
On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
+ timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - elapsed);
nitpick: cast to DWORD instead of int
No; timeout is of type int; after an explicit type cast we don't want to
h
Am 02.11.18 um 15:47 schrieb Steve Hoelzer:
> On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
>>
>> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
>>> @@ -614,7 +618,7 @@ restart:
>>>
>>> if (!rc && orig_timeout &am
Am 01.11.18 um 07:12 schrieb Junio C Hamano:
"Johannes Schindelin via GitGitGadget"
writes:
The `--preserve-merges` mode of the `rebase` command is slated to be
deprecated soon, ...
Is everybody on board on this statement? I vaguely recall that some
people wanted to have something
Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
From: Steve Hoelzer
From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
'GetTickCount64' instead of 'GetTickCount'.
Reason: GetTickCount() overflows roughly every 49 days. Code that does
not take that into account
commands are optional in the FAKE_LINES variable, but
when used, they do end up in the insn sheet. Test them, too.
Signed-off-by: Johannes Sixt
---
v2:
- updated commit message
- patch text is unchanged
t/lib-rebase.sh | 4 ++--
t/t3404-rebase-interactive.sh | 10 +-
2
Am 25.10.18 um 22:54 schrieb Johannes Sixt:
Test each short command at least once. The commands changed here
are chosen such that
- tests do not have a prerequisite,
- the 'git rebase' command is not guarded by test_must_fail.
The pick commands are optional noise words in the FAKE_LINES
Test each short command at least once. The commands changed here
are chosen such that
- tests do not have a prerequisite,
- the 'git rebase' command is not guarded by test_must_fail.
The pick commands are optional noise words in the FAKE_LINES
variable. Test them, too.
Signed-off-by: Johannes
The sequencer instruction 'b', short for 'break', is rejected:
error: invalid line 2: b
The reason is that the parser expects all short commands to have
an argument. Permit short commands without arguments.
Signed-off-by: Johannes Sixt
---
I'll send a another patch in a moment that tests
Am 19.10.18 um 08:02 schrieb Junio C Hamano:
* js/diff-notice-has-drive-prefix (2018-10-19) 1 commit
- diff: don't attempt to strip prefix from absolute Windows paths
"git diff /a/b/c /a/d/f" noticed these are full paths with shared
leading prefix "/a", but failed to notice a similar fact
should be changed from == '/' to
is_dir_sep() or not. It turns out not to be necessary. That code
only ever investigates paths that have undergone pathspec
normalization, after which there are only forward slashes even on
Windows.
Signed-off-by: Johannes Sixt
---
v2:
- added a test that demonstrates the proble
Am 18.10.18 um 20:49 schrieb Stefan Beller:
> On Thu, Oct 18, 2018 at 11:38 AM Johannes Sixt wrote:
>
>> There is one peculiarity, though: [...]
>
> The explanation makes sense, and the code looks good.
> Do we want to have a test for this niche case?
>
Good point. Tha
ot. It turns out not to be necessary. That code
only ever investigates paths that have undergone pathspec
normalization, after which there are only forward slashes even on
Windows.
Signed-off-by: Johannes Sixt
---
diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dif
Am 13.10.18 um 04:46 schrieb Jeff King:
But no, right before that we have this line:
offset -= win->offset;
So offset is in fact no longer its original meaning of "offset into the
packfile", but is now an offset of the specific request into the window
we found.
So I think it's
Am 12.10.18 um 08:33 schrieb Junio C Hamano:
"Derrick Stolee via GitGitGadget" writes:
+struct topo_walk_info {};
+
+static void init_topo_walk(struct rev_info *revs)
+{
+ struct topo_walk_info *info;
+ revs->topo_walk_info = xmalloc(sizeof(struct topo_walk_info));
+ info =
Am 10.10.18 um 07:43 schrieb Junio C Hamano:
We haven't seen much complaints and breakages reported against the
two big "rewrite in C" topics around "rebase"; perhaps it is a good
time to merge them to 'next' soonish to cook them for a few weeks
before moving them to 'master'?
Please let me
Am 07.10.18 um 21:06 schrieb Ævar Arnfjörð Bjarmason:
Picking any one number is explained in the comment. I'm asking why 17 in
particular not for correctness reasons but as a bit of historical lore,
and because my ulterior is to improve the GC docs.
The number in that comic is 4 (and no
Am 07.10.18 um 20:28 schrieb Ævar Arnfjörð Bjarmason:
In 2007 Junio wrote
(https://public-inbox.org/git/7vr6lcj2zi@gitster.siamese.dyndns.org/):
+static int need_to_gc(void)
+{
+ /*
+ * Quickly check if a "gc" is needed, by estimating how
+ * many loose objects
Am 21.09.18 um 07:22 schrieb Junio C Hamano:
> The tip of 'next' hasn't been rewound yet. The three GSoC "rewrite
> in C" topics are still unclassified in this "What's cooking" report,
> but I am hoping that we can have them in 'next' sooner rather than
> later. I got an impression that Dscho
Am 12.09.18 um 21:16 schrieb Randall S. Becker:
I feel really bad asking this, and I should know the answer, and yet.
I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions
Am 10.09.18 um 19:05 schrieb Jeff Hostetler via GitGitGadget:
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..f87376b26a 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -341,6 +341,19 @@ int mingw_mkdir(const char *path, int mode)
return ret;
}
+/*
+ * Calling
Am 08.09.2018 um 04:04 schrieb Junio C Hamano:
> Jonathan Nieder writes:
>
>> It is late in the release cycle, so revert the whole 3-patch series.
>> We can try again later for 2.20.
>>
>> Reported-by: Allan Sandfeld Jensen
>> Helped-by: Stefan Beller
>> Signed-off-by: Jonathan Nieder
>> ---
Am 08.09.2018 um 11:26 schrieb Johannes Sixt:
Am 07.09.2018 um 20:19 schrieb Jeff Hostetler via GitGitGadget:
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..ef03bbe5d2 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -355,7 +355,7 @@ static int mingw_open_append(wchar_t const
Am 07.09.2018 um 20:19 schrieb Jeff Hostetler via GitGitGadget:
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
compat/mingw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..ef03bbe5d2 100644
--- a/compat/mingw.c
Am 22.08.2018 um 15:16 schrieb Derrick Stolee:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1c42364988..f846543414 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -917,7 +917,11 @@ core.notesRef::
This setting defaults to "refs/notes/commits",
Am 20.08.2018 um 19:40 schrieb Phillip Wood:
On 20/08/2018 11:22, Konstantin Kharlamov wrote:
It's spectacular, that content of one of inserted conflict markers is
empty, so all you have to do is to remove the markers, and use `git add`
on the file, and then `git rebase --continue`
Its a lot
Am 14.08.2018 um 00:37 schrieb Jeff King:
And then you can do something like:
for size in 4097 8193 16385 32769 65537 131073 262145 524289 1048577; do
>out ;# clean up from last run
echo "Trying $size..."
timeout 5 ./write $size out
if ! ./check $size
I used your
Am 13.08.2018 um 22:20 schrieb Junio C Hamano:
Johannes Sixt writes:
The Windows CRT implements O_APPEND "manually": on write() calls, the
file pointer is set to EOF before the data is written. Clearly, this is
not atomic. And in fact, this is the root cause of failures observe
unusal error ENOSYS is reported if an
unsupported mode is encountered.
Diagnosed-by: Johannes Schindelin
Helped-by: Jeff Hostetler
Signed-off-by: Johannes Sixt
---
compat/mingw.c | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/compat/ming
Am 10.08.2018 um 18:51 schrieb Jeff Hostetler:
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows
Am 05.08.2018 um 06:20 schrieb William Chargin:
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can fail when filenames contain newlines. This patch
changes the implementation to use `ls -A`, which is specified by POSIX.
The output should be empty exactly if
I'm testing origin/next on Windows with a few other topics on top.
The first test fails like this. Do you see what is wrong?
Where should I start looking? Is it perhaps that upload-pack
is responding too soon so that fetch does not send 'have c1'?
this is the console output
Am 22.07.2018 um 10:04 schrieb Nguyễn Thái Ngọc Duy:
+ if (size < pack->oe_delta_size_limit) {
+ e->delta_size_ = size;
+ e->delta_size_valid = 1;
+ } else {
+ packing_data_lock(pack);
+ if (!pack->delta_size)
+
Am 23.07.2018 um 15:52 schrieb Johannes Schindelin via GitGitGadget:
From: Johannes Schindelin
This adds a couple settings for the .c/.h files so that it is easier to
conform to Git's conventions while editing the source code.
Signed-off-by: Johannes Schindelin
---
contrib/vscode/init.sh |
Am 12.07.2018 um 18:26 schrieb Junio C Hamano:
Johannes Schindelin writes:
A much more meaningful measure would be: how many octopus merge commits
have been pushed to GitHub in the past two weeks. I don't think I have the
technical means to answer that question, though.
It does not mean that
Am 27.06.2018 um 19:27 schrieb Elijah Newren:
On Wed, Jun 27, 2018 at 9:54 AM, Junio C Hamano wrote:
Having said that, it would be simpler for at least the latter to
write it using a single-shot environment assignment, perhaps? I.e.
PATH=./test-bin:$PATH git rebase --continue &&
Am 27.06.2018 um 04:15 schrieb Elijah Newren:
On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote:
On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
Some of these dangers can be de-thoothed during the linting phase by
defining do-nothing shell functions:
cp () { :; }
mv
Am 26.06.2018 um 20:14 schrieb Eric Sunshine:
On Tue, Jun 26, 2018 at 2:06 PM Johannes Sixt wrote:
Hence, these lines should actually be
p4 help client &&
! p4 help nosuchcommand
Thanks for the comment; you're right, of course. I'll certai
Am 26.06.2018 um 11:21 schrieb Eric Sunshine:
On Tue, Jun 26, 2018 at 4:58 AM Elijah Newren wrote:
On Tue, Jun 26, 2018 at 12:29 AM, Eric Sunshine wrote:
+ p4 help client &&
+ test_must_fail p4 help nosuchcommand
same question?
Same answer. Not shown in this
Am 22.06.2018 um 14:04 schrieb Marc Strapetz:
On Windows, when creating following repository:
$ git init
$ echo "1" > file.txt
$ git add .
$ git commit -m "initial import"
$ ren file.txt File.txt
$ git config core.ignorecase false
This is a user error. core.ignorecase is *not* an instruction
Am 19.06.2018 um 03:06 schrieb Jonathan Nieder:
Ian Jackson wrote[1]:
git-rebase leaves entries like this in the reflog:
c15f4d5391 HEAD@{33}: rebase: checkout
c15f4d5391ff07a718431aca68a73e672fe8870e
It would be nice if there were an option to control this message.
Particularly, when
Am 11.06.2018 um 23:58 schrieb Stefan Beller:
On Mon, Jun 4, 2018 at 10:48 PM Bert Wesarg wrote:
the last time this topic came up, Stefan (in Cc) offered to volunteer.
Stefan, is this offer still open? I would support this.
After I made this offer, I started looking at the code base more and
Am 09.06.2018 um 22:43 schrieb Johannes Schindelin:
On Sat, 9 Jun 2018, Johannes Sixt wrote:
When you want usage data, ask your users for feedback. Look over their
shoulders. But do not ask the software itself to gather usage data. It will be
abused.
Do not offer open source software that has
Am 09.06.2018 um 08:51 schrieb Jeff King:
I actually think this could be useful for normal users, too. We have
GIT_TRACE for dumping debug output, and we sometimes ask users to turn
it on to help diagnose a problem (not to mention that we use it
ourselves).
The BIG difference is in "we ask the
Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason:
On Fri, Jun 08 2018, Johannes Sixt wrote:
Am 08.06.2018 um 18:00 schrieb Thomas Braun:
I for my part would much rather prefer that to be a compile time
option so that I don't need to check on every git update on windows
if this is now
Am 08.06.2018 um 04:53 schrieb Theodore Y. Ts'o:
And of course, that's the other thing you seem to fundamentally not
understand about how git works. Every developer in the world working
on that open source project has their own copy.
Everyone here understands how Git works, of course.
Am 08.06.2018 um 18:00 schrieb Thomas Braun:
I for my part would much rather prefer that to be a compile time
option so that I don't need to check on every git update on windows
if this is now enabled or not.
This exactly my concern, too! A compile-time option may make it a good
deal less
Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
From: Jeff Hostetler
I've been working to add code to Git to optionally collect telemetry data.
The goal is to be able to collect performance data from Git commands and
allow it to be aggregated over a user community to find "slow
Am 03.06.2018 um 11:53 schrieb Robert P. J. Day:
if i wanted to do something this admittedly awkward, would using
periods give me some benefit related to, i don't know, regex matching,
as compared to using a different character? or am i just way
overthinking this? is anyone out there actually
Am 31.05.2018 um 19:27 schrieb Robert P. J. Day:
On Thu, 31 May 2018, Duy Nguyen wrote:
git diff-index is "plumbing", designed for writing scripts. "git
diff" on the other hand is for users and its behavior may change
even if it breaks backward compatibility.
ah, this was a philosophical
Am 19.05.2018 um 04:07 schrieb Elijah Newren:
There is really no need for four branches of nearly identical messages
when we can store the differences into small variables before printing.
Oh, there is a reason for the repeated message text: translations!
Please do not play sentence Lego with
Am 16.05.2018 um 20:19 schrieb Mehdi Zeinali:
Git Version: Version: 2.14.2
When reversing a range in git log, it does not start from the expected commit:
--reverse does not change the meaning A..B to B..A or something. For a
particular A..B specification, the set of commits selected when
Am 13.05.2018 um 04:24 schrieb brian m. carlson:
Adjust the test so that it computes values for blobs instead of using
hard-coded hashes.
Signed-off-by: brian m. carlson
---
t/t4014-format-patch.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
that the output remains visible in
the terminal. For this, the option --no-pager can be used. But
it is a bit cumbersome to type, even when command completion is
available. Provide a short option, -P, to make the option easier
accessible.
Signed-off-by: Johannes Sixt <j...@kdbg.org>
---
Given the po
Am 01.05.2018 um 13:57 schrieb Johannes Schindelin:
Hi Hannes,
On Mon, 30 Apr 2018, Johannes Sixt wrote:
Am 30.04.2018 um 05:25 schrieb Junio C Hamano:
* js/no-pager-shorthand (2018-04-25) 1 commit
- git: add -N as a short option for --no-pager
"git --no-pager cmd" did not
Am 30.04.2018 um 00:17 schrieb Johannes Schindelin:
t1406 specifically verifies that certain code paths fail with a BUG: ...
message.
In the upcoming commit, we will convert that message to be generated via
BUG() instead of die("BUG: ..."), which implies SIGABRT instead of a
regular exit code.
Am 30.04.2018 um 16:26 schrieb Ben Peart:
@@ -82,8 +83,6 @@ static int cmd_dropcaches(void)
{
HANDLE hProcess = GetCurrentProcess();
HANDLE hToken;
- HMODULE ntdll;
- DWORD(WINAPI *NtSetSystemInformation)(INT, PVOID, ULONG);
SYSTEM_MEMORY_LIST_COMMAND
Am 30.04.2018 um 05:25 schrieb Junio C Hamano:
* js/no-pager-shorthand (2018-04-25) 1 commit
- git: add -N as a short option for --no-pager
"git --no-pager cmd" did not have short-and-sweet single letter
option. Now it does.
Will merge to 'next'.
I consider your argument that -N is
Am 25.04.2018 um 11:21 schrieb Phillip Wood:
On 24/04/18 17:59, Johannes Sixt wrote:
In modern setups, less, the pager, uses alternate screen to show
the content. When it is closed, it switches back to the original
screen, and all content is gone.
Are you setting LESS explicitly
Am 25.04.2018 um 09:41 schrieb Johannes Schindelin:
Hi Hannes,
On Wed, 25 Apr 2018, Johannes Sixt wrote:
Am 25.04.2018 um 02:05 schrieb Junio C Hamano:
Johannes Sixt <j...@kdbg.org> writes:
It is not uncommon to request that the output remains visible in
the terminal.
I ran `g
Am 25.04.2018 um 02:05 schrieb Junio C Hamano:
Johannes Sixt <j...@kdbg.org> writes:
It is not uncommon to request that the output remains visible in
the terminal. For this, the option --no-pager can be used. But
it is a bit cumbersome to type, even when command completion is
available. P
. But
it is a bit cumbersome to type, even when command completion is
available. Provide a short option, -N, to make the option easier
accessible.
Signed-off-by: Johannes Sixt <j...@kdbg.org>
---
Documentation/git.txt | 3 ++-
git.c | 4 ++--
2 files changed, 4 insertions(+), 3 del
Junio,
you may want to squash this into your merge commit of branch
ps/test-chmtime-get (today it is fa57c0871fc9)
-- Hannes
diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c
index daeddc1cbc..aa22af48c2 100644
--- a/t/helper/test-chmtime.c
+++ b/t/helper/test-chmtime.c
@@ -25,7
author date nor the committer date are explicitly
>>> set. 'commit' always passes the author date to commit_tree_extended()
>>> and relied on the date caching to have the same committer and author
>>> dates when neither was specified. Fix this by setting
>>> GIT
Am 15.04.2018 um 23:35 schrieb Junio C Hamano:
Ah, do you mean we have an internal sequence like this, when "rebase
--continue" wants to conclude an edit/reword?
Yes, it's only 'reword' that is affected, because then subsequent picks
are processed by the original process.
- we figure out
I just noticed that all commits in a 70-commit branch have the same
committer timestamp. This is very unusual on Windows, where rebase -i of
such a long branch takes more than one second (but not more than 3 or
so thanks to the builtin nature of the command!).
And, in fact, if you mark some
Am 09.04.2018 um 21:26 schrieb Hari Lubovac:
It appears to be just a reporting issue. Probably not a big deal, but
I thought I should report this, if it hasn't been noticed: when a
branch is switched to by being named with non-original
character-casing, then it's not clear which branch is
Am 03.04.2018 um 15:12 schrieb Johannes Schindelin:
On Fri, 30 Mar 2018, Junio C Hamano wrote:
* js/runtime-prefix-windows (2018-03-27) 2 commits
- mingw/msvc: use the new-style RUNTIME_PREFIX helper
- exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows
(this branch uses
Am 02.04.2018 um 02:36 schrieb Robert Dailey:
I'm struggling with a bug that I found introduced in git v2.13.2. The
bug was not reproducible in v2.13.1. The issue is that using arguments
like "@{-1}" to aliases causes those curly braces to be removed, so
once the command is executed after alias
Am 13.03.2018 um 21:39 schrieb Ævar Arnfjörð Bjarmason:
Add a INSTALL_SYMLINKS option which if enabled, changes the default
hardlink installation method to one where the relevant binaries in
libexec/git-core are symlinked back to ../../bin, instead of being
hardlinked.
This new option also
Am 12.02.2018 um 04:15 schrieb Eric Sunshine:
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -454,20 +454,29 @@ post_checkout_hook () {
test_when_finished "rm -f .git/hooks/post-checkout" &&
mkdir -p .git/hooks &&
write_script .git/hooks/post-checkout
Am 09.02.2018 um 07:11 schrieb Sergey Organov:
Johannes Schindelin writes:
Let me explain the scenario which comes up plenty of times in my work with
Git for Windows. We have a thicket of some 70 branches on top of git.git's
latest release. These branches often
Am 07.02.2018 um 09:07 schrieb Ævar Arnfjörð Bjarmason:
On Wed, Feb 07 2018, Johannes Sixt jotted:
Am 07.02.2018 um 00:13 schrieb Ævar Arnfjörð Bjarmason:
The $test_case variable hasn't been used since
decd3c0c28 ("t0050-*.sh: mark the rename (case change) test as
passing", 2014-1
ke in the original --preserve-merges, and you
bring with you to this new --recreate-merges... It's sad. Even more sad
as solution is already known for years:
bc00341838a8faddcd101da9e746902994eef38a
Author: Johannes Sixt <j...@kdbg.org>
Date: Sun Jun 16 15:50:42 2013 +0200
Am 07.02.2018 um 00:13 schrieb Ævar Arnfjörð Bjarmason:
The $test_case variable hasn't been used since
decd3c0c28 ("t0050-*.sh: mark the rename (case change) test as
passing", 2014-11-28) when its last user went away.
Let's remove the "say" as well, since it's obvious from subsequent
output
Am 03.02.2018 um 22:34 schrieb Elijah Newren:
> If anyone can find an
> example of a real world open source repository (linux, webkit, git,
> etc.) with a merge where n is greater than about 10, I'll be
> surprised.
git rev-list --parents --merges master |
grep " .* .* .* .* .* .* .* .* .* .* "
Am 02.02.2018 um 00:10 schrieb Keith Goldfarb:
Dear git,
While tracking down a problem with a filesystem shared by Windows and Ubuntu, I
came across the following code in compat/mingw.c (ming_fstat(), also in
do_lstat()):
if (GetFileInformationByHandle(fh, )) {
Am 29.01.2018 um 23:36 schrieb Brandon Williams:
A while back there was some discussion of getting our codebase into a state
where we could use a c++ compiler if we wanted to (for various reason like
leveraging c++ only analysis tools, etc.). Johannes Sixt had a very large
patch that achieved
Am 15.01.2018 um 06:44 schrieb Alexander Shopov:
@@ -5,11 +5,11 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--help] [-C ] [-c name=value]\n"
- " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
- " [-p
1 - 100 of 1147 matches
Mail list logo