Jeff King p...@peff.net writes:
But I think that points to a larger problem, which is that we do
not want to just look at the entries that are different between the
tree and the index.
True. The unpack-trees API knows how to walk the index and trees in
parallel, and I tend to
On Tue, Sep 17, 2013 at 03:14:39PM -0700, Junio C Hamano wrote:
Yeah, then I agree that git checkout HEAD^ -- subdir should be a
one-way go HEAD^ merge limited only to the paths that match
subdir/.
If implemented in a straight-forward way, I suspect that we may end
up not removing subdir/b
Jeff King p...@peff.net writes:
An alternative would be to write the new entries to a temporary index
in memory. And then you can throw away the entries in the current index
that match the pathspec, and add in the entries from the temporary
index. I was just hoping that unpack-trees would do
On Thu, Sep 19, 2013 at 11:02:17AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
An alternative would be to write the new entries to a temporary index
in memory. And then you can throw away the entries in the current index
that match the pathspec, and add in the entries
Hello,
after these commands:
$ git init
$ mkdir subdir
$ echo a subdir/a
$ git add subdir/a
$ git commit -m a
$ echo more a subdir/a
$ echo b subdir/b
$ git add subdir/*
$ git commit -m b
$ git checkout HEAD^ --
Uwe Kleine-König u.kleine-koe...@pengutronix.de writes:
after these commands:
$ git init
$ mkdir subdir
$ echo a subdir/a
$ git add subdir/a
$ git commit -m a
$ echo more a subdir/a
$ echo b subdir/b
$ git add subdir/*
$ git
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the resulting paths in the index and the work tree
that match the given pathspec must be identical to that of the
tree-ish. In the resulting
On Tue, Sep 17, 2013 at 09:06:59PM +0200, Uwe Kleine-König wrote:
$ git checkout HEAD^ -- subdir
I'd expect that subdir/b is removed from the index as this file didn't
exist in HEAD^ but git-status only reports:
I'm not sure if this is intentional or not. The definition of git
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the resulting paths in the index and the work tree
that match the given pathspec must be identical to that of
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the resulting paths in the index and the
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the
On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote:
Hrm. Probably not. It is almost a one-way merge going to the named tree
(but limited by the pathspec), except that I think the current
git-checkout code may provide some safety checks related to where we are
coming from
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote:
So given that, is it fair to say that a one-way go here merge, limited
by pathspec, is the closest equivalent?
Sorry, but it is unclear to me what you mean by one-way go here
merge. Do you
13 matches
Mail list logo
