This is the mail archive of the
mailing list for the glibc project.
Re: A wrong commit
On Thu, Feb 16, 2012 at 7:04 AM, Thomas Schwinge
> On Thu, 16 Feb 2012 00:21:08 +0000 (UTC), "Joseph S. Myers" <firstname.lastname@example.org> 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
That's a good point. I've already mentioned that I don't care about
the mege-master-before-push commits. However, the more developers you
have the more these messages clutter the log view.
I don't have a strong opinion.