Elijah Newren <newren@xxxxxxxxx> writes: > On Fri, Apr 8, 2016 at 11:08 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Elijah Newren <newren@xxxxxxxxx> writes: >> >> The goal is stated rather vaguely--when you have a working tree and >> perform this "in index" merge, you would obviously update the index >> with the merge result and ... > > Yes, I think you hit the nail on the head with your suggestions > elsewhere to (1) limit this to bare repository only, and/or (2) do the > "git merge --into master en/topic" > > I'll fix this. > ... > The pointer is helpful, but I struggle a bit with the name '--cached'. > The past tense in that word suggests to me that it should be a > read-only operation on the cache (which works for grep), rather than a > write operation (such as for merge or apply). It could also be > misconstrued in merge's case to think that the index is one of the > things being merged (rather than erroring out if the index doesn't > match HEAD). I know apply already uses --cached, but if others don't > mind, I personally would rather not use it here. Is this something > you feel strongly about, or are you okay with --index-only? "cached" is not in past tense, but is used an adjective. You can update what is in the index and that is to update the "cached" information. But I do not think we need to discuss this, because we do not need such an option, as I understand that your updated direction is to do one or both of (1) do the "merge and update HEAD only when no manual conflict resolution is needed" thing in a bare repository, (2) "git merge --into=master en/topic" does the "merge master and en/topic and update master only when no manual conflict resolution is needed and do so without touching HEAD, index or the working tree". Because the current "git merge" refuses to work without the working tree, (1) can be done without adding any new option---if you are run in a bare repository, by definition, you are being asked to do that new thing, and because you will not do the new thing in a repository with a working tree, there is no need for an option to tell the command, "no, don't do the usual thing but do this new thing". And obviously (2) already has a new option --into and no other new option is needed to tell the command that it needs to do that new thing. >> I have a suspicion that this would become moot, as the conclusion >> may become that "git merge" that works only in index does not make >> sense unless you are in a bare repository---in which case, these >> external merge drivers has to be given a temporary working tree >> anyway, and they can keep writing their result out to what they >> consider is the working tree (i.e. via GIT_WORK_TREE or something). >> You read the result of them from that temporary working tree into >> the index before cleaning the temporary working tree. That way, >> you do not have to touch them at all, no? In fact, the temporary >> working tree trick may be applicable even when you are working in a >> repository with a tree working tree. > > I'm a little confused; you seem to be suggesting git-merge-one-file > will always need to have a working tree of some sort, though I don't > see why. I was loosely referring to the working tree, which includes things like having a place you can safely check out temporary files as if they were one of the working tree files, i.e. the arrangement in which "merge-one-file" is designed to operate. Even if they are "tmpname" generated files, you do not want to clobber your $GIT_DIR with these random files when driving these blob level merge drivers in a bare repository. -- 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