{"thread":{"id":"44191","subject":"\"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","startedAt":"2016-09-30T16:24:34Z","lastAt":"2016-10-07T18:56:24Z","messageCount":9,"participants":["Konstantin Khomoutov","Jakub Narębski","Kevin Daudt","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"302988","messageId":"20160930191413.002049b94b3908b15881b77f@domain007.com","threadId":"44191","inReplyTo":null,"subject":"\"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2016-09-30T16:14:13Z","receivedAt":"2016-09-30T16:24:34Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"The \"It Will Never Work in Theory\" blog has just posted a summary of a\nstudy which tried to identify shortcomings in the design of Git.\n\nIn the hope it might be interesting, I post this summary here.\nURL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n\nThe except from that resource written by Greg Wilson, the blog author:\n---------------->8----------------\nSantiago Perez De Rosso and Daniel Jackson: \"[Purposes, Concepts,\nMisfits, and a Redesign of Git]\n(http://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf)\", _SPLASH\n2016_. \n\n> Git is a widely used version control system that is powerful but\n> complicated. Its complexity may not be an inevitable consequence of\n> its power but rather evidence of flaws in its design. To explore this\n> hypothesis, we analyzed the design of Git using a theory that\n> identifies concepts, purposes, and misfits. Some well-known\n> difficulties with Git are described, and explained as misfits in\n> which underlying concepts fail to meet their intended purpose. Based\n> on this analysis, we designed a reworking of Git (called Gitless)\n> that attempts to remedy these flaws. \n> \n> To correlate misfits with issues reported by users, we conducted a\n> study of Stack Overflow questions. And to determine whether users\n> experienced fewer complications using Gitless in place of Git, we\n> conducted a small user study. Results suggest our approach can be\n> profitable in identifying, analyzing, and fixing design problems. \n\nThis paper presents a detailed, well-founded critique of one of the\nmost powerful, but frustrating, tools in widespread use today. A\nfollow-up to earlier work published in 2013, it is distinguished from\nmost other discussion of software design by three things: \n\n  1. It clearly describes its design paradigm, which comprises\n_concepts_ (the major elements of the user's mental model of the\nsystem), _purposes_ (which motivate the concepts), and _misfits_ (which\nare instances where concepts do not satisfy purposes, or contradict one\nanother). \n\n  2. It lays out Git's concepts and purposes, analyzes its main\nfeatures in terms of them, and uses that analysis to identify\nmis-matches. \n\n  3. Crucially, it then analyzes independent discussion of Git (on\nStack Overflow) to see if users are stumbling over the misfits\nidentified in step 2. \n\nThat would count as a major contribution on its own, but the authors go\nfurther. They have designed a tool called Gitless that directly\naddresses the shortcomings they have identified, and the penultimate\nsection of this paper presents a usability study that compares it to\nstandard Git. Overall, subjects found Gitles more satisfying and less\nfrustrating than Git, even though there was no big difference in\nefficiency, difficulty, or confusion. Quoting the paper, \"This apparent\ncontradiction might be due to the fact that all of the participants had\nused Git before but were encountering Gitless for the first time\nwithout any substantive training. Some participants (2 regular, 1\nexpert) commented that indeed their problems with Gitless were mostly\ndue to their lack of practice using it.\" \n\nThis paper is one of the best examples I have ever seen of how software\ndesigns ought to be critiqued. It combines an explicit, coherent\nconceptual base, detailed analysis of a specific system, design\ngrounded in that analysis, and an empirical check of that design.\nSadly, nothing shows the actual state of our profession more clearly\nthan the way this work has been greeted: \n\n> In some respects, this project has been a fool's errand. We picked a\n> product that was popular and widely used so as not to be investing\n> effort in analyzing a strawman design; we thought that its popularity\n> would mean that a larger audience would be interested in our\n> experiment. In sharing our research with colleagues, however, we have\n> discovered a significant polarization. Experts, who are deeply\n> familiar with the product, have learned its many intricacies,\n> developed complex, customized workflows, and regularly exploit its\n> most elaborate features, are often defensive and resistant to the\n> suggestion that the design has flaws. In contrast, less intensive\n> users, who have given up on understanding the product, and rely on\n> only a handful of memorized commands, are so frustrated by their\n> experience that an analysis like ours seems to them belaboring the\n> obvious.\n---------------->8----------------\n(This text is Copyright © Never Work in Theory, under the CC license.)\n"},{"id":"303028","messageId":"481910fd-5a5f-ffc6-b98c-61d48b4a2e49@gmail.com","threadId":"44191","inReplyTo":"20160930191413.002049b94b3908b15881b77f@domain007.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-09-30T22:24:57Z","receivedAt":"2016-09-30T22:25:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 30.09.2016 o 18:14, Konstantin Khomoutov pisze:\n\n> The \"It Will Never Work in Theory\" blog has just posted a summary of a\n> study which tried to identify shortcomings in the design of Git.\n> \n> In the hope it might be interesting, I post this summary here.\n> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n\nI will comment on the article itself, not just on the summary.\n\n| 2.2 Git\n[...]\n| But tracked files cannot be ignored; to ignore a tracked file\n| one has to mark it as “assume unchanged.” This “assume\n| unchanged” file will not be recognized by add; to make it\n| tracked again this marking has to be removed.\n\nWRONG!  Git has tracked files, untracked unignored files, and\nuntracked ignored files (mostly considered unimportant).\n\nThe \"assume unchanged\" bit is _performance_ optimization. It is not,\nand cannot be a 'ignore tracked files' bit - here lies lost work!!!\nYou can use (imperfectly) \"prefer worktree\" bit hack instead.\n\nYou can say, if 'ignoring change to tracked files' is motivation,\nor purpose, it lacks direct concept.\n\n[...]\n| As a result, when a user switches branches, files may be\n| unexpectedly overwritten. \n\nThis is possible _only_ if there are uncommitted changes. If they\nare there, and they do not conflict with switching a branch, they\nare \"floated\" to a newly checked out branch.\n\n| Git fails with an error if there are any conflicting changes,\n| effectively preventing the user from switching in this case.\n| To mitigate this problem, Git provides a way to save versions\n| of files to another storage area, called the “stash,” using\n| a special command issued prior to the branch switch.\n\nOr you can try to merge uncommitted changes with changes between\ntwo branches: current and switched to.\n\nOr you can forcibly discard your changes.\n\nOr (with modern Git), you can put each branch in a separate\nworking area (with \"git worktree\"), though the article may predate\nthis feature.\n\n[...]\n| *Syncing with Other Repositories* Crucial to the understanding\n| of how syncing with other repositories work is the notion\n| of a “remote branch.” This is a branch (pointer to a commit)\n| that (asynchronously) reflects the state of a branch in another\n| repository. It is updated whenever there is some network\n| communication (e.g., a push or fetch).\n\nIt is called \"remote-tracking branch\", rather than \"remote branch\".\nAt least in Git documentation. This branch is in local repository,\nnot in remote one. The remote-tracking branch for example\n`origin/master` follows (tracks) branch `master` in remote\nrepository `origin`.\n\n| The notion of a “remote branch” must not be confused\n| with that of an “upstream branch.” An upstream branch is\n| just a convenience for users: after the user assigns it to some\n| branch, commands like pull and push default to use that\n| branch for fetching and pushing changes if no branch is given\n| as input.\n\nActually \"upstream branch\" (and related \"upstream repository\")\nare a concept, not only a convenience. They denote a branch\n(usually in remote repository) which is intended to ultimately\ninclude changes in given branch. Note that \"upstream branch\"\ncan be set separately for any given local branch.\n\nOne thing that can enormously help recovering from errors, and\nis not covered in the list of concepts is REFLOG.\n\n\n[...]\n| 3. Operational Misfits\n[...]\n| *Saving Changes* Suppose you are in the middle of a long\n| task and want to save your changes, so that they can be later\n| retrieved in case of failure. How would you do that?\n\nYou would use `git stash` or `git stash --include-untracked`!\nIn more complicated situations (during long-running operation\nlike resolving merge conflicts, interactive rebase, or finding\nbugs with bisect) with modern Git you can create a new separate\nworking area with `git worktree`.\n\nThis also applies to the \"*Switching branches*\" problem (which\nis more involved, as `git stash` would often not work, and if\nit does it is harder to restore state - note however that stash\ndescription includes the branch it was on).\n\nSo I would say that *Saving Changes* is solved with stash,\nwhile *Switching Branches* remains a misfit.\n\n| *Detached Head* Suppose you are working on some branch\n| and realize that the last few commits you did are wrong, so\n| you decide to go back to an old commit to start over again.\n| You checkout that old commit and keep working creating\n| commits. You might be surprised to discover that these new\n| commits you’ve been working on belong to no branch at all.\n| To avoid losing them you need to create a new branch or reset\n| an existing one to point to the last commit.\n\nIt would be hard to be surprised unless one is in habit of\ndisregarding multi-line warning from Git... ;-)\n\nI think it might be more of an UX problem, namely that the\n`git checkout` command does too many things, which include\nchecking out revision (detaching HEAD, or landing on unnamed\nbranch, unless we create a new branch at the same time with\nthe '-b <newbranch>' option), and checking out a branch,\nthat is switching to other branch.\n\n| *File Rename* Suppose you rename a file and make some\n| changes to it. If you changed a significant portion of the file,\n| then, as far as Git is concerned, you didn’t rename the file,\n| but it is instead as if you deleted the old file and created a new\n| one (which means that the file history is now lost). To work\n| around this, you have to be diligent about creating a commit\n| with the rename only, and only then creating a new commit\n| with the modifications. This, however, likely creates a bogus\n| commit that doesn’t correspond to a logical group of changes.\n\nFirst, I think it might be inherent problem. The version control\nsystem may implement *rename tracking* (store information about\nrenames), or *rename detection*. The latter is what Git does,\nand it is what allows to do for example detecting copying and\nmovement of contents across files and within the same file\nfor `git blame` (and `git gui blame`) - which is impossible with\nonly rename tracking.\n\nNb. that handling file renames and other source reorganization\nis important thing that modern version control systems should\nbe able to handle.\n\nSecond, the need for handling renames can be found in two\ndifferent operations. One is following history of a single\nfile across renames, or seeing a rename when looking at changes\nin a single revision. The other is merging two lines of\ndevelopment where one did a rename. The trick of splitting\nlarge rename+change into pure rename and change without rename\ncan help only the former... the less important one. Merging\nin Git is done using [recursive] 3-way merge strategy, which\ntakes into account only the endpoint state, and not history\nbetween them - so if it was rename then change doesn't matter.\n\nThird, (which is a bit of victim^W user blaming), large changes\nare process smell. The cases when change accompanying rename\nis so large that it screws heuristic based rename detection\nlegitimately are (or are supposed to be) rare. And for the\nlegitimate cases, that is end-of-line changes, there are\nsolutions to help (-w for diff, -Xrenormalize for merge).\n\n| *File Tracking* Suppose you create a new file and then you\n| add the file to start tracking changes to it. You keep working\n| on the file making new modifications and then you make\n| a vanilla commit. You might be surprised to find out that\n| what actually got committed is the old version of the file\n| (representing its state the last time the file was staged), and\n| not the most recent one.\n\nUnless one uses `git commit -a`, like most people (I think)\nin most cases do.\n\nHopefully `git add -N`, aka. \"intent to add\", would help here...\nwhen people switch to it to adding new files, and when the\nfeature gets improved (as it is now) to make it better and\neasier to use (e.g. so \"git diff\" shows new i-t-a files).\n\n| *Untracking File* Suppose there’s a database configuration\n| file committed in the repository and you now want to edit\n| this file to do some local testing. This new version of the\n| file should not be committed. You could always leave out\n| the file from the commit every time, but this is laborious and\n| error-prone. You might think that you could make it ignored\n| by modifying the `.gitignore` file but this doesn’t work for\n| committed files.\n\nThe name \"Untracking File\" is misleading. You untrack file\n(that is remove it from future commits) with `git rm --cached`.\nNo problem here. The name is \"Ignore changes to tracked files\",\nor \"Stopping tracking changes to file\".\n\nIf you think of ignored files as unimportant, not precious,\nthen mismatch between understanding and what Git does would\nlessen.\n\n| The way to ignore this file is to mark it as\n| “assume unchanged,” but this marking will be cleared when\n| you switch to another branch.\n\ns/“assume unchanged,”/“skip worktree,” (see earlier comment).\n\nRight. Also, currently you need to use low-level commands\n(`git update-index`) to mark file in this way.\n\n[...]\n| 4. Purposes for Version Control\n[...]\n| *Collaboration* To this point, all the purposes might apply in\n| the context of a single user. Collaboration needs arise when\n| multiple users work together on a single code base.\n| /* ..........................................................\n| /* _Purpose 4. Synchronize changes of collaborators_\n\nOne very important purpose that must be fulfilled before even\ntrying to synchronize changes is *isolation of changes*. Each\ndeveloper needs its own working area, so his or her changes do\nnot interfere with work of other developers.\n\nThough \"Disconnected operations\" a bit overlaps (and is partial\nsuperset) of this purpose.\n\nSee also intro to \"Version Control by Example\", by Eric Sink\nhttp://ericsink.com/vcbe/html/intro.html\n\n[...]\n| 5.1 Stashing: An Example\n|\n| We consider the motivating purpose of stashing not to be\n| a subpurpose of any of the high-level purposes for version\n| control (§4). This section elaborates on our rationale for this.\n|\n| Take (what seem to be) the motivating use cases for stashing\n| [9, Chapter 7.3]: (1) to pull into a dirty working directory\n| and (2) to deal with an interruption in your workflow\n\nActually (1) is not a separate use case, but a subset \n(specialization) of (2) - and interruption in your workflow,\nwhere the interruption is pull.\n\nNote that to synchronize with remote repository one should use\nfetch, not pull.  The latter is more involved operation, and\nshould be considered interruption.  Also, rarer if using\nfeature branches workflow, and not working on long-lived\nstabilization branches directly.\n\n[...]\n| The problem\n| is the lack of connection between this purpose and the highlevel\n| purposes for version control, which suggests that the\n| introduction of stashing might be to patch flaws in the design\n| of Git and not to satisfy a requirement of version control.\n\nOr the problem might be that you are missing some (maybe minor)\nrequirement of version control system. Just saying...\n\n| 6. Analysis\n[...]\n| *Divided Ignored and Assumed Unchanged*\n\nThis ignores the fact that (unstated) assumption is that ignored\nfiles are considered not important (or at least less important;\nGit cares less about changes in those files, and may in some\ncases make you loose changes to them).\n\nIgnore file != ignore changes, though it may look like it is.\n\n[...]\n| 7. Gitless\n|\n| 7.1 Overview\n|\n| Gitless has no staging area, and the only file classifications\n| are “tracked,” “untracked,” “ignored,” and “in conflict.”\n\nWithout staging area, I wonder how you would be able to handle\nwell different types of integration conflicts, which are not\nlimited to CONFLICT(content).\n\nYou also loose the ability to select subset of *changes* to\nbe committed, not only files.  This is often very useful, see\nhttp://tomayko.com/writings/the-thing-about-git\nhttp://2ndscale.com/rtomayko/2008/the-thing-about-git\n\n[...]\n| A branch in Gitless is a completely independent line of\n| development: each branch includes the working version of\n| files [...]\n\nIf I understand your model correctly, you would get rid of\none problem / mismatch, but get into other. What would you\ndo if you started work on some branch, and then realized\nthat you should have been working on a new topic branch?\nOr you realized that you are on wrong branch, and want to\nmove changes?\n\nAh, I haven't realized that it is described later (well,\nat least the first case):\n\n: In regard to branching, to address situations in which the\n: user wants changes made in the current branch to be moved\n: onto the destination branch (e.g., the user realizes that she\n: has been working in the wrong branch), the Gitless branch\n: command has a `move-over` flag\n\n\n[...]\n|  Also, there\n| is no possible way of getting in a “detached head” state; at\n| any time, the user is always working on some branch (the\n| “current” branch). Head is a per-branch reference to the last\n| commit of the branch.\n\nHow do you solve the problem of checking out the state of\nthe tag, that is the state of repository at given revision?\n\nAlso during some long lived multi-step operations, like bisect\nor interactive rebase, you are not really on any branch,\n\n| 7.2.1 Discussion\n[...]\n| There could be other use cases for the\n| staging area that Gitless doesn’t handle well but we expect\n| these to be fairly infrequent.\n\nLike handling merge conflict...??? Infrequent doesn't mean\nunimportant.\n\n\nThat's all my comments for now.\n\n\nThis is a very interesting research.  Those problems (misfits)\nare legitimate concern.  Even if it would not result in changes\nto how Git works, it should improve how we are talking about\nversion control, and how we design them (that includes GUIs\nthat work above version control systems).\n\nBest regards,\n-- \nJakub Narębski\n\n"},{"id":"303053","messageId":"20161001201325.GA29588@ikke.info","threadId":"44191","inReplyTo":"481910fd-5a5f-ffc6-b98c-61d48b4a2e49@gmail.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2016-10-01T20:13:25Z","receivedAt":"2016-10-01T20:14:32Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Sat, Oct 01, 2016 at 12:24:57AM +0200, Jakub Narębski wrote:\n> \n> | 7.2.1 Discussion\n> [...]\n> | There could be other use cases for the\n> | staging area that Gitless doesn’t handle well but we expect\n> | these to be fairly infrequent.\n> \n> Like handling merge conflict...??? Infrequent doesn't mean\n> unimportant.\n> \n\nFor me the most important thing is that the lack of staging area leads\non commits that have no clear goal, people just commit everything they\nhave changed at some point, as a sort of checkpoint.\n\nAlthough lots of people still do this with git currently, they don't\neven have the possibility[1] to improve on this.\n\nThis makes history and features like git bisect less useful.\n\n\n[1] At most they can specify the files they want to commit, but this is\nstill a very crude way to group together changes.\n"},{"id":"303056","messageId":"ce42f934-4a94-fa29-cff0-5ebb0f004eb5@gmail.com","threadId":"44191","inReplyTo":"20161001201325.GA29588@ikke.info","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-10-01T21:39:13Z","receivedAt":"2016-10-01T21:39:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 01.10.2016 o 22:13, Kevin Daudt pisze:\n> On Sat, Oct 01, 2016 at 12:24:57AM +0200, Jakub Narębski wrote:\n>>\n>> | 7.2.1 Discussion\n>> [...]\n>> | There could be other use cases for the\n>> | staging area that Gitless doesn’t handle well but we expect\n>> | these to be fairly infrequent.\n\nI'd like to point to the word \"other\" in the above sentence...\n\n>>\n>> Like handling merge conflict...??? Infrequent doesn't mean\n>> unimportant.\n> \n> For me the most important thing is that the lack of staging area leads\n> on commits that have no clear goal, people just commit everything they\n> have changed at some point, as a sort of checkpoint.\n> \n> Although lots of people still do this with git currently, they don't\n> even have the possibility[1] to improve on this.\n> \n> This makes history and features like git bisect less useful.\n> \n> \n> [1] At most they can specify the files they want to commit, but this is\n> still a very crude way to group together changes.\n\n... If you had read the original discussed research paper \nhttp://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf\nyou would notice that this use case is covered by Gitless,\nthough imperfectly.\n\n  Common use cases for the staging area in Git are to select\n  files to commit, split up a large change into multiple commits,\n  and review the changes selected to be committed. We address\n  the first by providing a more flexible `commit` command that\n  lets the user easily customize the set of files to commit (with\n  `only`, `include` and `exclude` flags). For the second use case\n  we have a `partial` flag in `commit` that allows the user to\n  interactively select segments of files to commit (like Git’s\n  `commit --patch`).\n\nFirst imperfection is that only equivalent of `git commit --patch`,\nthat is additive selection of changes during commit.  There are,\nfrom what I understand, no equivalents of `git add --interactive`\n(crafting additively and subtractively part by part, not all at\nonce), `git reset --patch` (crafting additively from any commit,\ndefaults to HEAD), `git checkout --patch` (crafting subtractively).\nIt is a good thing to have those possibilities when disentangling\nworking area, or splitting commit during interactive rebase.\n\nThough all of those could be added (if they are not present\nalready) to the interactive interface of `partial` flag in\n`gl commit`.\n\n\nSecond imperfection is that you cannot test the crafted state\nwithout creating a commit.  In Git you have `git stash --keep-index`\nfor this; go to the state crafted in the staging area (the index),\nand you can test it.\n\nThough you can always create a [temporary] commit, run tests, and\nthen if necessary amend this commit.\n\n\nOn the other hand the index / the staging area is important and\nuseful thing in helping to resolve merge conflicts, for example\nthe one where one side changed file and other deleted it, or\nwhere one side renamed file and other changed it, etc.\n\n-- \nJakub Narębski\n\nmailto:jnareb@gmail.com\nmailto:jnareb@mat.umk.pl\n\n"},{"id":"303343","messageId":"CANQwDwcj15bk3uvjqnOwqqLFN_qOZCoWATssNBwD4kDTDfS6Hw@mail.gmail.com","threadId":"44191","inReplyTo":"CAKbZu+BUOAjixTmEC4octseyJbMnFuaCTtLT9hx3H10=AECeKw@mail.gmail.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-10-05T10:14:10Z","receivedAt":"2016-10-05T10:14:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[git@vger.kernel.org does not accept HTML emails]\n\nI just hope that this email don't get mangled too much...\n\nOn 5 October 2016 at 04:55, Santiago Perez De Rosso\n<sperezde@csail.mit.edu> wrote:\n> On Fri, Sep 30, 2016 at 6:25 PM Jakub Narębski <jnareb@gmail.com> wrote:\n>> W dniu 30.09.2016 o 18:14, Konstantin Khomoutov pisze:\n>>\n>>> The \"It Will Never Work in Theory\" blog has just posted a summary of a\n>>> study which tried to identify shortcomings in the design of Git.\n>>>\n>>> In the hope it might be interesting, I post this summary here.\n>>> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n>>\n>> I will comment on the article itself, not just on the summary.\n>>\n>> | 2.2 Git\n>> [...]\n>> | But tracked files cannot be ignored; to ignore a tracked file\n>> | one has to mark it as “assume unchanged.” This “assume\n>> | unchanged” file will not be recognized by add; to make it\n>> | tracked again this marking has to be removed.\n>>\n>> WRONG!  Git has tracked files, untracked unignored files, and\n>> untracked ignored files (mostly considered unimportant).\n>>\n>> The \"assume unchanged\" bit is _performance_ optimization. It is not,\n>> and cannot be a 'ignore tracked files' bit - here lies lost work!!!\n>> You can use (imperfectly) \"prefer worktree\" bit hack instead.\n>>\n>> You can say, if 'ignoring change to tracked files' is motivation,\n>> or purpose, it lacks direct concept.\n>\n>\n> I don't see what's wrong with the paragraph you mention. I am aware of the\n> fact that assumed unchanged is intended to be used as a performance\n> optimization but that doesn't seem to be the way it is used in practice.\n> Users have appropriated the optimization and effectively turned into a\n> concept that serves the purpose of preventing the commit of a file. For\n> example:\n>\n> from http://gitready.com/intermediate/2009/02/18/temporarily-ignoring-files.html\n>\n>  So, to temporarily ignore changes in a certain file, run:\n>  git update-index --assume-unchanged <file>\n>  ...\n>\n> from http://stackoverflow.com/questions/17195861/undo-git-update-index-assume-unchanged-file\n>  The way you git ignore watching/tracking a particular dir/file.\n>  you just run this:\n>  git update-index --assume-unchanged <file>\n> ...\n>\n>\n> btw, this appropriation suggests that users want to be able to ignore\n> tracked files and they do what they can with what they are given (which\n> in this case means abusing the assumed unchanged bit).\n\nYes, this is true that users may want to be able to ignore changes to\ntracked files (commit with dirty tree), but using `assume-unchanged` is\nwrong and dangerous solution.  Unfortunately the advice to use it is\nsurprisingly pervasive.  I would thank you to not further this error.\n(Well, `skip-worktree` is newer, that's why it is lesser known, perhaps)\n\nTo ignore tracked files you need to use `skip-worktree` bit.\n\nYou can find the difference between `assume-unchanged` and\n`skip-worktree`, and when use which in:\nhttp://stackoverflow.com/questions/13630849/git-difference-between-assume-unchanged-and-skip-worktree\nhttp://fallengamer.livejournal.com/93321.html\nhttp://blog.stephan-partzsch.de/how-to-ignore-changes-in-tracked-files-with-git/\n\nThe difference is that skip-worktree will not overwrite a file that is\ndifferent from the version in the index, but assume-unchanged can.  This\nmeans that the latter can OVERWRITE YOUR PRECIOUS CHANGES!\n\nSome people started to recommend it\nhttp://stackoverflow.com/questions/32251037/ignore-changes-to-a-tracked-file\nhttp://www.virtuouscode.com/2011/05/20/keep-local-modifications-in-git-tracked-files/\n\n\n>> | The notion of a “remote branch” must not be confused\n>> | with that of an “upstream branch.” An upstream branch is\n>> | just a convenience for users: after the user assigns it to some\n>> | branch, commands like pull and push default to use that\n>> | branch for fetching and pushing changes if no branch is given\n>> | as input.\n>>\n>> Actually \"upstream branch\" (and related \"upstream repository\")\n>> are a concept, not only a convenience. They denote a branch\n>> (usually in remote repository) which is intended to ultimately\n>> include changes in given branch. Note that \"upstream branch\"\n>> can be set separately for any given local branch.\n>\n>\n> We never say upstream branch is not a concept. It even appears in the\n> table.\n\nHmmm... I got onfused by words \"is just a convenience\", which for me\nimplies that it is not a concept.\n\n>>\n>>\n>> One thing that can enormously help recovering from errors, and\n>> is not covered in the list of concepts is REFLOG.\n>\n>\n> Yes, the analysis is not exhaustive, there are other concepts missing\n> too (e.g., \"submodule\")\n\nI think reflog is something that every user should know about, and\nuseful for all.  Submodules and subtrees is something situational,\nneeded only for a subset of users.\n\nOn the other hand the concept of \"submodules\" is something that it is\nunder active development, and it is assumed to be immature.  So coming\nup with a good (re)design for this feature, and/or good set of\nconcept, would be a very good thing.\n\n\nAnother thing that it is not present is the concept of \"immutable\nhistory\", and how to deal with it (`git-notes`, `git-replace`), and\nhow it conflict with other concepts (interactive rebase and the\nconcept of \"rewriting history\").  But I agree with focusing on most\ncommonly known, used and encountered concepts and misfits.\n\n>> [...]\n>> | 3. Operational Misfits\n>> [...]\n>> | *Saving Changes* Suppose you are in the middle of a long\n>> | task and want to save your changes, so that they can be later\n>> | retrieved in case of failure. How would you do that?\n>>\n>> You would use `git stash` or `git stash --include-untracked`!\n>> In more complicated situations (during long-running operation\n>> like resolving merge conflicts, interactive rebase, or finding\n>> bugs with bisect) with modern Git you can create a new separate\n>> working area with `git worktree`.\n>\n> A general comment regarding misfits: misfits correspond to scenarios\n> in which Git behaves in a way that is unpredictable or inconvenient.\n> It doesn't mean that a task has to be impossible to do in order for\n> something to be a misfit.\n\nIf there were one-command solution, and the problem was that users\ndon't know about it, I would say that it is not a misfit.  But,\nadmittedly, it is not the case here...\n\n>> | *Detached Head* Suppose you are working on some branch\n>> | and realize that the last few commits you did are wrong, so\n>> | you decide to go back to an old commit to start over again.\n>> | You checkout that old commit and keep working creating\n>> | commits. You might be surprised to discover that these new\n>> | commits you’ve been working on belong to no branch at all.\n>> | To avoid losing them you need to create a new branch or reset\n>> | an existing one to point to the last commit.\n>>\n>> It would be hard to be surprised unless one is in habit of\n>> disregarding multi-line warning from Git... ;-)\n>\n> True if you are an expert user, but I can assure you novices will\n> find that situation baffling, even with the multi-line warnings.\n\nTrue, the \"detached HEAD\" case (aka \"unnamed branch\") can be puzzling\nfor Git users, and it has few uses (e.g. checking out the state of\ntag temporarily, to test it).\n\nI wonder if `git status` should be enhanced to tell user how to get\nout of \"detached HEAD\" situation -- it has lots of advices in it.\n\n>> [...]\n>> | The problem\n>> | is the lack of connection between this purpose and the highlevel\n>> | purposes for version control, which suggests that the\n>> | introduction of stashing might be to patch flaws in the design\n>> | of Git and not to satisfy a requirement of version control.\n>>\n>> Or the problem might be that you are missing some (maybe minor)\n>> requirement of version control system. Just saying...\n>\n> What would that purpose be? and why would you say that's a\n> high-level purpose for version control and not one that's\n> git-specific?\n\nThe stash (or rather its equivalent) is not something Git specific.\nIt is present also in other version control systems, among others:\n\n* Mercurial: as 'shelve' extension (in core since 1.8)\n* Bazaar: as 'bzr shelve' command\n* Fossil: as 'fossil stash' command (with subcommands)\n* Subversion: Shelve planned for 1.10 (2017?)\n\nI would say that 'stash' could be considered about isolating work on\ndifferent features, different sub-branch sized parallel work.\n\nBut it might be that stash doesn't have connection with highlevel\npurposes for version control, and that it is purely convenience\nfeature.  Just playing the role of Advocatus Diaboli (important in\nscientific works, isn' it?)...\n\n>> [...]\n>> | 7. Gitless\n>> |\n>> | 7.1 Overview\n>> |\n>> | Gitless has no staging area, and the only file classifications\n>> | are “tracked,” “untracked,” “ignored,” and “in conflict.”\n>>\n>> Without staging area, I wonder how you would be able to handle\n>> well different types of integration conflicts, which are not\n>> limited to CONFLICT(content).\n>>\n>> You also loose the ability to select subset of *changes* to\n>> be committed, not only files.  This is often very useful, see\n>> http://tomayko.com/writings/the-thing-about-git\n>> http://2ndscale.com/rtomayko/2008/the-thing-about-git\n>\n> This is described later:\n\nRight, my mistake, I have missed this.  I should have read article in\nfull, then respond, rather than reply as I go...\n\n> Common use cases for the staging area in Git are to select files to commit,\n> split up a large change into multiple commits, and review the changes\n> selected to be committed. We address the first by providing a more flexible\n> commit command that lets the user easily customize the set of files to\n> commit (with only, include and exclude flags). For the second use case we\n> have a partial flag in commit that allows the user to interactively select\n> segments of files to commit (like Git’s commit --patch). Finally, our diff\n> command accepts the same only, include and exclude flags to customize the\n> set of files to be diffed. There could be other use cases for the staging\n> area that Gitless doesn’t handle well but we expect these to be fairly\n> infrequent.\n\nI wrote later that Git offers more flexibility with respect of\ninteractive edition of the staging area (additive, substractive, from\nHEAD, from arbitrary commit) and checking the prepared state (add <->\ndiff <-> stash --keep-index + test + unstash)... but I think this is a\nmatter of implementing interface for those fetures to 'partial'\ncommit.  It might be less flexible, and less powerfull, but it would\nbe there.\n\n> Note that Gitless is built on top of Git so we do have a staging area, the\n> difference is that unlike Git, in Gitless the index is hidden from the user.\n\nAll right.\n\nI have just an idea of using the index (or rather its extensions) to\nimplement sub-commit history (forgotten after committing), as a way to\nresolve misfit about \"commit\" concept and (P1) vs (P2) purposes...\n\n>> [...]\n>> |  Also, there\n>> | is no possible way of getting in a “detached head” state; at\n>> | any time, the user is always working on some branch (the\n>> | “current” branch). Head is a per-branch reference to the last\n>> | commit of the branch.\n>>\n>> How do you solve the problem of checking out the state of\n>> the tag, that is the state of repository at given revision?\n>\n> You can't checkout a tag, you would have to create a new branch with\n> its head equal to the tag, and switch to that branch.\n\nFor the purpose of testing a state at a tag (for example as a\nprerequisite to bisection), it fills like unnecessarily complicated\nsolution, a new misfit.  But I guess that you consider \"detached HEAD\"\nmisfit to be more important to get rid of.\n\n>> Also during some long lived multi-step operations, like bisect\n>> or interactive rebase, you are not really on any branch,\n>\n> In Gitless we don't have bisect but for rebase (fuse in Gitless) we\n> record the current branch.\n\nNo bisect?  This is very useful feature.  Though it might be done\nwithout detached HEAD, but with specialized pseudo-branch 'bisect' (as\nit was done in earlier versions of Git, or maybe even now).\n\nAnyway, for [interactive] rebase / transplant / graft / fuse you need\nto be able to abort an operation and return to the state before\nstaring rebase.  Though you can or do solve this by remembering\nthe starting position.\n\n>> | 7.2.1 Discussion\n>> [...]\n>> | There could be other use cases for the\n>> | staging area that Gitless doesn’t handle well but we expect\n>> | these to be fairly infrequent.\n>>\n>> Like handling merge conflict...??? Infrequent doesn't mean\n>> unimportant.\n>\n> I regard handling merge conflicts as very important. Why do you need\n> an explicit staging area for this? Note that Gitless has a staging\n> area, it's just hidden from the user. The `gl diff` or `gl status`\n> command should be able to show the same conflict information.\n\nWell, the staging area was created (also?) to handle merges.  Though\nperhaps it doesn't need to be explicit to be useful...\n\nBest regards,\n-- \nJakub Narębski\n"},{"id":"303347","messageId":"CACsJy8A8QGAtmv0BGOb2ZgXP=_iXz-oDZ82ebq+gmRe7TWoWBQ@mail.gmail.com","threadId":"44191","inReplyTo":"CANQwDwcj15bk3uvjqnOwqqLFN_qOZCoWATssNBwD4kDTDfS6Hw@mail.gmail.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-10-05T10:42:30Z","receivedAt":"2016-10-05T10:43:07Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Oct 5, 2016 at 5:14 PM, Jakub Narębski <jnareb@gmail.com> wrote:\n> [git@vger.kernel.org does not accept HTML emails]\n>\n> I just hope that this email don't get mangled too much...\n>\n> On 5 October 2016 at 04:55, Santiago Perez De Rosso\n> <sperezde@csail.mit.edu> wrote:\n>> On Fri, Sep 30, 2016 at 6:25 PM Jakub Narębski <jnareb@gmail.com> wrote:\n>>> W dniu 30.09.2016 o 18:14, Konstantin Khomoutov pisze:\n>>>\n>>>> The \"It Will Never Work in Theory\" blog has just posted a summary of a\n>>>> study which tried to identify shortcomings in the design of Git.\n>>>>\n>>>> In the hope it might be interesting, I post this summary here.\n>>>> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n>>>\n>>> I will comment on the article itself, not just on the summary.\n>>>\n>>> | 2.2 Git\n>>> [...]\n>>> | But tracked files cannot be ignored; to ignore a tracked file\n>>> | one has to mark it as “assume unchanged.” This “assume\n>>> | unchanged” file will not be recognized by add; to make it\n>>> | tracked again this marking has to be removed.\n>>>\n>>> WRONG!  Git has tracked files, untracked unignored files, and\n>>> untracked ignored files (mostly considered unimportant).\n>>>\n>>> The \"assume unchanged\" bit is _performance_ optimization. It is not,\n>>> and cannot be a 'ignore tracked files' bit - here lies lost work!!!\n>>> You can use (imperfectly) \"prefer worktree\" bit hack instead.\n>>>\n>>> You can say, if 'ignoring change to tracked files' is motivation,\n>>> or purpose, it lacks direct concept.\n>>\n>>\n>> I don't see what's wrong with the paragraph you mention. I am aware of the\n>> fact that assumed unchanged is intended to be used as a performance\n>> optimization but that doesn't seem to be the way it is used in practice.\n>> Users have appropriated the optimization and effectively turned into a\n>> concept that serves the purpose of preventing the commit of a file. For\n>> example:\n>>\n>> from http://gitready.com/intermediate/2009/02/18/temporarily-ignoring-files.html\n>>\n>>  So, to temporarily ignore changes in a certain file, run:\n>>  git update-index --assume-unchanged <file>\n>>  ...\n>>\n>> from http://stackoverflow.com/questions/17195861/undo-git-update-index-assume-unchanged-file\n>>  The way you git ignore watching/tracking a particular dir/file.\n>>  you just run this:\n>>  git update-index --assume-unchanged <file>\n>> ...\n>>\n>>\n>> btw, this appropriation suggests that users want to be able to ignore\n>> tracked files and they do what they can with what they are given (which\n>> in this case means abusing the assumed unchanged bit).\n>\n> Yes, this is true that users may want to be able to ignore changes to\n> tracked files (commit with dirty tree), but using `assume-unchanged` is\n> wrong and dangerous solution.  Unfortunately the advice to use it is\n> surprisingly pervasive.  I would thank you to not further this error.\n> (Well, `skip-worktree` is newer, that's why it is lesser known, perhaps)\n>\n> To ignore tracked files you need to use `skip-worktree` bit.\n>\n> You can find the difference between `assume-unchanged` and\n> `skip-worktree`, and when use which in:\n> http://stackoverflow.com/questions/13630849/git-difference-between-assume-unchanged-and-skip-worktree\n> http://fallengamer.livejournal.com/93321.html\n> http://blog.stephan-partzsch.de/how-to-ignore-changes-in-tracked-files-with-git/\n>\n> The difference is that skip-worktree will not overwrite a file that is\n> different from the version in the index, but assume-unchanged can.  This\n> means that the latter can OVERWRITE YOUR PRECIOUS CHANGES!\n>\n> Some people started to recommend it\n> http://stackoverflow.com/questions/32251037/ignore-changes-to-a-tracked-file\n> http://www.virtuouscode.com/2011/05/20/keep-local-modifications-in-git-tracked-files/\n\nAnd since skip-worktree bits may be set/cleared freely when sparse\ncheckout mode is on, you should never manipulate these bits directly\nif you also use sparse checkout.\n\n>>> | *Detached Head* Suppose you are working on some branch\n>>> | and realize that the last few commits you did are wrong, so\n>>> | you decide to go back to an old commit to start over again.\n>>> | You checkout that old commit and keep working creating\n>>> | commits. You might be surprised to discover that these new\n>>> | commits you’ve been working on belong to no branch at all.\n>>> | To avoid losing them you need to create a new branch or reset\n>>> | an existing one to point to the last commit.\n>>>\n>>> It would be hard to be surprised unless one is in habit of\n>>> disregarding multi-line warning from Git... ;-)\n>>\n>> True if you are an expert user, but I can assure you novices will\n>> find that situation baffling, even with the multi-line warnings.\n\nHmm...  when you switch away from a detached HEAD, you are advised to\ndo \"git branch <new-name> blah blah\". How is it baffling? Genuine\nquestion, maybe I have been using git for too long I just fail to see\nit.\n\n> True, the \"detached HEAD\" case (aka \"unnamed branch\") can be puzzling\n> for Git users, and it has few uses (e.g. checking out the state of\n> tag temporarily, to test it).\n>\n> I wonder if `git status` should be enhanced to tell user how to get\n> out of \"detached HEAD\" situation -- it has lots of advices in it.\n\nDetached HEAD is also present in interactive rebase or any command\nthat has --abort/--continue options. I don't think we need to tell the\nuser to get out of detached HEAD in that case. Just two cents if\nsomeone is going to add this advice to git-status.\n-- \nDuy\n"},{"id":"303592","messageId":"20161007205220.e7cc582a042f12cd13b6aef7@domain007.com","threadId":"44191","inReplyTo":"20160930191413.002049b94b3908b15881b77f@domain007.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2016-10-07T17:52:20Z","receivedAt":"2016-10-07T17:52:29Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Fri, 30 Sep 2016 19:14:13 +0300\nKonstantin Khomoutov <kostix+git@007spb.ru> wrote:\n\n> The \"It Will Never Work in Theory\" blog has just posted a summary of a\n> study which tried to identify shortcomings in the design of Git.\n> \n> In the hope it might be interesting, I post this summary here.\n> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n\nI think it would be cool if someone among subscribers could post a link\nto our discussion thread [2] back onto that page.  Unfortunatrly that\nrequires a Disqus login which I don't have, so may be someone in\npossession of such login could do that? ;-)\n\n2. https://public-inbox.org/git/ce42f934-4a94-fa29-cff0-5ebb0f004eb5@gmail.com/T/#e95875b7940512b432ab2e29b3dd50ca448df9720\n"},{"id":"303594","messageId":"CANQwDwcCGcgnGGrLM4OWq+W6CNepLUX-vy7tv4ai_CpH=-MUcQ@mail.gmail.com","threadId":"44191","inReplyTo":"CAKbZu+CTobJ9omSDtK5WQxUZuq=b0g0r59k+9MFFy247YijgUw@mail.gmail.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-10-07T18:05:39Z","receivedAt":"2016-10-07T18:06:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 7 October 2016 at 18:55, Santiago Perez De Rosso\n<sperezde@csail.mit.edu> wrote:\n> On Wed, Oct 5, 2016 at 6:15 AM Jakub Narębski <jnareb@gmail.com> wrote:\n>> On 5 October 2016 at 04:55, Santiago Perez De Rosso\n>> <sperezde@csail.mit.edu> wrote:\n>>> On Fri, Sep 30, 2016 at 6:25 PM Jakub Narębski <jnareb@gmail.com> wrote:\n>>>> W dniu 30.09.2016 o 18:14, Konstantin Khomoutov pisze:\n>>>>\n>>>>> The \"It Will Never Work in Theory\" blog has just posted a summary of a\n>>>>> study which tried to identify shortcomings in the design of Git.\n>>>>>\n>>>>> In the hope it might be interesting, I post this summary here.\n>>>>> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n>>>>\n>>>> I will comment on the article itself, not just on the summary.\n>>>>\n>>>> | 2.2 Git\n>>>> [...]\n>>>> | But tracked files cannot be ignored; to ignore a tracked file\n>>>> | one has to mark it as “assume unchanged.” This “assume\n>>>> | unchanged” file will not be recognized by add; to make it\n>>>> | tracked again this marking has to be removed.\n[...]\n>> Yes, this is true that users may want to be able to ignore changes to\n>> tracked files (commit with dirty tree), but using `assume-unchanged` is\n>> wrong and dangerous solution.  Unfortunately the advice to use it is\n>> surprisingly pervasive.  I would thank you to not further this error.\n>\n> Ok, I added a footnote in the paper when we first mention assume unchanged\n> that says:\n>\n> Assume unchanged was intended to be used as a performance optimization but\n> has since been appropriated by users as a way to ignore tracked files. The\n> current advice is to use the “skip worktree” marking instead\n>\n> This should prompt readers to look into skip worktree next time they want to\n> ignore tracked files. I don't think people reading the paper are doing so to\n> learn Git but at least it should contribute to not furthering the error.\n\nThank you very much.\n\nThe problem with \"assume-unchanged\" is that by using it to ignore\nchanges to tracked files you are lying to Git (telling it 'assume this\nis unchanged' while changing it), and can lead to DATA LOSS, that\nis to losing those changes.\n\n[...]\n>>>> [...]\n>>>> | The problem\n>>>> | is the lack of connection between this purpose and the highlevel\n>>>> | purposes for version control, which suggests that the\n>>>> | introduction of stashing might be to patch flaws in the design\n>>>> | of Git and not to satisfy a requirement of version control.\n>>>>\n>>>> Or the problem might be that you are missing some (maybe minor)\n>>>> requirement of version control system. Just saying...\n>>>\n>>> What would that purpose be? and why would you say that's a\n>>> high-level purpose for version control and not one that's\n>>> git-specific?\n>>\n>> The stash (or rather its equivalent) is not something Git specific.\n>> It is present also in other version control systems, among others:\n>>\n>> * Mercurial: as 'shelve' extension (in core since 1.8)\n>> * Bazaar: as 'bzr shelve' command\n>> * Fossil: as 'fossil stash' command (with subcommands)\n>> * Subversion: Shelve planned for 1.10 (2017?)\n>\n> Do these other VCSs have the same \"Switching branches\" misfit? Do you\n> usually need to stash if you want to switch with uncommitted changes? I know\n> Mercurial has the same problem since ``bookmarks'' are like Git branches, so\n> it makes sense for them to have added something like stashing (if otherwise\n> switching with uncommitted changes would be very difficult).\n\nI suspect that all those are inspired by each other, and that\nthey all use 'uncommitted changes are not tied to a branch'\nparadigm, which allows for creating a branch for changes\nafter a fact (when it turns out that it would take more than\none commit to implement the feature) quite easy.\n\n>> I would say that 'stash' could be considered about isolating work on\n>> different features, different sub-branch sized parallel work.\n\nNote that 'isolating work' is missing from your list of purposes\nof a version control system; though it is fairly obvious.\n\n>\n> That sounds a lot like having independent lines of development, which is\n> what branches are supposed to be for\n\nThose are sub-commit changes. Branches are composed of\ncommits. But I agree that this may be a bit of a stretch in\ntrying to find a high-level purpose for stash (rather than it being\na convenience feature). As I said below...\n\n>> But it might be that stash doesn't have connection with highlevel\n>> purposes for version control, and that it is purely convenience\n>> feature.  Just playing the role of Advocatus Diaboli (important in\n>> scientific works, isn' it?)...\n\n[...]\n\n>>>> | 7. Gitless\n[...]\n>>>> |  Also, there\n>>>> | is no possible way of getting in a “detached head” state; at\n>>>> | any time, the user is always working on some branch (the\n>>>> | “current” branch). Head is a per-branch reference to the last\n>>>> | commit of the branch.\n[...]\n>>>> [...] during some long lived multi-step operations, like bisect\n>>>> or interactive rebase, you are not really on any branch,\n>>>\n>>> In Gitless we don't have bisect but for rebase (fuse in Gitless) we\n>>> record the current branch.\n>>\n>> No bisect?  This is very useful feature.  Though it might be done\n>> without detached HEAD, but with specialized pseudo-branch 'bisect' (as\n>> it was done in earlier versions of Git, or maybe even now).\n>>\n>> Anyway, for [interactive] rebase / transplant / graft / fuse you need\n>> to be able to abort an operation and return to the state before\n>> staring rebase.  Though you can or do solve this by remembering\n>> the starting position.\n>\n> Yes, Gitless remembers the starting position. We should be able to get\n> bisect working too in the same way. Internally, the head is detached but\n> that's irrelevant to the user. As far as the user is concerned she's still\n> working on the current branch.\n\nThere are quite a few problems with \"remember the starting position\"\napproach. For one, the rebase / fuse operation should be recorded as\nwhole in the branch reflog (assuming that you implement this feature).\nWorking on a branch would ordinarily mean that all those intermediate\nsteps would be recorded (well, they are, but in separate reflog, namely\nHEAD reflog).\n\nThe second issue is that you wouldn't want for your partially done rebase\nto be visible; for example, you would want for 'git push' to not include\npartial work (which might get abandoned).\n\nI suppose all this can be solved without user-visible detached HEAD...\n\n\nI have one more comment and one more issue about the article in\ngeneral.\n\nFirst, while the entry into a list of version control systems (or even\ninterfaces to them) is hard, among others because of network effects,\nit should be much easier to try to come up with a GUI or IDE plugin\nstarting from the same principles. Also with GUI there is not much\nproblem if you don;t implement everything; users would just fall back\non command line of underlying version control system.\n\nSecond, I think at least some of the concepts phase would not be\npossible when Git was starting to be created. At the beginning, we\ndidn't know much about how distributed version control systems would\nbe used. For example, the very useful \"topic branch\" workflow was\nnot even imagined. Mercurial, which was created in parallel and at\nthe same time as Git, started with \"clone to create a new branch\"\nparadigm!  Unfortunately the curse of \"worse is better\" is often many\nmisfits in paid for lots of power.\n\nBest regards,\n-- \nJakub Narębski\n"},{"id":"303607","messageId":"4879aa41-e84f-634f-4c4a-1a16f5980e39@gmail.com","threadId":"44191","inReplyTo":"20161007205220.e7cc582a042f12cd13b6aef7@domain007.com","subject":"Re: \"Purposes, Concepts,Misfits, and a Redesign of Git\" (a research paper)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-10-07T18:56:15Z","receivedAt":"2016-10-07T18:56:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 07.10.2016 o 19:52, Konstantin Khomoutov pisze:\n> On Fri, 30 Sep 2016 19:14:13 +0300\n> Konstantin Khomoutov <kostix+git@007spb.ru> wrote:\n> \n>> The \"It Will Never Work in Theory\" blog has just posted a summary of a\n>> study which tried to identify shortcomings in the design of Git.\n>>\n>> In the hope it might be interesting, I post this summary here.\n>> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html\n> \n> I think it would be cool if someone among subscribers could post a link\n> to our discussion thread [2] back onto that page.  Unfortunatrly that\n> requires a Disqus login which I don't have, so may be someone in\n> possession of such login could do that? ;-)\n> \n> 2. https://public-inbox.org/git/ce42f934-4a94-fa29-cff0-5ebb0f004eb5@gmail.com/T/#e95875b7940512b432ab2e29b3dd50ca448df9720\n\nPosted.  Thanks for the idea.\n\n-- \nJakub Narębski\n\n\n"}]}