On Fri, Sep 20, 2013 at 10:51:55AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > My original question was going to be: why bother peeling at all if we
> > are just going to push the outer objects, anyway?
> >
> > And after staring at it, I somehow convinced myself that the answer was
>
Jeff King writes:
> My original question was going to be: why bother peeling at all if we
> are just going to push the outer objects, anyway?
>
> And after staring at it, I somehow convinced myself that the answer was
> that you were pushing both. But that is not the case. Sorry for the
> noise.
On Thu, Sep 19, 2013 at 09:58:23PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > One question, though. With your patch, if I do "tag1..tag2", I get both
> > the tags and the peeled commits in the pending object list. Whereas with
> > "^tag1 tag2", we put only the tags into the list, and
Jeff King writes:
> One question, though. With your patch, if I do "tag1..tag2", I get both
> the tags and the peeled commits in the pending object list. Whereas with
> "^tag1 tag2", we put only the tags into the list, and we expect the
> traversal machinery to peel them later. I cannot off-hand
On Thu, Sep 19, 2013 at 02:35:40PM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: revision: do not peel tags used in range notation
>
> A range notation "A..B" means exactly the same thing as what "^A B"
> means, i.e. the set of commits that are reachable from B but not
> from A. But the int
Junio C Hamano writes:
> Kevin Bracey writes:
>
>> To see the effect at the command line: "git log v1.8.3..v.1.8.4" hides
>> the merge, but "git log ^v1.8.3 v1.8.4" shows it. Whoops. A new
>> example of a dotty shorthand not being exactly equivalent.
>>
>> In the ".." case the v1.8.3 tag gets pe
Kevin Bracey writes:
> To see the effect at the command line: "git log v1.8.3..v.1.8.4" hides
> the merge, but "git log ^v1.8.3 v1.8.4" shows it. Whoops. A new
> example of a dotty shorthand not being exactly equivalent.
>
> In the ".." case the v1.8.3 tag gets peeled before being sent to
> add_r
On 11/09/2013 21:24, Jonathan Nieder wrote:
Kevin Bracey wrote:
On reflection I'm not sure what we should for the "simple history"
view of v1.8.3.1..v1.8.4. We're not rewriting parents, so we don't
get a chance to reconsider the merge as being zero-parent, and we do
have this little section of
Jonathan Nieder writes:
> I think you're right that dropping the "don't follow off-graph
> treesame parents" rule would be a sensible change. The usual point of
> the "follow the treesame parent" rule is to avoid drawing undue
> attention to merges of ancient history where some of the parents ar
Kevin Bracey wrote:
> On reflection I'm not sure what we should for the "simple history"
> view of v1.8.3.1..v1.8.4. We're not rewriting parents, so we don't
> get a chance to reconsider the merge as being zero-parent, and we do
> have this little section of graph to traverse at the bottom:
>
>
On 11/09/2013 01:23, Junio C Hamano wrote:
Kevin Bracey writes:
On 10/09/2013 20:19, Junio C Hamano wrote:
This command
$ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl
reports that a merge 766f0f8ef7 (which did not touch the specified
path at all) touches it.
Bisecting points at d0a
On 10/09/2013 20:19, Junio C Hamano wrote:
I am grumpy X-<.
It appears that we introduced a large breakage during 1.8.4 cycle to
the revision traversal machinery and made pathspec-limited "git log"
pretty much useless.
This command
$ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl
reports
Kevin Bracey writes:
> On 10/09/2013 20:19, Junio C Hamano wrote:
>> I am grumpy X-<.
>>
>> It appears that we introduced a large breakage during 1.8.4 cycle to
>> the revision traversal machinery and made pathspec-limited "git log"
>> pretty much useless.
>>
>> This command
>>
>> $ git log
I am grumpy X-<.
It appears that we introduced a large breakage during 1.8.4 cycle to
the revision traversal machinery and made pathspec-limited "git log"
pretty much useless.
This command
$ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl
reports that a merge 766f0f8ef7 (which did not touch
14 matches
Mail list logo
