Felix Held wrote: > > Maybe the patch train is too long if it becomes hard to keep an overview? > > I'd say that it always better to have to look at all the individual > patches instead of just looking at the bigger picture
I agree completely, and don't want to suggest otherwise! By "keep an overview" I mean to know which commits in a pushed branch that have been reviewed and which not. > > If you have pushed a branch with 3 commits, use interactive rebase > > locally to fix up the middle commit and then push the branch again, > > doesn't Gerrit always recognize that the first commit remains > > unchanged, ie. with one generation less than the middle and last commit? > > To reduce unnecessary load on the build servers, it has become common > practice to only push up to the changed patch and not the patches after I don't understand this at all..? I'm all for skipping unneeded build load, but pushing only commits 1 and 2 in my case would still create build load (because commit 2 is new), right? Later pushing 3 will also always create build load, because that too is a new commit. What am I missing here? > that if the changes if the fixes are unrelated and there's more than > maybe one patch after the one being updated. .. > > If the patches aren't actually linked (ie. can be submitted individually) > > then I think they shouldn't be pushed as a single branch, right? > > Yes, but that's not the case I tried to outline; Hm, but "fixes are unrelated" seems to describe exactly this case? Felix Held wrote: > I reread the documentation and the thing I missed in there is that > Gerrit will only automatically rebase a patch when submitting when none > of the files it changed have been changed between the parent commit of > the to be submitted patch and the current top of tree. That seems like an improvement to me. By the way, I don't think Gerrit has ever actually rebased anything, nor will it with the new setting, I understand it to always do an equivalent of "git cherry-pick" but with different requirements with the new strategy. > This makes both treewide changes and submitting patch trains patch > by patch more difficult. Hmm, how so? Submitting one commit at a time should make top of tree always match the parent commit of the to-be-submitted commit, right? Kind regards //Peter _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
