Apache Subversion 1.11.0 released

> 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:
> (use "git add/rm <file>..." to update what will be committed)
> (use "git checkout -- <file>..." to discard changes in working directory)

> 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:
> (use "git reset HEAD <file>..." to unstage)

> 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.

'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...

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,
Wol

That special-ness could be even signalled without touching the core data structure: a normal no-follow merge commit mentions its parents in a specific order (the "null" parent is first). A "this is a group" commit would simply invert that.

For the moment I'm thinking of a group as a merge commit plus all the commits on the right side of the merge that aren't also on the left (for some reasonable understanding of "left" and "right").

1/ you want "git bisect" to recognise these merge points and preferentially test those, rather than commits on the right. I suspect it would be fairly easy to do this for all merges. It would be expected to increase the number of steps a little, but probably just by one or two.

2/ you want to allow a new commit to mark an existing commit as part of it's group. This is comparatively huge. For git-bisect to be able to notice, you would need to create some sort of index from child commits back to their parents, at least for merged commits.
Between 4.1 and 4.19 (just a random sample) there are 20808 merge commits and 232659 non-merges. That means about 10% of commits are merges. Adding an index for the children of all merges should be manageable. If it was just "all merges with some magic string in the message" it would be even more manageable. I'm not sure if that is quite enough to allow git-bisect to do what we want.

I've occasionally thought this would be good for patches labeled "Fixes:". If they were attached to the patch they fix in a way that git-bisect could detect, then maybe it could always pull in fix - or a least warn that a fix was missing.

I think there are ideas worth exploring here (if only I had the time).

I think this would be handled well with a `git bisect --first-parent` option which bisects the first-parent history and then starts bisecting the history between the two commits recursively on the remaining history using the same first-parent semantics. Then your "groupings" are exactly merges.