A wrong commit

[Thomas Schwinge]

Hi!

On Thu, 16 Feb 2012 00:21:08 +0000 (UTC), "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Wed, 15 Feb 2012, Roland McGrath wrote:
> 
> > But AFAICT that commit is a no-op merge.
> > So there's nothing that really needs to be done.
> 
> And if people want to avoid merge commits, I suggest using "git pull 
> --rebase" instead of just "git pull" when merging in other people's 
> changes to a tree with local commits.

True about the mechanism, but do we have/want to set a policy there?

I for one quite like seeing which was the baseline a patch was developed
and tested on, which is obvious in the merge-master-before-push scenario,
but that information is lost if the patch is rebased onto master before
pushing (and possibly not even re-tested on that new baseline).  (Of
course, ideally, after merging the master, a patch should then be
re-tested before pushing.)  At this point, I think everyone has gotten
familiar enough with Git's distributed many-branches concept, and we need
not follow CVS' have-to-update-before-being-able-to-commit principle
anymore.


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120216/38443901/attachment.sig>