[PATCH v2 1/5] doc: add documentation for OPT_STRING_LIST

From: Jacob Keller <jacob.kel...@gmail.com> Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper", 2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated list of strings. However, this was not documented in the api-parse-options documentation. Add docu

[PATCH v2 0/5] extend describe and name-rev pattern matching

From: Jacob Keller <jacob.kel...@gmail.com> This series adds support for extending describe and name-rev pattern matching to allow (a) taking multiple patterns and (b) negative patterns which discard instead of keep. These changes increase the flexibility of the describe mechan

[PATCH] diff: prefer indent heuristic over compaction heuristic

From: Jacob Keller <jacob.kel...@gmail.com> The current configuration code for enabling experimental heuristics prefers the last-set heuristic in the configuration. However, it is not necessarily easy to see what order the configuration will be read. This means that it is possible for

Re: indent-heuristic, compaction-heuristic combination

On Fri, Dec 16, 2016 at 4:44 PM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Fri, Dec 16, 2016 at 4:28 PM, Norbert Kiesel <nkie...@gmail.com> wrote: >> Hi, >> >> I started using compaction-heuristic with 2.9, and then also (or so I >> thought) enab

Re: indent-heuristic, compaction-heuristic combination

On Fri, Dec 16, 2016 at 4:28 PM, Norbert Kiesel wrote: > Hi, > > I started using compaction-heuristic with 2.9, and then also (or so I > thought) enabled indent-heuristic with 2.11. > Only after reading a comment in "Git rev news" I realized that these 2 > options are mutually

Re: indent-heuristic, compaction-heuristic combination

On Fri, Dec 16, 2016 at 4:28 PM, Norbert Kiesel wrote: > Hi, > > I started using compaction-heuristic with 2.9, and then also (or so I > thought) enabled indent-heuristic with 2.11. > Only after reading a comment in "Git rev news" I realized that these 2 > options are mutually

Re: Any interest in 'git merge --continue' as a command

On Sat, Dec 10, 2016 at 1:00 AM, Jeff King wrote: > On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote: > >> > There is nothing to "continue" in a stopped merge where Git asked >> > for help from the user, and because of that, I view the final "git >> > commit" as

Re: Any interest in 'git merge --continue' as a command

On December 9, 2016 1:11:27 AM PST, Jeff King wrote: >On Fri, Dec 09, 2016 at 08:57:58PM +1300, Chris Packham wrote: > >> I hit this at $dayjob recently. >> >> A developer had got themselves into a confused state when needing to >> resolve a merge conflict. >> >> They knew about

Re: [PATCH v2 1/4] real_path: resolve symlinks by hand

On Thu, Dec 8, 2016 at 3:58 PM, Brandon Williams wrote: > The current implementation of real_path uses chdir() in order to resolve > symlinks. Unfortunately this isn't thread-safe as chdir() affects a > process as a whole and not just an individual thread. Instead perform >

Re: [PATCH v8 00/19] port branch.c to use ref-filter's printing options

On Thu, Dec 8, 2016 at 10:58 AM, Junio C Hamano wrote: > > *1* A malformed formatting request (e.g. %(if) that is not closed) > cannot be satisified but that is true for all refs and is > outside of the scope of this discussion. The command should die > and I think

Re: [PATCH 2/2] describe: add support for multiple match patterns

On Wed, Dec 7, 2016 at 4:20 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> Basically, this started as a script to try each pattern in sequence, >> but this is slow, cumbersome and easy to mess up. >> >>

Re: [PATCH v8 00/19] port branch.c to use ref-filter's printing options

On Wed, Dec 7, 2016 at 7:36 AM, Karthik Nayak wrote: > This is part of unification of the commands 'git tag -l, git branch -l > and git for-each-ref'. This ports over branch.c to use ref-filter's > printing options. > > Initially posted here: $(gmane/279226). It was decided

Re: [PATCH 2/2] describe: add support for multiple match patterns

On Wed, Dec 7, 2016 at 2:08 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.e.kel...@intel.com> writes: > >> ... Suppose that you version all >> your official releases such as "v1.2", "v1.3", "v1.4", "v2.1

[PATCH 1/2] name-rev: allow passing multiple patterns using --refs

From: Jacob Keller <jacob.kel...@gmail.com> Allow git name-rev to take a string list of patterns instead of only a single pattern. All patterns are matched inclusively, meaning that a ref only needs to match one pattern to be included. Add tests and documentation for this change. Sign

[PATCH 2/2] describe: add support for multiple match patterns

From: Jacob Keller <jacob.kel...@gmail.com> Convert "--match" into a string list that accumulates patterns. If any patterns are given, then include all tags that match at least one pattern. This allows the user to construct multiple small patterns and compose them. If desired

Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules

On Fri, Dec 2, 2016 at 11:28 AM, Stefan Beller <sbel...@google.com> wrote: > On Fri, Dec 2, 2016 at 11:20 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: >>> >>> So is there a reason why the library function realpath() can't be used? >>> From a c

Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules

On Fri, Dec 2, 2016 at 10:49 AM, Brandon Williams <bmw...@google.com> wrote: > On 12/02, Jacob Keller wrote: >> On Fri, Dec 2, 2016 at 10:36 AM, Brandon Williams <bmw...@google.com> wrote: >> > On 12/01, Jeff King wrote: >> >> On Thu, Dec 01, 201

Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules

On Fri, Dec 2, 2016 at 10:36 AM, Brandon Williams wrote: > On 12/01, Jeff King wrote: >> On Thu, Dec 01, 2016 at 01:56:32PM -0800, Stefan Beller wrote: >> >> > > Bleh. Looks like it happens as part of the recently-added >> > > get_common_dir(). I'm not sure if that is ever

Re: [PATCH v2 1/1] convert: git cherry-pick -Xrenormalize did not work

On Wed, Nov 30, 2016 at 9:02 AM, wrote: > From: Torsten Bögershausen > diff --git a/convert.c b/convert.c > index be91358..f8e4dfe 100644 > --- a/convert.c > +++ b/convert.c > @@ -281,13 +281,13 @@ static int crlf_to_git(const char *path, const char > *src, size_t

Re: v2.11 new diff heuristic?

On November 22, 2016 6:42:36 AM PST, Robert Dailey wrote: >The release notes mention a new heuristic for diff: > >* Output from "git diff" can be made easier to read by selecting >which lines are common and which lines are added/deleted >intelligently when the lines

Re: Feature request: Improve diff algorithm

On Mon, Nov 21, 2016 at 10:17 AM, Stefan Beller <sbel...@google.com> wrote: > On Mon, Nov 21, 2016 at 8:56 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: >> On Mon, Nov 21, 2016 at 12:11 AM, KES <kes-...@yandex.ru> wrote: >>> Hi. >>> >> >

Re: [PATCH 0/3] Fix problems with rebase -i when core.commentchar is defined

On Mon, Nov 21, 2016 at 6:18 AM, Johannes Schindelin wrote: > The Git for Windows project recently got a bug report that detailed how > `git rebase -i` fails when core.commentchar=auto: > > https://groups.google.com/forum/#!topic/git-for-windows/eOZKjkgyX1Q > >

Re: Feature request: Improve diff algorithm

On Mon, Nov 21, 2016 at 12:11 AM, KES wrote: > Hi. > Hi, > I have some question about how diff works then give proposal: > > it will be very useful for each "symbol" store additional meta info as source > line length. So in this case when git counter two equal sequence of

[PATCH 0/2] add format specifiers to display trailers

From: Jacob Keller <jacob.kel...@gmail.com> This is based off of jt/use-trailer-api-in-commands so that we can make use of the public trailer API that will parse a string for trailers. I use trailers as a way to store extra commit metadata, and would like a convenient way to obtain the tr

[PATCH v2 2/2] ref-filter: add support to display trailers as part of contents

From: Jacob Keller <jacob.kel...@gmail.com> Add %(trailers) and %(contents:trailers) to display the trailers as interpreted by trailer_info_get. Update documentation and add a test for the new feature. Signed-off-by: Jacob Keller <jacob.kel...@gmail.com> --- Documentation/git-for-

[PATCH v2 1/2] pretty: add %(trailers) format for displaying trailers of a commit message

From: Jacob Keller <jacob.kel...@gmail.com> Recent patches have expanded on the trailers.c code and we have the builtin commant git-interpret-trailers which can be used to add or modify trailer lines. However, there is no easy way to simply display the trailers of a commit message. Add s

Re: [PATCH 0/2] add format specifiers to display trailers

On Fri, Nov 18, 2016 at 3:38 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.e.kel...@intel.com> writes: > >> Git interpret-trailers will not recognize this as a trailer block >> because it doesn't have any standard git tags within it. Would it b

[PATCH 2/2] ref-filter: add support to display trailers as part of contents

From: Jacob Keller <jacob.kel...@gmail.com> Add %(trailers) and %(contents:trailers) to display the trailers as interpreted by trailer_info_get. Update documentation and add a test for the new feature. Signed-off-by: Jacob Keller <jacob.kel...@gmail.com> --- Documentation/git-for-

[PATCH 0/2] add format specifiers to display trailers

From: Jacob Keller <jacob.kel...@gmail.com> This is based off of jt/use-trailer-api-in-commands so that we can make use of the public trailer API that will parse a string for trailers. I use trailers as a way to store extra commit metadata, and would like a convenient way to obtain the tr

[PATCH 1/2] pretty: add %bT format for displaying trailers of a commit message

From: Jacob Keller <jacob.kel...@gmail.com> Recent patches have expanded on the trailers.c code and we have the builtin commant git-interpret-trailers which can be used to add or modify trailer lines. However, there is no easy way to simply display the trailers of a commit message. Add s

Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms

:12 PM, Junio C Hamano <gits...@pobox.com> wrote: >>>> Jacob Keller <jacob.kel...@gmail.com> writes: >>>> ... >>>> I think you are going in the right direction. I had a similar >>>> thought but built around a different axis. I.e. if

Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms

On November 15, 2016 9:42:03 AM PST, Junio C Hamano wrote: >I think you are going in the right direction. I had a similar >thought but built around a different axis. I.e. if strip=1 strips >one from the left, perhaps we want to have rstrip=1 that strips one >from the right,

Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms

On Mon, Nov 14, 2016 at 10:48 PM, Karthik Nayak wrote: > On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano wrote: >> Karthik Nayak writes: >> - More importantly, what do these do? I do not think of a good description

Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms

On Mon, Nov 14, 2016 at 11:55 PM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Mon, Nov 14, 2016 at 10:48 PM, Karthik Nayak <karthik@gmail.com> wrote: >> On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano <gits...@pobox.com> wrote: >>> Karthik

Re: [PATCH v7 16/17] branch: use ref-filter printing APIs

On Mon, Nov 14, 2016 at 11:23 AM, Karthik Nayak <karthik@gmail.com> wrote: > Hello > > On Wed, Nov 9, 2016 at 5:44 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: >> On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik@gmail.com> wrote: >>>

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

On Fri, Nov 11, 2016 at 12:19 PM, Dennis Kaarsemaker wrote: > Today on #git, a user asked why git diff <(command1) <(command2) gave only > some > gibberish about pipes as output. The answer is fairly simple: git diff gets as > arguments /dev/fd/62 and /dev/fd/63, which

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > >> No tests or documentation updates yet, and I'm not sure whether >> --follow-symlinks in other modes than --no-index should be supported, ignored >> (as it is now)

Re: [PATCH v7 04/17] ref-filter: modify "%(objectname:short)" to take length

On Thu, Nov 10, 2016 at 9:36 AM, Karthik Nayak <karthik@gmail.com> wrote: > On Wed, Nov 9, 2016 at 4:57 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: >> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik@gmail.com> wrote: >>> From: Karthik Nayak

Re: [PATCH v7 03/17] ref-filter: implement %(if:equals=) and %(if:notequals=)

On Thu, Nov 10, 2016 at 9:31 AM, Karthik Nayak <karthik@gmail.com> wrote: > On Wed, Nov 9, 2016 at 4:52 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: >> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik@gmail.com> wrote: >> >> Ok. How do

Re: [PATCH v7 03/17] ref-filter: implement %(if:equals=) and %(if:notequals=)

On Thu, Nov 10, 2016 at 3:26 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >>> @@ -49,6 +51,10 @@ static struct used_atom { >>> enum { C_BARE, C_BODY, C_BODY_DEP,

Re: [PATCH v7 16/17] branch: use ref-filter printing APIs

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Port branch.c to use ref-filter APIs for printing. This clears out > most of the code used in branch.c for printing and replaces them with > calls made to the ref-filter

Re: [PATCH v7 00/17] port branch.c to use ref-filter's printing options

On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak wrote: > This is part of unification of the commands 'git tag -l, git branch -l > and git for-each-ref'. This ports over branch.c to use ref-filter's > printing options. > > Initially posted here: $(gmane/279226). It was

Re: [PATCH v7 15/17] branch, tag: use porcelain output

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Call ref-filter's setup_ref_filter_porcelain_msg() to enable > translated messages for the %(upstream:tack) atom. Although branch.c > doesn't currently use ref-filter's

Re: [PATCH v7 14/17] ref-filter: allow porcelain to translate messages in the output

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Introduce setup_ref_filter_porcelain_msg() so that the messages used in > the atom %(upstream:track) can be translated if needed. This is needed > as we port branch.c to

Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Add the options `:dir` and `:base` to all ref printing ('%(refname)', > '%(symref)', '%(push)' and '%(upstream)') atoms. The `:dir` option gives > the directory (the part

Re: [PATCH v7 12/17] ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Use the recently introduced refname_atom_parser_internal() within > remote_ref_atom_parser(), this provides a common base for all the ref > printing atoms, allowing

Re: [PATCH v7 11/17] ref-filter: introduce symref_atom_parser() and refname_atom_parser()

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Using refname_atom_parser_internal(), introduce symref_atom_parser() and > refname_atom_parser() which will parse the atoms %(symref) and > %(refname) respectively. Store

Re: [PATCH v7 09/17] ref-filter: make "%(symref)" atom work with the ':short' modifier

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > The "%(symref)" atom doesn't work when used with the ':short' modifier > because we strictly match only 'symref' for setting the 'need_symref' > indicator. Fix this by

Re: [PATCH v7 08/17] ref-filter: add support for %(upstream:track,nobracket)

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Add support for %(upstream:track,nobracket) which will print the > tracking information without the brackets (i.e. "ahead N, behind M"). > This is needed when we port

Re: [PATCH v7 07/17] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams

e behavior if people were expecting it to remain silent, but I think this could be considered a bug. > Mentored-by: Christian Couder <christian.cou...@gmail.com> > Mentored-by: Matthieu Moy <matthieu@grenoble-inp.fr> > Helped-by : Jacob Keller <jacob.kel...@gmail.com>

Re: [PATCH v7 06/17] ref-filter: introduce format_ref_array_item()

On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote: > From: Karthik Nayak > > To allow column display, we will need to first render the output in a > string list to allow print_columns() to compute the proper size of > each column before starting

Re: [PATCH v7 05/17] ref-filter: move get_head_description() from branch.c

On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Move the implementation of get_head_description() from branch.c to > ref-filter. This gives a description of the HEAD ref if called. This > is used as the refname for

Re: [PATCH v7 04/17] ref-filter: modify "%(objectname:short)" to take length

correct. Thanks, Jake > Add tests and documentation for the same. > > Mentored-by: Christian Couder <christian.cou...@gmail.com> > Mentored-by: Matthieu Moy <matthieu@grenoble-inp.fr> > Helped-by: Jacob Keller <jacob.kel...@gmail.com> > Signed-off-by: Karthik N

Re: [PATCH v7 03/17] ref-filter: implement %(if:equals=) and %(if:notequals=)

On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Implement %(if:equals=) wherein the if condition is only > satisfied if the value obtained between the %(if:...) and %(then) atom > is the same as the given ''. > >

Re: [PATCH v7 02/17] ref-filter: include reference to 'used_atom' within 'atom_value'

On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Ensure that each 'atom_value' has a reference to its corresponding > 'used_atom'. This let's us use values within 'used_atom' in the > 'handler' function. > > Hence we

Re: [PATCH v7 01/17] ref-filter: implement %(if), %(then), and %(else) atoms

On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak wrote: > From: Karthik Nayak > > Implement %(if), %(then) and %(else) atoms. Used as > %(if)...%(then)...%(end) or %(if)...%(then)...%(else)...%(end). If the > format string between %(if) and %(then)

Re: [PATCH v4 1/2] lib-proto-disable: variable name fix

On Mon, Nov 7, 2016 at 12:48 PM, Jeff King wrote: > It's possible that I'm overly picky about my commit messages, but that > does not stop me from trying to train an army of picky-commit-message > clones. :) > > -Peff You're not the only one ;) Regards, Jake

Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate

On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson wrote: > +log.noAbbrevTags:: > + Each value is a glob pattern, specifying tag nammes which > + should always be displayed in full, even when other tags may > + be omitted or abbreviated (for example, by

Re: [PATCH 1/3] gitk: turn off undo manager in the text widget

On Mon, Nov 7, 2016 at 10:57 AM, Markus Hitter wrote: > From e965e1deb9747bbc2b40dc2de95afb65aee9f7fd Mon Sep 17 00:00:00 2001 > From: Markus Hitter > Date: Sun, 6 Nov 2016 20:38:03 +0100 > Subject: [PATCH 1/3] gitk: turn off undo manager in the text widget >

Re: Regarding "git log" on "git series" metadata

On Sun, Nov 6, 2016 at 5:18 PM, Josh Triplett wrote: > Once we have gitrefs, you have both alternatives: reachable (gitref) or > not reachable (gitlink). > > However, if you want some way to mark reachable objects as not > reachable, such as for a sparse checkout, external

Re: gitk: avoid obscene memory consumption

On Sun, Nov 6, 2016 at 2:28 AM, Markus Hitter wrote: > - Storing only the actually viewed diff. It's an interactive tool, so there's > no advantage in displaying the diff in 0.001 seconds over viewing it in 0.1 > seconds. As far as I can see, Gitk currently stores every diff

Re: Regarding "git log" on "git series" metadata

On Sun, Nov 6, 2016 at 9:33 AM, Josh Triplett wrote: > On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote: >> Josh Triplett writes: >> > We could, but if we (or one of the many third-party git implementations) >> > miss a case,

Re: [PATCH v2 1/6] submodules: add helper functions to determine presence of submodules

On Tue, Nov 1, 2016 at 10:31 AM, Stefan Beller wrote: > On Tue, Nov 1, 2016 at 10:20 AM, Junio C Hamano wrote: > >> >> Maybe I am old fashioned, but I'd feel better to see these with >> explicit "extern" in front (check the older header files like >>

Re: Regarding "git log" on "git series" metadata

On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett wrote: > On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote: >> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett wrote: >> > On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote: >>

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett wrote: > That said, I'd *love* to have gitrefs available, for a wide variety of > applications, and I can see an argument for introducing them and waiting > a few years for them to become universally available, similar to the >

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 12:49 PM, Jeff King wrote: > I think the main complication is that the reachability rules are used > during object transfer. So you'd probably want to introduce some > protocol extension to say "I understand gitrefs", so that when one side > says "I have sha1

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 10:57 AM, Junio C Hamano wrote: > I think this is backwards. The root cause of the issue you have > with "gitk" is because you added something that is *NOT* a parent to > your commit. We shouldn't have to add a mechanism to filter > something that

Re: Git issue

On Tue, Nov 1, 2016 at 2:23 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote: >> >>> > From "git help update-index": >>> > >>> > --[no-]assume-unchanged >>> >When this flag is specified,

Re: [PATCH 2/3] submodule-config: rename commit_sha1 to commit_or_tree

On Wed, Nov 2, 2016 at 4:17 PM, Stefan Beller wrote: > -`const struct submodule *submodule_from_path(const unsigned char > *commit_sha1, const char *path)`:: > +`const struct submodule *submodule_from_path(const unsigned char > *commit_or_tree, const char *path)`:: > >

Re: [ANNOUNCE] Git v2.11.0-rc0

On Tue, Nov 1, 2016 at 2:10 PM, Stefan Beller wrote: > On Tue, Nov 1, 2016 at 1:59 PM, Jeff King wrote: >> On Tue, Nov 01, 2016 at 01:56:34PM -0700, Junio C Hamano wrote: >> >>> > As of -rc0, we have both --indent-heuristic and --compaction-heuristic >>> >

Re: [PATCH] compat: Allow static initializer for pthreads on Windows

On Fri, Oct 28, 2016 at 6:01 AM, Philip Oakley wrote: > From: "Johannes Sixt" >> >> >> One point is that the DCLP idiom must be implemented correctly. There are >> solutions, of course, and when the initialization is over, we have a >> miniscule overhead at

Re: [PATCH] compat: Allow static initializer for pthreads on Windows

On Fri, Oct 28, 2016 at 4:58 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Jake, > > On Thu, 27 Oct 2016, Jacob Keller wrote: > >> I agree with Stefan that there isn't really a great place to put a >> dynamic initialization. > > Ummm. Wait. Wh

Re: [PATCH] compat: Allow static initializer for pthreads on Windows

On Thu, Oct 27, 2016 at 10:55 PM, Johannes Sixt wrote: > One point is that the DCLP idiom must be implemented correctly. There are > solutions, of course, and when the initialization is over, we have a > miniscule overhead at each pthread_mutex_lock call. > Right, this I

Re: [PATCH] compat: Allow static initializer for pthreads on Windows

On Thu, Oct 27, 2016 at 1:05 PM, Johannes Sixt wrote: >> The implementation under discussion (well we did not discuss the >> implementation a >> whole lot yet) ... > > > There's not a whole lot to discuss: it must be rewritten from scratch (it's > not just the memory barriers, it

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 2:04 PM, Jeff King wrote: > I'm not convinced this is needed for in-repo .gitignore files. The point > is that you are pulling together separate files that may be administered > independently. But git repositories inherently have a whole-project > view. I'm

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 3:50 AM, Jeff King wrote: > On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote: > >> The use case for this is where I did not write my own rules, but I want >> to keep them updated. https://github.com/github/gitignore is a damn good >> resource, but

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Sat, Oct 22, 2016 at 2:19 AM, Lukas Fleischer <lfleisc...@lfos.de> wrote: > On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote: >> [...] >> I still think we're misunderstanding. I want git commit to complain >> *only* under the following circumstance: >> >&g

Re: [PATCH 4/3] test-lib: bail out when "-v" used under "prove"

On Fri, Oct 21, 2016 at 9:45 PM, Jeff King wrote: > I thought I'd just knock this out in 5 minutes before I forgot about it. > But as with so many things, getting it right proved slightly harder than > I thought. Always seems to be that way, doesn't it? > But I did learn about

Re: generating combined diff without an existing merge commit

On Fri, Oct 21, 2016 at 3:41 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> Turns out that somehow I must have messed up my command because "git >> diff " does indeed do exactly what I >> want. &

Re: generating combined diff without an existing merge commit

On Fri, Oct 21, 2016 at 2:40 PM, Jacob Keller <jacob.kel...@gmail.com> wrote: > Hi, > > I recently determined that I can produce an interdiff for a series > that handles rebasing nicely and shows the conflicts resolved when > rebasing plus any other changes. > > The b

generating combined diff without an existing merge commit

Hi, I recently determined that I can produce an interdiff for a series that handles rebasing nicely and shows the conflicts resolved when rebasing plus any other changes. The basic idea is something like the following, assuming that v1 is a tag that points to the first version, v2 is a tag that

Re: Prove "Tests out of sequence" Error

On Fri, Oct 21, 2016 at 8:48 AM, Jeff King <p...@peff.net> wrote: > On Fri, Oct 21, 2016 at 08:42:58AM -0700, Jacob Keller wrote: > >> > For $HARNESS_ACTIVE with _just_ "--verbose", I don't think it would be a >> > good idea to activate it. We

Re: Prove "Tests out of sequence" Error

On Fri, Oct 21, 2016 at 8:35 AM, Jeff King <p...@peff.net> wrote: > On Fri, Oct 21, 2016 at 08:29:49AM -0700, Jacob Keller wrote: > >> > The Travis tests do exactly this (along with --tee to actually save the >> > output). It seems like a minor miracle that this

Re: Prove "Tests out of sequence" Error

On Fri, Oct 21, 2016 at 1:43 AM, Jeff King wrote: > prove t5547-push-quarantine.sh :: -v > > The Travis tests do exactly this (along with --tee to actually save the > output). It seems like a minor miracle that this is the first test > output that has actually triggered as TAP

[PATCH v3] rev-list: use hdr_termination instead of a always using a newline

From: Jacob Keller <jacob.kel...@gmail.com> When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output.

[PATCH v2] rev-list: use hdr_termination instead of a always using a newline

From: Jacob Keller <jacob.kel...@gmail.com> When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output.

Re: [PATCH] rev-list: use hdr_termination instead of a always using a newline

On Thu, Oct 20, 2016 at 11:54 AM, Junio C Hamano wrote: > > The main part of the patch looks good. For "passing NUL to sed", > I'd probably work it around like so: > Yep. I wasn't sure on the test as it was, because of the portability concern. > t/t6000-rev-list-misc.sh |

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >>> I am not sure if that is OK. I think it is less not-OK than the use >>> case I mentioned in my earlier message, in that this is

[PATCH] rev-list: use hdr_termination instead of a always using a newline

From: Jacob Keller <jacob.kel...@gmail.com> When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output.

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> I still think we're misunderstanding. I want git commit to complain >> *only* under the following circumstance: >> >> I

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

On Thu, Oct 20, 2016 at 11:04 AM, Dennis Kaarsemaker wrote: > On Wed, 2016-10-19 at 15:41 -0700, Junio C Hamano wrote: >> Dennis Kaarsemaker writes: >> >> > + touch expect && >> > + printf "\0" > expect && >> >> >> What's the point of that

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano wrote: > Jeff King writes: > >>> I still think it's worth while to add a check for git-commit which >>> does something like check when we say "git commit " and if the >>> index already has those files marked as

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Wed, Oct 19, 2016 at 7:13 PM, Jeff King wrote: > I suspect both of those would complain about legitimate workflows. > > I dunno. I do not ever use "git commit " myself. I almost > invariably use one of "git add -p" (to review changes as I add them) or > "git add -u" (when I

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Wed, Oct 19, 2016 at 3:42 PM, Jeff King <p...@peff.net> wrote: > On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote: > >> I recently (and in the past) had an issue where I was using git add >> --interactive and accidentally did something like the following: >

tools for easily "uncommitting" parts of a patch I just commited?

Hi, I recently (and in the past) had an issue where I was using git add --interactive and accidentally did something like the following: # hack lots of randmo changes, then begin trying to commit then separately git add -i # set only the changes I want # accidentally add to the commit $git

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

Hi, On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker wrote: > Commit 660e113 (graph: add support for --line-prefix on all graph-aware > output) changed the way commits were shown. Unfortunately this dropped > the NUL between commits in --header mode. Restore the NUL

Re: [PATCH v12 3/8] graph: add support for --line-prefix on all graph-aware output

Hi, On Wed, Oct 19, 2016 at 1:24 PM, Dennis Kaarsemaker <den...@kaarsemaker.net> wrote: > On Wed, 2016-08-31 at 16:27 -0700, Jacob Keller wrote: >> From: Jacob Keller <jacob.kel...@gmail.com> >> >> Add an extension to git-diff and git-log (and any other

Re: [PATCHv2] attr: convert to new threadsafe API

On Wed, Oct 12, 2016 at 1:07 PM, Johannes Sixt wrote: > > Sigh. DCLP, the Double Checked Locking Pattern. These days, it should be > common knowledge among professionals that this naïve version _does_not_work_ > [1]! > > I suggest you go without it, then measure, and only *then*

Re: [PATCH 5/5] versioncmp: cope with common leading parts in versionsort.prereleaseSuffix

On Wed, Oct 5, 2016 at 3:15 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >> Gut feeling tells me that I should take this as a subtle >> encouragement to look into adding 'versionsort.postreleasesuffix', >> shouldn't I ;) > > It is more like "this made

Re: [PATCH 06/18] t5613: clarify "too deep" recursion tests

On Wed, Oct 5, 2016 at 7:40 AM, Jeff King wrote: > On Wed, Oct 05, 2016 at 03:58:53PM +0200, Jakub Narębski wrote: > >> I would prefer the following: >> >> # A --> B --> C --> D --> E --> F --> G --> H >> # 0 1 2 3 4 5 6 > > Yeah, that is also more

<    1   2   3   4   5   6   7   8   9   10   >