git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Subject: Re: Question on multi-level git repository heiarchy.
Date: Fri, 27 Oct 2006 16:31:47 +0100	[thread overview]
Message-ID: <200610271631.49803.andyparkins@gmail.com> (raw)
In-Reply-To: <4542120E.1050903@candelatech.com>

On Friday 2006 October 27 15:05, Ben Greear wrote:

> I want to synchronize the entire git repo, including all branches.  How
> would I go
> about doing that?

That happens anyway.  "git pull" is actually a fetch + a merge.  Personally I 
recommend never doing a "git pull" without arguments.  Instead:

First, update every "Pull:" line from .git/remotes/origin
 $ git fetch
Now manually merge one of the (now locally stored) upstream trees into your 
working tree.
 $ git pull . upstream-tree

> Is there any way to recover my currently mangled tree on the
> workstation, or do I need
> to start fresh there?  If I start fresh, do I re-clone, or is there some
> better way to get

I'm relatively new to git; my experience is that there is very little that 
can't be undone.  Exactly what sort of mangling has happened to your tree?

If you've got yourself in a real state, I suggest editing .git/remotes/origin 
to pull the upstream trees to some newly named branches (maybe just 
add "new/" to the front of them).  Treat those as read-only (i.e. don't check 
them out), and start comparing branches.  "gitk --all" is incredibly useful 
for this.

Make yourself a new branch for your own work based off a new/upstream branch  
(git checkout -b fixthings new/upstream), then use git-cherry-pick to pull 
your patches out of your mangled tree to build up a branch with your changes 
on it.

Now, you can delete all the branches that you think are mangled and (if you 
really want to), rename all the new/ refs back to whatever they started as.

> the synchronization that I want?

I am going to guess that you've fallen for the same thing I did at first: 
confusing "git pull" with "git fetch"; "git pull" can get you in 
trouble, "git fetch" probably won't.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

  reply	other threads:[~2006-10-27 15:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-27  5:12 Question on multi-level git repository heiarchy Ben Greear
2006-10-27  5:25 ` Shawn Pearce
2006-10-27 14:05   ` Ben Greear
2006-10-27 15:31     ` Andy Parkins [this message]
2006-11-16  0:43   ` Ben Greear
  -- strict thread matches above, loose matches on Subject: below --
2006-10-27 19:26 linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610271631.49803.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).