This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: <Paul_Koning at Dell dot com>
- To: <jason at redhat dot com>
- Cc: <law at redhat dot com>, <gcc at gnu dot org>
- Date: Thu, 20 Aug 2015 20:34:06 +0000
- Subject: Re: Moving to git
- Authentication-results: sourceware.org; auth=none
- References: <55D61512 dot 8010002 at redhat dot com> <55D61B23 dot 3000309 at redhat dot com> <55D63403 dot 4000603 at redhat dot com> <4A73B17F-0BE7-4576-83FC-ECD212CB2691 at dell dot com> <55D63764 dot 8030300 at redhat dot com>
> On Aug 20, 2015, at 4:24 PM, Jason Merrill <firstname.lastname@example.org> wrote:
> On 08/20/2015 04:22 PM, Paul_Koning@dell.com wrote:
>> Let's make sure the procedures that people are supposed to follow are clearly documented. I recently went looking for the equivalent in the binutils/gdb project and it doesn't seem to be written down there, though if you ask enough questions on the mailing list you do get some answers.
> Do you have pointers to relevant email threads?
It was in a private email exchange. Here's what I wrote and the reply I received:
>> I used to know the GDB workflow back in the CVS days, but GIT is of course very different. Iâm not particularly fluent with GIT. Some of the projects in our company that Iâm starting to get involved with use it. Iâve seen their procedures documents and they mention that GIT supports an amazing variety of work flows with very different visible outcomes. For example, it seems to make a lot of difference whether you allow branching thatâs natural to GIT development to remain visible in the history, or rebase (I think thatâs the right term) everything before itâs pushed to create the appearance of a single stream of history.
>> I gather GDB is one of those single linear history projects, but I havenât yet found any documents that describe the GDB development procedures as far as GIT is concerned. Can you point to some?
> Yeah, gdb's git workflow is similar to the CVS days. We rebase patches on top of master
> to maintain a linear history. That is, only fast-forward merges are accepted.
> Don't worry, if you get this wrong and try to push a non-linear merge, the server
> will reject it with an error. At which point you just pull/fetch upstream again,
> rebase your patch, and push again.
> I'm afraid I'm not aware of any GDB-specific docs for that. Though, glibc
> follows a similar model and they do have a guide. See:
> The git-specifics are the same for gdb.