Hmm …
Hmm …
Posted Oct 31, 2018 20:48 UTC (Wed) by aleXXX (subscriber, #2742)In reply to: Hmm … by smurf
Parent article: Apache Subversion 1.11.0 released
Posted Oct 31, 2018 21:32 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (16 responses)
Posted Nov 2, 2018 16:15 UTC (Fri)
by nix (subscriber, #2304)
[Link] (15 responses)
Posted Nov 2, 2018 21:15 UTC (Fri)
by epa (subscriber, #39769)
[Link] (14 responses)
People often note that git takes care with its repository, and it’s hard to lose data from it permanently. But git is lot more cavalier with files in the working copy — at least more so than you might expect from a common command ‘checkout’. (‘git overwrite’ or something would be fine)
Posted Nov 2, 2018 21:24 UTC (Fri)
by pizza (subscriber, #46)
[Link] (13 responses)
If you say 'git checkout foo.c' doesn't that count as explicitly telling git that you want to overwrite 'foo.c'?
If you say 'git checkout tagname' when foo.c has local modifications, by default git will report an error ("foo.c has local modifications" or something like that) and not overwrite the file.
> People often note that git takes care with its repository, and it’s hard to lose data from it permanently. But git is lot more cavalier with files in the working copy
Commit early, commit often. You can always slice and dice using 'git rebase'. Or use 'git stash' before potentially destructive operations.
Posted Nov 4, 2018 17:52 UTC (Sun)
by epa (subscriber, #39769)
[Link] (12 responses)
Perhaps the fault is with whoever recommended 'git checkout .' as the way to recover, from the current commit, files deleted in the working copy. (With svn I would do 'svn update' for that, which is reasonably safe.) But then, what is the safe git command to bring back deleted files while not trashing local changes in others?
Posted Nov 4, 2018 19:03 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (3 responses)
That depends on whether you want to get a single file (or three), or go to a different commit. The latter refuses to overwrite things.
> what is the safe git command to bring back deleted files
There is none. If you overwrite a file that hasn't been checked in, it's gone, just like when you use "rm". In fact, if you try to "git rm" a modified file, it'll warn you.
Adding a warning option does make sense; I'll file a feature request.
Posted Nov 4, 2018 20:11 UTC (Sun)
by madscientist (subscriber, #16861)
[Link]
> It's more about 'git checkout .' which will silently overwrite every local change in the working copy.
Adding a "." causes a checkout of all (modified) files from the current directory down. It cannot go to a different commit.
For me, if I want to un-modify a file I use "git status" to see a list of modified files, and "git checkout filex filey ..." (perhaps copy/paste) to check out specific files. If I want to throw away everything I use "git reset --hard HEAD" or similar. I virtually never use "git checkout <directory>" and wouldn't suggest it to others, either.
> what is the safe git command to bring back deleted files
By this I assume you mean a committed file that you have deleted and then want to recover and not an untracked file that you've deleted.
The best way to know how to solve almost ANY issue in a workspace is to run "git status" and it will tell you how to undo it. For example, if you "rm somefile" and then decide you want it back, "git status" will tell you:
> Changes not staged for commit:
> deleted: Demo/readme.txt
If you use "git rm somefile" then decide you want it back, "git status" will tell you:
> Changes to be committed:
> deleted: Demo/readme.txt
And finally when in doubt, I use "git stash" to stash modified files before doing any kind of bizarre operations on a repository where there are modifications I want to preserve, just in case.
Posted Nov 5, 2018 6:59 UTC (Mon)
by epa (subscriber, #39769)
[Link] (1 responses)
'git checkout .' will appear to work for this task but it is highly dangerous, since it unconditionally trashes any other local changes. As another poster noted, there doesn't seem to be a command which does it, short of running 'git status', looking for 'deleted' lines, and running 'git checkout' over those.
Now, you may say that this isn't a sensible way to work, and the right way to revert changes in a file if you messed it up is to run 'git checkout FILE' directly. Not to just delete the file and then hunt for the right incantation to bring it back. But rightly or wrongly it is a natural human reaction to say "I really messed this up, let's just delete it and start again".
I did raise the feature request on the mailing list: https://public-inbox.org/git/loom.20150603T104534-909@pos...
Posted Nov 13, 2018 22:51 UTC (Tue)
by arnout (subscriber, #94240)
[Link]
You might want to give 'git checkout -p' a try.
Posted Nov 6, 2018 15:55 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (2 responses)
Posted Nov 6, 2018 20:09 UTC (Tue)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Nov 11, 2018 18:37 UTC (Sun)
by jezuch (subscriber, #52988)
[Link]
Posted Nov 6, 2018 20:14 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (4 responses)
Anyone want to write a patch which causes "git checkout" (and anything else potentially destructive) to do an automatic "git stash" first ???
Posted Nov 11, 2018 17:58 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
I tend to use git with a bit of a cookbook aide-memoir, I have an understanding of what's going on but it's not particularly good. An automatic "git stash" will be a pretty good way of helping me lose stuff, because I haven't yet got to grips with what stash actually does. Yes I know it puts stuff "somewhere safe", but as it is at home, "somewhere safe" usually equates to "I've forgotten where I put it" ie I've lost it.
Cheers,
Posted Nov 11, 2018 21:59 UTC (Sun)
by neilbrown (subscriber, #359)
[Link]
The best way to help noobs like you is through education.
If something goes wrong and you try to fix it up and fail, and then post in some community "Hi, X happened so I tried Y and now Z", then someone says "Oh no, never try Y - that is a disaster, I hope you have backups" - then you might not want to experiment again.
So I agree that auto-git-stash is not a complete solution, but it does seem that it would still be valuable.
Posted Nov 14, 2018 8:29 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (1 responses)
Posted Nov 14, 2018 15:28 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 3, 2018 14:31 UTC (Sat)
by mgedmin (subscriber, #34497)
[Link] (2 responses)
To recover the repo I had to hack the subversion source code and have it ignore the bad deltas, dump, then load everything afresh.
Git never caused me such pain.
Posted Nov 9, 2018 19:53 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 9, 2018 22:07 UTC (Fri)
by flussence (guest, #85566)
[Link]
That didn't last unfortunately; somehow it led to the svn server writing corrupt metadata to its own DB that it couldn't read, and I ended up spending a day to repair it by hand.
(Maybe this anecdote says more about the working conditions at that gig than SVN, but it was still an unpleasant bug to run into.)
Hmm …
Hmm …
Hmm …
Hmm …
Hmm …
Hmm …
Hmm …
> (use "git add/rm <file>..." to update what will be committed)
> (use "git checkout -- <file>..." to discard changes in working directory)
> (use "git reset HEAD <file>..." to unstage)
Hmm …
Hmm …
> from the current commit (or from git's index, if they happen to be in there).
Hmm …
Hmm …
Hmm …
Hmm …
Hmm …
Wol
Hmm …
An important part of education is encouraging exploration and experimentation.
If, instead, they could say "Y probably wasn't the best approach, but git has your back - just run this simple command and look through the resulting log until you see the code you lost - then do Q to recover it" - you might be more likely to experiment more next time.
Hmm …
Hmm …
Hmm …
Hmm …
Hmm …