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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
