[PATCH] request-pull: drop old USAGE stuff

request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete) USAGE and LONG_USAGE anymore. Signed-off-by: Wolfram Sang --- git-request-pull.sh |3 --- 1 file changed, 3 deletions(-) Index: git-2.11.0/git-request-pull.sh

[RFC for GIT] pull-request: add praise to people doing QA

Asking for opinions on lkml and git... Getting enough quality assurance is likely one of the bigger upcoming tasks in the near future. To improve the situation, praise the people already doing that by adding their names to pull requests in the same manner that patch authors are credited. Here is

[PATCH v5 2/7] ref-filter: add function to print single ref_array_item

From: Lukas Puehringer ref-filter functions are useful for printing git object information using a format specifier. However, some other modules may not want to use this functionality on a ref-array but only print a single item. Expose a pretty_print_ref function to

[PATCH v5 5/7] builtin/tag: add --format argument for tag -v

From: Lukas Puehringer Adding --format to git tag -v mutes the default output of the GPG verification and instead prints the formatted tag object. This allows callers to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG

[PATCH v5 1/7] gpg-interface, tag: add GPG_VERIFY_QUIET flag

From: Lukas Puehringer Functions that print git object information may require that the gpg-interface functions be silent. Add GPG_VERIFY_QUIET flag and prevent print_signature_buffer from being called if flag is set. Signed-off-by: Lukas Puehringer

[PATCH v5 6/7] t/t7030-verify-tag: Add --format specifier tests

From: Santiago Torres Verify-tag now provides --format specifiers to inspect and ensure the contents of the tag are proper. We add two tests to ensure this functionality works as expected: the return value should indicate if verification passed, and the format specifiers must

[PATCH v5 7/7] t/t7004-tag: Add --format specifier tests

From: Santiago Torres tag -v now supports --format specifiers to inspect the contents of a tag upon verification. Add two tests to ensure this behavior is respected in future changes. Signed-off-by: Santiago Torres --- t/t7004-tag.sh | 16

[PATCH v5 0/7] Add --format to tag verification

From: Santiago Torres This is the fifth iteration of [1][2][3][4], and as a result of the discussion in [5]. The main goal of this patch series is to bring --format to git tag verification so that upper-layer tools can inspect the content of a tag and make decisions based on

[PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

From: Lukas Puehringer Calling functions for gpg_verify_tag() may desire to print relevant information about the header for further verification. Add an optional format argument to print any desired information after GPG verification. Signed-off-by: Lukas Puehringer

[PATCH v5 4/7] builtin/verify-tag: add --format to verify-tag

From: Santiago Torres Callers of verify-tag may want to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG verification. This is to avoid tag refs that point to an incorrect object. Add a --format parameter to git verify-tag to print

Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]

On 1/13/2017 12:30 PM, Stefan Beller wrote: This question is about networking; the patch you originally replied to was strictly about local operations in the filesystem, which is quite a difference, so let's discuss it separately. Yep ok look like you reclassified this and opened new topic

[PATCH v3 2/2] diff: document the format of the -O (diff.orderFile) file

Signed-off-by: Richard Hansen --- Documentation/diff-config.txt | 5 ++--- Documentation/diff-options.txt | 34 -- 2 files changed, 34 insertions(+), 5 deletions(-) diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt

[PATCH v3 0/2] diff orderfile documentation improvements

Changes from v2: * The orderfile feature doesn't set the WM_PATHNAME flag when it calls wildmatch(), so document the pattern format accordingly. Richard Hansen (2): diff: document behavior of relative diff.orderFile diff: document the format of the -O (diff.orderFile) file

[PATCH v3 1/2] diff: document behavior of relative diff.orderFile

Document that a relative pathname for diff.orderFile is interpreted as relative to the top-level work directory. Signed-off-by: Richard Hansen --- Documentation/diff-config.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/diff-config.txt

Re: [PATCH 00/27] Revamp the attribute system; another round

This one unfortunately clashes with jk/nofollow-attr-ignore where Peff adds sanity to refuse following symbolic links when reading .gitignore and .gitattributes; I'll eject jk/nofollow-attr-ignore topic for now and see how well this topic fits together with the remainder of the topics in flight.

[RFC] stash --continue

Hi, a git-newbie-ish co-worker uses git-stash sometimes. Last time he used "git stash pop", he got into a merge conflict. After he resolved the conflict, he did not know what to do to get the repository into the wanted state. In his case, it was only "git add " followed by a "git reset" and a

Re: gitk pull request // was: Re: gitk: "lime" color incompatible with older Tk versions

Paul Mackerras writes: >> Paul, is it a good time to pull, or do you still have something not >> published yet that should go together with what you have already >> queued? > > I recently pushed out one more commit to update the Russian > translation from Dimitriy Ryazantcev.

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Johannes Sixt writes: > Am 16.01.2017 um 02:51 schrieb Junio C Hamano: >> * jk/vreport-sanitize (2017-01-11) 2 commits >> - vreport: sanitize ASCII control chars >> - Revert "vreportf: avoid intermediate buffer" >> >> An error message with an ASCII control character like '\r'

Re: Different merges from translation perspective

Alexander Shopov writes: > What is the difference between simple, fast forward, automatic and > trivial merge? "fast forward" and "trivial" (and "automatic" to some degree) are technical terms with precise meaning. Other phrases that are related to "merge" that are not in

Re: feature request: allow to stash changed files

On 01/15, KES wrote: > http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833 > > Sometimes poople are forced to save stash for changed files. But there is no > such option ( You may just be lucky. I've been

[RFC] stash: support filename argument

While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

Am 15.01.2017 um 11:06 schrieb Vegard Nossum: On 15/01/2017 03:39, Junio C Hamano wrote: René Scharfe writes: How about extending the context upward only up to and excluding a line that is either empty *or* a function line? That would limit the extra context to a single

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

Am 15.01.2017 um 03:39 schrieb Junio C Hamano: > René Scharfe writes: > >>> I am also more focused on keeping the codebase maintainable in good >>> health by making sure that we made an effort to find a solution that >>> is general-enough before solving a single specific problem

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

On 15/01/2017 03:39, Junio C Hamano wrote: René Scharfe writes: I am also more focused on keeping the codebase maintainable in good health by making sure that we made an effort to find a solution that is general-enough before solving a single specific problem you have today. We

feature request: allow to stash changed files

http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833 Sometimes poople are forced to save stash for changed files. But there is no such option (

Re: [PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)

On Fri, Jan 13, 2017 at 8:14 PM, Junio C Hamano wrote: > Christian Couder writes: > >> The following part of the description: >> >> git bisect (bad|new) [] >> git bisect (good|old) [...] >> >> may be a bit confusing, as a reader may wonder if

Re: [PATCHv3 2/2] builtin/commit.c: switch to xstrfmt(), instead of snprintf,

2017-01-15 3:42 GMT+01:00 Junio C Hamano : > Elia Pinto writes: > >> Ok. I agree. But is it strictly necessary to resend for this ? > > FWIW, the attacched is what I queued locally, after complaining > "both have the same title? They need to be

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

René Scharfe writes: > ... How bad would it be to only > implement the first part (as in the patch I just sent) without adding > new config settings or parameters? That probably is a good place to stop ;-)

Re: [RFC] stash: support filename argument

Hi, On 01/16/2017 01:21 AM, Junio C Hamano wrote: > I haven't spent enough time to think if it even makes sense to > "stash" partially, leaving the working tree still dirty. My initial > reaction was "then stashing away the dirty WIP state to get a spiffy > clean working environment becomes

Re: gitk pull request // was: Re: gitk: "lime" color incompatible with older Tk versions

Hi Junio, On Sat, Jan 14, 2017 at 06:35:43PM -0800, Junio C Hamano wrote: > David Aguilar writes: > > > On Fri, Jan 13, 2017 at 03:20:43AM -0800, David Aguilar wrote: > >> > >> Ping.. it would be nice to get this patch applied. > > > > Sorry for the noise, and thank you Paul

Different merges from translation perspective

Hi all, What is the difference between simple, fast forward, automatic and trivial merge? I am updating the translation and the only thing I am sure about is that these four are not octopus merges, Fast forward is when current state is ancestor of tip, automatic merge is when the merge algorithm

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Sun, Jan 15, 2017 at 4:35 PM, Junio C Hamano wrote: > As to the implementation, I am wondering if we can make this somehow > work well with the "trailers" code we already have, instead of > inventing yet another parser of trailers. > > In its current shape,

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Am 16.01.2017 um 02:51 schrieb Junio C Hamano: * jk/vreport-sanitize (2017-01-11) 2 commits - vreport: sanitize ASCII control chars - Revert "vreportf: avoid intermediate buffer" An error message with an ASCII control character like '\r' in it can alter the message to hide its early part,

Re: [RFC] stash: support filename argument

Thomas Gummerer writes: > While working on a repository, it's often helpful to stash the changes > of a single or multiple files, and leave others alone. Unfortunately > git currently offers no such option. git stash -p can be used to work > around this, but it's often

Re: [PATCH] request-pull: drop old USAGE stuff

Wolfram Sang writes: > request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete) > USAGE and LONG_USAGE anymore. > > Signed-off-by: Wolfram Sang > --- Makes sense. These are not used anywhere after we switched to use parse-options. Thanks.

Re: [RFC] stash --continue

On Sun, Jan 15, 2017 at 3:56 PM, Stephan Beyer wrote: > Hi, > > a git-newbie-ish co-worker uses git-stash sometimes. Last time he used > "git stash pop", he got into a merge conflict. After he resolved the > conflict, he did not know what to do to get the repository into the >

Re: [RFC for GIT] pull-request: add praise to people doing QA

Wolfram Sang writes: > === new stuff starts here > > with much appreciated quality assurance from > > Andy Shevchenko (1): > (Rev.) i2c: piix4: Avoid race conditions with IMC > > Benjamin Tissoires (1): >

What's cooking in git.git (Jan 2017, #02; Sun, 15)

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. You can find the changes

Re: [PATCH v3 01/38] sequencer: avoid unnecessary curly braces

On Sat, Jan 14, 2017 at 10:05 AM, Jeff King wrote: > On Sat, Jan 14, 2017 at 06:57:13PM +0100, Johannes Schindelin wrote: > >> On Thu, 12 Jan 2017, Junio C Hamano wrote: >> >> > Johannes Schindelin writes: >> > >> > > >> > > - if (!commit->parents) { >>

Re: Different merges from translation perspective

On Sun, Jan 15, 2017 at 8:41 PM, Alexander Shopov wrote: > Hi all, > What is the difference between simple, fast forward, automatic and > trivial merge? > I am updating the translation and the only thing I am sure about is > that these four are not octopus merges, > Fast