Re: kha/safe and kha/experimental updated

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 19 Dec 2007, Karl Hasselström wrote:
> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> > "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> >
> > > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > >
> > > >       Remove "stg resolved"
> > >
> > > I'd like to keep this command. git-mergetool doesn't support the
> > > tool I use (emacs + ediff and more stgit-specific file extensions
> > > like current, patch etc.). I also don't find 'git add' to be
> > > meaningful for marking a conflict as solved.
> >
> > 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.

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.

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


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


P.S. I have just noticed that 'git-checkout' [<tree-ish>] <paths>...
form of operation is not documented; you can derive what it do
only from examples.

-- 
Jakub Narebski
Poland