<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 31, 2016, 21:13 George Barrett <bob@bob131.so> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Nov 01, 2016 at 12:03:44AM +0500, Alexandr Akulich wrote:<br class="gmail_msg">
> I can not agree. You can fit a trivial change into an individual patch, but<br class="gmail_msg">
> it would be more clear and easier to review a branch with an implementation<br class="gmail_msg">
> of a new feature, rather than a single patch for that.<br class="gmail_msg">
> It is better when you *can* propose a commits series, than when you're<br class="gmail_msg">
> limited by a patch. (I would like to say "hello" to reviewboard here).<br class="gmail_msg">
<br class="gmail_msg">
Well, no-one said anything about a /single/ patch either. As I'm sure you<br class="gmail_msg">
know, Bugzilla has no issue with attaching a set of patches to a bug. Feature<br class="gmail_msg">
branches that are justifiably more than a handful of patches are quite the<br class="gmail_msg">
edge case, but git has support for this baked-in with git-bz anyway.</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> There is no problem to rebase your own branch and clear it before merging.<br class="gmail_msg">
<br class="gmail_msg">
Well, except for it being a pain. Requiring a branch-in-review to be based on<br class="gmail_msg">
the upstream tip before merge sounds like it just adds an extra round-trip<br class="gmail_msg">
between reviewer and contributor.<br class="gmail_msg"></blockquote></div><div><br></div><div>Not really, especially if you are the sole owner of a feature branch. GitHub handles it very well, too. And if the workflow (ie. the CONTRIBUTING file) clearly states you must rebase, then core devs can instantly reject a patch that hasn’t been rebased.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> We didn't said any word about pull request.<br class="gmail_msg">
<br class="gmail_msg">
I'm afraid I don't understand how GitHub's issues system is applicable to code<br class="gmail_msg">
contributions, then.<br class="gmail_msg">
<br class="gmail_msg">
> Oh, indeed? Let's start with any random feature. Can BZ expand a diff to<br class="gmail_msg">
> show you a ten more lines of code before the change?<br class="gmail_msg">
<br class="gmail_msg">
No, but that's hardly "any random feature". I'm not trying to say that BZ's<br class="gmail_msg">
features are a superset of GitHub's, because that just isn't true. Nor is it<br class="gmail_msg">
the case that GitHub's features are a superset of BZ's.<br class="gmail_msg">
<br class="gmail_msg">
> >  * There's no big "MERGE NOW" button to be tempted by mid-review (I'm<br class="gmail_msg">
> >    guilty of this)<br class="gmail_msg">
><br class="gmail_msg">
> It is not a problem of github. You should be able to resist from clicking<br class="gmail_msg">
> on buttons. :)<br class="gmail_msg">
<br class="gmail_msg">
Perhaps, but I don't think code review UI should be steering a reviewer into<br class="gmail_msg">
accepting code. You're probably right, though, the more I think about it the<br class="gmail_msg">
more it seems like a non-issue; the Telepathy committers aren't me ;)<br class="gmail_msg"></blockquote></div><div><br></div><div>Then let’s set up code review rules. You can’t press the Big Tempting Button of Merge until at least two people (and perhaps the CI) said it’s OK. It can be done in GitHub for a few months now.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> >  * Poor commit messages are understood as valid grounds to reject a<br class="gmail_msg">
> >    patch<br class="gmail_msg">
><br class="gmail_msg">
> It is equally a valid point to reject a commit.<br class="gmail_msg">
><br class="gmail_msg">
> > * editing a patch is easier than rewriting branch history<br class="gmail_msg">
><br class="gmail_msg">
> No. Rewriting a branch is easier, if you use a proper tool (git rebase<br class="gmail_msg">
> --interactive; git add --patch at the very least).<br class="gmail_msg">
<br class="gmail_msg">
I meant that in the context of rewriting commit messages: You can change the<br class="gmail_msg">
commit message without leaving the browser, you just edit the text. I think<br class="gmail_msg">
people would be much less frustrated over commit message nitpicking if<br class="gmail_msg">
rebase-then-push weren't involved; even more so since such nitpicking is part<br class="gmail_msg">
of established convention on BZs.<br class="gmail_msg">
<br class="gmail_msg">
Something else you lose with branches over patches is patch history. I seem to<br class="gmail_msg">
recall hunk comments being clobbered by force pushes.<br class="gmail_msg"></blockquote></div><div><br></div><div>I can’t argue with that, it must become a part of the individual developers’ work. I personally have a pretty good workflow for this, but I must admit it can be tedious sometimes.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> >  * There's no argument over git merge vs git rebase, over a commit log<br class="gmail_msg">
> >    full of merge commits or rewriting history<br class="gmail_msg">
><br class="gmail_msg">
> In Telepathy we have a very reasonable merge/rebase convension for years.<br class="gmail_msg">
<br class="gmail_msg">
Allow me to reword: There's no reason for someone to uselessly open a bug<br class="gmail_msg">
linking a blogger's opinion on merge vs rebase ;)<br class="gmail_msg">
<br class="gmail_msg">
> You're actually comparing a really bad github workflow vs an ideal BZ<br class="gmail_msg">
> workflow.<br class="gmail_msg">
<br class="gmail_msg">
My aim was more to compare the sort of workflow each tool seems to promote,<br class="gmail_msg">
but it's true that I've never been exposed to discussion over the ideal GitHub<br class="gmail_msg">
workflow. But it remains the case that I'm much more likely to submit code to<br class="gmail_msg">
a BZ than to open a pull request on GitHub; I'm sure I'm not alone, but I<br class="gmail_msg">
guess the question is whether I'm in the minority ;)<br class="gmail_msg"></blockquote></div><div><br></div><div>I think we all should forget about ideal BZ/GH/whatever workflows, and concentrate on what the ideal Tp workflow is. I just went through a year of discussions on the same topic (with different systems) that could have been skipped if the devs would have told what they really wanted.</div><div><br></div><div>Again, I’m sorry for getting into this argument without a name in the community. But I have seen where such transitions and arguments can go, and it can do pretty big damage to any product, and I aim to use Tp 1.0 in the future :)</div><div><br></div><div>Best,</div><div>Gergely</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div>