[arvados-dev] Brett's opinions on git workflow

[Tom Clegg]

One possibility on the "rebase" topic: create a 1234-feature-rebased
branch, rebase that from master, then push it. This avoids encouraging
any "pull -f" habits, and makes it explicit that you rebased. You can
then delete the original branch from remote, to make it less likely
someone will accidentally pull your old branch because they don't
notice your new one.

I agree with Peter that "merge master frequently" seems to cause less
trouble. Brett, have you tried "git log ^master branch" -- optionally
with --no-merges if you don't care how many times master was merged
into the branch?

I think at minimum we should expect "master is merged into the branch"
at review time. You're not really reviewing a branch so much as
reviewing [your best prediction of] what will happen when this branch
gets merged into master.

The main trouble I have with merging is that the above 2 items don't
play well together. Each time I rebase I have to re-resolve conflicts.
I heard a legend that some "rerere" tool can address this, but I
haven't looked further than that.

While we're on the topic, my wish list includes:

1. Write git commit messages that actually describe/explain the changes you made

2. Use git merge --no-ff when merging into master, and write "closes
#1234" in the comment so redmine shows the merge on the issue page.

Reason for 2: This helps me understand context for the merge's
immediate ancestors:

 Merge branch '2596-refactor-pipeline-create'

But if you fast-forward merge into master, you get what we have right
now. git log tells me the last few changes to "master" were:

* Merge branch 'master' of git.clinicalfuture.com:arvados
* Thumbnail behavior now conforms to original story
* Added documentation to a few methods

At least I get the clue "thumbnail", but the issue# or feature branch
name is nowhere to be found.