This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A wrong commit


On Thu, Feb 16, 2012 at 7:04 AM, Thomas Schwinge
<thomas@codesourcery.com> wrote:
> 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.

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.

Comments?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]