On 2011-12-13 at 03:59:26 [+0100], devine-mlist@xxxxxxxxxxx wrote: > On Tue, 13 Dec 2011 00:56:39 +0100, Ingo Weinhold wrote: > > I'd say creating a ticket with the reference to your branch is a good > > idea nonetheless. > > The trouble at the moment is that a branch may solve both bugs and > enhancements so I was not sure which to file that under. Perhaps there > should be a category for pull requests? It makes sense because then > conversation on what needs to be done to get the request accepted can be > tracked in Trac. The category doesn't matter all that much. If the changes also fix a bug, I'd consider marking the ticket "bug" appropriate. If the changes can be easily split (i.e. don't build on top of each other) multiple tickets aren't a bad idea either (provide respective patches or create branches in that caes). > > I suspect you'd like the whole branch [1] to be merged, right? Or is > > the reference to ec90b9219bb6 (the penultimate commit) intentional? > > Given that the latest commit (making getters non-const) seems > > counterproductive, I'd agree, though. > > I was intending for the whole branch to be merged. I actually also > intended to put the latest reference that I had done before I sent the > email but I screwed that up and it was one behind. > > Counter-productive? I had better go read up on const then. Adding to what Rene already wrote: Getter methods should virtually always be const, as they should not change the object (there are only rare useful exceptions). > > * Please clean up your commit messages to conform to the recommended > > format (cf. [2]). > Certainly. > > > * Please clean up the commits. > > I need to work out how to make Git do what I need... Can somebody link > to documentation on the appropriate workflow for achieving this? There are probably others, but the tools I use for such a purpose are "git rebase -i" (reorder, edit, squash commits), "git commit --amend" (change the last commit), "git reset" (pop commits), "git cherry-pick" (copy individual commits from another branch). The man pages for those can help. For finding more descriptive/explanatory sources, Google helps a lot (e.g. search "git rewrite history"). If you feel unsure messing with your repository in that way, clone it or at least copy the branch before you start, so you won't lose your work, if something goes terribly wrong. CU, Ingo