Moving a file back to an earlier revision.

Moving a file back to an earlier revision.

[David Ho]

Hi,

Another user question.  Other may actually have similar needs.

I am working on a board port on a separate branch.  The branch has
accumulated several revision of changes to a driver I worked on.  Now,
someone has come along with a better fix so I want to help test his
patch.  To do that I have to revert my changes to that driver (several
revisions back) before I can apply his patch.

What would be a convenient way to do that with git?

TIA, David

Re: Moving a file back to an earlier revision.

[Linus Torvalds]

On Fri, 31 Mar 2006, David Ho wrote:
> 
> I am working on a board port on a separate branch.  The branch has
> accumulated several revision of changes to a driver I worked on.  Now,
> someone has come along with a better fix so I want to help test his
> patch.  To do that I have to revert my changes to that driver (several
> revisions back) before I can apply his patch.
> 
> What would be a convenient way to do that with git?

Don't revert.

Just pick the point you want to start testing his patch at (with gitk, for 
example, just cut-and-paste the sha1), and do

	git checkout -b test-better-fix <sha1>

which creates a new branch ("test-better-fix") that starts at that point, 
and checks it out. 

Then, just apply the patch, and off you go. You now have _both_ his patch 
and your own series in separate branches, so you can cherry-pick and do 
other things (like do a "diff" between branches - which can sometimes be 
useful too to verify that the two branches end up fixing all the same 
problems).

		Linus

Re: Moving a file back to an earlier revision.

[David Ho]

On 3/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Don't revert.
>
> Just pick the point you want to start testing his patch at (with gitk, for
> example, just cut-and-paste the sha1), and do
>
>         git checkout -b test-better-fix <sha1>
>
> which creates a new branch ("test-better-fix") that starts at that point,
> and checks it out.

I forget to mention I have also in my branch changes necessary to run
on my board.  So what I did was

git-branch test-better-fix my-branch
git-checkout test-better-fix
git-diff commit(my-fixes)..commit(original) filename | git-apply
git-commit

>
> Then, just apply the patch, and off you go. You now have _both_ his patch
> and your own series in separate branches, so you can cherry-pick and do
> other things (like do a "diff" between branches - which can sometimes be
> useful too to verify that the two branches end up fixing all the same
> problems).
>

Yes, good point.

Thanks, David

Re: Moving a file back to an earlier revision.

[David Ho]

Sorry I might already have found it.

File revisions

+----+----+
1    2    3

git diff commit(3)..commit(1) filename | git-apply

David

On 3/31/06, David Ho <davidkwho@gmail.com> wrote:
> Hi,
>
> Another user question.  Other may actually have similar needs.
>
> I am working on a board port on a separate branch.  The branch has
> accumulated several revision of changes to a driver I worked on.  Now,
> someone has come along with a better fix so I want to help test his
> patch.  To do that I have to revert my changes to that driver (several
> revisions back) before I can apply his patch.
>
> What would be a convenient way to do that with git?
>
> TIA, David
>

Re: Moving a file back to an earlier revision.

[Junio C Hamano]

"David Ho" <davidkwho@gmail.com> writes:

>> I am working on a board port on a separate branch.  The branch has
>> accumulated several revision of changes to a driver I worked on.  Now,
>> someone has come along with a better fix so I want to help test his
>> patch.  To do that I have to revert my changes to that driver (several
>> revisions back) before I can apply his patch.
>>
>> What would be a convenient way to do that with git?
>
> Sorry I might already have found it.
>
> File revisions
>
> +----+----+
> 1    2    3
>
> git diff commit(3)..commit(1) filename | git-apply

[please do not top-post].

That lets you go back to the state before 1, so what you are
doing is to start from here:

	---0---1---2---3

and

	---0---1---2---3---*

where * has the same tree as 0, and then on top of that you
apply his patch:

	---0---1---2---3---X

But what if you find a room for further improvements in his
patch?  You could commit X (which is revert of 321 *and* his
patch) and then build on top of it, like this:

	---0---1---2---3---X---Y

and feed him "diff X..Y" back.

However.

What Linus said is more natural in git.  Starting from the same
picture, you do this:

             X (side branch to test his patch on)
            /
	---0---1---2---3 (your original branch)

You apply his patch to a new branch.  You could even make
further improvements like this:

             X---Y
            /
	---0---1---2---3

And if you decide Y is better than your version 3 after all, you
can switch to his branch and then pick up anything important
from your development track between 0..3 on top of Y by
cherry-picking, and you can even later discard your original
development track.  On the other hand, if you end up deciding 3
is better than Y after all, you can just discard the whole side
branch.

Remember, a branch in git is very cheap, and is a powerful way
to keep track of things while you decide which alternate
universe to take.  And even after you decide, you could always
look at and even build on the other universe.

Re: Moving a file back to an earlier revision.

[David Ho]

> Remember, a branch in git is very cheap, and is a powerful way
> to keep track of things while you decide which alternate
> universe to take.  And even after you decide, you could always
> look at and even build on the other universe.

I feel embarrassed to say this but in my branch there are commits to
the driver and other commits for the board so it looks more like

---0---D1---B1---B2---D2---B3---B4---

D* - driver changes
B* - board changes

So to go back to the 0 state I lose my board changes.  But I hope what
I did (in my reply to Linus) is very close to your idea of having
separate branches.

David

Re: Moving a file back to an earlier revision.

[Karl Hasselström]

On 2006-03-31 17:21:48 -0500, David Ho wrote:
[quoting junkio]

> > Remember, a branch in git is very cheap, and is a powerful way to
> > keep track of things while you decide which alternate universe to
> > take. And even after you decide, you could always look at and even
> > build on the other universe.
>
> I feel embarrassed to say this but in my branch there are commits to
> the driver and other commits for the board so it looks more like
>
> ---0---D1---B1---B2---D2---B3---B4---
>
> D* - driver changes
> B* - board changes
>
> So to go back to the 0 state I lose my board changes. But I hope
> what I did (in my reply to Linus) is very close to your idea of
> having separate branches.

You could use either stgit or the cherry-picking stuff in git to
create a new branch with these commits, but reordered any way you
like. (Or, given what you want to use it for, maybe two separate topic
branches -- one for board changes and one for driver changes -- that
can be merged to produce the end result.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Moving a file back to an earlier revision.

[Petr Baudis]

Dear diary, on Fri, Mar 31, 2006 at 11:32:16PM CEST, I got a letter
where David Ho <davidkwho@gmail.com> said that...
> Sorry I might already have found it.
> 
> File revisions
> 
> +----+----+
> 1    2    3
> 
> git diff commit(3)..commit(1) filename | git-apply

Note that it might be more convenient to just say "restore the file to
the contents as of commit X" - in pure Git this would involve dances
with git-ls-tree and git-cat-file, I'm not sure if the core Git
porcelain has an interface for doing this easily.

In Cogito, you can just do:

	cg-restore -f -r commitid filename

-- 
				Petr "Pasky on a dialup" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.