Re: [STGIT PATCH] replace "git repo-config" usage by "git config"

From: Karl Hasselström <kha@treskal.com>
Date: Jan 24, 2008, 07:01 UTC
Message-ID: <20080124070125.GA19653@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0801230842w250ab963t16a1ab3c8024487e@mail.gmail.com>

On 2008-01-23 16:42:41 +0000, Catalin Marinas wrote:

Show 20 quoted lines

> On 23/01/2008, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2008-01-23 11:35:03 +0000, Catalin Marinas wrote:
> >
> > > The 'goto' checks the local status before pushing
> >
> > No, it doesn't anymore
>
> Ah, OK. BTW, even if the tree was clean, a 'goto' failed on my Linux
> tree earlier today with the following message:
>
> $ stg goto realview-eb-header
> Popped realview-pb1176 -- realview-ioaddress
> fatal: Entry 'arch/arm/mach-realview/realview_pb11mp.c' not uptodate.
> Cannot merge.
> stg goto: Command aborted (all changes rolled back)
>
> It worked fine after running 'stg status' once (and not showing any
> changes). In the old GIT interface, we use to call refresh_index (i.e.
> 'git update-index -q --unmerged --refresh'). Does this still happen?

Ah, no, I guess it doesn't. And I guess it should. We should probably have a test for that ...

> The message above also shows what I meant with messages not being
> very clear. It reports "Popped" but actually failed. Showing
> "Popping ... done" would be better.

Not necessarily. Even with the latter message style, you'd sometimes get sequences like this:

  Popping p3 -- p1 ... done
  Pushing p4 ... done
  Pushing p5 ... done
  fatal: Entry 'some/annoying/file' not uptodate.
  Cannot merge.
  stg cool-command: Command aborted (all changes rolled back)

That is, the sequence of pushes and pops succeeded, but the changes were still rolled back due to a dirty worktree.

Now, this doesn't mean I don't agree with you about the "done" messages -- they serve as a kind of progress bar -- but just because it says "done" doesn't mean the change will still be in effect when the command returns.

And there should probably be an explicit "Checking out files ... done" stage when we run git-read-tree, since that tends to take relatively much time.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle