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

[Geoffrey De Smet <ge0ffrey.spam@gmail.com>]

Op 03-10-12 18:52, Andreas Schwab schreef:
> Geoffrey De Smet <ge0ffrey.spam@gmail.com> writes:
>
>> 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?
> Because there is nothing wrong with that.
>
>> // I just "broke" my local repository, because if I continue
> No you didn't.
>
>> // do changes
>> git commit -m"good1"
>> git push origin master // fails because the history disrespects the remote
>> repo's history
> You may just as well want to push it to a different branch (or even a
> different repository).
In most cases (probably more than 90%?), the developer will want to get 
his changes into the remote branch where it came from.

What do you think of the -respectRepository flag idea? If you want to 
push to different branches/repo's you can not use it, turn it off or 
-force those commands.

A remote repository can be optionally flagged with -respectRepository.
That means that git should prevent the user from making local changes in 
the history that will prevent a normal push to that remote repository.

If a remote repository is flagged as such, git keeps track of a 
"pointOfNoReset" commit:
Every time a branch merges or rebases with a remote repository, it's 
flags the last commit of that remote repository as the pointOfNoReset 
commit.
If local branches merge or rebase with a local branch, the 
pointOfNoReset commit is transitively applied (only the last one wins).
git reset will fail to reset beyond the pointOfNoReset commit, unless 
forced.
git rebase and other git commands will also fail accordingly, unless forced.

>
> Andreas.
>