On 24/03/2008, Karl Hasselström <kha@treskal.com> wrote:
quoted text
> On 2008-03-20 15:19:12 +0000, Catalin Marinas wrote:
>
>
> > As I wrote on the patch system, I'd like to put back the explicit
>  > --keep option in goto.
>
>
> There are three possible values of "keepiness":
>
>   1. Make sure there are _no_ local changes. (Default for old
>      infrastructure.)
>
>   2. Make sure there are no local changes in the files we need to
>      touch. (Default for new infrastructure.)
>
>   3. Bring along local changes by means of a merge. (What the --keep
>      option does.)
>
>  git defaults to doing (2), and optionally does (3). (1) is
>  significantly slower than (2); I don't know how slow (3) is.

With the current functionality (see below), I prefer (1) to be the
default and (3) as optional (on stable, it does a reverse-apply of the
diff and it's kind of combination between 2 and 3 but without the
conflicts you could get with only 3).

My reason for this is that usually you "goto" a patch to do some
changes followed by "refresh". If there were local changes, they would
be included in the refreshed patch since this is the default StGIT
behaviour. To avoid this, I find myself running "status" before any
"goto".

quoted text
>  I think that (2) should be the default, because it's faster, it's what
>  git does, and I don't really see the point in complaining about local
>  changes in a file we won't need to touch anyway.

But in git, for committing, you usually need to run "git add" on the
files or specify "commit -a" explicitly. We would need to change the
"refresh" behaviour in the same way and, in this case, I would be OK
with (2) as the default.

I personally prefer the current "refresh" way but maybe because I'm
used to it. It would be useful to get other users' opinion on this UI
change. Might not be a bad change since git does this already, quilt
needs an explicit "add" (anyone knows about guilt?).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html