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: follow-up on tile architecture changes


> I went ahead and created a cmetcalf/tile_elf_h branch, following the
> instructions in http://sourceware.org/glibc/wiki/GlibcGit.  If that's
> structurally the kind of thing you were looking for, that would be good to
> know.

Yes, that's the right thing to do (assuming cmetcalf is your username on
sourceware).  Note that the git hooks disallow "non-fast-forward" pushes
even for private branches.  You can defeat that constraint by a removal and
re-addition:
	git push origin :cmetcalf/tile_elf_h
	git push origin cmetcalf/tile_elf_h

> But based on the recent exchange between you and Joseph Myers I suspect it
> may make as much sense for me to directly commit the Tile-specific changes
> to the core.  So I'll repost the series of changes; let me know if they are
> suitable for directly committing or whether you would like to commit them,
> and if so, whether I should create branches like the tile_elf_h branch for
> them.

It never hurts to publish a private branch.  Then someone like me or Joseph
who is ready to declare it kosher can just do a git merge (or tell you it's
OK to, knowing precisely what you'll be pushing to master).  I think it is
probably wise for someone like you who does not yet have a history of doing
direct commits to use the private branch method for a while first.  When
there is a track record of your private branches getting merged without
any fixups required, then we'll be more confident about telling you to
commit a change yourself after just seeing the patch.


Thanks,
Roland


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