Moving a file back to an earlier revision.

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

On Fri, 31 Mar 2006, David Ho 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.

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

On 3/31/06, Linus Torvalds <torvalds@osdl.org> wrote:

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

Yes, good point.

Thanks, David

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:

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

[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.

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

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

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.)

Dear diary, on Fri, Mar 31, 2006 at 11:32:16PM CEST, I got a letter where David Ho <davidkwho@gmail.com> said that...

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