Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Tue, 17 Feb 2009, Jay Soffian wrote: > >> On Tue, Feb 17, 2009 at 12:22 PM, Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> wrote: >> >> Unless dwim_ref() is updated to handle FETCH_HEAD specially, and >> >> return not the first SHA1, but the one not marked "not-for-merge". >> >> Then the UI would at least be consistent, but this would not be >> >> backward compatible. >> > >> > You cannot fix parsing FETCH_HEAD as a ref (and neither will you be able >> > to do with PUSH_HEAD), as it can contain _more_ than one SHA-1s. This >> > still holds true when ignoring the not-for-merge lines, as an octopus is >> > a quite real possibility. >> >> An even better argument against than it not being backward compatible. :-) >> >> And there is no PUSH_HEAD. > > Heh, that's why I used the future tense :-) FETCH_HEAD is something the user who is sitting in front of the repository controls with "git fetch" into it. The objects referenced from it is not part of the "reachable" set, and expectation is that anything that requires the objects will happen before that user decides to actively go prune unreachable objects. PUSH_HEAD is quite different, and it needs to be handled a lot more carefully. We have been looking at denyCurrentBranch as a way to capture gremlin updates and prevent it from confusing the end user, but PUSH_HEAD is more like a pull request in reverse. The necessary object transfer part has been already done, and the tip commit waits for the final merge step to pick it up. You might want a loud notification that tells you that there are outstanding reverse pull requests waiting to be picked up. Its need to protect the objects pushed from pruning is stronger than that of FETCH_HEAD. When PUSH_HEAD is in use for a receiving repository, we would intercept pushes to certain refs, and instead of updating them, append a record in the PUSH_HEAD file. Each entry of the file would record the object name and who pushed it from where and for which branch. A new front-end command to deal with PUSH_HEAD would allow the user to: * browse them, * choose one of them and comply, by checking out the destination branch and performing the merge, * choose one of them and discard, or * leave undecided. Earlier I've considered introducing the notion of (per-ref) split head. Forgetting the presense of packed-refs for now, when a gremlin push tries to update a ref that is the current branch, you would instead of overwriting the ref (that is 40-byte hexadecimal SHA-1 plus LF), append it (making it contain two such lines). Bash completion and friends can notice the situation and say "Your HEAD is split by a gremlin push", and the the user can choose to "git merge" the two (or more) commits recorded in the ref to get the split head merged again (optionally, if the work tree and the index is clean, and if the object the push is trying to overwrite the HEAD with is a descendant of the HEAD, then you can allow it to overwrite and run "reset --hard" afterwards, instead of splitting the head). I think Hg does something like that, and I think PUSH_HEAD is nicer than outright "you are not allowed to push into this branch", because the users already understand how a pull in response to a pull request works as a workflow. Having said that, there need to be clear and sane semantics defined to tell which push should go to PUSH_HEAD file and which should directly go to the underlying ref. It is probably the easiest to explain if all pushes to local refs are redirected to PUSH_HEAD when the repository is non-bare, but it means a non-bare repository cannot be used as the central shared repository for everybody to meet and swap with push-pull. We could only redirect push to the checked-out branch to PUSH_HEAD, but then that would introduce an inconsistency between checked-out branches and others from fetchers' point of view; pushes to some branches are observable from the outside while pushes to one special branch (the checked-out one) are not. -- 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
