On Sat, Mar 22, 2008 at 12:06:37PM -0700, Andrew Arnott wrote:
> Thanks, Jeff. That was very helpful. I have published my repo online
> already, but only a couple people (if even that) have cloned it by now
> and I am prepared to email the list of interested parties letting them
> know. About this rebasing thing, is there a better way than for them
> to just wipe their repo and clone again? Would a simple git fetch and
> git rebase do the trick?
Short answer: if they haven't done any work on top of yours, re-cloning
is probably the simplest route.
If they do have work, then they will want to fetch and rebase. The
commands are fairly simple, but what is happening is a little tricky, so
I'll subject you to some ascii art.
# user has commits C..D built on top of your original A..B (in the
# diagram, "..." refers to an arbitrary number of commits)
#
# A--...--B <-- origin/master
# \
# C--...--D <-- master
git fetch
# after the fetch, we now have the filtered A'..B' pointed to by
# origin/master, but the reflog for origin/master points to the
# original.
#
# A'--...--B' <-- origin/master
# A--...--B <-- origin/master@{1}
# \
# C--...--D <-- master
#
# so now we can rebase. We want all of the commits between the
# _original_ upstream and our current state to be rebased on top
# of the new upstream.
git rebase --onto origin/master origin/master@{1} master
Three things to note here.
1. This works even if C..D is empty, so it is valid even if they didn't
do any work. Though in that case, simply doing "git reset --hard
origin/master" would work just as well.
2. The annoying thing is that you have to do this for every branch. So
depending on how many branches you have and how much work they did, it
may just be simpler to export the work as patches, re-clone, and then
apply:
git checkout master
git format-patch origin/master >/some/path/outside/repo
cd .. && rm -rf repo
git clone /path/to/repo && cd repo
git am /some/path/outside/repo
3. Since you haven't changed the trees at all, a fetch will just need to
download the new commits. Thus a fetch should be way less
network-intensive than a re-clone. Whether that matters, of course,
depends on your repo size and your users' bandwidth.
Hope that helps,
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
