A real go back plan

Showing 1-6 of 6 messages
A real go back plan Patrick 4/17/12 10:59 AM
I run into this problem a couple times and I have not figured out how
to fix it.

-In a central repo environment

-local system A gets new changes pushed up to central repo

-local system B has changes and pulls from the central repo creating a
merge conflict.

After reviewing the merge conflict it is decided to drop the changes
on local system B and match it up with the central repo.

I ultimately have just deleted the local repo on local system B and
checked it out again.

I do want to know when the merge conflict exists so I can check it
but, is there a way to drop the pull that local system B did and pull
the central repo version after I decide review it?
Re: A real go back plan tombert 4/17/12 11:46 AM
My first tip would be:
git checkout --force <ref>

... but others might know better ...


Re: [git-users] A real go back plan Serge Matveenko 4/17/12 2:05 PM
On Tue, Apr 17, 2012 at 21:59, Patrick <pn1....@gmail.com> wrote:
> I do want to know when the merge conflict exists so I can check it
> but, is there a way to drop the pull that local system B did and pull
> the central repo version after I decide review it?

1. git reset --hard  # this to reset your local reviewing into local
history state
2. git reset --hard origin/<branch_name>  # this to reset your local
checkouted branch to the central repo state

Repeat step 2 for every branch you want to reset into central repo
state after checkouting each corresponding local branch


--
Serge Matveenko
se...@matveenko.ru
http://www.ohloh.net/accounts/lig
http://ru.linkedin.com/in/sergematveenko

Re: [git-users] Re: A real go back plan pasky 4/17/12 2:08 PM

This will change your head (active branch) to point to the <ref>,
which is not something you want, especially if <ref> is a remote branch;
you want to stay on your local branch but change the *contents* of the
local branch. The git reset --hard suggestion is a good one, since it
does exactly that. :-)

--
                                Petr "Pasky" Baudis
        Smart data structures and dumb code works a lot better
        than the other way around.  -- Eric S. Raymond

Re: A real go back plan Thomas Ferris Nicolaisen 4/17/12 2:17 PM

On Tuesday, April 17, 2012 7:59:43 PM UTC+2, Patrick wrote:
I run into this problem a couple times and I have not figured out how
to fix it.

-In a central repo environment

-local system A gets new changes pushed up to central repo

-local system B has changes and pulls from the central repo creating a
merge conflict.

After reviewing the merge conflict it is decided to drop the changes
on local system B and match it up with the central repo.

I ultimately have just deleted the local repo on local system B and
checked it out again.

It's easier to do a git reset --hard origin/master (assuming the branch is called master and the remote is called origin). 

I do want to know when the merge conflict exists so I can check it
but, is there a way to drop the pull that local system B did and pull
the central repo version after I decide review it? 

Not sure if I understand what you mean here. Usually I would do a 

git fetch origin

to get hold of what's going on in the central repo. 

I'd then have a look at the histories with

git log --graph --oneline --decorate --all

and then decide what to do. If I think the local changes are worth keeping (which they probably are, cause I made them for a reason), I'll do

git rebase origin/master

(this is the same as doing a git pull --rebase in the first place). This places my local commits orderly after the ones coming from central.

I could also put my local commits in a branch, and merge them in, but I'll keep out that scenario for now.
Re: A real go back plan Patrick 4/21/12 10:18 AM
I tried the git reset --hard HEAD and this worked as I wanted.  But I have now also tried the process of fetch first and this is more along the lines of what I really want to do.
 
1.  See whats up on the central repo:  git fetch origin
2.  Look at the logs:  git log --graph --oneline --decorate --all
3.  If cool with what logs show, then add the local changes after the pull:  git rebase origin/master