On Fri, Mar 01, 2013 at 03:49:23PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> I actually was wondering if we can remove that sole uses of two-way
> >> merge with --reset -u from "git am" and replace them with something
> >> else. But we do want to keep local change that existed bef
Jeff King writes:
>> I actually was wondering if we can remove that sole uses of two-way
>> merge with --reset -u from "git am" and replace them with something
>> else. But we do want to keep local change that existed before "am"
>> started, so we cannot avoid use of two-way merge, I guess...
>
On Fri, Mar 01, 2013 at 03:06:57PM -0800, Junio C Hamano wrote:
> > I can believe it. So do we want to do that fix, then? Did you want to
> > roll up the two halves of it with a test and write a commit message? I
> > feel like you could write a much more coherent one than I could on this
> > subje
Jeff King writes:
> On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote:
>>
>> Nobody seems to use that combination, either from scripts or from C
>> (i.e. when opts.update==1 and opts.merge==1, opts.reset is not set)
>> with a twoway merge, other than "git am --abort/--skip".
>
> I c
On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote:
> An initial checkout is *supposed* to happen in an empty working
> tree, so if we code it not to overwrite an existing path in the
> working tree, the user cannot lose possibly precious contents with
> an mistaken initial checkout (t
Jeff King writes:
> PS I wonder if the "initial_checkout" hack can just go away under this
>new rule. Although we don't seem to use "o->reset" for the initial
>checkout. Which seems kind of weird. I would think the initial
>checkout would actually just be a oneway merge. Is the point
On Tue, Feb 26, 2013 at 01:41:54PM -0800, Junio C Hamano wrote:
> > Isn't this a repeat of:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=212316
> [...]
>
> Yeah, I think the patch in your message is a good starting point to
> solve a half of the issue (i.e. unmerg
Jeff King writes:
> On Tue, Feb 26, 2013 at 12:06:42PM -0800, Junio C Hamano wrote:
>
>> It seems that we have a corner case bug in two-way merge to reset
>> away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
>
> Isn't this a repeat of:
>
> http://thread.gmane.org/gmane.comp.version
On Tue, Feb 26, 2013 at 12:06:42PM -0800, Junio C Hamano wrote:
> It seems that we have a corner case bug in two-way merge to reset
> away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
Isn't this a repeat of:
http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=21231
It seems that we have a corner case bug in two-way merge to reset
away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
In a freshly created repository:
rm -f A Z
for i in $(seq 100)
do
echo hello
done >Z
git add Z
git commit -m initial
git branch
10 matches
Mail list logo
