On Sat, Dec 29, 2012 at 8:53 AM, Eric <[email protected]> wrote: > On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams <[email protected]> > wrote: > <snip> > > Actually I agree with most of Mike Meyer's reply, but I wanted to pick > this paragraph apart: > >> How many times have you submitted a patch to an upstream > > Well, phrasing it like that says that you are thinking git-style anyway. > Let's assume a Fossil push with one commit nominated as "this is my > current contribution". > >> and then been told to make a bunch of changes, > > That's only to be expected, so you create a new commit based on your > previous nominated one, push it and tell them which is your new commit. > >> re-organize your commits, > > I don't see why they (the centre) should do that. It's the result that > matters, and if they want a pristine tree that includes only approved > commits they can do that. (See below.)
It matters a great deal. Let's say you submit a patch for the main branch and the maintainers of an older release branch want to pull your patch in for a micro release of that older release. If your patches are broken up into suitable pieces then the maintainers might pull some of your commits (e.g., bug fixes) but not others (e.g., riskier ones, features). But if your commits were badly organized then the maintainers will have to copy/paste or apply chunks of patches -- very manual, risky processes. To me what you say indicates that you have very little experience with *large* projects. I've worked on quite a few large projects. I'd drop names, but to what end. The key is this *happens*. A lot. And it's not just because the VCS supports rebase: I've had to do rebasing with VCSes that don't have explicit support for it, because if that's what the upstream wants, then that's what the upstream gets (or nothing at all, but what if your job -that you're paid for- is to contribute to that upstream?). >> make specific changes to specific commits, > > Why, why, why? It's the result that matters, this is just rewriting > _your_ history because they feel like it. Because that history is of a PRIVATE branch. PRIVATE. And the way I do it (go look at my github repos) is that I rebase brand new *copies* of the branch in question, so I never actually rewrite any history. (I thought I'd explained this. Hadn't I?) >> and/or squash commits? > > Again, this is about them wanting a pristine tree. Their problem. Or my problem: I want my fixes in. Or maybe I get paid to contribute to them. Nico -- _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
