> On Aug 20, 2015, at 4:24 PM, Jason Merrill <ja...@redhat.com> wrote: > > On 08/20/2015 04:22 PM, paul_kon...@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: > > https://sourceware.org/glibc/wiki/Committer%20checklist > > The git-specifics are the same for gdb. paul