git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [StGit PATCH 0/6] Two bugfixes

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
Mar 25, 2008, 10:46 UTC
Message-ID
<b0943d9e0803250346h7405c37egc9ba170a6dcc06bf@mail.gmail.com>
In-Reply-To
<20080324181225.GC23337@diana.vm.bytemark.co.uk>
On 24/03/2008, Karl Hasselström <kha@treskal.com> wrote:
Show 20 quoted lines
> 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
Previous: Karl HasselströmNext: Karl Hasselström
Message 12 of 14 in “Two bugfixes”
  1. 0/6 Two bugfixesKarl Hasselström, Mar 20, 2008
  2. 1/6 Use a special exit code for bugsKarl Hasselström, Mar 20, 2008
  3. 2/6 Make sure patches with no parents have an empty list of parentsKarl Hasselström, Mar 20, 2008
  4. 3/6 Try uncommitting a commit with not exactly one parentKarl Hasselström, Mar 20, 2008
  5. 4/6 Make sure that we only uncommit commits with exactly one parentKarl Hasselström, Mar 20, 2008
  6. 5/6 New test: conflicting push in dirty worktreeKarl Hasselström, Mar 20, 2008
  7. 6/6 Handle failed pushes differently depending on causeKarl Hasselström, Mar 20, 2008
  8. Catalin MarinasMar 20, 2008
  9. Karl HasselströmMar 24, 2008
  10. Catalin MarinasMar 24, 2008
  11. Karl HasselströmMar 24, 2008
  12. Catalin MarinasMar 25, 2008
  13. Karl HasselströmMar 25, 2008
  14. Catalin MarinasMar 25, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.