Re: kha/safe and kha/experimental updated

From: Karl Hasselström <kha@treskal.com>
Date: Dec 19, 2007, 11:40 UTC
Message-ID: <20071219114021.GB5565@diana.vm.bytemark.co.uk>
In-Reply-To: <200712191144.59747.jnareb@gmail.com>

On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:

Show 22 quoted lines

> On Wed, 19 Dec 2007, Karl Hasselström wrote:
>
> > On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> >
> > > I also would like to have this command kept (and shown in 'stg
> > > help'!). Contrary to 'git add' it can check and add to index /
> > > update index only for files with conflict; we have -r
> > > (ancestor|current|patched) to choose one side, and we could add
> > > --check to check if there are no conflict markers with files
> > > (useful with -a/--all).
> >
> > This too sounds like stuff that could profitably be added to "git
> > add". Except for the ancestor/current/patched words, it is not
> > specific to patch stacks, so the implementation should be in git
> > and not in stg.
>
> No it cannot, at least the '-r (ancestor|current|patched)' part for
> resetting file to given version, even if we change the wording to
> ancestor, ours and theirs. The git-add command is about adding
> contents, which updates index, which almost as a intended
> side-effect clears merge state, i.e. stages; and not about resetting
> to stage.

  git checkout-index --stage=1|2|3 <filename>

does what you want. But "git cat-file" knows this handy syntax for getting at particular index stages:

  :stage:<filename>

It would be very convenient to be able to do

  git checkout :stage:<filename>

but it doesn't seem to work currently. Does anyone know the "best" way of manually checking out a particular index stage in git?

> Besides with "stg resolved" you can update index _only_ for files
> which were in the conflict, also for -a/--all, and not all the files
> not only those which were in the conflict like "git add -u" does.

This sounds like a straightforward addition to "git add".

> "stg resolved --check" could happily ignore things that only look
> like conflict markers, but must have been intended, because they are
> in files not in conflict.

git knows about conflicting files too.

> Unless you are talking about adding "resolve"/"resolved" command to
> git-core, as a porcelain wrapper around git-update-index, like "git
> add"...

Yes, that's what I want. You and others like what "stg resolved" does, but I don't want it in StGit because it's a generic git enhancement that has nothing to with patch stacks. People who don't use StGit would presumably like it as well.

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