From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH v3 0/7] rebase.autostash completed
Date: Mon, 13 May 2013 10:32:11 +0200 [thread overview]
Message-ID: <vpqobcfcmb8.fsf@grenoble-inp.fr> (raw)
In-Reply-To: <CALkWK0mWRC9_QVYAu9Q4iAoVTpfkf9xkc9apjrdv6SyEiCq+hA@mail.gmail.com> (Ramkumar Ramachandra's message of "Mon, 13 May 2013 13:29:29 +0530")
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Junio C Hamano wrote:
>> Especially I did not check if there are
>> still undesirable data loss behaviour in corner cases that people
>> were worried about in the discussion.
>
> Check the tests. What am I missing?
I didn't do a thorough check, but my earlier comments are taken into
account, I didn't see anything wrong and the tests in 7/7 are good.
>> Perhaps "rebase" can be taught to be more careful when checking
>> if local changes may overlap with the changes being replayed.
>
> Frankly, I don't know if it's worth the effort. It might be a nice
> theoretical exercise, but what tangible benefit do I get as the end
> user (now that I have rebase.autostash)? In fact, I'll probably be
> slowing down the interactive rebase noticeably by executing a
> diff-tree at every step. And for what?
One benefit would be to avoid triggering rebuild (and editor reload) by
keeping the timestamps intact. But I agree it's probably not worth the
effort (and definitely isn't in the scope of this series).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2013-05-13 8:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-12 11:56 [PATCH v3 0/7] rebase.autostash completed Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 1/7] am: tighten a conditional that checks for $dotest Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 2/7] rebase -i: don't error out if $state_dir already exists Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 3/7] rebase: prepare to do generic housekeeping Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 4/7] am: return control to caller, for housekeeping Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 5/7] rebase -i: " Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 6/7] rebase --merge: " Ramkumar Ramachandra
2013-05-12 11:56 ` [PATCH 7/7] rebase: implement --[no-]autostash and rebase.autostash Ramkumar Ramachandra
2013-05-13 6:28 ` Junio C Hamano
2013-05-13 8:03 ` Ramkumar Ramachandra
2013-05-13 13:49 ` Junio C Hamano
2013-05-13 13:52 ` Ramkumar Ramachandra
2013-05-13 8:24 ` Matthieu Moy
2013-05-13 8:27 ` Ramkumar Ramachandra
2013-05-13 8:41 ` Matthieu Moy
2013-05-13 4:57 ` [PATCH v3 0/7] rebase.autostash completed Junio C Hamano
2013-05-13 7:59 ` Ramkumar Ramachandra
2013-05-13 8:32 ` Matthieu Moy [this message]
2013-05-13 14:02 ` Junio C Hamano
2013-05-13 14:00 ` Junio C Hamano
2013-05-13 14:17 ` Ramkumar Ramachandra
2013-05-13 14:56 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqobcfcmb8.fsf@grenoble-inp.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.