Re: git reset respect remote repo (make git idiot proof)

Geoffrey De Smet [off-list ref] writes:

Op 03-10-12 18:40, Phil Hord schreef:

quoted

But I feel your pain.  I think the solution lies in relegating 'reset'
to the plumbing or the power-user realm of commands since I feel it is
quite overloaded and sometimes dangerous.  There was a thread some
months back heading in this direction, but I failed to keep it going.

     http://comments.gmane.org/gmane.comp.version-control.git/185825

I personally use git reset a lot:
- Try an experiment
- Commit a few commits as the experiment progresses
- figure out that the experiment is a dead end
- git reset all those _local_ commits

The point is: they are local commits, so no harm done.
But there's nothing preventing me from resetting pushed commits too,
which would mean harm.

Even if you reset your local branch beyond the point you pushed out,
no harm is caused, as "git push" will catch that mistake, e.g.

	: on 'master' that integrates with 'master' at remote
	$ git reset --hard HEAD~4
        : work work work and commit commit commit
        $ git push origin master
        ... will result in refusal due to non-fast-forward

And then you can recover from it easily; one workflow may go like
this:

	: update refs/remotes/origin/master, among other things
	$ git fetch origin
        : recover the "work work ... commit commit" part
        $ git rebase origin/master

Another thing we could think about doing is to warn at the point you
reset your head away.  The above "reset --hard HEAD~4", before doing
what it was told to do, could perform:

	git rev-list HEAD~4..HEAD

(replace "HEAD~4" with whereever you are attempting to go) and see
if any of the listed commits is an ancestor of @{upstream} of the
current branch.  And if that is true, then your updated "reset" can
issue a warning, just like "git checkout branchname" to leave the
detached HEAD state gives you a friendly warning.