From: "Andreas Bießmann" <andreas.devel@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] AT91SAM9XE add embedded flash support
Date: Mon, 09 Aug 2010 09:28:25 +0200 [thread overview]
Message-ID: <4C5FAE19.9040701@googlemail.com> (raw)
In-Reply-To: <4C5FA96B.9040704@emk-elektronik.de>
Dear Reinhard Meyer,
Am 09.08.2010 09:08, schrieb Reinhard Meyer:
> Andreas Bie?mann schrieb:
> Dear Andreas Bie?mann,
>>> So, simple question: how do I get a new patch against the original
>>> state after editing the file?
>> 'git rebase' does the trick, e.g. 'git checkout <my patch branch> && git
>> rebase master'
>
> Here the problem starts... I have made changes to like 2 dozen files
> since then. I cannot switch branches, nor will a rebase work.
No problem, so how about:
1. git checkout master && git pull
2. git checkout -b my_branch_for_single_commit
3. git cherry-pick <hash of commit in question>
4. fix conflicts, make changes a.s.o.
5. generate clean commit on top of current master as already described
6. git format-patch ....
7. git checkout master && git branch -d my_branch_for_single_commmit
> I do not want to ADD and COMMIT those changes yet, so I guess I am stuck
> in that branch for the time being.
Ah, i see ... you have uncommited changes in your current branch? Bad
thing!
> Maybe my approach is wrong?
Consider creating a branch for each task you want to e.g. my_test_task1,
my_test_task2. Use git to switch between them (checkout) and get changes
from one branch to another (cherry-pick/merge). These test branches are
cheap to create and delete. Btw it is ok to switch between branches with
uncommited changes. You can e.g. switch, commit there and switch back.
Consider using a branch for patches to go upstream. You can switch to
this branch every time you have to do changes in your patches. Use 'git
rebase origin/master' to stay up to date. Then your local commits will
be replaced by the one in upsteream (they have different hashes!) ..
maybe 'git merge' will also work.
Consider generating small commits (small in means of timeline of
feature). They are so easy to cherry-pick/squash in other branches ...
Git is built to do rework of single commits up to the perfect one ;)
regards
Andreas Bie?mann
next prev parent reply other threads:[~2010-08-09 7:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-16 7:47 [U-Boot] [PATCH v2] AT91SAM9XE add embedded flash support Reinhard Meyer
2010-08-08 21:51 ` Wolfgang Denk
2010-08-09 5:13 ` Reinhard Meyer
2010-08-09 6:34 ` Andreas Bießmann
2010-08-09 7:08 ` Reinhard Meyer
2010-08-09 7:28 ` Andreas Bießmann
2010-08-09 7:39 ` Reinhard Meyer
2010-08-09 7:43 ` Alessandro Rubini
2010-08-09 7:46 ` Andreas Bießmann
2010-08-09 7:28 ` Andreas Bießmann [this message]
2010-08-09 16:00 ` [U-Boot] [PATCH v3] AT91SAM9XE: " Reinhard Meyer
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=4C5FAE19.9040701@googlemail.com \
--to=andreas.devel@googlemail.com \
--cc=u-boot@lists.denx.de \
/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