On Jan 7, 2011, at 12:43 PM, Stevie Strickland wrote:
> On Jan 7, 2011, at 12:29 PM, Robby Findler wrote:
>> Then, on the laptop, I did a git pull, and I ended up with the commits
>> back in the original order and a merge commit afterwards but I would
>> rather just have my state be like the server's was.
> Then don't do git pull.  That not only updates your remotes, but does a "git 
> merge" (which will create a merge point if it's not a simple fast-forward, as 
> you've seen here).  What you want to do is update your remotes using "git 
> remote update", and then use "git reset --hard" to reset to the server's 
> master (or whichever branch off of which you're working).

At this point, though, you can still do git reset --hard to just throw away all 
the merging you did and reset to the server's state.  So it's not like you have 
to go back in time or anything to fix this.

In general, this is why people say you really shouldn't train yourself to do 
"git pull" automatically, because there's plenty of places where you don't want 
that.  I always do "git remote update"/"git merge ..." separately because 
there's plenty of times where I don't want to merge.

  For list-related administrative tasks:

Reply via email to