Hi Ben, I'm really interested on improving on this. Please read below :)
On Sun, Sep 9, 2018 at 5:07 PM Ben Coman <b...@openinworld.com> wrote: > First, kudos to Iceberg team for detecting the mistake I made messing > around at the command line under the feet of an Iceberg managed repo. > I'm interested in some general discussion of a few ideas before logging > any issues. > > I had an Iceberg managed repo branch "ready-multiple-commands" > as shown at [A] in the attached pic. > (note that this is "exercism/pharo" not "pharo-project/pharo") > > I wanted to compare "git log --graph" between a few branches > so I jumped into a command prompt and did so. Along the way I changed > branch to "master" from the command line [B]. > Then friends arrived and it was six hours until I got back to it > and was presented with "Detached Working Copy" [C], > and I'd forgotten what I'd done. > > Repair repository [D] didn't make this immediately obvious > although given the two commits after a while I managed to work it out > and simply `git checkout ready-multiple-commands` at the command line > fixed things, returning the display to [A]. > > So the discussion points I'm interested in are: > > a. An extra column "Image Branch" with the existing column > renamed "Disk Branch" would have made my mistake immediately obvious. > Yes, this could be easily done. We can have a new version with that soon to try it out and see if this improves the situation. This change would have no significant side effect, and rolling back is cheap. So I'd like to experiment with this kind of simple UI issues, that may improve the overall understanding. > > b. Such under the covers command line operation may be a corner case(??), > so if not an extra column, a red Status message "Image Branch > ready-multiple-commands" or similar would have helped. > > Well, it is not necessarily a corner case, because this will happen for people maintaining external files... At least with current implementation. We are thinking on adding support for external files, but that will not arrive soon. Also, the "Detached working copy" is also a bit more complicated than checking out a different branch :). I'll do some writeup here so people can better understand the motivations behind the current implementation. I'll try to be clear, but this is much easier to talk about this issues around a blackboard... I can try to do some drawings next time ^^. So far we decided that Iceberg will not let you work unless you image's working copy is aligned with the repository's working copy/HEAD. This provokes this kind of situations when touching the repository from outside the image, but we think it is simpler to understand. An alternative solution could be to let the image and the disk diverge (like implementing in the image some kind of virtual branch). But this could be confusing also. Because this could lead to scenarios where you touch your disk working copy and the image does not "care" them? Also, take into account that every point of divergence in history will lead to new merge points, and this will increase the possibilities of conflicts. So, we could have: Image [commit X] - Disk working copy [commit Y] - Remote repository [commit Z] Imagine that we have a more complex (but flexible?) implementation that allows you to work in this scenario. Then you choose to pull from the image. - Merging Z with Y could lead to conflicts - Merging Y with X too. - And merging Z with X too. So that would lead to a super mess that would be hyper complicated for average users :) We have thought about this complex scenarios and we decided we wanted to avoid them, because already bare-git is complicated in itself... Actually, we have been really picky in our merge design and Iceberg only lets you merge 2 commits at a time (even if there are three commits in play when you pull: image, git HEAD and the pulled commit ;)). > c. In the first paragraph of [D] it was not apparent what "working copy" > and "repository commit" referred to (although after a while I worked it out > from the given commit hashes -- the former was in-Image and the latter > on-disk. But the files on disk are a "working copy" in all other git > documentation and it invites confusion not to refer to it like that. It > seems to me we deal with two working copies: an "image working copy" and a > "disk working copy". That terminology would have eased discovery of my > mistake. > There are effectively two working copies, yes :) I'll try to propose a new text for the repair action explanations soon enough. I'll ping you so you can do a double check on it ^^. > > d. Instead of the commit hashes [D], is it feasible to match those to > branches/tags and display those. That would have made my mistake more > obvious. > Not quite. Iceberg's working copy remembers the commit from where the code was loaded, not the branch. And the branch can move, so it's not necessarily a good source of that information. What I mean by this is that you will have also a "detached working copy" even if you're in the same branch, but on a different commit. Imagine you go to the command line, edit some tonel file by hand and commit. Iceberg will detect the change and tell you you're detached. > > d. In [D], its not clear the difference between: > "Discard local changes" > "Discard image changes" > I think they mean the same, we should review these texts. Also, consider that one of those repair actions (checkout what is in disk) is just a subset of the other one (checkout an existing branch). I was thinking if having both is really worth it or not... Keep pushing, I like your feedback, and if you're not satisfied with any of my answers just go on ^^. > > cheers -ben > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
