On Mon, 14 Dec 2009, Takashi Iwai wrote: > Or, use the same name snd_hda_add_nid() and snd_hda_add_nids(), unify > the argument order, but make the latter accept array, or so. Renamed in this way. Please, check topic/hda-nid or for-next branch. >>>>> branch based on the upstream tree. Right now I can't pull your >>>>> commits but only do cherry-picks, which is basically stupid when both >>>>> are using GIT. >>>> >>>> I found the possible changes (resolving clashes) during merges very evil, >>>> altough I understand your easy work scheme. >>> >>> Right. IOW, the commits that have been already published for the >>> public tree shouldn't be rebased. The rebasing is the most evil thing >>> for the published commits. >>> >>> Rebasing doesn't matter for local commits, of course. Also, it's also >>> more or less OK for some test trees / branches. But, never rebase if >>> a branch gets merged. >>> >>>> Also, I don't like the missing >>>> lines in comments (Signed-off-by etc.) for merged patches for all involved >>>> people. It makes more difficult to track the patch flow. >>> >>> Well, the meta info has to be set properly *before* merge. So, the >>> only question is whether a developed branch is ready for merging or >>> not... >> >> Unfortunately, I'm not talking about the meta-info. The patch delivery >> should be in the patch comment itself according to the SubmittingPatches >> document. For example: >> >> commit 761c9d45d14e0afa3c0b8eb84b4075602e50533b >> Author: Olof Johansson <olof@xxxxxxxxx> >> Date: Thu Dec 10 11:15:55 2009 -0600 >> >> ASoC: Fix build of OMAP sound drivers >> >> .... >> Reported-by: Anand Gadiyar <gadiyar@xxxxxx> >> Signed-off-by: Olof Johansson <olof@xxxxxxxxx> >> Acked-by: Liam Girdwood <lrg@xxxxxxxxxxxxxxx> >> Signed-off-by: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> >> >> Where's your Signed-off-by: line? You rely on the SCM system to obtain >> this information from the 'Merge' commit. I don't think that it's good. > > This is fully normal. Do you see sign-off in each pull by Linus? Linus should be only exception, because this patch route is quite obvious. > Many trees with sub-trees or sub-projects are done in that way. > See x86 tree, for example. It does not mean that it's the correct way. Anyway, I created for-next branch in my repository. Could you import changes without explicitly asking if you do not have any comments? I'll merge patches from Clemens there as well. Thanks, Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
