Op 03-10-12 18:52, Andreas Schwab schreef:
Geoffrey De Smet <ge0ffrey.spam@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html