On 7/16/11 5:37 PM, "Graham Percival" <gra...@percival-music.ca> wrote:
> On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote: >> >> IMO, we should be aiming at one commit per Rietveld issue, rather than a >> series of commits per Rietveld issue. > > That's beside the point, at least as far as I understand it. > > - Bertrand writes some code. > - Bertrand makes a git commit. That commit has a nice message, it > has his name, etc. > - Bertrand gets this patch onto Rietveld using git-cl. More common, patch needs some changes. So Bertrand makes some changes and then makes a git commit. This commit reflects the changes. Then Bertrand pushes a new patch set. This happens a couple of times. Now Bertrand's repository doesn't have one commit on this branch, he has three or four commits on his branch. And the first two or three are not right -- they haven't passed code review. The final patch set passes code review. Graham wants to push this patch set. But he can't, unless he writes his own commit message and sets the author. But if Bertrand has been uploading as he did with his test issue, there are *3* patches, not *1*. And the first 2 are not accepted, so we don't want them in our source tree. They might even break compiling; if so, they'd mess up git bisect. Since we're only ready for committing after getting approval, we need to combine into a single commit after approval. Either you can do it (creating your own metadata, as you said) or he can do it (using git rebase -i). But somebody needs to make the change to the commits in order get them ready for pushing. Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
