On Wed, Oct 3, 2012 at 10:49 AM, Geoffrey De Smet
<ge0ffrey.s...@gmail.com> wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
