Aaron Bentley wrote: > Petr Baudis wrote: >> >> Another aspect of this is that Git (Linus ;) is very focused on getting >> the history right, nice and clean (though it does not _mandate_ it and >> you can just wildly do one commit after another; it just provides tools >> to easily do it). > > Yes, rebasing is very uncommon in the bzr community. We would rather > evaluate the complete change than walk through its history. (Bundles > only show the changes you made, not the changes you merged from the > mainline.) > > In an earlier form, bundles contained a patch for every revision, and > people *hated* reading them. So there's definitely a cultural > difference there. Take for example "[PATCH 0/6] ref deletion and D/F conflict avoidance with packed-refs." http://thread.gmane.org/gmane.comp.version-control.git/28150/focus=28154 > This series cleans up the area that was affected by the recent > addition of "packed-refs". Christian Couder and Jeff King CC'ed > since they seem to be touching in the general vicinity of the > code these patches touch. > > [1/6] ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore. > [2/6] refs: minor restructuring of cached refs data. > [3/6] lock_ref_sha1(): do not sometimes error() and sometimes die(). > [4/6] lock_ref_sha1(): check D/F conflict with packed ref when creating. > [5/6] delete_ref(): delete packed ref > [6/6] git-branch: remove D/F check done by hand. > > I opted for removing from the packed-ref file when a ref that is > packed is deleted. Isn't it easier to review than "bundle", aka. mega-patch? -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html