El 18/4/2008, a las 14:16, David C. [email protected]
escribió:> On Apr 18, 2008, at 3:43 AM, Dan N. wrote:
3. Oh silly sod - of course I committed from the other machine.
This is actually what happened. Two people were doing work at the same
time and one got the warning from the repo and did a “push --force.”
We’ve all learned a lesson from this and it won’t happen again.
In my opinion, even if you are allowed to force a push, the repo
should maintain some reachable history somewhere of the commits that
you are “hiding.” So the public “view” removes those commits but they
can be retrieved.
This is a potentially painful lesson that I think we all learn once we
start using Git. If you’re lucky, you learn it on an unimportant repo
or one which you fully control and can dig around in.
By way of counter-opinion, the ability to force a push like that may
be considered a feature. Example case: you accidentally include
confidential company files when you push to a remote repo; if you fix
the mistake by altering the history in your local repo and then trying
pushing again Git will correctly warn you that this won’t be a fast-
forward merge, but the ability to force the push anyway allows you to
“remove” the unwanted history from the remote repo.
Note that the history should still be there, it’s just that it won’t
be “reachable” when someone clones the public repo. Does GitHub
provide shell access so that you can get into the remote repo and run
stuff like “git fsck” on it? The missing commits should still be in
the object database, unless the GitHub crew are doing overly
aggressive automatic repacking and pruning on the repos (or unless
there is something about the way bare repos work which I don’t know;
quite possible!). In the case that GitHub doesn’t provide shell access
then it’s really like pushing into a blackhole drop box, with no way
to do any “archaeology” on the object database.
Could a pull-merge-commit before pushing have avoided this, and
should we make that our endorsed way of working? Or am I missing
something else about how dscm works?
I do think this should be the way we do things. We have some rake
tasks that manage these bits one step at a time. I’ll add one that
combines them. You’ll still be able to do them one at a time, and
you’ll still need to pull/merge again if central repo warns you on
If you get into the habit of rebasing before committing rather than
merging you’ll get a much nicer history. It will basically look linear:
Rather than full of crisscrosses from multiple small merges:
\ / \ \ /
Sure, Git can easily do the merges but the resulting history is harder
to analyse and less “bisectable” (with “git bisect”).