On Fri, Sep 20, 2013 at 10:51:55AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com writes:
Kevin Bracey ke...@bracey.fi 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
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 internal
Jeff King p...@peff.net 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
On Thu, Sep 19, 2013 at 09:58:23PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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,
On 11/09/2013 01:23, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi 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.
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:
Jonathan Nieder jrnie...@gmail.com 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
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
Kevin Bracey ke...@bracey.fi 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
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
Kevin Bracey ke...@bracey.fi 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
13 matches
Mail list logo
