On Wed, Aug 10, 2011 at 2:53 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: >>> Then when I pull to push to the repository, then without rebasing on >>> my end I will not get a linear history. >> this is the key point linear history make is lose the information on which >> commit the code was bsed and tested before the merge. So for bisect point of >> view it's not good > > An objection I have to patches is that they do not contain any information > about which commit they were tested against. > > git pull w/merge preserves that information. It is possible to make a > linear history > later on if required. > All patches should be tested on the latest upstream before merge, shouldn't it? If we follow this rule, we can keep the linear history and know the patch has been tested just on the HEAD before it's committed. The commit they were tested against when they were being developed is not so important then. The developer, who develops the patches, might still want to remember that commit to debug bugs in his patches found later, but others can always make sure those patches have been tested on the HEAD when they are committed.
For example, one developer has a branch which was branched off from upstream one month ago and asks for merging the branch to the upstream. But during the past month, something might have changed in upstream, which would cause break after merging his branch into the upstream. Tested against a one-month old commit does not guarantee that it should work as expected after merge. The developer surely should rebase his branch to the current HEAD of master to resolve any issues and do a testing to make sure his branch works as correctly on the current HEAD before ask for a pull to merge. I would like a clean, atomic, linear history in the upstream. Regards, Jie _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
