On Fri, 3 May 2019 at 18:01, Torsten Bögershausen wrote:
[snip]
> I think that patch 1/2 is in upstream Git,
> and even in git-for-windows/master - on which codebase are you ?
>
Sorry, it's my first time submitting a patch, so I'm probably somewhat
incompetent :D
I was trying to follow the instru
gitignore.txt: make slash-rules more readable
Make all paragraphs valid, even if they are not read
in strict order. Make paragraph better understandable
for pattern without slash. Add paragraph for pattern
with slash. Be precise whenever a trailing slashes
would make a difference. Add some exampl
On Sat, May 04, 2019 at 08:52:01AM +0200, Ævar Arnfjörð Bjarmason wrote:
> As an aside this is the Nth time I notice how crappy that "Enumerating
> objects" progress bar is.
And don't forget that the commit-graph progress bar still prints
nonsense :)
https://public-inbox.org/git/87ef6ydds8@
'flags' parameter was replaced by 'raw' in commit:
76141e2e62 ("format_note(): simplify API", 2012-10-17)
Signed-off-by: Chris Mayo
---
notes.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/notes.h b/notes.h
index 414bc6855a..76337f2384 100644
--- a/notes.h
+++ b/no
The exit code of the upstream in a pipe is ignored thus we should avoid
using it. By writing out the output of the git command to a file, we can
test the exit codes of both the commands.
Signed-off-by: Boxuan Li
---
t/t4253-am-keep-cr-dos.sh | 6 --
1 file changed, 4 insertions(+), 2 deletio
Phillip Wood writes:
> I've had a look at the rebase -i code and I think it only overwrites
> ignored files when it is fast-forwarding. This matches what merge does
> when fast-forwarding but I'm not convinced either of them should be
> doing this by default (I think checkout doing it is probably
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 25 Apr 2019, Junio C Hamano wrote:
>
>> * js/macos-gettext-build (2019-04-15) 1 commit
>> (merged to 'next' on 2019-04-22 at de4cbb1431)
>> + macOS: make sure that gettext is found
>>
>> Build with gettext breaks on recent macOS w/ Homebrew
Jeff King writes:
> FWIW, I agree with you here. These patches are not making anything worse
> (and may even make them better, since we'd probably need to swap out the
> BLOCKSIZE constant for a run-time "blocksize" variable in fewer places).
It's just that leaving the interface uneven is an eas
Jeff King writes:
> I think spatch is smart enough not to hit the same header multiple
> times. But the problem is that we invoke it once per file, so it
> actually processes cache.h many times. That's slow, but also produces
> bogus patches.
Yes, I've seen this and was a bit irritated myself, b
On Sat, May 4, 2019 at 10:39 PM Boxuan Li wrote:
> The exit code of the upstream in a pipe is ignored thus we should avoid
> using it. By writing out the output of the git command to a file, we can
> test the exit codes of both the commands.
>
> Signed-off-by: Boxuan Li
> ---
> diff --git a/t/t42
10 matches
Mail list logo