On 2019-03-06, Junio Hamano, Jeff King wrote:> Jeff King
writes
>
>> TBH, I still have mixed feelings on rendering these technical docs with
>> asciidoc at all. It seems like few enough people bother to render them
>> that bugs persist for a long time. It kind of seems like make-work
>> getting t
Correct misspelled ".gitattribute" in comments only, so no functional
change.
Signed-off-by: Robert P. J. Day
---
diff --git a/attr.c b/attr.c
index fdd110bec5..93dc16b59c 100644
--- a/attr.c
+++ b/attr.c
@@ -431,14 +431,14 @@ static struct match_attr *parse_attr_line(const char
*line, const
On Tue, Mar 5, 2019 at 10:42 PM Eric Sunshine wrote:
>
> On Tue, Mar 5, 2019 at 7:32 AM Nguyễn Thái Ngọc Duy wrote:
> > diff --git a/diff.c b/diff.c
> > @@ -5299,6 +5299,8 @@ static void prep_parse_options(struct diff_options
> > *options)
> > + OPT_BOOL(0, "quiet", &options->flags
On Wed, Mar 6, 2019 at 11:49 AM Jeff King wrote:
>
> On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote:
>
> > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > There are now ideas, micro-projects and organization application pages
> > > for G
On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano wrote:
> * tg/checkout-no-overlay (2019-02-04) 9 commits
> (merged to 'next' on 2019-02-04 at 9968bcf4fb)
> + revert "checkout: introduce checkout.overlayMode config"
> (merged to 'next' on 2019-01-18 at 1e2a79ba5c)
> + checkout: introduce checko
Hi Junio,
On Wed, 6 Mar 2019, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Johannes Schindelin via GitGitGadget"
> > writes:
> >
> >> As suggested by Jeff King in a nearby thread.
> >>
> >> Johannes Schindelin (1):
> >> remote-curl: mark all error messages for translation
> >
> > Do
I can only concur about the genuine usefulness of symbolic refs as
branch aliases. I wrote my shell script for this 5 years ago, and
I've made use of the facility almost every working day since.
I jump around branches frequently, and my feature branch names always
start with an issue/bug number f
On Wed, Mar 6, 2019 at 6:47 AM Matheus Tavares Bernardino
wrote:
>
> This exercise of estimating a good spot to gain performance with
> parallelism at git seems more difficult than I thought, firstly. Also,
> I'm not that familiar yet with git packing (neither with the sections
> of it that could
As I stated earlier[1], I discovered today that git revert (and thus,
git cherry-pick as well) do not place the scissors line properly as
well. This patchset adds a scissors line when conflicts arise in both
cherry-pick and revert, which fixes the same bug present in git-merge
earlier.
This patchs
Signed-off-by: Denton Liu
---
t/t3507-cherry-pick-conflict.sh | 34 -
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
index 0db166152a..74ff925526 100755
--- a/t/t3507-cherry-pick-con
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Note that the removal of the if-else tower in git_sequencer_config may
appear to be a no-op refactor but it actually isn't. First of all, we
now accept
In the git-clean documentation, -x and -e documented .gitignore,
$GIT_DIR/info/excludes but neglected to mention the file pointed to by
core.excludesFile.
Explicitly mention that variable so that the list is exhaustive.
Reported-by: Robert P. J. Day
Signed-off-by: Denton Liu
---
Documentation/
Robert reported that core.excludesFile was not mentioned in the
git-clean docs[1]. This cleans that up by mentioning that in the docs.
[1]:
https://public-inbox.org/git/alpine.LFD.2.21.1902231328560.@localhost.localdomain/
Denton Liu (1):
git-clean.txt: specify core.excludesFile variable i
Hi Junio,
On Wed, 6 Mar 2019, Junio C Hamano wrote:
> * js/rebase-orig-head-fix (2019-03-04) 4 commits
> - built-in rebase: set ORIG_HEAD just once, before the rebase
> - built-in rebase: demonstrate that ORIG_HEAD is not set correctly
> - built-in rebase: use the correct reflog when switching
Hi Junio,
On Wed, 6 Mar 2019, Junio C Hamano wrote:
> * nb/branch-show-other-worktrees-head (2019-02-01) 3 commits
> - branch: add an extra verbose output displaying worktree path for refs
> checked out in a linked worktree
> - branch: mark and color a branch differently if it is checked out i
The current documentation uses both quotes (italics) and backquotes
(monospace) to render URLs and pathnames, which is inconsistant.
Document a best practice in CodingGuidelines to help reduce
inconsistencies in the futur.
We set the best practice to using backquotes, since:
* It is already an es
Applying CodingGuidelines about monospace on pathnames and URLs.
See Documentation/CodingGuidelines.txt for more information.
Signed-off-by: Corentin BOMPARD
Signed-off-by: Nathan BERBEZIER
Signed-off-by: Pablo CHABANNE
Signed-off-by: Matthieu MOY
---
Changes: We listen to Matthieu MOY and E
Hi Junio,
On Wed, 6 Mar 2019, Junio C Hamano wrote:
> * ab/makefile-help-devs-more (2019-02-24) 6 commits
> - Makefile: allow for combining DEVELOPER=1 and CFLAGS="..."
> - Makefile: move the setting of *FLAGS closer to "include"
> - Makefile: Move *_LIBS assignment into its own section
> - M
Hi Junio,
On Wed, 6 Mar 2019, Junio C Hamano wrote:
> * ps/stash-in-c (2019-03-01) 28 commits
> - tests: add a special setup where stash.useBuiltin is off
> - stash: optionally use the scripted version again
> - stash: add back the original, scripted `git stash`
> - stash: convert `stash--hel
Hi Stefan,
just wanted to express my gratitude for your idea to introduce the `break`
command in `git rebase -i`'s todo list. I use it *all* the time now.
Ciao,
Dscho
Hi Peff,
On Tue, 5 Mar 2019, Jeff King wrote:
> On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote:
>
> > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > There are now ideas, micro-projects and organization application pages
> > > for GSoC
Hi Woody,
On Mon, 4 Mar 2019, Woody Woodman wrote:
>
>
Details, please.
> Sent from my iPhone
Not sent from my iPhone, as it would really be cumbersome to type an
informative, useful bug report on a phone, even the best of them.
Ciao,
Johannes
going back to a couple threads:
https://marc.info/?l=git&m=151048015116473&w=2
https://marc.info/?l=git&m=152690160605723&w=2
and i'm going to try to clarify what (if anything) was decided
regarding the internally inconsistent phrase "known to Git." junio's
take on this here:
https://marc.in
When it is run in a worktree 'git for-each-ref' only seems to show refs
under refs/rewritten if that directory also exists under $GIT_COMMON_DIR
even though they are local to the worktree.
Initially I thought this was due to $GIT_COMMON_DIR pointing to a bare
repo, but that is not the case. Ho
Hi Denton
On 06/03/2019 10:30, Denton Liu wrote:
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Was that the case with cherry-pick and revert as well as merge, or were
they missing the scissors
> * jt/test-protocol-version (2019-02-06) 8 commits
> - t5552: compensate for v2 filtering ref adv.
> - tests: fix protocol version for overspecifications
> - t5700: only run with protocol version 1
> - t5512: compensate for v0 only sending HEAD symrefs
> - t5503: fix overspecification of trac
On Wed, Mar 06, 2019 at 02:28:01PM +0900, Junio C Hamano wrote:
> > +#ifndef COMPAT_BSWAP_H
> > +#define COMPAT_BSWAP_H
> [...]
>
> This probably is worth having as an independent clean-up.
Yeah, let's do that now before we forget.
-- >8 --
Subject: [PATCH] compat/bswap: add include header guar
On Wed, Mar 06, 2019 at 09:07:11AM +0100, Jean-Noël Avila wrote:
> TBH, I discovered this while diving into the rendering on manpages for
> the localized version because asciidoctor issued a warning, and pushed
> this patch for "cultural" knowledge (sometimes, automatic linefeed
> triggers uninten
On Wed, Mar 06, 2019 at 04:36:12PM +0700, Duy Nguyen wrote:
> > It seems like that would even be pretty easy to do, with the exception
> > of the numbering.
>
> I'd like some niceties from test-lib.sh though. -i should be supported
> to stop at the first failure. -v would be nice if possible. Ski
Hello all,
I've been on "jch" for my daily use and I noticed today that git stash
isn't working. I managed to debug it down to "ps/stash-in-c".
To reproduce on git.git, it's simply the following:
echo // >>dir.c
git stash
This gives me the following error:
$ git stash
Il giorno mar, 05/03/2019 alle 14.15 -0500, Jeff King ha scritto:
> On Mon, Mar 04, 2019 at 03:40:07PM -0500, Jeff King wrote:
>
> > You can patch the Makefile, or just override it like:
> >
> > make LIBS='-lcrypto -lz'
> >
> > which builds for me on current Debian unstable. I don't think you
On Wed, Mar 06, 2019 at 11:52:36AM -0800, Denton Liu wrote:
> Hello all,
>
> I've been on "jch" for my daily use and I noticed today that git stash
> isn't working. I managed to debug it down to "ps/stash-in-c".
>
> To reproduce on git.git, it's simply the following:
>
> echo // >>dir.c
>
On Wed, Mar 06, 2019 at 08:58:40PM +0100, Fabio Aiuto wrote:
> Yes the fetch command wasn't written at that time, right? I didn't
> understand why should be better to work with the git code from github.
> There's something I misunderstood?
I just mean that it is an interesting fact that modern Gi
Yes that's great.
Why somebody told me about a outdate toolchain when I started this
little thread about first git compiling? Sorry for my stupid question
but the you just resolved with that make override...
Maybe there's something I have to know?
Il giorno mer, 06/03/2019 alle 15.03 -0500, Jeff K
On Wed, 6 Mar 2019 at 12:17, Denton Liu wrote:
>
> In the git-clean documentation, -x and -e documented .gitignore,
> $GIT_DIR/info/excludes but neglected to mention the file pointed to by
> core.excludesFile.
Nit: I suppose it doesn't so much document it, as mention it. So
In the git-clean do
Found this error
Program received signal SIGSEGV, Segmentation fault.
0x00401628 in verify_hdr (hdr=0x0, size=32) at read-cache.c:192
192 if (hdr->signature != CACHE_SIGNATURE)
when tracing on line
static int verify_hdr(struct cache_header *hdr, unsigned long size)
{
SHA_CTX
That was proably my bad.
I still find it somewhat astounding that it compiles with a modern
toolchain after 15+ years. Many projects fail to do so (it's an
understandably high bar to have).
I'm glad this is possible and you were able to do so (maybe you want to
share your experiences about it so
On Tue, Mar 05, 2019 at 07:08:33PM +0700, Nguyễn Thái Ngọc Duy wrote:
> @@ -71,11 +82,15 @@ static unsigned char refname_disposition[256] = {
> * - it ends with a "/", or
> * - it ends with ".lock", or
> * - it contains a "@{" portion
> + *
> + * in which case cp_out points to the beginning
On Wed, Mar 06, 2019 at 03:39:11PM -0500, Santiago Torres wrote:
> I still find it somewhat astounding that it compiles with a modern
> toolchain after 15+ years. Many projects fail to do so (it's an
> understandably high bar to have).
I think the key thing is that Git has very few external depen
On Wed, Mar 06, 2019 at 09:52:59PM +0100, Fabio Aiuto wrote:
> Found this error
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00401628 in verify_hdr (hdr=0x0, size=32) at read-cache.c:192
> 192 if (hdr->signature != CACHE_SIGNATURE)
>
> when tracing on line
>
> static i
On Wed, Mar 06, 2019 at 03:14:11PM +0100, Johannes Schindelin wrote:
> Hi Stefan,
>
> just wanted to express my gratitude for your idea to introduce the `break`
> command in `git rebase -i`'s todo list. I use it *all* the time now.
+1. Before that, I was using `x bash`, and ended up doing `git re
On 03/06, Jeff King wrote:
> On Wed, Mar 06, 2019 at 11:52:36AM -0800, Denton Liu wrote:
>
> > Hello all,
> >
> > I've been on "jch" for my daily use and I noticed today that git stash
> > isn't working. I managed to debug it down to "ps/stash-in-c".
> >
> > To reproduce on git.git, it's simply
Jeff King writes:
> On Wed, Mar 06, 2019 at 02:28:01PM +0900, Junio C Hamano wrote:
>
>> > +#ifndef COMPAT_BSWAP_H
>> > +#define COMPAT_BSWAP_H
>> [...]
>>
>> This probably is worth having as an independent clean-up.
>
> Yeah, let's do that now before we forget.
Thanks
>
> -- >8 --
> Subject:
On 03/05, Matheus Tavares Bernardino wrote:
> First of all, I must apologize for not replying during these last
> days. I'm traveling and I rarely get a connection here. But I'll be
> back March 11th.
>
> On Sun, Mar 3, 2019 at 4:18 AM Christian Couder
> wrote:
> >
> > On Sat, Mar 2, 2019 at 4:09
Brandon Richardson writes:
> @@ -23,6 +23,9 @@ Creates a new commit object based on the provided tree
> object and
> emits the new commit object id on stdout. The log message is read
> from the standard input, unless `-m` or `-F` options are given.
>
> +When mixing `-m` and `-F` options, the
Jeff King writes:
> (Though I am also happy to see it applied since you went to the trouble
> to make it).
Yup.
On Tue, Mar 05, 2019 at 02:57:32PM +0900, Junio C Hamano wrote:
> Yup, that would be a very sensible first step, regardless of what
> the next step is.
>
> After that, choices are
>
> (1) we'd introduce new inconsistency among --type= by
> matching what --type=color does to what --get-color d
Denton Liu writes:
> It's safe to merge to master but it'd probably be better if we keep
> cooking in next until I can get the fixup patches out.
OK. Or we could kick it out of 'next' and replace with an updated
series instead of "start with broken patches, with fixup on top".
Thanks.
Hi Johannes,
On Sat, Mar 02, 2019 at 09:25:28PM +0100, Johannes Schindelin wrote:
> Hi Taylor,
>
> On Fri, 1 Mar 2019, Taylor Blau wrote:
>
> > [ ... ]
>
> This should do the right thing if you write
>
> printf "" >expect
>
> instead?
>
> Ciao,
> Dscho
>
> > + printf "\\033[31m" >expect &&
Jeff King writes:
> I think this merge message needs a slight tweak with this v2; we don't
> document the failing now, but instead just fix it.
True. Thanks.
Duy Nguyen writes:
> On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano wrote:
>> * tg/checkout-no-overlay (2019-02-04) 9 commits
>> (merged to 'next' on 2019-02-04 at 9968bcf4fb)
>> Will hold.
>
> If it's ready for master, I'd love to see it merged. Either that or
> topic is rebased on 'master'.
In 63e2a0f8e9 (builtin/config: introduce `color` type specifier,
2018-04-09), `--type=color` was introduced and preferred to the
old-style `--get-color`.
The two behave the same in almost every way, save for the fact that
`--type=color` prints a trailing newline where `--get-color` does not.
Inste
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 6 Mar 2019, Junio C Hamano wrote:
>
>> * nb/branch-show-other-worktrees-head (2019-02-01) 3 commits
>> - branch: add an extra verbose output displaying worktree path for refs
>> checked out in a linked worktree
>> - branch: mark and color a b
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 6 Mar 2019, Junio C Hamano wrote:
>
>> * ps/stash-in-c (2019-03-01) 28 commits
>> ...
>>
>> "git stash" rewritten in C.
>>
>> Will merge to 'next'.
>
> Yes, yes, yes!
>
> Thank you so much!
Not "me", but all those who worked on whipping the
Hi Phillip,
On Wed, Mar 06, 2019 at 04:29:20PM +, Phillip Wood wrote:
> Hi Denton
>
> On 06/03/2019 10:30, Denton Liu wrote:
> >Fix a bug where the scissors line is placed after the Conflicts:
> >section, in the case where a merge conflict occurs and
> >commit.cleanup = scissors.
>
> Was tha
Hi Phillip, sorry I forgot to address one of your replies.
On Wed, Mar 06, 2019 at 04:29:20PM +, Phillip Wood wrote:
> Hi Denton
>
> On 06/03/2019 10:30, Denton Liu wrote:
> >Fix a bug where the scissors line is placed after the Conflicts:
> >section, in the case where a merge conflict occurs
Jonathan Tan writes:
>> * jt/test-protocol-version (2019-02-06) 8 commits
>> - t5552: compensate for v2 filtering ref adv.
>> - tests: fix protocol version for overspecifications
>> - t5700: only run with protocol version 1
>> - t5512: compensate for v0 only sending HEAD symrefs
>> - t5503:
tbo...@web.de writes:
> Use the following attributes if your '*.ps1' files are UTF-16 little
> endian encoded without BOM and you want Git to use Windows line endings
> -in the working directory (use `UTF-16-LE-BOM` instead of `UTF-16LE` if
> +in the working directory (use `UTF-16LE-BOM` instead
Martin Ågren writes:
> These tabs happen to appear in columns where they don't stand out too
> much, so the diff here is non-obvious. Some of these are rendered
> differently by AsciiDoc and Asciidoctor (although the difference might
> be invisible!), which is how I found a few of them. The remai
Martin Ågren writes:
> But on the topic of preferring shorter, I sort of wonder if we really
> need to provide all of those filenames here. The point we're trying to
> make is that we consider another source. So something like this would be
> just as technically correct, I think:
>
> Use the gi
Thomas Gummerer writes:
> Here's a patch that can either be squashed into 4/27 of the
> ps/stash-in-c series, applied on top, or I can re-send the series with
> the fix. Junio, please let me know which way you'd prefer.
Thanks for a quick turnaround. Let me see how squashing it into
4/27 wou
Jeff King writes:
> Mostly I was just surprised by the new behavior. Perhaps the right
> solution is not a patch to the code, but to the documentation. Something
> like:
Let me forge your sign-off and commit this to prevent us from
forgetting.
Thanks, all.
-- >8 --
From: Jeff King
Date: Mon,
Dear International Sales & Marketing Director
Zhejiang Wuchuan Industrial Co., Ltd,
Hello, this is Eiichi Hasegawa from LIFESTYLE EXPO TOKYO Show Management.
LIFESTYLE EXPO TOKYO is Japan's leading "B-to-B" show for Interior, Lifestyle
products, Tableware/Kitchenware and Gifts.
*
On Wed, Mar 6, 2019 at 7:21 PM Junio C Hamano wrote:
> >
> > +When mixing `-m` and `-F` options, the commit log message will be
> > +composed in the order in which the options are given.
>
> It may be just me, but this new paragraph made me think that we can
> give at most one -m and one -F option
On Thu, Mar 07, 2019 at 09:50:57AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Mostly I was just surprised by the new behavior. Perhaps the right
> > solution is not a patch to the code, but to the documentation. Something
> > like:
>
> Let me forge your sign-off and commit this to p
On Wed, Mar 06, 2019 at 03:52:38PM -0800, Taylor Blau wrote:
> In 63e2a0f8e9 (builtin/config: introduce `color` type specifier,
> 2018-04-09), `--type=color` was introduced and preferred to the
> old-style `--get-color`.
>
> The two behave the same in almost every way, save for the fact that
> `-
Jeff King writes:
> On Wed, Mar 06, 2019 at 03:52:38PM -0800, Taylor Blau wrote:
>
>> In 63e2a0f8e9 (builtin/config: introduce `color` type specifier,
>> 2018-04-09), `--type=color` was introduced and preferred to the
>> old-style `--get-color`.
>>
>> The two behave the same in almost every way,
On Tue, Mar 5, 2019 at 8:43 PM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > Note that there is also a third possibility here:
> >
> > C) There are different answers depending on the context and content
> > that cannot be determined by git, so this is a conflict. Use a
> > high
Hi Everyone,
I built Git 2.2.0 from sources. I added CFLAGS="-DNDEBUG -g2 -O1
-fsantize=undefined'. Then, a 'make test V=1'. The tests don't produce
output. For example:
*** t0021-conversion.sh ***
ok 1 - setup
ok 2 - check
ok 3 - expanded_in_repo
ok 4 - filter shell-escaped filenames
ok 5 - requ
Elijah Newren writes:
> I'm not sure I'm following well enough to answer any your question(s),
> so I'll instead ask a few of my own:
> * Are you referring to stage #2 and stage #3 of the old path or the
> new path or one of each or both of each?
If they moved the sole neighbouring file X/A to
Elijah Newren writes:
> I'm not sure I'm following well enough to answer any your question(s),
> so I'll instead ask a few of my own:
> * Are you referring to stage #2 and stage #3 of the old path or the
> new path or one of each or both of each?
If they moved the sole neighbouring file X/A to
On Thu, Mar 07, 2019 at 12:35:58AM -0500, Jeffrey Walton wrote:
> I built Git 2.2.0 from sources. I added CFLAGS="-DNDEBUG -g2 -O1
> -fsantize=undefined'. Then, a 'make test V=1'. The tests don't produce
> output. For example:
>
> *** t0021-conversion.sh ***
> ok 1 - setup
> [...]
Try:
make t
In the git-clean documentation, -x and -e documented .gitignore,
$GIT_DIR/info/excludes but neglected to mention the file pointed to by
core.excludesFile.
Remove specific list of files and, instead, reference gitignore(5)
documentation so that information is consolidated and the git-clean
document
Robert reported that core.excludesFile was not mentioned in the
git-clean docs[1]. This cleans that up by mentioning that in the docs.
[1]:
https://public-inbox.org/git/alpine.LFD.2.21.1902231328560.@localhost.localdomain/
Changes since v1:
* Use Martin's suggestions of referencing the giti
As I stated earlier[1], I discovered today that git revert (and thus,
git cherry-pick as well) do not place the scissors line properly as
well. This patchset adds a scissors line when conflicts arise in both
cherry-pick and revert, which fixes the same bug present in git-merge
earlier.
This patchs
Signed-off-by: Denton Liu
---
t/t3507-cherry-pick-conflict.sh | 34 -
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
index 0db166152a..74ff925526 100755
--- a/t/t3507-cherry-pick-con
When get_cleanup_mode was provided with an invalid cleanup_arg, it used
to die. Warn user and fallback to default behaviour if an invalid
cleanup_arg is given.
Signed-off-by: Denton Liu
---
sequencer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/seque
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Note that the removal of the if-else tower in git_sequencer_config may
appear to be a no-op refactor but it actually isn't. First of all, we
now accept
Denton Liu writes:
> -e ::
> --exclude=::
> - In addition to those found in .gitignore (per directory) and
> - $GIT_DIR/info/exclude, also consider these patterns to be in the
> - set of the ignore rules in effect.
> + Use the exclude pattern in addition to those found in
> +
Denton Liu writes:
> Signed-off-by: Denton Liu
> ---
> t/t3507-cherry-pick-conflict.sh | 34 -
> 1 file changed, 17 insertions(+), 17 deletions(-)
A good preliminary clean-up. Looks good.
On Thu, 7 Mar 2019 at 07:57, Junio C Hamano wrote:
>
> Denton Liu writes:
>
> > + Use the exclude pattern in addition to those found in
> > + `.gitignore` and similar files (see linkgit:gitignore[5]).
> I do agree with the direction to abandon the attempt to be
> exhaustive, which has fa
On Thu, Mar 7, 2019 at 6:21 AM Junio C Hamano wrote:
> The change to this main function looks quite straight-forward. I am
> kind of surprised that a very low hanging fruit like this had survived
> without getting hit by parseopt a lot earlier ;-)
There are more (I guess we tag #leftovers nowada
Denton Liu writes:
> Fix a bug where the scissors line is placed after the Conflicts:
> section, in the case where a merge conflict occurs and
> commit.cleanup = scissors.
>
> Note that the removal of the if-else tower in git_sequencer_config may
> appear to be a no-op refactor but it actually is
83 matches
Mail list logo
