Revert-style merge/Working tree-only checkout?

Revert-style merge/Working tree-only checkout?

[Yuriy Romanenko]

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

Re: Revert-style merge/Working tree-only checkout?

[Konstantin Khomoutov]

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.

Re: Revert-style merge/Working tree-only checkout?

[Andreas Schwab]

Konstantin Khomoutov <flatworm@users.sourceforge.net> 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."

Re: Revert-style merge/Working tree-only checkout?

[Neal Kreitzinger]

"Yuriy Romanenko" <groman@gmail.com> 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