[PATCH] rebase docs: drop stray word in merge command description

Delete a misplaced word introduced by caafecfcf1 (rebase --rebase-merges: adjust man page for octopus support, 2018-03-09). Signed-off-by: Kyle Meyer --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt b/Documentation

Re: Git Evolve

Ævar Arnfjörð Bjarmason writes: > On Tue, Oct 02 2018, Taylor Blau wrote: [...] >> Specifically, I've wanted the 'hg absorb' command. My understanding of >> the commands functionality is that it builds a sort of flamegraph-esque >> view of the blame, and then cascades downwards parts of a

[PATCH v3] range-diff: update stale summary of --no-dual-color

-by: Kyle Meyer --- builtin/range-diff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/range-diff.c b/builtin/range-diff.c index f52d45d9d6..0aa9bed41f 100644 --- a/builtin/range-diff.c +++ b/builtin/range-diff.c @@ -25,7 +25,7 @@ int cmd_range_diff(int argc, const

Re: [PATCH] range-diff: update stale summary of --no-dual-color

Junio C Hamano writes: > Johannes Schindelin writes: [...] >>> - N_("color both diff and diff-between-diffs")), >>> + N_("restrict coloring to outer diff markers")), >> >> How about "use simple diff colors" instead? That's certainly better than the

[PATCH v2] range-diff: update stale summary of --no-dual-color

275267937b (range-diff: make dual-color the default mode, 2018-08-13) replaced --dual-color with --no-dual-color but left the option's summary untouched. Rewrite the summary to describe --no-dual-color rather than dual-color. Helped-by: Jonathan Nieder Signed-off-by: Kyle Meyer --- builtin

Re: [PATCH] range-diff: update stale summary of --no-dual-color

Jonathan Nieder writes: - N_("color both diff and diff-between-diffs")), + N_("restrict coloring to outer diff markers")), [...] > Aha: I think you're missing a few words (e.g. "color only according to > outer diff markers"). Though based on

Re: [PATCH] range-diff: update stale summary of --no-dual-color

Jonathan Nieder writes: [...] > What is an outer diff marker? The diff markers from the diff of patches as opposed to the ones from the original patches. I took the term from git-range-diff.txt: --no-dual-color:: When the commit diffs differ, `git range-diff` recreates the

[PATCH] range-diff: update stale summary of --no-dual-color

275267937b (range-diff: make dual-color the default mode, 2018-08-13) replaced --dual-color with --no-dual-color but left the option's summary untouched. Rewrite the summary to describe --no-dual-color rather than dual-color. Signed-off-by: Kyle Meyer --- builtin/range-diff.c | 2 +- 1 file

Re: git-bug: Distributed bug tracker embedded in git

[+cc Stefan Monnier] Jonathan Nieder writes: > (cc-ing Scott) [...] > I believe you're thinking of TicGit[1]. > > Some other related work is listed at [2]. Most of these projects have > gone quiet: > > - ditz[3] > - git-issues[4] > - cil[5] > - Bugs Everywhere[6] > - milli by Steve Kemp,

[PATCH] gitworkflows: fix grammar in 'Merge upwards' rule

Signed-off-by: Kyle Meyer --- Documentation/gitworkflows.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index 926e044d0..ca11c7bda 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation

Re: [PATCH] git{,-blame}.el: remove old bitrotting Emacs code

Ævar Arnfjörð Bjarmason writes: [...] > These days these modes have very few if users, and users of git aren't s/if// or s/if/if any/ ? -- Kyle

Re: [PATCH v2 6/7] reflog-walk: stop using fake parents

Jeff King writes: > Prior to this commit, we show both entries with > identical reflog messages. After this commit, we show > only the "comes back" entry. See the update in t3200 > which demonstrates this. > > Arguably either is fine, as the whole

Re: [PATCH v2 1/7] t1414: document some reflog-walk oddities

Jeff King writes: > +test_expect_failure 'walking multiple reflogs shows all' ' > + # We expect to see all entries for all reflogs, but interleaved by > + # date, with order no the command line breaking ties. We s/order no/order on/ -- Kyle

Re: name-rev: anchor pattern without --exclude?

Bryan Turner writes: [...] > If you don't need the ancestor traversals "git name-rev" provides, > "git for-each-ref --count 1 --format "%(refname:short)" --points-at > refs/heads/" might work. That only goes back to Git 2.7.0, > though; still quite a ways off your 1.9

Re: name-rev: anchor pattern without --exclude?

Junio C Hamano <gits...@pobox.com> writes: > Kyle Meyer <k...@kyleam.com> writes: > >> [*] A bit more information on why I'm trying to do this: In Magit, we >> have a work-in-progress feature that takes "snapshots" of changes >> before t

name-rev: anchor pattern without --exclude?

Hello, I'm trying to restrict name-rev's output to a ref whose name begins with the supplied pattern [*]. Looking at "man git-name-rev", builtin/name-rev.c, and wildmatch.c, I don't see a way to accomplish this with "--refs=". Say, for example, that I want to limit name-rev's output to a ref in

Re: Truncating HEAD reflog on branch move

Kyle Meyer <k...@kyleam.com> writes: > Eh, sorry about that. I haven't dug very deeply, but it seems like the > entry is still in .git/logs/HEAD, while "git reflog" is only showing > they latest entry. s/entry is still/missing entries are still/

Re: Truncating HEAD reflog on branch move

Junio C Hamano writes: > "brian m. carlson" writes: > >> I get the following on 2.11.0: >> >> 2cbfbd5 HEAD@{0}: >> 2cbfbd5 HEAD@{1}: checkout: moving from cPanel to master >> eaf8db2 HEAD@{2}: checkout: moving from master to cPanel >> 2cbfbd5

[PATCH] config.txt: add an entry for log.showSignature

The configuration variable log.showSignature is mentioned in git-log's manpage. Document it in git-config's manpage as well. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- Documentation/config.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/config.txt b/Documen

[PATCH] doc/revisions: remove brackets from rev^-n shorthand

Given that other instances of "{...}" in the revision documentation represent literal characters of revision specifications, describing the rev^-n shorthand as "^-{}" incorrectly suggests that something like "master^-{1}" is an acceptable form. Signed-off-b

[PATCH] t1400: use consistent style for test_expect_success calls

Structure calls as test_expect_success 'description' ' body ' Use double quotes for the description if it requires parameter expansion or contains a single quote. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- This patch follows up on a recent t1400 series: https://

[PATCH] doc/config: grammar fixes for core.{editor,commentChar}

Signed-off-by: Kyle Meyer <k...@kyleam.com> --- Documentation/config.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 0d8df5a9f..1df196545 100644 --- a/Documentation/config.txt +++ b/Documentation/conf

Re: [PATCH 0/5] t1400: modernize style

Junio C Hamano <gits...@pobox.com> writes: > Jeff King <p...@peff.net> writes: > >> On Mon, Mar 20, 2017 at 08:56:11PM -0400, Kyle Meyer wrote: [...] >>> I also considered >>> >>> * making the quoting/spacing/breaks around the test descripti

Re: [PATCH 2/5] t1400: set core.logAllRefUpdates in "logged by touch" tests

Jeff King <p...@peff.net> writes: > On Mon, Mar 20, 2017 at 08:56:13PM -0400, Kyle Meyer wrote: [...] >> I'm confused about the setup for the "logged by touch" tests. >> d0ab05849 (tests: remove some direct access to .git/logs, 2015-07-27) >> changed th

Re: [PATCH 0/5] t1400: modernize style

Jeff King <p...@peff.net> writes: > On Mon, Mar 20, 2017 at 08:56:11PM -0400, Kyle Meyer wrote: [...] >> * moving the here-documents for log creation into the following >> tests, but I don't think it's worth it because it makes already >> long lines eve

[PATCH 3/5] t1400: use test_path_is_* helpers

Signed-off-by: Kyle Meyer <k...@kyleam.com> --- t/t1400-update-ref.sh | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh index be8b113b1..c5c8e95fc 100755 --- a/t/t1400-update-

[PATCH 4/5] t1400: remove a set of unused output files

This test case redirects stdout and stderr to output files, but, unlike the other cases of redirection in the t1400 tests, these files are not examined downstream. Remove the redirection so that the output is visible when running the tests verbosely. Signed-off-by: Kyle Meyer <k...@kyleam.

[PATCH 2/5] t1400: set core.logAllRefUpdates in "logged by touch" tests

tests to disable core.logAllRefUpdates explicitly so that the behavior does not depend on the default value. While we're here, update the "logged by config" tests to use test_config() rather than setting core.logAllRefUpdates to "true" outside of the tests. Signed-

[PATCH 0/5] t1400: modernize style

These patches follow up on Peff's suggestion to modernize the style in t1400-update-ref.sh. 20170217082253.kxjezkxfqkfxj...@sigill.intra.peff.net The first two commits aren't concerned with "modernizing" the tests, but instead address issues that I noticed while looking more closely at

[PATCH 5/5] t1400: use test_when_finished for cleanup

Move cleanup lines that occur after test blocks into test_when_finished calls within the test bodies. Don't move cleanup lines that seem to be related to mutiple tests rather than a single test. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- t/t1400-update-ref.s

[PATCH 1/5] t1400: rename test descriptions to be unique

A few tests share their description with another test. Extend the descriptions to indicate how the tests differ. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- t/t1400-update-ref.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t1400-update-ref.sh b/t

Re: [PATCH v2 1/4] delete_ref: accept a reflog message argument

Duy Nguyen writes: > You'll probably want to update the comment block above if msg can be > NULL. We have _very_ good documentation in this file, let's keep it > uptodate. Looking at how other functions in refs.h document their "msg" or "logmsg" parameter, none seem to

Re: [PATCH v2 0/4] delete_ref: support reflog messages

Junio C Hamano writes: > These looked reasonable. I had to resolve conflicts with another > topic in flight that removed set_worktree_head_symref() function > while queuing, and I think I resolved it correctly, but please > double check what is pushed out on 'pu'. The merge

[PATCH v2 1/4] delete_ref: accept a reflog message argument

set by split_head_update(), resulting in the deletion being logged. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- builtin/am.c | 4 ++-- builtin/branch.c | 2 +- builtin/notes.c| 4 ++-- builtin/remote.c | 4 ++-- builtin/replace.c | 2 +- builtin/r

[PATCH v2 0/4] delete_ref: support reflog messages

lete_refs" was written instead of "delete_ref". Kyle Meyer (4): delete_ref: accept a reflog message argument update-ref: pass reflog message to delete_ref() rename_ref: replace empty message in HEAD's log branch: record creation of renamed branch in HEAD's log bra

[PATCH v2 3/4] rename_ref: replace empty message in HEAD's log

HEAD's log to also include the second part of the rename, the creation of the new branch. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Kyle Meyer <k...@kyleam.com> --- refs/files-backend.c | 2 +- t/t3200-branch.sh| 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff

[PATCH v2 4/4] branch: record creation of renamed branch in HEAD's log

. Based-on-patch-by: Jeff King <p...@peff.net> Signed-off-by: Kyle Meyer <k...@kyleam.com> --- branch.c | 5 +++-- branch.h | 3 ++- builtin/branch.c | 5 +++-- refs.h | 3 ++- refs/files-backend.c | 4 ++-- t/t3200-branch.sh| 5 +++-- 6 files

[PATCH v2 2/4] update-ref: pass reflog message to delete_ref()

Now that delete_ref() accepts a reflog message, pass the user-provided message to delete_ref() rather than silently dropping it. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- builtin/update-ref.c | 2 +- t/t1400-update-ref.sh | 18 ++ 2 files changed, 19 insertions

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Jeff King writes: > On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote: > >> Yes. I think the options are basically (in order of decreasing >> preference in my opinion): >> >> 1. Log a rename entry (same sha1, but note the rename in the free-form >> text). >> >>

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Junio C Hamano writes: [...] > Do we even want these "internal" delete_ref() invocations to be > logged in HEAD's reflog? I understand that this is inside the > implementation of renaming an old ref to a new ref, and reflog > message given to delete_ref() would matter only

Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs

Jeff King writes: [...] >> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh >> index b0ffc0b57..65918d984 100755 >> --- a/t/t1400-update-ref.sh >> +++ b/t/t1400-update-ref.sh >> @@ -85,6 +85,15 @@ test_expect_success "delete $m (by HEAD)" ' >> ' >> rm -f .git/$m >>

Re: [PATCH 1/3] delete_refs(): accept a reflog message argument

Junio C Hamano writes: > Jeff King writes: > >>> diff --git a/refs.h b/refs.h >>> index 9fbff90e7..81627a63d 100644 >>> --- a/refs.h >>> +++ b/refs.h >>> @@ -277,7 +277,7 @@ int reflog_exists(const char *refname); >>> * be NULL_SHA1. flags is passed through

[PATCH 1/3] delete_refs(): accept a reflog message argument

it along to ref_transaction_delete(). Modify all callers to pass NULL for the new message argument; no change in behavior is intended. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- builtin/am.c | 4 ++-- builtin/branch.c | 2 +- builtin/notes.c| 4 ++-- builtin/re

[PATCH 2/3] update-ref: pass reflog message argument to delete_refs

branch. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- I'm not sure if the test here (or in the next patch) is worth including. builtin/update-ref.c | 2 +- t/t1400-update-ref.sh | 9 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/builtin/update-ref.c b/builtin/

[PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

the renaming event with a message of "Branch: renamed ...". Signed-off-by: Kyle Meyer <k...@kyleam.com> --- refs/files-backend.c | 8 +++- t/t3200-branch.sh| 4 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/refs/files-backend.c b/refs/files-backend.c

[PATCH 0/3] delete_ref(): support reflog messages

[Sorry for the slow response.] Jeff King <p...@peff.net> writes: > On Mon, Jan 16, 2017 at 06:17:29PM -0500, Kyle Meyer wrote: [...] >>$ cat .git/logs/refs/heads/new-master >> 00000... 68730... Kyle Meyer <k...@kyleam.com> 1484607020 -0500 commit

Re: init --separate-git-dir does not set core.worktree

Duy Nguyen <pclo...@gmail.com> writes: > On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer <k...@kyleam.com> wrote: [...] >> * COMMIT_EDITMSG in .git/modules//: set working tree to the >>output of "git rev-parse --show-toplevel" >> >> * COM

Re: init --separate-git-dir does not set core.worktree

Duy Nguyen <pclo...@gmail.com> writes: > On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer <k...@kyleam.com> wrote: >> >> As of 6311cfaf9 (init: do not set unnecessary core.worktree, >> 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree &g

init --separate-git-dir does not set core.worktree

Hello, As of 6311cfaf9 (init: do not set unnecessary core.worktree, 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree (test below). Based on the commit message and the corresponding thread [1], I don't think this change in behavior was intentional, but I wasn't able to

HEAD's reflog entry for a renamed branch

git branch -m master new-master resulted in the following reflogs: $ cat .git/logs/refs/heads/new-master 0... 68730... Kyle Meyer <k...@kyleam.com> 1484607020 -0500 commit (initial): Add file.txt 68730... 68730... Kyle Meyer <k...@kyleam.com> 1484607020 -0500 Br

Re: [PATCH] branch_get_push: do not segfault when HEAD is detached

Jeff King <p...@peff.net> writes: > On Fri, Jan 06, 2017 at 08:09:32PM -0500, Kyle Meyer wrote: > >> > $ git grep -c HEAD^{} junio/pu -- t/ >> > junio/pu:t/t3200-branch.sh:3 >> > >> > Maybe use HEAD^0 just for consistency? >> >> Yes, tha

[PATCH v2] branch_get_push: do not segfault when HEAD is detached

Move the detached HEAD check from branch_get_push_1() to branch_get_push() to avoid setting branch->push_tracking_ref when branch is NULL. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- remote.c | 6 +++--- t/t1514-rev-parse-push.sh | 6 ++ 2 files changed, 9 i

Re: [PATCH] branch_get_push: do not segfault when HEAD is detached

Johannes Schindelin writes: [...] >> +test_expect_success 'resolving @{push} fails with a detached HEAD' ' >> +git checkout HEAD^{} && > > I seem to recall that we prefer HEAD^0 over HEAD^{} and the existing > scripts seem to agree with me: > > $ git grep -c

[PATCH] branch_get_push: do not segfault when HEAD is detached

Move the detached HEAD check from branch_get_push_1() to branch_get_push() to avoid setting branch->push_tracking_ref when branch is NULL. Signed-off-by: Kyle Meyer <k...@kyleam.com> --- remote.c | 6 +++--- t/t1514-rev-parse-push.sh | 6 ++ 2 files changed, 9 i

What's the ".git/gitdir" file?

Hello, When a ".git" file points to another repo, a ".git/gitdir" file is created in that repo. For example, running $ mkdir repo-a repo-b $ cd repo-a $ git init $ cd ../repo-b $ echo "gitdir: ../repo-a/.git" > .git $ git status results in a file "repo-a/.git/gitdir"