Jed Brown writes:
> $ git rev-list --count v3.2..master
> 9651
> $ git rev-list --count v3.3..master
> 6378
> $ git describe --tags master
> v3.2-9651-ga018267
Is 'master' a descendant of v3.3? I.e. what does
git rev-list master..v3.3
say?
--
To unsubscribe from this list: send the li
$ git rev-list --count v3.2..master
9651
$ git rev-list --count v3.3..master
6378
$ git describe --tags master
v3.2-9651-ga018267
I would have expected to see v3.3-6378-ga018267, given the documentation:
If multiple tags were found during the walk then the tag which has the
fewest commits dif
Johan Herland writes:
> The "$remote/$branch" syntax can be interpreted in two subtly different
> ways:
>
> 1. A shorthand name for the remote-tracking branch corresponding to a
> specific $branch from a specific $remote.
>
> 2. A refname fragment, which - when appended to "refs/remotes/" -
Jonathan Nieder writes:
> Thomas Rast wrote:
>> Junio C Hamano writes:
>
>>> * jn/config-ignore-inaccessible (2013-04-15) 1 commit
>>> - config: allow inaccessible configuration under $HOME
>>>
>>> When $HOME is misconfigured to point at an unreadable directory, we
>>> used to complain and di
refname_match() is used to check whether a given shorthand name matches a
given full refname, but that full refname does not always belong in the
local repo, rather it is sometimes taken from list of refs sent over from
a remote repo.
In preparation for adding alternative ways of expanding refspec
The "$remote/$branch" expression is often used as a shorthand with the
intention of referring to the remote-tracking branch corresponding to
the given $branch in the $remote repo.
Currently, Git resolves this by prepending "refs/remotes/" to the given
"$remote/$branch" expression, resulting in "re
shorten_unambiguous_ref() provides the reverse functionality to the
expansion of shorthand names into full refnames, i.e. it takes a full
refname (like "refs/heads/master"), and matches it against a pattern
(like "refs/heads/%.*s") to produce a shorthand name (like "master").
Being the last remain
In preparation for allowing alternative ways of expanding shorthand refs
(like "master") into full refnames (like "refs/heads/master"): Expand
the current ref_rev_parse_rules list into ref_expand_rules, a list of
struct ref_expand_rule objects that encode both an expansion pattern
(e.g. "refs/heads
Some users are interested in fetching remote refs into a separate namespace
in the local repo. E.g. instead of the usual remote config:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ...
they want to keep remote tags separate from local tags, and they may al
This test verifies that the following expressions all evaluate to the
full refname "refs/remotes/origin/heads/master":
- refs/remotes/origin/heads/master
- remotes/origin/heads/master
- origin/heads/master
- origin/master
Currently the last of these fail, because the "$remote/$branch" syntax
When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
we use the ref_rev_parse_rules list of expansion patterns. This list
allows "origin" to be expanded into "refs/remotes/origin/HEAD", by
using the "refs/remotes/%.*s/HEAD" pattern from that list.
shorten_unambiguous_ref() exists
The "$remote/$branch" syntax can be interpreted in two subtly different
ways:
1. A shorthand name for the remote-tracking branch corresponding to a
specific $branch from a specific $remote.
2. A refname fragment, which - when appended to "refs/remotes/" -
yields the remote-tracking bran
On Sat, May 4, 2013 at 9:48 PM, Jonathan Nieder wrote:
> Is there no way to convince PowerShell to treat the output of a
> command as binary data with no particular encoding?
The best I could find out is to pipe the output to set-content:
git show HEAD:targetfile | set-content targetfile
The de
Ramkumar Ramachandra writes:
> On Matthieu's note, I have a comment: symbolic refs are an absolute
> dead end. We didn't think of it from the start, and it's too late
> now. Do NOT go there: from my investigation, I believe that hooking
> up everything to the revision parser is the way forward.
On 02/05/2013 23:05, Junio C Hamano wrote:
>
>>> Z...A===X---o---o---B
>>>\\/
>>> W---Y
>>>
> OK, I think I understand it, and we are in agreement. For the
> purpose of the above paragraph, a side branch is what is not on the
> "--ancestry-path", so all of the
Thomas Rast wrote:
> Junio C Hamano writes:
>> * jn/config-ignore-inaccessible (2013-04-15) 1 commit
>> - config: allow inaccessible configuration under $HOME
>>
>> When $HOME is misconfigured to point at an unreadable directory, we
>> used to complain and die. This loosens the check.
>>
>> I
Junio C Hamano writes:
> "I have something worth saving, better than HEAD in some way
> (e.g. contains fixes), in my index. I want to keep it while I
> experiment an approach that is unrelated to it, so I want a clean
> slate in the working tree from HEAD without disturbing the index".
>
> At the
Thomas Rast writes:
>> I have been looking for such a command/option and no one gave me
>> sufficient answer. So this message should be considered as a feature
>> request. I had a situation where I had staged a file with a problem
>> solution in it, then I wanted to experiment with a different so
Thomas Rast writes:
> So for one thing, "ha ha we told you so" is not an extremely
> satisfactory answer, especially since we only "told them so" with the
> recent doc update. Wouldn't a stern warning or even an early error be
> better?
Sorry, I am not sure exactly what alternative you have i
Felipe Contreras writes:
>> This updates the parse_object() moved by the previous patch. At this
>> point in the codeflow, unlike the original, we already _know_ the
>> object must be a commit; wouldn't an equivalent of:
>>
>> object = &(lookup_commit(sha1)->object)
>>
>> be more correct
Martin Langhoff wrote:
> On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt wrote:
>> Since git 1.8.0 you can express this check as
>>
>> if git merge-base --is-ancestor $production_sha1 refs/heads/master
>
> Ah, that's great! Unfortunate it's not there in earlier / more widely
> used releases of
Dimitar Bonev wrote:
> @ThomasRast: 'git show HEAD:targetfile > targetfile' was proposed in
> the both links that I provided in the email that your replied to, but
> this introduces external dependency to the command interpreter to
> output the file unmodified but not every interpreter does this.
On 04/05/2013 20:25, Ramsay Jones wrote:
Sparse issues an "'sole_interesting' not declared. Should it be static?"
warning. In order to suppress the warning, since this symbol does not
need more than file visibility, we simply add the static modifier to
its declaration.
Thanks! I'll include tha
Sparse issues an "'sole_interesting' not declared. Should it be static?"
warning. In order to suppress the warning, since this symbol does not
need more than file visibility, we simply add the static modifier to
its declaration.
Signed-off-by: Ramsay Jones
---
Hi Kevin,
If you need to re-roll
On Sat, May 4, 2013 at 7:35 AM, Martin Langhoff
wrote:
[snip]
> When I do git pull, git is careful to only update the branch I have
> checked out (if appropriate). It leaves any other branches that track
> branches on the remote that has just been fetched untouched. I always
> thought that at some
[joining the discussion late; was travelling]
Duy Nguyen wrote:
> git co long-branch-name
> git diff A/@
> git reset --hard A/@
In this form, this looks highly inconsistent. You have to decide if
you want @ to resolve to the current branch name or HEAD. Our current
@-proposal makes @@{1} displa
On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt wrote:
> You mean "refs/heads/master" and "!=" here because -ne is numeric
> comparison in a shell script.
thanks! Yeah, I fixed those up late last night :-)
> Since git 1.8.0 you can express this check as
>
> if git merge-base --is-ancestor $pro
I think if there was such a command, it could well be common, at least
for me. I am somewhat surprised that from the three combinations of
resetting index and working dir's states of a file this is the one
that is missing (it is missing at commit level also for what is
worth). Summary table of res
Dimitar Bonev writes:
> I have been looking for such a command/option and no one gave me
> sufficient answer. So this message should be considered as a feature
> request. I had a situation where I had staged a file with a problem
> solution in it, then I wanted to experiment with a different solu
Junio C Hamano writes:
> * jn/config-ignore-inaccessible (2013-04-15) 1 commit
> - config: allow inaccessible configuration under $HOME
>
> When $HOME is misconfigured to point at an unreadable directory, we
> used to complain and die. This loosens the check.
>
> I do not think we agreed that
On 05/04/2013 02:31 AM, Felipe Contreras wrote:
> Turns out fast-export throws bad 'reset' commands because of a behavior
> in transport-helper that is not even needed.
>
> We should ignore them, otherwise we will threat
>
s/threat/treat/
> them as branches and fail.
>
> This was fixed in v1.8.2
On Sat, May 4, 2013 at 1:10 AM, David Aguilar wrote:
> On Thu, May 2, 2013 at 10:09 AM, Ramkumar Ramachandra
> wrote:
>> Felipe Contreras wrote:
>>> We probably should fix those, but that is orthogonal to the '@' shortcut.
>>>
>>> We can have the '@' shortcut *today*, with minimal changes to the
On Thu, May 2, 2013 at 10:09 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> We probably should fix those, but that is orthogonal to the '@' shortcut.
>>
>> We can have the '@' shortcut *today*, with minimal changes to the code
>> and the documentation, in a limited and understood sco
On Sat, May 4, 2013 at 8:31 AM, Norah Jones wrote:
> Hi,
>
> I did a series of commits and now I find one of my commit (not the topmost
> one) has an incorrect commit message. How can I change that specific one? I
> believe "git commit --amend" works only for the last commit.
True. Be aware tha
Hi,
I have been looking for such a command/option and no one gave me
sufficient answer. So this message should be considered as a feature
request. I had a situation where I had staged a file with a problem
solution in it, then I wanted to experiment with a different solution
so I had to revert the
Am 04.05.2013 00:46, schrieb Martin Langhoff:
> I am building a small git wrapper around puppet, and one of the
> actions it performs is auto-fastforwarding of branches without
> checking them out.
>
> In simplified code... we ensure that we are on a head called master,
> and in some cases "ppg co
36 matches
Mail list logo
