From: Junio C Hamano <junkio@cox.net>
To: "David Ho" <davidkwho@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Moving a file back to an earlier revision.
Date: Fri, 31 Mar 2006 13:49:44 -0800 [thread overview]
Message-ID: <7vacb6thc7.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 4dd15d180603311332p60fa1867nc303bd92d515b4e0@mail.gmail.com
"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.
next prev parent reply other threads:[~2006-03-31 21:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-31 21:13 Moving a file back to an earlier revision David Ho
2006-03-31 21:26 ` Linus Torvalds
2006-03-31 22:03 ` David Ho
2006-03-31 21:32 ` David Ho
2006-03-31 21:49 ` Junio C Hamano [this message]
2006-03-31 22:21 ` David Ho
2006-04-03 8:29 ` Karl Hasselström
2006-04-01 23:01 ` Petr Baudis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vacb6thc7.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=davidkwho@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox