# Revert-style merge/Working tree-only checkout? 4 messages from 2010-12-13 to 2010-12-14. Participants: Yuriy Romanenko, Konstantin Khomoutov, Neal Kreitzinger, Andreas Schwab. Thread: https://gitlist.dev/t/26042 ## Yuriy Romanenko, 2010-12-13 23:30 Subject: Revert-style merge/Working tree-only checkout? Message-ID: URL: https://gitlist.dev/e/AANLkTi%3DioX25aqXg-yWDA0oXBTATkFe%2BJ25g-dB7-psS%40mail.gmail.com ``` Hello, 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'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, which seems silly --> I'm not actually reverting anything. I don't know if this would even work. Any suggestions on how to accomplish this easier? Some sort of a force-checkout that affects working tree only but not the index? Thank you, Yuriy ``` ## Konstantin Khomoutov, 2010-12-14 05:46 Subject: Re: Revert-style merge/Working tree-only checkout? Message-ID: <20101214054604.GI3264@localhost.localdomain> URL: https://gitlist.dev/e/20101214054604.GI3264%40localhost.localdomain In-Reply-To: ``` 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. ``` ## Neal Kreitzinger, 2010-12-14 14:36 Subject: Re: Revert-style merge/Working tree-only checkout? Message-ID: URL: https://gitlist.dev/e/ie7veg%24ks5%241%40dough.gmane.org In-Reply-To: ``` "Yuriy Romanenko" wrote in message news:AANLkTi=ioX25aqXg-yWDA0oXBTATkFe+J25g-dB7-psS@mail.gmail.com... > Hello, > > 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'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, > which seems silly --> I'm not actually reverting anything. I don't > know if this would even work. > > > Any suggestions on how to accomplish this easier? Some sort of a > force-checkout that affects working tree only but not the index? > Have you looked at the vendor branch methodology in the git-rm manpage? It may give you some ideas you're interested in. v/r, Neal ``` ## Andreas Schwab, 2010-12-14 19:37 Subject: Re: Revert-style merge/Working tree-only checkout? Message-ID: URL: https://gitlist.dev/e/m2zks89me7.fsf%40igel.home In-Reply-To: <20101214054604.GI3264@localhost.localdomain> ``` Konstantin Khomoutov writes: > (2) $ git read-tree --reset master > (3) $ git checkout-index --all --force $ git rm -r . $ git checkout master . Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ```