Hi Vipin, I'm not so smart in diff / patch and git tools usage. Could be so kind to write to me how to build a patch for just one file I have modified in driver/mtd directory of u-boot?

Thanks in advange and sorry for my request, but I read on the net and nothing appeared to be usfull.

Thanks and sorry again

In data martedì 20 luglio 2010 09:00:39, Vipin KUMAR ha scritto: : > On 7/20/2010 12:25 PM, Fabio Giovagnini wrote:

...

Hi all, for sending a patch do I need to have on my PC two u-bbot tree, one original obtaned by git command, and another to make the modifications?

Or can I produce the patches using the original tree resident on git server?

Ciao Fabio,

You can use git format patch command to produce numbered patches You can google it to know more

Regards Vipin

...

Thanks

Many thanks to you and everybody

Cheers

In data martedì 20 luglio 2010 09:52:50, Xiangfu Liu ha scritto: : > Hi Fabio

1. git clone git://git.denx.de/u-boot.git u-boot.upstream
2. cd u-boot.upstream/
3. echo "/* just for git test */" >> driver/mtd/dataflash.c
4. git diff
5. git commit -a -s -m "this patch is for test"
6. git format-patch -1

then you will got a 0001-***.patch file.

On 07/20/2010 03:39 PM, Fabio Giovagnini wrote:

...

Hi Vipin, I'm not so smart in diff / patch and git tools usage. Could be so kind to write to me how to build a patch for just one file I have modified in driver/mtd directory of u-boot?

Thanks in advange and sorry for my request, but I read on the net and nothing appeared to be usfull.

Thanks and sorry again

In data martedì 20 luglio 2010 09:00:39, Vipin KUMAR ha scritto: :> On 7/20/2010 12:25 PM, Fabio Giovagnini wrote:

...

...

Hi all, for sending a patch do I need to have on my PC two u-bbot tree, one original obtaned by git command, and another to make the modifications?

Or can I produce the patches using the original tree resident on git server?

Ciao Fabio,

You can use git format patch command to produce numbered patches You can google it to know more

Regards Vipin

...

Thanks

No problems. It takes a little time to get used to git but then you start liking it. Anyway

you can create a patch for each commit. You can see a summary of commits via "git log"

Basically you need to run git format-patch -n <reference> reference is a branch name or tag or a direct reference to commit from which you want to create patches

eg git format-patch -n origin/master would create numbered patches for commits after the commit pointed to by origin/master

Also, run "gitk --all -1000" to get an understanding of what exactly is happening in the background when you commit a change

Hope this helps a little

I would also recommend looking at 'Stacked Git' (stgit) - It is basically a wrapper around it which allows you to manage a set of patches and move back and forth between them, merge, re-order etc.

It makes life a lot easier when you make a mess of things :)

Regards,

Graeme

Wolfgang Denk schrieb:

Dear Graeme Russ,

In message AANLkTil1Czc80PISUCnoxQK0lVhfTuDbwVNnsoZ9Cc-_@mail.gmail.com you wrote:

...

I would also recommend looking at 'Stacked Git' (stgit) - It is basically a wrapper around it which allows you to manage a set of patches and move back and forth between them, merge, re-order etc.

It makes life a lot easier when you make a mess of things :)

What exactly can stgit do that cannot be done with a number of branches and "git rebase -i" ? [Sorry for the stupid question, but I haven't used stgit yet...]

A wrapper: It probably makes the process even more obscure :)

Reinhard

Dear Graeme Russ,

In message AANLkTilaJ7MVv7VxxreBkCCSzYSZVSqULk_3I5AHlS4s@mail.gmail.com you wrote:

Now you will have a bunch of commits, but maybe they are in the wrong order

...

you can then use stg pop/push/merge to re-arrange and merge commits together to get them in a more logical arrangement before submitting

With "git rebase -i" I get an editor started like this:

pick 3e9b349 NAND: show manufacturer and device ID for unknown chips pick 1445f6f NAND: add Toshiba TC58NVG0 identifier pick bc1a884 mtd: nand_plat: add simple GPIO framework DEV_READY option pick 67ceefa Blackfin: convert plat-nand code to GPIO framework pick c9f7351 NAND: environment offset in OOB (CONFIG_ENV_OFFSET_OOB) pick 53504a2 NAND: formatting cleanups from env.oob support ... # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message

I can reorder, drop, combine (squash), edit patches...

Sometimes when I'm in the middle of a very long development session I tend to end up with one 'big patch' which has multiple logical change units. In this case, you can pop the 'big patch', insert a new smaller patch implementing some of the 'big patch' then when you push the 'big patch', all the duplicate changes are stripped. So you can basically whittle down a big, complex commit into multiple smaller commits very easily.

We can use "git add -i" to do this as well. You can even split hunks to add them to different commits.

I'm sure you'll argue that this is poor development management, but I find myself more efficient if a 'get in the zone' and then go back and break things up. It also serves as a really good self imposed code review

No, I don't argue. I'm trying to undestand. I am well aware that there are many tools for the same tasks, and the most efficient ones are these you know well, so "vi" is probably much more eficient to me than your favorite editor is to you. But I always like at least to know what the tools can do that I don't use or don't know that well - sometimes - sometimes i's time to make room in the toolbox for a new tool or another :-)

Thanks!

Wolfgang Denk

On Tue, Jul 20, 2010 at 10:59 PM, Wolfgang Denk wd@denx.de wrote:

Dear Graeme Russ,

In message AANLkTilaJ7MVv7VxxreBkCCSzYSZVSqULk_3I5AHlS4s@mail.gmail.com you wrote:

...

I'm sure you'll argue that this is poor development management, but I find myself more efficient if a 'get in the zone' and then go back and break things up. It also serves as a really good self imposed code review

No, I don't argue. I'm trying to undestand. I am well aware that there are many tools for the same tasks, and the most efficient ones are these you know well, so "vi" is probably much more eficient to me than your favorite editor is to you. But I always like at least to know what the tools can do that I don't use or don't know that well - sometimes - sometimes i's time to make room in the toolbox for a new tool or another :-)

Knowing what tools others use (and those tools influence how people work) is very helpful in understanding how and why people do what they do

You have a very good grip on git, and I would suggest stg is not really going to make your life any easier. I know only a few git commands, so stg is good for me. Who knows, over time I may get to know git well enough to not need stg any more ;)

-- Graeme