Approve branches? (pull requests)

[aaronjensen]

It seems barkeep is oriented around reviewing commits on a one by one basis. Perhaps this is just a different in commit size and atomicity, but in my experience it is easier to review multiple commits at once in sort of the pull request manner that github does it. In other words, reviewing an entire topic branch at once before it is merged back in rather than watching it one commit at a time and commenting on work in progress.

So I guess this is really a question, do you guys plan to support that? and do you have any additional thoughts as to why you would want to review 1 commit at a time? Has that been useful internally?

[edvinasbartkus]

Also commits could be group by the id number (#1234) that is being used often to reference the ticket in bug tracking application.

[aaronjensen]

I'm not sure how that would work @edvinabartkus, what if the commits are disjoint? How would you display a unified diff?

[cespare]

Hey Aaron -- this is definitely an interesting and useful idea. Internally, we do tend to review a single commit at a time (whether it is a bugfix, which we push directly into master, or some commit on a feature branch) and this has been fine. But I agree that viewing all the changes for a branch would be a useful feature.

I'm imagining this as a new kind of view that displays a list of commits (essentially a barkeep view for git log) and would allow for approving whole batches at once. We could also allow you to pull in individual diffs for each commits, or the total diff introduced by the matched commits (git log master..featureA vs. git diff master featureA) if these would be useful.

I'd be interested to hear what other Barkeep devs think about this as well.

[aaronjensen]

Not to dedicate this issue to discussing practices.... but how does that work for you guys? in our experience, during the course of a feature we change our minds, refactor things, etc. There would be a ton of waste if we reviewed every commit one by one as we rarely write it "right" the first time. It seems that this is similar to pairing in the amount of time and scrutiny, but without the actual benefits (preventing rework in real time)

[noahgibbs]

aaronjensen It's not bad, but I'm sure it could be improved upon. Also, often we do the commit-refactor-recommit thing where you commit locally, consolidate into fewer commits and then push them to the server.

[aaronjensen]

Sure, I squash/fixup/reorder as well, but I typically encourage fairly regular pushes of topic branches for backup and collaboration reasons. Another question, what was the motivation for writing barkeep? Do you not use github for your company's source control? Pull requests work pretty well, though I would love to have side by side diff.

[noahgibbs]

We use Git, but not GitHub. We wanted review and the other big option was Gerrit. We decided against Gerrit, for a variety of reasons.

[svenwin]

What about git log 123456-topic ^master? That would be our use case for barkeep.

[peterfarsinsen]

Are there any news on this?

We just went through this exact discussion at work, and it would be awesome to be able to compare a feature branch with the target branch before merging the feature feature in.

[cryos]

I am also interested in this feature, and wonder if there was any movement. We have been using a forked Gerrit with some support for topic branches but this looks unlikely to be merged upstream. I am now looking at alternatives, and first impressions of Barkeep's UI are very positive (although I am no Ruby coder, I am no Java expert either). I like the approach of a minimal, hackable code base, but most open source code review options seem to lack any decent level of support for topic branches.