On Mon, Dec 13, 2010 at 03:30:00PM -0800, Yuriy Romanenko wrote:
> I am somewhat new to Git and I keep running into having to accomplish
> a certain task and reading through the documentation I can't seem to
> find any way of doing this easily.
>
> The problem is when branches diverge and I want to sync a branch to
> another branch with full overwrite, but maintain history and maintain
> separate branches.
>
> For example, say there is a branch "master" and I create a branch "b1"
> from master at some point. After this, there are 5 commits
> (C1,C2,C3,C4,C5) to master and
> 17 commits to b1 (let's call them cb1, cb2, cb3, ..., cb17). Say I
> want to create an 18-th commit to "b1" that makes it identical to the
> C5 (current) state of master. Essentially a single commit wipe of
> changes cb1 -> cb17 as well as application of C1->C5. So far I have
> found one way of accomplishing this, but it is difficult, error prone,
> slow and I just plain don't like it. I feel like there should be an
> easier way.
>
> What I currently do:
>
> $ rm -rf *
> $ git checkout -f master
> $ tar -cvzf /tmp/master.tar.gz *
> $ git checkout b1
> $ rm -rf *
> $ tar -xvzf /tmp/master.tar.gz
> $ git add
> $ git commit -a
> $ git merge master
I think this method would work better instead:
$ git checkout b1
(2) $ git read-tree --reset master
(3) $ git checkout-index --all --force
$ git commit -m "Bring b1 to the state of master"
(4) $ git merge --no-ff master
In this sequence, (2) makes the index contain the same state as
the tip of the master branch (you can also use more direct name,
master^{tree}, if you like), then (3) throws away any changes appeared
in the work tree after resetting the index. As the last step, you record
explicit merge to indicate that you converged histories back.
> I've considered doing something like the following
>
> $ git checkout b1
> $ git revert b1~17..b1
> $ git merge master
>
> but it also seems wrong, and requires me to count the submits by hand,
To not count commits by hand, you could use `git merge-base HEAD master`
to find the last commit b1 and master shared just before diverging.
> which seems silly --> I'm not actually reverting anything. I don't
> know if this would even work.
This is questionable -- like any VCS, Git was supposedly designed to
track evolving history, and you want to somehow make it track
"devolving" history at times. So, if we would opt not to play powerful
tricks with Git but rather go a "normal" VCS way, you would naturally
have to revert your changes to explicitly bring b1 to master.
--
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