git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org, "Erik Sandberg" <mandolaerik@gmail.com>
Subject: Re: [StGit PATCH 0/6] Two bugfixes
Date: Tue, 25 Mar 2008 10:46:00 +0000	[thread overview]
Message-ID: <b0943d9e0803250346h7405c37egc9ba170a6dcc06bf@mail.gmail.com> (raw)
In-Reply-To: <20080324181225.GC23337@diana.vm.bytemark.co.uk>

On 24/03/2008, Karl Hasselström <kha@treskal.com> wrote:
> 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".

>  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

  reply	other threads:[~2008-03-25 10:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20  0:31 [StGit PATCH 0/6] Two bugfixes Karl Hasselström
2008-03-20  0:31 ` [StGit PATCH 1/6] Use a special exit code for bugs Karl Hasselström
2008-03-20  0:31 ` [StGit PATCH 2/6] Make sure patches with no parents have an empty list of parents Karl Hasselström
2008-03-20  0:31 ` [StGit PATCH 3/6] Try uncommitting a commit with not exactly one parent Karl Hasselström
2008-03-20  0:31 ` [StGit PATCH 4/6] Make sure that we only uncommit commits with " Karl Hasselström
2008-03-20  0:31 ` [StGit PATCH 5/6] New test: conflicting push in dirty worktree Karl Hasselström
2008-03-20  0:32 ` [StGit PATCH 6/6] Handle failed pushes differently depending on cause Karl Hasselström
2008-03-20 15:19 ` [StGit PATCH 0/6] Two bugfixes Catalin Marinas
2008-03-24  8:35   ` Karl Hasselström
2008-03-24  9:16     ` Catalin Marinas
2008-03-24 18:12   ` Karl Hasselström
2008-03-25 10:46     ` Catalin Marinas [this message]
2008-03-25 11:05       ` Karl Hasselström
2008-03-25 15:27         ` Catalin Marinas

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=b0943d9e0803250346h7405c37egc9ba170a6dcc06bf@mail.gmail.com \
    --to=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    --cc=mandolaerik@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).