Re: kha/safe and kha/experimental updated

[Jakub Narebski <jnareb@gmail.com>]

Karl Hasselström wrote:
> On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:
>> 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>

I always forget which stage is which. It would be nice if 
git-checkout-index implemented human-friendly names, just like 
git-diff-files has --base, --ours, --theirs, i.e. if it would be 
possible to write

  git checkout-index --stage=base|ours|theirs <filename>

and perhaps even

  :base|ours|theirs:<filename>.

(but there is a problem with files containing ':'...).

> 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?

It's a pity it doesn't work. Or if not this, then perhaps

  git checkout --stage=ours -- <filename>

>> 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.

You mean adding another option to git-add, similar to '-u' option, but
updating only the files which were (are) in merge conflict; 
'-c'/'-r'/'-s' perhaps? This would be replacement for 
"stg resolved --all", wouldn't it (and with filename replacement for 
"stg resolved <filename>", of course)?


P.S. Sidenote: it would be nice if git-mergetool was updated to 
understand StGIT style interactive 2-way and 3-way merge configuration,
and not offer only limited choice of pre-defined interactive merge tools 
(although pre-defined are nice, too).

-- 
Jakub Narebski
Poland