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

From: Phil Hord <phil.hord@gmail.com>
Date: Oct 3, 2012, 16:40 UTC
Message-ID: <CABURp0qVWg2PvD4PcjJ9q45x9WxJCuJEQL8Rze=qerWXg72Txw@mail.gmail.com>
In-Reply-To: <k4hj91$4tt$4@ger.gmane.org>

On Wed, Oct 3, 2012 at 10:49 AM, Geoffrey De Smet <ge0ffrey.spam@gmail.com> wrote:

Show 28 quoted lines

> Suppose this case:
>
> git clone .../blessedRepo.git
> // do changes
> git commit -m"bad1"
> // do changes
> git commit -m"bad2"
> git reset --hard HEAD^4 // Why does it let me do this?
>
> // I just "broke" my local repository, because if I continue
>
> // do changes
> git commit -m"good1"
> git push origin master // fails because the history disrespects the remote
> repo's history
>
> The following commands are ok to do (because I have 2 unpushed commits):
>  git reset --hard^1
>  git reset --hard^2
> but these are not and should be prevented (unless forced):
>  git reset --hard^3
>  git reset --hard^4
>
>
> Is there any way to make git idiot proof by enabling that the local repo
> should always respect the history of the remote repo (unless forced)?
> Is there any way to make this a default for anyone who clones our blessed
> repo?

I suppose if we go down this path we must also prevent users from having any local branches whose names match those used on the remote unless the remote branches are also ancestors of our local branch. But then we may get into trouble when we pull new branches which now conflict but previously did not.

I'm afraid this is a Pandora's box of woes.

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

Phil