and html.
Signed-off-by: Martin Ågren
---
See
https://git-scm.com/docs/git-init#git-init---sharedfalsetrueumaskgroupallworldeverybody0xxx
Documentation/git-init.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 3c5a67fb96
his commit, both for git-status.1
and git-status.html.
Signed-off-by: Martin Ågren
---
See https://git-scm.com/docs/git-status#_short_format ,
https://git-scm.com/docs/git-status#_branch_headers and
https://git-scm.com/docs/git-status#_changed_tracked_entries .
Documentation/git-status
few URLs which show the current
Asciidoctor rendering at git-scm.com.
With Asciidoc, `doc-diff origin/master HEAD` reports that there is no
difference.
[1]
https://public-inbox.org/git/can0hesob+ac4bvm-vukvpzkxrtw53-d91a55nx5kc7zynxn...@mail.gmail.com/
Martin Ågren (4):
git-column.txt: fix
t;. Asciidoc
renders identically before and after this patch, both man-page and html.
Signed-off-by: Martin Ågren
---
See https://git-scm.com/docs/git-log#git-log--g and
https://git-scm.com/docs/git-rev-list#git-rev-list--g . The indentation
doesn't look too bad, but the "+ Under" is clea
rendering the dashes literally.
Make sure we have as many dashes as we have characters in "Examples".
This fixes the section-issue and, somehow, makes the listing blocks
render correctly.
Asciidoc renders identically before and after this patch, both man-page
and html.
Signed-
On Sun, 16 Dec 2018 at 11:51, Jeff King wrote:
>
> On Sat, Dec 15, 2018 at 12:27:39PM +0100, Martin Ågren wrote:
>
> > We have too few dashes under "Examples", which causes Asciidoctor to not
> > pick it up as a section header, but to instead just render the dashes
as we have characters in "Examples".
Asciidoc renders identically before and after this patch, both man-page
and html.
Signed-off-by: Martin Ågren
---
Documentation/git-column.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-column.txt b/Documentation/
renders identically before and after this patch, both
man-pages and html.
This also makes Asciidoctor stop rendering a literal '+' before "Under
--pretty=oneline ..." in the manuals for git-log and git-rev-list.
Signed-off-by: Martin Ågren
---
Documentation/git-
his commit, both for git-status.1
and git-status.html.
Signed-off-by: Martin Ågren
---
Documentation/git-status.txt | 162 ++-
1 file changed, 85 insertions(+), 77 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index
comments on v1.
[1]
https://public-inbox.org/git/20181215112742.1475882-1-martin.ag...@gmail.com/
Martin Ågren (3):
git-column.txt: fix section header
Documentation: do not nest open blocks
git-status.txt: render tables correctly under Asciidoctor
Documentation/git-column.txt | 2
On Sun, 16 Dec 2018 at 11:45, Jeff King wrote:
>
> On Sat, Dec 15, 2018 at 12:27:38PM +0100, Martin Ågren wrote:
> I think the relevant bits from [1] are:
>
> * Use `make --always-make ... install-man` in doc-diff.
> * ./doc-diff -f HEAD HEAD # note -f
> * Add empty commit
On Mon, 17 Dec 2018 at 22:56, Jonathan Nieder wrote:
> That makes experimenting with the stripspace command unnecessarily
> fussy. Fix it by discovering the git directory gently, as intended
> all along.
> if (mode == STRIP_COMMENTS || mode == COMMENT_LINES) {
> - setup_git
introduced `struct repository_format`, and brian, who
introduced its `hash_algo` field (see patch 2).
Martin Ågren (3):
setup: drop return value from `read_repository_format()`
setup: do not use invalid `repository_format`
setup: add `clear_repository_format()`
cache.h | 13
at was changed in v2. Almost three years
later, no-one has used this return value.
Signed-off-by: Martin Ågren
---
I only discovered the full history after writing the patch. Had I known
it from the beginning, maybe I'd have just skipped this step, but I was
sufficiently disturbed by the
and
`hash_algo = GIT_HASH_SHA1`?), but "clear()" and/or "read()" seem like
the wrong places to enforce fallback configurations. Let's leave things
as "undefined" instead to encourage users to check `version`.
Signed-off-by: Martin Ågren
---
The error state can always
lid ref."
because it has moved .git/config out of the way and is now trying to use
a bad hash algorithm.
Check that `version` is non-negative before using `hash_algo`.
This patch adds no tests, but do note that if we skip this patch, the
next patch would cause existing tests to fail as outlined
On Wed, 19 Dec 2018 at 16:27, Jeff King wrote:
>
> On Tue, Dec 18, 2018 at 08:25:26AM +0100, Martin Ågren wrote:
>
> > No-one looks at the return value, so we might as well drop it. It's
> > still available as `format->version`.
>
> Hmm. If we have to pick one,
On Wed, 19 Dec 2018 at 01:18, brian m. carlson
wrote:
> I think this change is fine, because we initialize the value in
> the_repository elsewhere, and if there's no repository, this should
> never have a value other than the default anyway.
Thanks, it feels good that this patch matches how you t
On Wed, 19 Dec 2018 at 16:38, Jeff King wrote:
>
> On Tue, Dec 18, 2018 at 08:25:27AM +0100, Martin Ågren wrote:
>
> > Check that `version` is non-negative before using `hash_algo`.
> Hmm. It looks like we never set repo_fmt.hash_algo to anything besides
> GIT_HASH_SHA
On Wed, 19 Dec 2018 at 16:48, Jeff King wrote:
>
> On Tue, Dec 18, 2018 at 08:25:28AM +0100, Martin Ågren wrote:
>
> > +void clear_repository_format(struct repository_format *format)
> > +{
> > + string_list_clear(&format->unknown_extensions, 0)
On Tue, 18 Dec 2018 at 13:00, Johannes Schindelin
wrote:
> > Makes me wonder if `setup_git_directory_gently()` should BUG if it
> > receives NULL. That would require some reshuffling in setup.c, since
> > `setup_git_directory()` calls out to it with NULL... Just thinking out
> > loud. In any case,
On Sat, 5 Jan 2019 at 07:07, Nguyễn Thái Ngọc Duy wrote:
>
> hold_locked_index() assumes the index path at $GIT_DIR/index. This is
> not good for places that take an arbitrary index_state instead of
> the_index, which is basically everywhere except builtin/.
>
> Replace it with repo_hold_locked_in
On Tue, 8 Jan 2019 at 00:34, Junio C Hamano wrote:
> * bc/sha-256 (2018-11-14) 12 commits
> - hash: add an SHA-256 implementation using OpenSSL
> - sha256: add an SHA-256 implementation using libgcrypt
> - Add a base implementation of SHA-256 support
> - commit-graph: convert to using the_hash
On Wed, 9 Jan 2019 at 08:37, Martin Ågren wrote:
>
> On Tue, 8 Jan 2019 at 00:34, Junio C Hamano wrote:
> > * bc/sha-256 (2018-11-14) 12 commits
> > - hash: add an SHA-256 implementation using OpenSSL
> > - sha256: add an SHA-256 implementation using libgcrypt
> >
On Thu, 10 Jan 2019 at 02:03, brian m. carlson
wrote:
>
> On Wed, Jan 09, 2019 at 10:06:08PM +0100, Martin Ågren wrote:
> > i.e., we copy sizeof(struct object_id) (=32) bytes. Which is 12 more
> > than what is known to be safe. For this particular input data, we read
> >
remain
plugged).
[1]
https://public-inbox.org/git/20181218072528.3870492-1-martin.ag...@gmail.com/#t
Martin Ågren (3):
setup: free old value before setting `work_tree`
setup: do not use invalid `repository_format`
setup: add `clear_repository_format()`
cache.h | 12 +++
Before assigning to `data->work_tree` in `read_worktree_config()`, free
any value we might already have picked up, so that we do not leak it.
Signed-off-by: Martin Ågren
---
setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/setup.c b/setup.c
index 1be5037f12..bb633942bb 100644
--
lid ref."
because it has moved .git/config out of the way and is now trying to use
a bad hash algorithm.
Check that `version` is non-negative before using `hash_algo`.
This patch adds no tests, but do note that if we skip this patch, the
next patch would cause existing tests to fail as outlined
roing
the struct. In the error path of the same function, be sure to restore
the error sentinel after we clear it with the rest of the struct.
Signed-off-by: Martin Ågren
---
I do wonder if introducing and depending on `REPOSITORY_FORMAT_INIT`
like this is 100% sane. Out-of-tree users cou
On Tue, 15 Jan 2019 at 20:31, Jeff King wrote:
>
> On Mon, Jan 14, 2019 at 07:34:56PM +0100, Martin Ågren wrote:
>
> > This can be observed by adding this to the end of
> > `read_repository_format()`:
> >
> > if (format->version == -1)
> >
Hi Brandon,
Welcome to the list! :-)
On Thu, 17 Jan 2019 at 20:30, Brandon Richardson
wrote:
> Subject: [PATCH] Allow usage of --gpg-sign flag in commit-tree builtin.
Good find!
Maybe "commit-tree: handle --gpg-sign" which looks more like what we
see in `git log --oneline builtin/commit-tree.
Hi Brandon,
On Fri, 18 Jan 2019 at 02:12, Brandon Richardson
wrote:
>
> Add --gpg-sign option in commit-tree, which was documented, but not
> implemented, in 55ca3f99ae.
>
> Signed-off-by: Brandon Richardson
> ---
Thank you for an updated version!
> builtin/commit-tree.c| 8 +++-
> t/
On Fri, 18 Jan 2019 at 18:23, SZEDER Gábor wrote:
> write_commit_graph() unconditionally invokes
> write_graph_chunk_large_edges(), even when it was decided earlier that
> that chunk won't be written. Strictly speaking there is no bug here,
> because write_graph_chunk_large_edges() won't write an
rify that "ninth-unsigned" is
indeed unsigned.
We have a similar problem a few lines later. If `git commit-tree -S`
fails with no output, we will happily tag HEAD as "tenth-signed". Here,
we are not so lucky. The tag ends up on the same commit as
"eighth-signed-alt",
On Sat, 19 Jan 2019 at 16:46, Martin Ågren wrote:
> # commit.gpgsign is still on but this must not be signed
> - git tag ninth-unsigned $(echo 9 | git commit-tree HEAD^{tree}) &&
> + echo 9 | git commit-tree HEAD^{tree} >oid &&
>
Hi Brandon,
On Sat, 19 Jan 2019 at 19:05, Brandon Richardson
wrote:
> > I looked into this test in a bit more detail, and it seems to be quite
> > hard to get right. Part of the reason is that `git commit-tree` requires
> > a bit more careful use than `git commit`, but part of it is that the
> >
Hi Brandon,
On Sun, 20 Jan 2019 at 00:24, Brandon Richardson
wrote:
> # explicit -S of course must sign.
> echo 10 | git commit-tree -S HEAD^{tree} >oid &&
> test_line_count = 1 oid &&
> - git tag tenth-signed $(cat oid)
> + git tag tenth-signed $(cat oid) &&
>
On Tue, 22 Jan 2019 at 08:07, Jeff King wrote:
>
> On Thu, Jan 17, 2019 at 07:31:14AM +0100, Martin Ågren wrote:
>
> > Something like the below on top of this series (then rebased). (The last
> > hunk below is a revert of this patch.)
>
> Yes, that's exactly what
On Tue, 22 Jan 2019 at 20:07, Junio C Hamano wrote:
>
> Martin Ågren writes:
>
> >> + echo 11 | git commit-tree --gpg-sign HEAD^{tree} >oid &&
> >> + test_line_count = 1 oid &&
> >> + git tag eleventh-signed $(cat oid
partial configuration we have picked up. For "extensions.*",
that's fine, since they require a positive version number. For
"core.bare" and "core.worktree", we're already verifying that we have a
non-negative version number before using them.
Signed-off-by: Mar
Before assigning to `data->work_tree` in `read_worktree_config()`, free
any value we might already have picked up, so that we do not leak it.
Signed-off-by: Martin Ågren
Signed-off-by: Junio C Hamano
---
setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/setup.c b/setup.c
in
On Tue, 22 Jan 2019 at 14:34, Martin Ågren wrote:
>
> On Tue, 22 Jan 2019 at 08:07, Jeff King wrote:
>
> > For the record, I can live with it either way. There are so many funky
> > little setup corner cases in the code already, and we don't even really
> > have
On Wed, 23 Jan 2019 at 06:57, Jeff King wrote:
>
> On Tue, Jan 22, 2019 at 10:45:48PM +0100, Martin Ågren wrote:
>
> > Call `clear_...()` at the start of `read_...()` instead of just zeroing
> > the struct, since we sometimes enter the function multiple times. This
> >
On Thu, 24 Jan 2019 at 01:15, brian m. carlson
wrote:
>
> On Wed, Jan 23, 2019 at 12:57:05AM -0500, Jeff King wrote:
> > > +void clear_repository_format(struct repository_format *format)
> > > +{
> > > + string_list_clear(&format->unknown_extensions, 0);
> > > + free(format->work_tree);
> > >
08-31) where we moved the call to
`cd_to_toplevel` to much earlier. Move it back to where it was, and
teach the "--clean" code to cd on its own. This way, we only cd once
we've verified the arguments.
Signed-off-by: Martin Ågren
---
Documentation/doc-diff | 8 +---
1 file chan
On Sun, 3 Feb 2019 at 10:12, Eric Sunshine wrote:
>
> On Sun, Feb 3, 2019 at 4:08 AM Eric Sunshine wrote:
> > I wonder if a more fruitful, longer-term fix which would save us from
> > having to worry about this in the future, would be to make
> > git-sh-setup.sh remember the original $0 before cd
h for $0 and then use that, instead. I'm not aware of any
portable way of doing that, see, e.g., d2addc3b96 ("t7800: readlink
may not be available", 2016-05-31), so let's just fix this user
instead.
Signed-off-by: Martin Ågren
---
> Punting and extending the commit messag
don't really
need it and we can work with absolute paths instead. There's just one
use of $PWD that we need to adjust by simply dropping it.
Suggested-by: Jeff King
Signed-off-by: Martin Ågren
---
Thanks Peff for the suggestions. Trying not to cd at all seems sane to
me. That it allows
On Sat, 30 Mar 2019 at 19:30, Todd Zullinger wrote:
>
> Just chipping away at the remaining differences between asciidoc and
> asciidoctor.
>
> Todd Zullinger (2):
> Documentation/rev-list-options: wrap --date= block with "--"
> Documentation/git-status: fix titles in porcelain v2 section
Nic
Hi Junio
On Fri, 29 Mar 2019 at 20:52, SZEDER Gábor wrote:
>
> On Fri, Mar 29, 2019 at 01:35:19PM +0100, SZEDER Gábor wrote:
> > The release of Asciidoctor v2.0.0 two days ago broke our documentation
>
> Well, what happened "two days ago" when I sent v2 is now seven days
> ago... Let's just say
Hi Todd,
On Fri, 5 Apr 2019 at 03:40, Todd Zullinger wrote:
> > On Sat, 30 Mar 2019 at 19:30, Todd Zullinger wrote:
> >>
> >> Just chipping away at the remaining differences between asciidoc and
> >> asciidoctor.
> >>
> >> Todd Zullinger (2):
> >> Documentation/rev-list-options: wrap --date=
On Sat, 6 Apr 2019 at 00:51, Todd Zullinger wrote:
> Here's what I have currently. I haven't tested this much with
> asciidoctor-1.5.x releases (or maybe not at all -- it's been a
> week or so since I worked on this).
Tested with Asciidoctor 1.5.5. For both patches, AsciiDoctor stumbles
before t
On Sat, 6 Apr 2019 at 00:51, Todd Zullinger wrote:
>
> The {apostrophe} was needed at the time of a521845800 ("Documentation:
> remove stray backslash in show-branch discussion", 2010-08-20). All
> other uses of {apostrophe} were removed in 6cf378f0cb ("docs: stop using
> asciidoc no-inline-liter
On Sat, 6 Apr 2019 at 00:51, Todd Zullinger wrote:
>
> The second paragraph in the CONFIGURATION section intends to emphasize
> the word 'must' with bold type. Adjust the formatting slightly to
> provide similar results between asciidoc and asciidoctor.
I don't think this explains the problem yo
Hi Dscho,
On Sat, 8 Jun 2019 at 16:45, Johannes Schindelin via GitGitGadget
wrote:
>
> From: Johannes Schindelin
>
> On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
> that the idea Bash has of the current directory differs in case from
> what Git thinks it is. That's total
Hi Rohit,
On Thu, 13 Jun 2019 at 19:46, Phillip Wood wrote:
>
> On 13/06/2019 05:05, Rohit Ashiwal wrote:
> > -static int create_seq_dir(void)
> > +static int create_seq_dir(struct repository *r)
> > {
> > - if (file_exists(git_path_seq_dir())) {
> > - error(_("a cherry-pick or r
On Thu, 13 Jun 2019 at 19:54, René Scharfe wrote:
>
> Calculating the sum of two array indexes to find the midpoint between
> them can overflow, i.e. code like this is unsafe for big arrays:
>
> mid = (first + last) >> 1;
>
> Make sure the intermediate value stays within the boundaries ins
On Thu, 13 Jun 2019 at 23:33, René Scharfe wrote:
>
> Am 13.06.19 um 21:42 schrieb Martin Ågren:
> > On Thu, 13 Jun 2019 at 19:54, René Scharfe wrote:
> >> Make sure the intermediate value stays within the boundaries instead,
> >> like this:
> >>
> >
Hi Catalin
Welcome to the list!
On Tue, 25 Jun 2019 at 09:43, Catalin Criste wrote:
> @@ -88,7 +88,7 @@ save [-p|--patch] [-k|--[no-]keep-index]
> [-u|--include-untracked] [-a|--all] [-q
>
> This option is deprecated in favour of 'git stash push'. It
> differs from "stash push
On Tue, 25 Jun 2019 at 13:40, Johannes Schindelin
wrote:
> On Tue, 25 Jun 2019, Martin Ågren wrote:
> > Do you have any suggestions as to how this could be made clearer?
> > There are at least two of us that have stumbled on this. :-)
>
> Make that three.
>
we need to be careful not
to zero `used_atom_cnt` until after we've called `free_array_item()`. We
could move just a single line, but let's keep related things close
together instead, by first handling `array`, then `used_atom`.
Signed-off-by: Martin Ågren
---
ref-filter.c | 14 +++
Hi Ariadne,
Welcome to the list!
On Thu, 11 Jul 2019 at 18:39, Ariadne Conill wrote:
>
> Hello,
>
> On Thu, Jul 11, 2019 at 10:19 AM brian m. carlson
> wrote:
> >
> > On 2019-07-11 at 08:19:58, Ariadne Conill wrote:
> > > The `git log` command shows the author and committer name recorded in
> >
On Thu, 11 Jul 2019 at 20:39, Ariadne Conill wrote:
>
> In order to prove that the --no-use-mailmap option works as expected,
> we add a test for it which runs with -c log.mailmap=true to ensure that
> the option successfully negates the configured default.
I believe that testing with `-c log.mai
On Fri, 12 Jul 2019 at 00:16, brian m. carlson
wrote:
>
> On 2019-07-11 at 21:36:50, Michael Kielstra wrote:
> > Hi all,
> >
> > I noticed that git pull reports "Already up to date." but git push
> > reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
> > the Ubuntu repos.) Jus
On Fri, 19 Jul 2019 at 00:57, Josh Steadmon wrote:
> --- /dev/null
> +++ b/templates/hooks--pre-merge.sample
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +#
> +# An example hook script to verify what is about to be committed.
> +# Called by "git merge" with no arguments. The hook should
> +# exit with non-z
On Fri, 19 Jul 2019 at 00:57, Josh Steadmon wrote:
> From: Michael J Gruber
>
> Analogous to commit, introduce a '--no-verify' option which bypasses the
> pre-merge hook. The shorthand '-n' is taken by the (non-existing)
> '--no-stat' already.
I don't understand this "(non-existing)". I realize
On Fri, 19 Jul 2019 at 00:57, Josh Steadmon wrote:
> +test_expect_success '--no-verify with succeeding hook (merge)' '
> +
> + git checkout side &&
> + git merge --no-verify -m "merge master" master &&
> + git checkout master
> +
> +'
This test doesn't even try to verify that th
On Fri, 19 Jul 2019 at 01:56, Josh Steadmon wrote:
> * Martin's objection on 1/4 that the sample hook would always exit
> successfully is (I believe) incorrect. To test this, I ran
> "/bin/true && exec test 0 == 1" in a /bin/sh subshell, and it
> correctly had a non-zero exit status.
I retr
On Fri, 19 Jul 2019 at 01:56, Josh Steadmon wrote:
> This series revives an old suggestion [...] to make merge honor
> pre-commit hook or a separate pre-merge hook. Since pre-commit does not
> receive any arguments (which the hook could use tell between commit and
> merge) and in order to keep exi
On Tue, 30 Jul 2019 at 01:43, Josh Steadmon wrote:
>
> On 2019.07.29 22:04, Martin Ågren wrote:
> > This script seems to me like if it passes 100%, we can be fairly sure
> > we're ok, but [...]
> Will squash these as you said in V3. Will also think about whether
>
Fix the spelling of the new "--no-show-forced-updates" option that "git
fetch/pull" learned. Similarly, spell "--function-context" correctly and
fix a few typos, grammos and minor mistakes.
One of these is also in 2.22.1.txt, so fix it there too.
Signed-off-by: Ma
On Thu, 1 Aug 2019 at 17:57, Junio C Hamano wrote:
>
> Martin Ågren writes:
>
> > Fix the spelling of the new "--no-show-forced-updates" option that "git
> > fetch/pull" learned. Similarly, spell "--function-context" correctly and
> > fi
On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index 82cd573776..7c4c994858 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -103,6 +103,13 @@ The default 'pre-commit' hook, when enabled--
AFAIU, we avoid using `touch` unless we really do want to update the
mtime. Here, we just want to create empty files, so write `>foo`
instead.
Signed-off-by: Martin Ågren
---
...3-pre-commit-and-pre-merge-commit-hooks.sh | 38 ---
1 file changed, 24 insertions(+), 14 deleti
With a failing automatic merge, we want to make sure that we *don't*
call the pre-merge-commit hook and that we (eventually) *do* call the
pre-commit hook.
Signed-off-by: Martin Ågren
---
...3-pre-commit-and-pre-merge-commit-hooks.sh | 30 +++
1 file changed, 30 inser
one when they're both available.
Feel free to pick and squash as you see fit. (I don't think it makes
sense to have these go in as-are. They really are meant for squashing.)
Martin
Martin Ågren (5):
t7503: use "&&" in "test_when_finished" rather than
If we fail to call the hook, we won't append to "actual_hooks".
"test_cmp" is able to handle a missing file just fine, so these
"pre-creations" are mostly confusing. Let's drop them.
Signed-off-by: Martin Ågren
--
This "pre-creation" does pr
Signed-off-by: Martin Ågren
---
t/t7503-pre-commit-and-pre-merge-commit-hooks.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7503-pre-commit-and-pre-merge-commit-hooks.sh
b/t/t7503-pre-commit-and-pre-merge-commit-hooks.sh
index 86a375ab3e..5cc6c98375 100755
--- a
;t start affecting later tests too.
Signed-off-by: Martin Ågren
---
...3-pre-commit-and-pre-merge-commit-hooks.sh | 60 +++
1 file changed, 20 insertions(+), 40 deletions(-)
diff --git a/t/t7503-pre-commit-and-pre-merge-commit-hooks.sh
b/t/t7503-pre-commit-and-pre-merge-commit-ho
On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
>
> t7503 did not verify that the expected hooks actually ran during
> testing. Fix that by making the hook scripts write their $0 into a file
> so that we can compare actual execution vs. expected execution.
It could be argued that this test is p
lue larger
than `INT_MAX` before that step, which it can't have had.
Let's be explicit about breaking out of the loop. This helps the
compiler grok our intention. As a bonus, it might make it (even) more
obvious to human readers that the loop stops at the first space.
While a
On Sun, 28 Oct 2018 at 20:01, Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 11:32 AM Martin Ågren wrote:
> > [...]
> > Let's be explicit about breaking out of the loop. This helps the
> > compiler grok our intention. As a bonus, it might make it (even) more
>
pe of `i`.
[1]
https://public-inbox.org/git/CAPig+cQbG2s-LrAo9+7C7=dXifbWFJ3SzuNa-QePHDk7egK=j...@mail.gmail.com/
[2]
https://public-inbox.org/git/capig+crju6nixpt2frdwz0x1hmgf1ojvzj3uk2qxege-s7i...@mail.gmail.com/
Helped-by: Eric Sunshine
Signed-off-by: Martin Ågren
---
Thanks for the commen
On Wed, 31 Oct 2018 at 18:28, Eric Sunshine wrote:
>
> On Wed, Oct 31, 2018 at 10:54 AM Johannes Schindelin
> wrote:
> > ACK. Thanks for cleaning up after me,
>
> Looks good to me, as well. Thanks for working on it.
Thanks, both of you.
Martin
On Wed, 7 Nov 2018 at 13:22, Ævar Arnfjörð Bjarmason wrote:
> +
> +This is particularly true when passing in diff options. Currently some
> +options like `--stat` can as an emergent effect produce output that's
> +quite useless in the context of `range-diff`. Future versions of
> +`range-diff` may
On Thu, 8 Nov 2018 at 21:53, Stefan Beller wrote:
>
> From: SZEDER Gábor
>
I haven't followed the original discussion too carefully, so I'll read
this like someone new to the topic probably would.
A nit, perhaps, but I was genuinely confused at first. The subject is
"Makefile: add pending seman
On Sat, 10 Nov 2018 at 01:10, Stefan Beller wrote:
> I dialed back on the workflow, as we may want to explore it first
> before writing it down.
Makes sense.
FWIW, this iteration looks good to me.
Martin
On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
wrote:
> However, the `.lock` file was still open and on Windows that means
> that it could not be deleted properly. This patch fixes that issue.
Hmmm, doesn't the tempfile machinery remove the lock file when we die?
> ref_count =
On Fri, 23 Nov 2018 at 11:13, Johannes Schindelin
wrote:
> On Mon, 30 Oct 2017, Pranit Bauva wrote:
>
> > On Fri, Oct 27, 2017 at 10:58 PM, Martin Ågren
> > wrote:
> > > On 27 October 2017 at 17:06, Pranit Bauva wrote:
> > >> +static voi
On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote:
>
> Hi!
> The git-reset documentation page section which is accessible via URL
> https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
[snip]
>
> The web archive has got a snapshot from 2014-06-28 when it was ok
> (https://web.arch
his commit, both for git-reset.1
and git-reset.html.
Reported-by: Paweł Samoraj
Signed-off-by: Martin Ågren
---
Documentation/git-reset.txt | 140
1 file changed, 78 insertions(+), 62 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git
On Wed, 28 Nov 2018 at 13:02, Martin Ågren wrote:
>
> On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote:
> >
> > The git-reset documentation page section which is accessible via URL
> > https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
>
Large parts of this document do not use `backticks` around literal
examples such as branch names (`topic/wip`), git usages, `HEAD` and
`` so they render as ordinary text. Fix that.
Signed-off-by: Martin Ågren
---
Documentation/git-reset.txt | 131 ++--
1 file
On Wed, 28 Nov 2018 at 20:45, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Nov 28 2018, Martin Ågren wrote:
>
> > Asciidoctor removes the indentation of each line in these tables, so the
> > last lines of each table have a completely broken alignment.
>
> Earlier I was trying
for this, that code path could also go, either as part of this
commit, or separately, once we've cut 2.20.
* The range-diff is written colored regardless of destination, i.e.,
when written to a file, it contains garbage.
Signed-off-by: Martin Ågren
---
builtin/log.c | 12 +
ead code and figuring out it isn't
actually dead and we've broken 2.20, just leave it for now.
Signed-off-by: Martin Ågren
---
Here's another attempt at fixing this recent regression.
t/t3206-range-diff.sh | 20 +---
builtin/log.c | 13 -
log
Some items that should be in "Performance, Internal Implementation,
Development Support etc." have ended up in "UI, Workflows & Features"
and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
Signed-off-by: Martin Ågren
---
Docu
I had to read this sentence a few times to understand it. Let's try to
clarify it.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.20.0.txt
b/Documentation/RelNotes/2.20.0.txt
.
Nothing critical.
Martin
Martin Ågren (3):
RelNotes 2.20: move some items between sections
RelNotes 2.20: clarify sentence
RelNotes 2.20: drop spurious double quote
Documentation/RelNotes/2.20.0.txt | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
--
2.2
We have three double-quote characters, which is one too many or too few.
Dropping the last one seems to match the original intention best.
Signed-off-by: Martin Ågren
---
Documentation/RelNotes/2.20.0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes
1 - 100 of 749 matches
Mail list logo
