Jeff King 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 agree that
On Thu, Sep 19, 2013 at 11:02:17AM -0700, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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 all of tha
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
Jeff King 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 y
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 mean oneway_merge() in un
Jeff King writes:
> On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote:
>
>> Taking the state of a subdirectory as a whole as "content", the
>> change we are discussing will make it more like "rm -fr dir && tar
>> xf some-content dir" to replace the directory wholesale, which I
>> per
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 fro
Jeff King writes:
> On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
>
>> Jeff King 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 resultin
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
> Jeff King 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 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 the
>
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
che
Uwe Kleine-König 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 commit -m b
>
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 result
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^ -
15 matches
Mail list logo
