[haiku-development] Re: Review & Pull request for Workspaces app

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 13 Dec 2011 17:20:45 +0100

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

Other related posts: