Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread Jacob Keller
On Wed, Jul 22, 2015 at 11:53 PM, Jeff King wrote: > "man git" already has such a list (which is generated from the > annotations in command-list.txt). But I agree that it would probably be > helpful to point people directly from "git log" to "git rev-list" and > vice versa. > > -Peff That's good

Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread Jeff King
On Wed, Jul 22, 2015 at 11:32:49PM -0700, Jacob Keller wrote: > Agreed. Fix the plumbing instead and document how/why to use it > instead of the porcelain. We might do better to help clearly document > which commands are porcelain and which are plumbing maybe by > referencing which plumbings to us

Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread Jacob Keller
On Wed, Jul 22, 2015 at 10:48 PM, Jeff King wrote: > On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote: > >> Script writers should not care here, because they should not be parsing >> the output of the porcelain "log" command in the first place. It already >> has many gotchas (e.g., log.da

Re: [PATCH] receive-pack: crash when checking with non-exist HEAD

2015-07-22 Thread Jeff King
On Wed, Jul 22, 2015 at 01:30:00PM -0700, Junio C Hamano wrote: > I see a similar "if head_name is NULL, don't bother." check in > is_ref_checked_out() so in that sense this is a correct fix to the > immediate problem. That check came from 986e8239 (receive-pack: > detect push to current branch o

Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread Jeff King
On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote: > Script writers should not care here, because they should not be parsing > the output of the porcelain "log" command in the first place. It already > has many gotchas (e.g., log.date, log.abbrevCommit). > > I am sympathetic, though. Ther

Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread Jeff King
On Wed, Jul 22, 2015 at 09:40:10PM -0700, David Aguilar wrote: > On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote: > > This patch adds an option to turn on --first-parent all the > > time, along with the corresponding --no-first-parent to > > disable it. > > [Putting on my scripter hat]

Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread David Aguilar
On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote: > This patch adds an option to turn on --first-parent all the > time, along with the corresponding --no-first-parent to > disable it. [Putting on my scripter hat] I sometimes think, "it would be really helpful if we had a way to tell Git

[RFC/PATCH] log: add log.firstparent option

2015-07-22 Thread Jeff King
This patch adds an option to turn on --first-parent all the time, along with the corresponding --no-first-parent to disable it. The "why" of this requires a bit of backstory. Some projects (like git.git) encourage frequent rebasing to generate a set of clean, bisectable patches for each topic. The

Re: [PATCH 2/2] refs: loosen restriction on wildcard "*" refspecs

2015-07-22 Thread Jacob Keller
On Wed, Jul 22, 2015 at 3:04 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> From: Jacob Keller >> >> Modify logic of check_refname_component and add a new disposition >> regarding "*". Allow refspecs that contain a single "*" if >> REFNAME_REFSPEC_PATTERN is set. Change the function to pa

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

2015-07-22 Thread Ramsay Jones
On 21/07/15 20:25, Junio C Hamano wrote: > "Philip Oakley" writes: > >> ... Ideally, if part of this >> mainstream Git, it would get picked up automatically by them >> (rather than being local 'fixes' endlessly carried forward). > > Actually, that is not "ideal", but what I want to avoid. > > A

Re: [PATCH 2/2] refs: loosen restriction on wildcard "*" refspecs

2015-07-22 Thread Junio C Hamano
Jacob Keller writes: > From: Jacob Keller > > Modify logic of check_refname_component and add a new disposition > regarding "*". Allow refspecs that contain a single "*" if > REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as > a pointer, and clear REFNAME_REFSPEC_PATTERN a

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

2015-07-22 Thread Tony Finch
Jakub Narębski wrote: > > Food for thought Yes, very helpful, thanks. I got mobbed by other things today so I won't be able to get back to this until next week. Tony (off for a few days holiday). -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea, Shannon: West or southwest, vee

[PATCH v5 0/2] refs: cleanup and new behavior

2015-07-22 Thread Jacob Keller
From: Jacob Keller As per Junio's suggestion, break cleanup/fix and new functionality into separate patches. Also update description of the new functionality. The first patch is entirely cleanup of comments with no functionality change at all (indeed only changes to comment text!). It now correc

[PATCH 1/2] refs: cleanup comments regarding check_refname_component

2015-07-22 Thread Jacob Keller
From: Jacob Keller Correctly specify all characters which are rejected under the '4' disposition, including '*' even though it does gain special treatment by callers of check_refname_component. Cleanup comment style for rejected refs by inserting a ", or" at the end of each statement. Signed-of

[PATCH 2/2] refs: loosen restriction on wildcard "*" refspecs

2015-07-22 Thread Jacob Keller
From: Jacob Keller Modify logic of check_refname_component and add a new disposition regarding "*". Allow refspecs that contain a single "*" if REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as a pointer, and clear REFNAME_REFSPEC_PATTERN after the first "*" so that only a

Re: [PATCH v5] pull: allow dirty tree when rebase.autostash enabled

2015-07-22 Thread Kevin Daudt
On Wed, Jul 22, 2015 at 12:42:17PM -0700, Junio C Hamano wrote: > Kevin Daudt writes: > > > On Tue, Jul 07, 2015 at 11:59:56AM +0800, Paul Tan wrote: > > > > Any news about this? Is it still waiting for something? > > Paul's patch was buried in the noise and I didn't notice it. > > I'd prefer t

Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet

2015-07-22 Thread Junio C Hamano
Sebastian Schuberth writes: > "--quite" is documented to "Disable all output of the program". Yet > calling diff-tree with a single commit like > > $ git diff-tree --quiet c925fe2 > > was logging > > c925fe23684455735c3bb1903803643a24a58d8f At this point, unfortunately I think we need to call th

Re: [PATCH] receive-pack: crash when checking with non-exist HEAD

2015-07-22 Thread Junio C Hamano
Jiang Xin writes: > If HEAD of a repository points to a conflict reference, such as: > > * There exist a reference named 'refs/heads/jx/feature1', but HEAD > points to 'refs/heads/jx', or > > * There exist a reference named 'refs/heads/feature', but HEAD points > to 'refs/heads/feature/bad'.

Re: Git tag: pre-receive hook issue

2015-07-22 Thread Jakub Narębski
On 2015-07-19, Jacob Keller wrote: > git describe will tell you if the commit you're passing it is > associated with an annotated tag. I do not understand who this > information can help you implement any policy, so understanding what > the policy you want is would be the most helpful. One policy

Re: [PATCH v5] pull: allow dirty tree when rebase.autostash enabled

2015-07-22 Thread Junio C Hamano
Kevin Daudt writes: > On Tue, Jul 07, 2015 at 11:59:56AM +0800, Paul Tan wrote: > > Any news about this? Is it still waiting for something? Paul's patch was buried in the noise and I didn't notice it. I'd prefer to see a new feature like this, that did not exist in the original, be done on top

Re: [PATCH v3 9/9] tag.c: implement '--merged' and '--no-merged' options

2015-07-22 Thread Matthieu Moy
Karthik Nayak writes: > +--merged []:: > + Only list tags whose tips are reachable from the > + specified commit (HEAD if not specified). > + > +--no-merged []:: > + Only list tags whose tips are not reachable from the > + specified commit (HEAD if not specified). You may want to

Re: [PATCH v3 8/9] tag.c: implement '--format' option

2015-07-22 Thread Matthieu Moy
Karthik Nayak writes: > --- a/Documentation/git-tag.txt > +++ b/Documentation/git-tag.txt > @@ -13,7 +13,8 @@ SYNOPSIS >[ | ] > 'git tag' -d ... > 'git tag' [-n[]] -l [--contains ] [--points-at ] > - [--column[=] | --no-column] [--sort=] [...] > + [--column[=] | --no-column] [--

Re: [PATCH v4] refs: loosen restrictions on wildcard '*' refspecs

2015-07-22 Thread Junio C Hamano
Jacob Keller writes: > diff --git a/refs.c b/refs.c > index ce8cd8d45001..a65f16fedaa0 100644 > --- a/refs.c > +++ b/refs.c > @@ -20,11 +20,12 @@ struct ref_lock { > * 2: ., look for a preceding . to reject .. in refs > * 3: {, look for a preceding @ to reject @{ in refs > * 4: A bad charac

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

2015-07-22 Thread Jakub Narębski
W dniu 2015-07-22 o 15:19, Tony Finch pisze: > Jakub Narębski wrote: >> >> A question about implementation: why emptying $path_info in >> evaluate_path_info()? > > That was for consistency with other parts of the subroutine which (mostly) > remove items from the global $path_info variable when th

Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

2015-07-22 Thread Junio C Hamano
Junio C Hamano writes: > The former, sort by "time", is interesting, but you need to define > what to do with various corner cases. For example, some people may > have one or more of the following desires: > > * My project did not use tags for a long time, and started using it >recently sta

Re: [PATCH v3 5/9] ref-filter: add option to match literal pattern

2015-07-22 Thread Matthieu Moy
Karthik Nayak writes: > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -943,9 +943,23 @@ static int commit_contains(struct ref_filter *filter, > struct commit *commit) > > /* > * Return 1 if the refname matches one of the patterns, otherwise 0. > + * A pattern can be a literal prefix (e.g. a

Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

2015-07-22 Thread Junio C Hamano
Halil Öztürk writes: > Passing a number as an option to "git tags" command should display latest > tags. > > e.g. "git tags -5" will display last 5 tags only. I think this conflates two unrelated things. - Ordering tags not by refnames (i.e. default) but by "time". - Limiting the output by

Re: [PATCH v5] pull: allow dirty tree when rebase.autostash enabled

2015-07-22 Thread Kevin Daudt
On Tue, Jul 07, 2015 at 11:59:56AM +0800, Paul Tan wrote: > On Mon, Jul 06, 2015 at 01:39:47PM -0700, Junio C Hamano wrote: > > Kevin Daudt writes: > > > > > rebase learned to stash changes when it encounters a dirty work tree, but > > > git pull --rebase does not. > > > > > > Only verify if the

Re: [PATCH 3/3] doc: give examples for send-email cc-cmd operation

2015-07-22 Thread Junio C Hamano
"Philip Oakley" writes: >> It is an >> unacceptable hack for us to encourage in the longer term. It may >> happen to work with the current implementation, but it does so >> merely by depending on the implementation too much. >> >> If it is so common to want to spray all your patches to exactly

Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

2015-07-22 Thread Andreas Schwab
Halil Öztürk writes: > Passing a number as an option to "git tags" command should display latest > tags. How do you define "the latest tags"? By tag creation? Lightweight tags don't have any kind of creation time attached. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerpri

Re: [PATCH v3 1/9] ref-filter: add option to align atoms to the left

2015-07-22 Thread Matthieu Moy
Karthik Nayak writes: > + strtoul_ui(valp, 10, &ref->align_value); > + if (ref->align_value < 1) > + die(_("Value should be greater than zero")); You're not checking the return value of strtoul_ui, which returns -1 before assign

Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

2015-07-22 Thread Jacob Keller
On Wed, Jul 22, 2015 at 10:17 AM, Halil Öztürk wrote: > Hello team, > > Passing a number as an option to "git tags" command should display latest > tags. > > e.g. "git tags -5" will display last 5 tags only. > > Similar behavior to "git log -5" > > Thanks, > Halil > -- > To unsubscribe from this

[PATCH v4] refs: loosen restrictions on wildcard '*' refspecs

2015-07-22 Thread Jacob Keller
From: Jacob Keller Update the check_refname_component logic in order to allow for a less strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously the '*' could only replace a single full component, and could not replace arbitrary text. Now, refs such as `foo/bar*:foo/bar*` will be

Re: [PATCH v3] refs: loosen restrictions on wildcard '*' refspecs

2015-07-22 Thread Jacob Keller
On Wed, Jul 22, 2015 at 11:21 AM, David Turner wrote: > On Wed, 2015-07-22 at 09:06 -0700, Jacob Keller wrote: >> From: Jacob Keller >> >> Update the check_refname_component logic in order to allow for a less >> strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously >> the '*' co

Re: [PATCH v3] refs: loosen restrictions on wildcard '*' refspecs

2015-07-22 Thread David Turner
On Wed, 2015-07-22 at 09:06 -0700, Jacob Keller wrote: > From: Jacob Keller > > Update the check_refname_component logic in order to allow for a less > strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously > the '*' could only replace a single full component, and could not > rep

Feature Request: Passing a number as an option to git tags for displaying latest tags

2015-07-22 Thread Halil Öztürk
Hello team, Passing a number as an option to "git tags" command should display latest tags. e.g. "git tags -5" will display last 5 tags only. Similar behavior to "git log -5" Thanks, Halil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vg

Re: [PATCH] userdiff: add support for Fountain documents

2015-07-22 Thread Zoë Blade
Hi again Junio! Yes, your more elegant and accurate regex sounds much better than the way I was trying it. :) Please, go ahead and use yours instead. Thank you for your help! Thanks, Zoë.-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vge

[PATCH v3] refs: loosen restrictions on wildcard '*' refspecs

2015-07-22 Thread Jacob Keller
From: Jacob Keller Update the check_refname_component logic in order to allow for a less strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously the '*' could only replace a single full component, and could not replace arbitrary text. Now, refs such as `foo/bar*:foo/bar*` will be

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

2015-07-22 Thread Tony Finch
Jakub Narębski wrote: > > A question about implementation: why emptying $path_info in > evaluate_path_info()? That was for consistency with other parts of the subroutine which (mostly) remove items from the global $path_info variable when they are added to %input_params. But since $path_info isn'

[PATCH v2] diff-tree: do not show the sha1 of the given head with --quiet

2015-07-22 Thread Sebastian Schuberth
"--quiet" is documented to "Disable all output of the program". Yet calling diff-tree with a single commit like $ git diff-tree --quiet c925fe2 was logging c925fe23684455735c3bb1903803643a24a58d8f to the console despite "--quiet" being given. This is inconsistent with both the docs and the beha

Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet

2015-07-22 Thread Johannes Schindelin
On 2015-07-22 11:29, Sebastian Schuberth wrote: > "--quite" is documented to "Disable all output of the program". s/--quite/quiet/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

2015-07-22 Thread Jakub Narębski
On 2015-07-22, Tony Finch wrote: > Jakub Narębski wrote: > > Thanks for the review! > >>> * tf/gitweb-project-listing (2015-03-19) 5 commits >>> - gitweb: make category headings into links when they are directories >>> - gitweb: optionally set project category from its pathname >>> - gitweb:

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

2015-07-22 Thread Tony Finch
Jakub Narębski wrote: > Thanks for the review! > > * tf/gitweb-project-listing (2015-03-19) 5 commits > > - gitweb: make category headings into links when they are directories > > - gitweb: optionally set project category from its pathname > > - gitweb: add a link under the search box to clea

Re: [PATCH 2/2] Fix sed usage in tests to work around broken xpg4/sed on Solaris

2015-07-22 Thread Johannes Schindelin
Hi, On 2015-07-20 18:07, Junio C Hamano wrote: > Johannes Sixt writes: > >>> I really wonder why the previous ">file+ && mv -f file+ file" dance >>> needs to be replaced? >> >> The sed must be replaced because some versions on Solaris choke on the >> incomplete last line in the file. > > Switch

[PATCH] diff-tree: do not show the sha1 of the given head with --quiet

2015-07-22 Thread Sebastian Schuberth
"--quite" is documented to "Disable all output of the program". Yet calling diff-tree with a single commit like $ git diff-tree --quiet c925fe2 was logging c925fe23684455735c3bb1903803643a24a58d8f to the console despite "--quite" being given. This is inconsistent with both the docs and the beha

Re: Shallow Push?

2015-07-22 Thread Samuel Williams
> What is the receiving repository expected to have? Does it have everything that is required to checkout the back-then latest HEAD the last time a push was made into it, and you are pushing an update? Yes, something like that On 9 April 2015 at 15:54, Junio C Hamano wrote: > Samuel Williams w