On Wed, Oct 5, 2016 at 5:14 PM, Jakub Narębski <jnareb@xxxxxxxxx> wrote: > [git@xxxxxxxxxxxxxxx does not accept HTML emails] > > I just hope that this email don't get mangled too much... > > On 5 October 2016 at 04:55, Santiago Perez De Rosso > <sperezde@xxxxxxxxxxxxx> wrote: >> On Fri, Sep 30, 2016 at 6:25 PM Jakub Narębski <jnareb@xxxxxxxxx> wrote: >>> W dniu 30.09.2016 o 18:14, Konstantin Khomoutov pisze: >>> >>>> The "It Will Never Work in Theory" blog has just posted a summary of a >>>> study which tried to identify shortcomings in the design of Git. >>>> >>>> In the hope it might be interesting, I post this summary here. >>>> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html >>> >>> I will comment on the article itself, not just on the summary. >>> >>> | 2.2 Git >>> [...] >>> | But tracked files cannot be ignored; to ignore a tracked file >>> | one has to mark it as “assume unchanged.” This “assume >>> | unchanged” file will not be recognized by add; to make it >>> | tracked again this marking has to be removed. >>> >>> WRONG! Git has tracked files, untracked unignored files, and >>> untracked ignored files (mostly considered unimportant). >>> >>> The "assume unchanged" bit is _performance_ optimization. It is not, >>> and cannot be a 'ignore tracked files' bit - here lies lost work!!! >>> You can use (imperfectly) "prefer worktree" bit hack instead. >>> >>> You can say, if 'ignoring change to tracked files' is motivation, >>> or purpose, it lacks direct concept. >> >> >> I don't see what's wrong with the paragraph you mention. I am aware of the >> fact that assumed unchanged is intended to be used as a performance >> optimization but that doesn't seem to be the way it is used in practice. >> Users have appropriated the optimization and effectively turned into a >> concept that serves the purpose of preventing the commit of a file. For >> example: >> >> from http://gitready.com/intermediate/2009/02/18/temporarily-ignoring-files.html >> >> So, to temporarily ignore changes in a certain file, run: >> git update-index --assume-unchanged <file> >> ... >> >> from http://stackoverflow.com/questions/17195861/undo-git-update-index-assume-unchanged-file >> The way you git ignore watching/tracking a particular dir/file. >> you just run this: >> git update-index --assume-unchanged <file> >> ... >> >> >> btw, this appropriation suggests that users want to be able to ignore >> tracked files and they do what they can with what they are given (which >> in this case means abusing the assumed unchanged bit). > > Yes, this is true that users may want to be able to ignore changes to > tracked files (commit with dirty tree), but using `assume-unchanged` is > wrong and dangerous solution. Unfortunately the advice to use it is > surprisingly pervasive. I would thank you to not further this error. > (Well, `skip-worktree` is newer, that's why it is lesser known, perhaps) > > To ignore tracked files you need to use `skip-worktree` bit. > > You can find the difference between `assume-unchanged` and > `skip-worktree`, and when use which in: > http://stackoverflow.com/questions/13630849/git-difference-between-assume-unchanged-and-skip-worktree > http://fallengamer.livejournal.com/93321.html > http://blog.stephan-partzsch.de/how-to-ignore-changes-in-tracked-files-with-git/ > > The difference is that skip-worktree will not overwrite a file that is > different from the version in the index, but assume-unchanged can. This > means that the latter can OVERWRITE YOUR PRECIOUS CHANGES! > > Some people started to recommend it > http://stackoverflow.com/questions/32251037/ignore-changes-to-a-tracked-file > http://www.virtuouscode.com/2011/05/20/keep-local-modifications-in-git-tracked-files/ And since skip-worktree bits may be set/cleared freely when sparse checkout mode is on, you should never manipulate these bits directly if you also use sparse checkout. >>> | *Detached Head* Suppose you are working on some branch >>> | and realize that the last few commits you did are wrong, so >>> | you decide to go back to an old commit to start over again. >>> | You checkout that old commit and keep working creating >>> | commits. You might be surprised to discover that these new >>> | commits you’ve been working on belong to no branch at all. >>> | To avoid losing them you need to create a new branch or reset >>> | an existing one to point to the last commit. >>> >>> It would be hard to be surprised unless one is in habit of >>> disregarding multi-line warning from Git... ;-) >> >> True if you are an expert user, but I can assure you novices will >> find that situation baffling, even with the multi-line warnings. Hmm... when you switch away from a detached HEAD, you are advised to do "git branch <new-name> blah blah". How is it baffling? Genuine question, maybe I have been using git for too long I just fail to see it. > True, the "detached HEAD" case (aka "unnamed branch") can be puzzling > for Git users, and it has few uses (e.g. checking out the state of > tag temporarily, to test it). > > I wonder if `git status` should be enhanced to tell user how to get > out of "detached HEAD" situation -- it has lots of advices in it. Detached HEAD is also present in interactive rebase or any command that has --abort/--continue options. I don't think we need to tell the user to get out of detached HEAD in that case. Just two cents if someone is going to add this advice to git-status. -- Duy