[PATCH v1] travis-ci: build and test Git on Windows

Most Git developers work on Linux and they have no way to know if their changes would break the Git for Windows build. Let's fix that by adding a job to TravisCI that builds and tests Git on Windows. Unfortunately, TravisCI does not support Windows. Therefore, we did the following: * Johannes Schi

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 --decorate >expect.short && >>> git log

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 the > upstream git

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 this leads to too much code >>>

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 rather than its >> c

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 quite long. Probably

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 insertion(+), 1 dele

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 fo

[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) er

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 then the submodule paths were >> made abso

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 issue

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. > > And then someone

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 > int

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 proceed when a repository corruption is det

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 >expect.full && > > This

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 su

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 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 previous

[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

[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 w

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 repository, "git describe" is

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 +++ b/b

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 u

[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 --git a/t/t3600-rm.sh b

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 > >> > @@ -299,10 +299,10 @@

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 trailing newline is a featur

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 few variations with some high profile switches >> > su

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 as USE_SHA1DC? Running all

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 --pretty='format:%h ("%s", %ad)' >>> + >>> +

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". > > [...] > > +int

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 >> 100 tag: add tests fo

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 work fine, excep

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 starts_with_case(const char *str, const char

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 100 > 100

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". > [...] > +int starts

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. Right now most of the things that say

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 git-tag.txt's "[--sort=]" around >> slightl

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 l

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 in my earlier "tag: Implicitly >> supp

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 the last-good rollout tag given a kno

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" commit, but I've split

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) && (cmdmode != 0))` code path in >> builtin/t

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 just add it back i

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 ("git-tag: Add > --contains

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

Makes sense. Thanks.

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 --pretty='format:%h ("%s", %ad)' >>> + >>> +

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 any object, such as a tag pointing to

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 cf5c7253e0, the gi

[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) er

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*' '*2.8*' instead. Wh

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 Arnfjörð Bjarmason > -

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, isn't it? > > Signed-

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 "branch" commands, > becau

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 sake of user friendliness, I

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 each option easier to

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 **list, > > { >

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 t

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 code doing that woul

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 *to_free; > >

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 FYI. Having this line

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: >> + >> +git config --globa

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

Duy Nguyen writes: >> if (recurse_submodules) >> argv_array_push(&submodule_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 data, spit

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 hash-object related to thi

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 those with thousands of cach

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 concerned with "

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 obtained using git (clone/fetch) or if it is ju

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 "cherry-pick

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 digging through the pile o

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 not adjust pathnames a

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 o

[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 end up in my > foreve

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 file changed, 10 i

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 this, as the only thing it provides is an additional H

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 /usr/local/Cellar/git/2.12.0/

[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: change..." doc/SubmittingPatches: show how to ge

[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, 10 insertions(+), 1

[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" Do: "Stefan Beller" ; 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, Ma

[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 thi

[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". Signed

[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ð Bjarma

[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 chang

[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 deletion(-) diff -

[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 (tag:

[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: Ævar

[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 thi

[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. Mak

[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 ++-- 1 file chang

[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 + 1 file changed, 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 contentious.

[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 nomenclature

  1   2   >