> 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
"--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
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
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
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:
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/
"--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
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'
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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
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] [--
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
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
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
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'.
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
46 matches
Mail list logo
