Re: [PATCH] log: if --decorate is not given, default to --decorate=auto

2017-03-21 16:28 GMT-06:00 Junio C Hamano : > Junio C Hamano writes: > >>> test_expect_success 'log.decorate configuration' ' >>> -git log --oneline >expect.none && >>> +git log --oneline --no-decorate >expect.none && >>> git log --oneline

Re: [PATCH v3] t2027: avoid using pipes

Are there any other changes which I can do to improve my patch? Thanks, Prathamesh On Mon, Mar 13, 2017 at 12:21 PM, Prathamesh wrote: > Whenever a git command is present in the upstream of a pipe, its failure > gets masked by piping and hence it should be avoided for testing

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

Junio C Hamano writes: > Jeff King 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 descriptions and >>> bodies more consistent, but I think

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

Jeff King 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 the setup to delete the log file itself

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

Jeff King 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 even longer. > > Yeah, they're

Re: [PATCH] t3600: rename test to describe its functionality

Stefan Beller wrote: > This was an oversight in 55856a35b2 (rm: absorb a submodules git dir > before deletion, 2016-12-27), as the body of the test changed without > adapting the test subject. > > Signed-off-by: Stefan Beller > --- > t/t3600-rm.sh | 2 +- > 1 file changed, 1

Re: [PATCH 4/6] prefix_filename: return newly allocated string

On Tue, Mar 21, 2017 at 02:23:35PM -0400, Jeff King wrote: > > worktree.c:265:6: error: to_free may be used uninitialized in this function > > Doh. I had originally written it without the "if (prefix)" and added it > as a micro-optimization at the end. > > Still, the whole thing compiles fine

[PATCH v2] builtin/describe: introduce --broken flag

git-describe tells you the version number you're at, or errors out, e.g. when you run it outside of a repository, which may happen when downloading a tar ball instead of using git to obtain the source code. To keep this property of only erroring out, when not in a repository, severe (submodule)

Re: [PATCH] builtin/describe: introduce --broken flag

On Tue, Mar 21, 2017 at 3:41 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> AFAICT, someone is (was?) using a version of Git that doesn't contain >> f8eaa0ba98 (submodule--helper, module_clone: always operate >> on absolute paths, 2016-03-31). So

What's cooking in git.git (Mar 2017, #09; Tue, 21)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Sorry for these back-to-back

Re: [PATCH] builtin/describe: introduce --broken flag

Stefan Beller writes: > AFAICT, someone is (was?) using a version of Git that doesn't contain > f8eaa0ba98 (submodule--helper, module_clone: always operate > on absolute paths, 2016-03-31). So then the submodule paths were > made absolute paths on creation of the Gerrit repo.

Re: [PATCH v2 3/3] stash: keep untracked files intact in stash -k

On Tue, Mar 21, 2017 at 10:12:19PM +, Thomas Gummerer wrote: > Currently when there are untracked changes in a file "one" and in a file > "two" in the repository and the user uses: > > git stash push -k one > > all changes in "two" are wiped out completely. That is clearly not the >

Re: [PATCH] builtin/describe: introduce --broken flag

On Tue, Mar 21, 2017 at 2:51 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> This patch helps to fix the root cause in [1], which tries to work around >> this situation. > > I do not necessarily think it is reasonable to give $version-dirty > and

Re: [PATCH] log: if --decorate is not given, default to --decorate=auto

Junio C Hamano writes: >> test_expect_success 'log.decorate configuration' ' >> -git log --oneline >expect.none && >> +git log --oneline --no-decorate >expect.none && >> git log --oneline --decorate >expect.short && >> git log --oneline --decorate=full

Re: [PATCH v2 2/3] stash: pass the pathspec argument to git reset

On Tue, Mar 21, 2017 at 10:12:18PM +, Thomas Gummerer wrote: > For "git stash -p --no-keep-index", the pathspec argument is currently > not passed to "git reset". This means that changes that are staged but > that are excluded from the pathspec still get unstaged by git stash -p. > > Make

Re: [PATCH v2 1/3] stash: don't show internal implementation details

On Tue, Mar 21, 2017 at 10:12:17PM +, Thomas Gummerer wrote: > git stash push uses other git commands internally. Currently it only > passes the -q flag to those if the -q flag is passed to git stash. when > using 'git stash push -p -q --no-keep-index', it doesn't even pass the > flag on to

Re: [PATCH/RFC 3/3] stash: pass the pathspec argument to git reset

On Tue, Mar 21, 2017 at 09:14:24PM +, Thomas Gummerer wrote: > > I don't think read-tree takes pathspecs, so it would have to drop the > > "-u" and replace it with checkout-index. I'm confused about why we would > > need it in the first place, though. We should have already dealt with > > the

[PATCH v2 3/3] stash: keep untracked files intact in stash -k

Currently when there are untracked changes in a file "one" and in a file "two" in the repository and the user uses: git stash push -k one all changes in "two" are wiped out completely. That is clearly not the intended result. Make sure that only the files given in the pathspec are changed

[PATCH v2 0/3] Re: [BUG] "git stash -- path" reports wrong unstaged changes

Thanks Junio and Peff for comments and suggestions on the previous round. Changes since v1: - 1/3 now contains the changes that were previously split up into 1/3 and 2/3, and also makes git reset --hard in the simple 'git stash' case quiet unconditionally. - 2/3 is what was 3/3 in the

[PATCH v2 2/3] stash: pass the pathspec argument to git reset

For "git stash -p --no-keep-index", the pathspec argument is currently not passed to "git reset". This means that changes that are staged but that are excluded from the pathspec still get unstaged by git stash -p. Make sure that doesn't happen by passing the pathspec argument to the git reset in

[PATCH v2 1/3] stash: don't show internal implementation details

git stash push uses other git commands internally. Currently it only passes the -q flag to those if the -q flag is passed to git stash. when using 'git stash push -p -q --no-keep-index', it doesn't even pass the flag on to the internal reset at all. It really is enough for the user to know that

Re: [PATCH] builtin/describe: introduce --broken flag

Stefan Beller writes: > This patch helps to fix the root cause in [1], which tries to work around > this situation. I do not necessarily think it is reasonable to give $version-dirty and proceed when a repository corruption is detected; if there is a breakage in the

gitk: bug viewing diffs with the word items

Hi. I see a bug with the diff view of gitk. when the text " " or " " appears on one of the surrounding contexts lines in a diff, gitk treats it as part of the "Old Version", highlighting it in red, and hiding it if "New Version" is selected I don't know if any other magic words are affected

Re: [PATCH] Correct compile errors when DEBUG_BISECT=1 after supporting other hash algorithms

Hi, Brian, We definitely prefer the wrapper function oid_to_hex() to sha1_to_hex(). Thanks for feedback. Below is the updated patch: --- bisect.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bisect.c b/bisect.c index 30808cadf..7b65acbcd 100644 --- a/bisect.c +++

Re: [PATCH/RFC 3/3] stash: pass the pathspec argument to git reset

On 03/20, Jeff King wrote: > On Sun, Mar 19, 2017 at 08:23:51PM +, Thomas Gummerer wrote: > > > For "git stash -p --no-keep-index", the pathspec argument is currently > > not passed to "git reset". This means that changed that are staged but > > that are excluded from the pathspec still get

[PATCH] t3600: rename test to describe its functionality

This was an oversight in 55856a35b2 (rm: absorb a submodules git dir before deletion, 2016-12-27), as the body of the test changed without adapting the test subject. Signed-off-by: Stefan Beller --- t/t3600-rm.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH/RFC 1/3] stash: show less information for stash push --

On 03/20, Junio C Hamano wrote: > Jeff King writes: > > > On Mon, Mar 20, 2017 at 10:51:16AM -0700, Junio C Hamano wrote: > > > >> > diff --git a/git-stash.sh b/git-stash.sh > >> > index 9c70662cc8..59f055e27b 100755 > >> > --- a/git-stash.sh > >> > +++ b/git-stash.sh > >> > @@

Re: [PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary

SZEDER Gábor writes: >> That depends on what you use it for. I most often use mine to >> insert the reference that flows in a sentence, not as a separate >> displayed material, e.g. >> >> 1f6b1afe ("Git 2.12.1", 2017-03-20) >> >> so for that purpose, not adding a

Re: USE_SHA1DC is broken in pu

Johannes Schindelin writes: > On Fri, 17 Mar 2017, Lars Schneider wrote: > >> > On 17 Mar 2017, at 11:18, Lars Schneider >> > wrote: >> > >> > Would it make sense/have value to add a job to our TravisCI build [1] >> > that compiles Git in a

Re: USE_SHA1DC is broken in pu

Hi Lars, On Fri, 17 Mar 2017, Lars Schneider wrote: > > On 17 Mar 2017, at 11:18, Lars Schneider > > wrote: > > > > Would it make sense/have value to add a job to our TravisCI build [1] > > that compiles Git in a few variations with some high profile switches > > such

Re: [PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary

On Tue, Mar 21, 2017 at 6:58 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >>> The "Copy commit summary" command of gitk can be used to obtain this >>> -format. >>> +format, or this invocation of "git show": >>> >>> +git show -s --date=short

Re: [PATCH] rev-parse: match @{u}, @{push} and ^{} case-insensitively

On Tue, Mar 21, 2017 at 08:19:34PM +0100, Ævar Arnfjörð Bjarmason wrote: > On Sat, Mar 18, 2017 at 11:34 PM, Ævar Arnfjörð Bjarmason > wrote: > > > The new starts_with_case() function is a copy of the existing adjacent > > starts_with(), just with a tolower() in the "else if".

Re: [PATCH v2 15/16] tag: implicitly supply --list given the -n option

On Tue, Mar 21, 2017 at 8:24 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Yeah I see now that this is rather badly explained. I'll fix this up >> for v3. All of this worked already: >> >> $ ./git tag 100 >> $ ./git tag -n -l 100 >>

Re: Issues with git send-email and msmtp

Jeff King wrote: > On Tue, Mar 21, 2017 at 03:49:21PM +, Roger Pau Monné wrote: > > > I'm trying to use git send-email with msmtp, and I have added the following > > to > > my .gitconfig: > > > > [sendemail] > > smtpserver = "/usr/local/bin/msmtp" > > > > This seems to

Re: [PATCH] rev-parse: match @{u}, @{push} and ^{} case-insensitively

Ævar Arnfjörð Bjarmason writes: > On Sat, Mar 18, 2017 at 11:34 PM, Ævar Arnfjörð Bjarmason > wrote: > >> The new starts_with_case() function is a copy of the existing adjacent >> starts_with(), just with a tolower() in the "else if". >> [...] >> +int

Re: [PATCH v2 15/16] tag: implicitly supply --list given the -n option

Ævar Arnfjörð Bjarmason writes: > Yeah I see now that this is rather badly explained. I'll fix this up > for v3. All of this worked already: > > $ ./git tag 100 > $ ./git tag -n -l 100 > 100 tag: add tests for --with and --without > $ ./git tag -l -n

Re: [PATCH] rev-parse: match @{u}, @{push} and ^{} case-insensitively

[Dropping Richard Hansen from CC, his E-Mail bounces, changed jobs probably...] On Sat, Mar 18, 2017 at 11:34 PM, Ævar Arnfjörð Bjarmason wrote: > The new starts_with_case() function is a copy of the existing adjacent > starts_with(), just with a tolower() in the "else if". >

Re: [PATCH v2 08/16] for-each-ref: partly change to in help

Ævar Arnfjörð Bjarmason writes: > On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano wrote: > >> Do these strictly require commit, or does any commit-ish also do? > > commit-ish, but that's a good point, and could be the subject of a > future follow-up patch.

Re: [PATCH v2 14/16] ref-filter: reflow recently changed branch/tag/for-each-ref docs

On Tue, Mar 21, 2017 at 7:53 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Reflow the recently changed branch/tag-for-each-ref >> documentation. This change shows no changes under --word-diff, except >> the innocuous change of moving

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 21.03.2017 um 14:29 schrieb Zenobiusz Kunegunda: I think I found a way to reproduce this error. I installed FreeBSD 10.3 under qemu with zfs partitioning. Test program did not report any access errors. Then I did chmod 711 /usr/home Now program started reporting permission denied errors just

Re: [PATCH v2 15/16] tag: implicitly supply --list given the -n option

On Tue, Mar 21, 2017 at 7:59 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Change the "tag" command to treat the "-n" invocation as a list-like >> option in addition to --contains, --points-at etc. >> >> Most of the work for this was done

Re: [PATCH v2 13/16] ref-filter: add --no-contains option to tag/branch/for-each-ref

On Tue, Mar 21, 2017 at 7:51 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Change the tag, branch & for-each-ref commands to have a --no-contains >> option in addition to their longstanding --contains options. >> >> This allows for finding

Re: [PATCH v2 15/16] tag: implicitly supply --list given the -n option

Ævar Arnfjörð Bjarmason writes: > Change the "tag" command to treat the "-n" invocation as a list-like > option in addition to --contains, --points-at etc. > > Most of the work for this was done in my earlier "tag: Implicitly > supply --list given another list-like option"

Re: [PATCH v2 09/16] tag: add more incompatibles mode tests

On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Amend the test suite to test for more invalid uses like "-l -a" >> etc. This mainly tests the `(argc == 0 && !cmdmode)` -> >> `((create_tag_object || force) &&

Re: [PATCH v2 14/16] ref-filter: reflow recently changed branch/tag/for-each-ref docs

Ævar Arnfjörð Bjarmason writes: > Reflow the recently changed branch/tag-for-each-ref > documentation. This change shows no changes under --word-diff, except > the innocuous change of moving git-tag.txt's "[--sort=]" around > slightly. > --- Thanks. Needs sign-off (I could

Re: [PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary

On Tue, Mar 21, 2017 at 6:58 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >>> The "Copy commit summary" command of gitk can be used to obtain this >>> -format. >>> +format, or this invocation of "git show": >>> >>> +git show -s --date=short

Re: [PATCH v2 11/16] tag: implicitly supply --list given another list-like option

Ævar Arnfjörð Bjarmason writes: > Spelunking through the history via: > > git log --reverse -p -G'only allowed with' -- '*builtin*tag*c' > > Reveals that there was no good reason for not allowing this in the > first place. The --contains option added in 32c35cfb1e

Re: [PATCH v2 12/16] tag: change --point-at to default to HEAD

Makes sense. Thanks.

Re: [PATCH v2 08/16] for-each-ref: partly change to in help

On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Change mentions of to in the help output of >> for-each-ref as appropriate. >> >> Both --[no-]merged and --contains only take commits, but --points-at >> can take

Re: [PATCH v2 13/16] ref-filter: add --no-contains option to tag/branch/for-each-ref

Ævar Arnfjörð Bjarmason writes: > Change the tag, branch & for-each-ref commands to have a --no-contains > option in addition to their longstanding --contains options. > > This allows for finding the last-good rollout tag given a known-bad > . Given a hypothetically bad commit

[PATCH] builtin/describe: introduce --broken flag

git-describe tells you the version number you're at, or errors out, e.g. when you run it outside of a repository, which may happen when downloading a tar ball instead of using git to obtain the source code. To keep this property of only erroring out, when not in a repository, severe (submodule)

Re: [PATCH v2 10/16] tag: change misleading --list documentation

Ævar Arnfjörð Bjarmason writes: > And after Jeff's change, one that took multiple patterns: > > git tag --list 'v*rc*' --list '*2.8*' I do not think this is a correct depiction of the evolution, and is a confusing description. It should say git tag --list 'v*rc*'

Re: [PATCH v2 08/16] for-each-ref: partly change to in help

Ævar Arnfjörð Bjarmason writes: > Change mentions of to in the help output of > for-each-ref as appropriate. > > Both --[no-]merged and --contains only take commits, but --points-at > can take any object, such as a tag pointing to a tree or blob. > > Signed-off-by: Ævar

Re: [PATCH v2 09/16] tag: add more incompatibles mode tests

Ævar Arnfjörð Bjarmason writes: > Amend the test suite to test for more invalid uses like "-l -a" > etc. This mainly tests the `(argc == 0 && !cmdmode)` -> > `((create_tag_object || force) && (cmdmode != 0))` code path in > builtin/tag.c. The second sentence is now stale,

Re: [PATCH v2 05/16] ref-filter: add test for --contains on a non-commit

Ævar Arnfjörð Bjarmason writes: > Change the tag test suite to test for --contains on a tree & blob, it Either s/, it/. It/ or s/, it/; it/. > only accepts commits and will spew out " is a tree, not a > commit". > > It's sufficient to test this just for the "tag" and

Re: [PATCH] log: if --decorate is not given, default to --decorate=auto

Alex Henrie writes: > Git's branching and merging system can be confusing, especially to new > users. When teaching people Git, I tell them to set log.decorate=auto. > This preference greatly improves the user's awareness of the local and > remote branches. So for the

Re: [PATCH v2 02/16] tag doc: split up the --[no-]merged documentation

Ævar Arnfjörð Bjarmason writes: > Split up the --[no-]merged documentation into documentation that > documents each option independently. This is in line with how "branch" > and "for-each-ref" are documented, and makes subsequent changes to > discuss the limits & caveats of

Re: [PATCH 4/6] prefix_filename: return newly allocated string

On Tue, Mar 21, 2017 at 11:14:23AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > diff --git a/worktree.c b/worktree.c > > index 42dd3d52b..2520fc65c 100644 > > --- a/worktree.c > > +++ b/worktree.c > > @@ -250,16 +250,19 @@ struct worktree *find_worktree(struct worktree

Re: cherry-pick --message?

On Tue, Mar 21, 2017 at 06:07:34PM +0100, Andreas Krey wrote: > > There's "cherry-pick --edit". > > Yes, but. I'm in a toolchain, not a user. I'm a command that let > the user cherry-pick specific things, and I need to edit out the things > that made the original commit eligible to be picked in

Re: [PATCH v2 01/16] tag doc: move the description of --[no-]merged earlier

Makes sense.

Re: [PATCH v2 00/16] Various changes to the "tag" command & related

Ævar Arnfjörð Bjarmason writes: > This series is now 2x the size of v1. The reason is that the > discussion for v1 brought up lots of related side-points that I fixed > while I was at it. Most if this *could* be split off, but since a lot > of it's modifying the same bits of

Re: [PATCH 4/6] prefix_filename: return newly allocated string

Jeff King writes: > diff --git a/worktree.c b/worktree.c > index 42dd3d52b..2520fc65c 100644 > --- a/worktree.c > +++ b/worktree.c > @@ -250,16 +250,19 @@ struct worktree *find_worktree(struct worktree **list, > { > struct worktree *wt; > char *path; > + char

Re: [PATCH v3 1/2] l10n: Introduce framework for localizing man pages

Jean-Noel Avila writes: > @@ -247,6 +260,11 @@ install-man: man > $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir) > $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir) > $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir) > + $(MAKE) install-man-l10n

Re: [PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary

SZEDER Gábor writes: >> The "Copy commit summary" command of gitk can be used to obtain this >> -format. >> +format, or this invocation of "git show": >> >> +git show -s --date=short --pretty='format:%h ("%s", %ad)' >> + >> +To turn that into a handy alias: >> + >>

Re: [PATCH v3 3/5] grep: fix bug when recursing with relative pathspec

Duy Nguyen writes: >> if (recurse_submodules) >> argv_array_push(_options, "--recurse-submodules"); > > Side note. It would be awesome if you could make parse_options() (or a > new function) do the reverse process: given a 'struct option' with > valid

Re: [PATCH 0/6] prefix_filename cleanups

Jeff King writes: > I noticed a spot in builtin/bundle.c that would benefit from using > prefix_filename(). But when I tried to use it, I noticed its interface > was a little error-prone (because it returns a static buffer). And > indeed, a little digging found a bug in

Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

Lars Schneider writes: > Agreed. Would it be OK to store the "delayed" bit in the cache > entry itself? The extended ce_flags are stored on disk which is not > necessary I think. Would a new member in the cache_entry struct be > an acceptable option? I'd imagine that

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

Jeff King writes: > On Mon, Mar 20, 2017 at 08:56:11PM -0400, Kyle Meyer wrote: > >> 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

Re: [PATCH 0/3] git-describe deals gracefully with broken submodules

On Mon, Mar 20, 2017 at 11:28 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Our own version generation in GIT-VERSION-GEN is somewhat sane by testing >> if we have a .git dir, and use that as a signal whether the obtained >> copy of git was

Re: cherry-pick --message?

On Tue, 21 Mar 2017 13:00:05 +, Jeff King wrote: ... > > I have an slightly unusual usecase for cherry-pick: > > I want to modify the commit message that is used in the process, > > e.g. do an d/^PROP:/ on it, but unfortunately -m does something > > else here. > > ... > > There's

Re: cherry-pick --message?

On Tue, Mar 21, 2017 at 05:05:20PM +0100, Andreas Krey wrote: > Hi all, > > I have an slightly unusual usecase for cherry-pick: > I want to modify the commit message that is used in the process, > e.g. do an d/^PROP:/ on it, but unfortunately -m does something > else here. > > And there is no

Re: [PATCH v3 0/2] bringing attributes to pathspecs

On 03/21, Duy Nguyen wrote: > On Tue, Mar 14, 2017 at 1:23 AM, Brandon Williams wrote: > > v3 fixes some nits in style in the test script (using <<-\EOF instead of > > <<-EOF) > > as well as fixing a few other minor things reported by Junio and Jonathan. > > I'm slowly

Re: [PATCH v3 2/5] setup: allow for prefix to be passed to git commands

Brandon Williams writes: > Yes, the prefix that is found during setup of a submodule process would > be NULL or "" as the command would be invoked from the root of that > repository. This series would sort of change that though. OK, because you (eh, rather your caller) do

Re: Issues with git send-email and msmtp

On Tue, Mar 21, 2017 at 03:49:21PM +, Roger Pau Monné wrote: > I'm trying to use git send-email with msmtp, and I have added the following to > my .gitconfig: > > [sendemail] > smtpserver = "/usr/local/bin/msmtp" > > This seems to work fine, except that sometimes git dies unexpectedly

cherry-pick --message?

Hi all, I have an slightly unusual usecase for cherry-pick: I want to modify the commit message that is used in the process, e.g. do an d/^PROP:/ on it, but unfortunately -m does something else here. And there is no --message here for good reason, as cherry-pick can pick multiple commits and so

[ANNOUNCE] Git for Windows 2.12.1

MIME-Version: 1.0 Fcc: Sent Dear Git users, It is my pleasure to announce that Git for Windows 2.12.1 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.12.0 (February 25th 2017) A MinGit-only v2.12.0(2) was released in the meantime. New Features

Re: [PATCH v3 0/2] bringing attributes to pathspecs

Duy Nguyen writes: > The series updated match_pathspec(), but that's only one of two > pathspec filtering functions. The other is tree_entry_interesting() > (e.g. for "git grep "). Do you have plans to support :(attr) > there too? "No" is a perfectly fine answer (and it will

Re: [PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary

> Amend the section which describes how to get a commit summary to show > how do to that with "git show", currently the documentation only shows > how to do that with gitk. > > Signed-off-by: Ævar Arnfjörð Bjarmason > --- > Documentation/SubmittingPatches | 11 ++- > 1

Re: [PATCH] Documentation/git-worktree: use working tree for trees on the file system

Duy Nguyen writes: > On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder wrote: >> Junio C Hamano wrote: >>> Stefan Beller writes: >> While it may be true that you can have bare worktrees; I would question why anyone wants to do

Issues with git send-email and msmtp

Hello, I'm trying to use git send-email with msmtp, and I have added the following to my .gitconfig: [sendemail] smtpserver = "/usr/local/bin/msmtp" This seems to work fine, except that sometimes git dies unexpectedly after queuing a patch to msmtp: Died at

[PATCH v2 0/2] A couple of minor improvements

Unchanged from v1 in my <20170318184203.16890-1-ava...@gmail.com>, except 2/2 changes the "show" command to use --date=short as Junio suggested in . Ævar Arnfjörð Bjarmason (2): doc/SubmittingPatches: clarify the casing convention for "area:

[PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary

Amend the section which describes how to get a commit summary to show how do to that with "git show", currently the documentation only shows how to do that with gitk. Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/SubmittingPatches | 11 ++- 1 file changed,

[PATCH v2 1/2] doc/SubmittingPatches: clarify the casing convention for "area: change..."

Amend the section which describes how the first line of the subject should look like to say that the ":" in "area: " shouldn't be treated like a full stop for the purposes of letter casing. Change the two subject examples to make this new paragraph clearer, i.e. "unstar" is not a common word, and

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Od: "René Scharfe" l@web.de> Do: "Stefan Beller" sbel...@google.com>; Wysłane: 22:08 Piątek 2017-03-17 Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 | > >> Am 17.03.2017 um 20:45 schrieb Stefan Beller: >> On Fri, Mar

[PATCH v2 00/16] Various changes to the "tag" command & related

This series is now 2x the size of v1. The reason is that the discussion for v1 brought up lots of related side-points that I fixed while I was at it. Most if this *could* be split off, but since a lot of it's modifying the same bits of code doing that would result in merge conflict galore, so I

[PATCH v2 05/16] ref-filter: add test for --contains on a non-commit

Change the tag test suite to test for --contains on a tree & blob, it only accepts commits and will spew out " is a tree, not a commit". It's sufficient to test this just for the "tag" and "branch" commands, because it covers all the machinery is shared between "branch" and "for-each-ref".

[PATCH v2 02/16] tag doc: split up the --[no-]merged documentation

Split up the --[no-]merged documentation into documentation that documents each option independently. This is in line with how "branch" and "for-each-ref" are documented, and makes subsequent changes to discuss the limits & caveats of each option easier to read. Signed-off-by: Ævar Arnfjörð

[PATCH v2 06/16] tag: remove a TODO item from the test suite

Change the test for "git tag -l" to not have an associated TODO comment saying that it should return non-zero if there's no tags. This was added in commit ef5a6fb597 ("Add test-script for git-tag", 2007-06-28) when the tests for "tag" were initially added, but at this point changing this would be

[PATCH v2 11/16] tag: implicitly supply --list given another list-like option

Change the "tag" command to implicitly turn on its --list mode when provided with a list-like option such as --contains, --points-at etc. This is for consistency with how "branch" works. When "branch" is given a list-like option, such as --contains, it implicitly provides --list. Before this

[PATCH v2 07/16] tag tests: fix a typo in a test description

Change "suceed" to "succeed" in a test description. The typo has been here since the code was originally added in commit ef5a6fb597 ("Add test-script for git-tag", 2007-06-28). Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t7004-tag.sh | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 12/16] tag: change --point-at to default to HEAD

Change the --points-at option to default to HEAD for consistency with its siblings --contains, --merged etc. which default to HEAD. Previously we'd get: $ git tag --points-at 2>&1 | head -n 1 error: option `points-at' requires a value This changes behavior added in commit ae7706b9ac

[PATCH v2 16/16] tag: add tests for --with and --without

Change the test suite to test for these synonyms for --contains and --no-contains, respectively. Before this change there were no tests for them at all. This doesn't exhaustively test for them as well as their --contains and --no-contains synonyms, but at least it's something. Signed-off-by:

[PATCH v2 13/16] ref-filter: add --no-contains option to tag/branch/for-each-ref

Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad . Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with

[PATCH v2 10/16] tag: change misleading --list documentation

Change the documentation for --list so that it's described as a toggle, not as an option that takes a as an argument. Junio initially documented this in b867c7c23a ("git-tag: -l to list tags (usability).", 2006-02-17), but later Jeff King changed "tag" to accept multiple patterns in 588d0e834b

[PATCH v2 04/16] ref-filter: make combining --merged & --no-merged an error

Change the behavior of specifying --merged & --no-merged to be an error, instead of silently picking the option that was provided last. Subsequent changes of mine add a --no-contains option in addition to the existing --contains. Providing both of those isn't an error, and has actual meaning.

[PATCH v2 08/16] for-each-ref: partly change to in help

Change mentions of to in the help output of for-each-ref as appropriate. Both --[no-]merged and --contains only take commits, but --points-at can take any object, such as a tag pointing to a tree or blob. Signed-off-by: Ævar Arnfjörð Bjarmason --- builtin/for-each-ref.c | 4

[PATCH v2 09/16] tag: add more incompatibles mode tests

Amend the test suite to test for more invalid uses like "-l -a" etc. This mainly tests the `(argc == 0 && !cmdmode)` -> `((create_tag_object || force) && (cmdmode != 0))` code path in builtin/tag.c. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t7004-tag.sh | 13 +

[PATCH v2 15/16] tag: implicitly supply --list given the -n option

Change the "tag" command to treat the "-n" invocation as a list-like option in addition to --contains, --points-at etc. Most of the work for this was done in my earlier "tag: Implicitly supply --list given another list-like option" commit, but I've split off this patch since it's more

[PATCH v2 03/16] tag doc: reword --[no-]merged to talk about commits, not tips

Change the wording for the --merged and --no-merged options to talk about "commits" instead of "tips". This phrasing was copied from the "branch" documentation in commit 5242860f54 ("tag.c: implement '--merged' and '--no-merged' options", 2015-09-10). Talking about the "tip" is branch

[PATCH v2 01/16] tag doc: move the description of --[no-]merged earlier

Move the documentation for the --merged & --no-merged options earlier in the documentation, to sit along the other switches, and right next to the similar --contains and --points-at switches. It makes more sense to group the options together, not have some options after the like of , , etc.

  1   2   >