On Fri, 2016-01-15 at 18:41 +0000, Ivan Vučica wrote: > On Thu, Jan 14, 2016 at 7:04 PM Sergio L. Pascual <s...@sinrega.org> > wrote: > > > > Bundling a bunch of changes of a branch into a single one doesn't > > sound > > as good, though. That could only mean that you have a really broken > > commit policy for your git repo, and that you need this to make > > some > > sense of it ;-) > This was mentioned having in mind the approach that people might > have: commit possibly broken things as you go, keep them on a branch, > then consider the "pull request" (with 20, 30 smaller commits) as the > final product. For purposes of GNUstep, however, not a "pull request" > but a "patch" should be considered the final product. This means "if > you commonly do pull request, it'd be preferable to squash it first". > > Why? Two reasons: > > - We still use Subversion > - your commits will spam watchers and history with many commit > notifications (e.g. via email or RSS) > - or they will get squashed (which watchers will probably prefer) > > - I would like to use Gerrit to review your changes. > - Gerrit has a concept of a 'change' (approximately, one Subversion > commit or Github/Bitbucket/pick_code_hosting_site pull request) > - Each change track the history of the change as it is being > reviewed > - Each item in the history is called a 'patch set' (approximately, > full diff from the base commit -- think 'squashed development > history') >
OK, now I see your point. Sergio. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
