Re: [PATCH 000/141] V4L/DVB updates part 1

[Mauro Carvalho Chehab]

Linus,

Em Ter, 2006-03-21 às 08:26 -0800, Linus Torvalds escreveu:
> > In particular, commit e338b736f1aee59b757130ffdc778538b7db18d6 is crap, 
> > crap, CRAP.
Sorry for the troubles. I didn't noticed anything here indicating
troubles, otherwise I would never asked you to pull it.

> Looking closer, the commit after that is a _real_ merge, and it looks like 
> you did something strange when that at first conflicted in saa7134-dvb.c 
> or something. I just don't even see _how_ you created that bogus non-merge 
> commit. Are you using cogito? It has some problems with conflict 
> resolution, I think. Real git should not even have allowed you to commit 
> something that hadn't been resolved.

I'm using stgit. It allows me to export the patches from V4L/DVB
Mercurial tree, removing backward compatible code and correcting the
patches. Is it broken?

Maybe I'm using a bad procedure to keep my -git tree.

My current procedure is:
branch origin - Your tree replica
branch work - my stgit main tree
branch work-fixes - my stgit tree for bug fixes
branch master - patches to current kernel
branch devel - patches to next kernel

All patches are generated against work branch, with stgit.
Branch work-fixes receives patches by using:

	stg pick <sha>@work

Before commiting to kernel.org, I do:
at origin:
	git pull linus_tree

at master:
	git pull . origin
	git pull . work-fixes

at devel:
	git pull . origin
	git pull . work

> 
> Anyway, if you want to fix this up without re-doing _everything_, the way 
> to do so is to just start a new branch, and cherry-pick the non-crap 
> commits. So you can fix it up, largely automatedly, with git.
> 
> I'm actually trying to do that right now, to see if I can re-create your 
> tree without the errors.
I'll retrieve from your tree and I'll do a double check if something
were misapplied.

> 
> 		Linus
Cheers, 
Mauro.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/