[rspec-users] rspec + github == !submodules
win at wincent.com
Fri Apr 18 09:34:53 EDT 2008
El 18/4/2008, a las 14:16, David Chelimsky <dchelimsky at gmail.com>
> On Apr 18, 2008, at 3:43 AM, Dan North wrote:
>> With mercurial I nearly did a similar thing, working on my own but
>> committing from two different machines. Luckily mercurial gave me a
>> warning that allowed me to make sense of what I was doing. Not sure
>> how this works with git but here goes.
>> 1. I push from laptop1 to my central server. All is good.
>> 2. I push from laptop2 to my central server. Mercurial doesn't allow
>> this and warns me that the remote repo will have two heads (which is
>> allowed but probably not what I want). I can override this with --
>> 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").
More information about the rspec-users