On 16 September 2014 13:45, David Cheney wrote:
> On Tue, Sep 16, 2014 at 7:27 PM, roger peppe
> wrote:
>> On 16 September 2014 09:22, Jonathan Aquilina
>> wrote:
>>> If i am not mistaken if you have multiple commits in a branch git has
>>> something built in called git squash. This obviously
On Tue, Sep 16, 2014 at 7:27 PM, roger peppe wrote:
> On 16 September 2014 09:22, Jonathan Aquilina wrote:
>> If i am not mistaken if you have multiple commits in a branch git has
>> something built in called git squash. This obviously eliminates the 5 step
>> process into one merge and one push.
That is it indeed :)
---
Regards,
Jonathan Aquilina
Founder Eagle
Eye T
On 2014-09-16 11:58, Dimiter Naydenov wrote:
> -BEGIN PGP
SIGNED MESSAGE-
> Hash: SHA1
>
> On 16.09.2014 12:32, Jonathan
Aquilina wrote:
>
>> I dont think you have to rebase though. I think
you can squash mult
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.09.2014 12:32, Jonathan Aquilina wrote:
> I dont think you have to rebase though. I think you can squash
> multiple commits together.
>
You're probably thinking about git commit --amend -m "msg", which
folds the current changeset into the one b
I dont think you have to rebase though. I think you can squash
multiple commits together.
---
Regards,
Jonathan Aquilina
Founder
Eagle Eye T
On 2014-09-16 11:27, roger peppe wrote:
> On 16 September
2014 09:22, Jonathan Aquilina wrote:
>
>> If
i am not mistaken if you have multiple commit
On 16 September 2014 09:22, Jonathan Aquilina wrote:
> If i am not mistaken if you have multiple commits in a branch git has
> something built in called git squash. This obviously eliminates the 5 step
> process into one merge and one push.
I don't see that command. Are you thinking of the "squas
If i am not mistaken if you have multiple commits in a branch git
has something built in called git squash. This obviously eliminates the
5 step process into one merge and one push.
---
Regards,
Jonathan
Aquilina
Founder Eagle Eye T
On 2014-09-16 09:44, roger peppe wrote:
> On 15 September
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.09.2014 10:44, roger peppe wrote:
> As far as I can make out, as long as you want to propose your
> branch with only a single commit added to the log, this makes it
> easy to use a merge-based flow and amounts to the same thing in the
> end.
>
On 15 September 2014 21:39, Ian Booth wrote:
> On 16/09/14 00:50, Eric Snow wrote:
>> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wrote:
>>> Yeah, those steps are a lot, though keep in mind that effectively it's
>>> only 2 steps more than before if you use the -p flag to rbt post and
>>> were alre
On 16 September 2014 08:39, Ian Booth wrote:
>
>
> On 16/09/14 00:50, Eric Snow wrote:
>
>
> > Step (0) is also pretty easy and I'll argue that people should be
> > doing it anyway.
> >
>
> Disagree :-)
> I never (or very, very rarely) had to do this with Launchpad and bzr and
> things
> Just Wor
>
> FWIW, I have the following in $GOPATH/src/github.com/juju/juju/.git/config
> :
>
> [remote "origin"]
> url = g...@github.com:ericsnowcurrently/juju.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [remote "upstream"]
> url = https://github.com/juju/juju.git
>
Is there a setting to make reviewboard show the diff in a review by
the default ? For some reason for me it always requires me to hit the
'view diff' link.
On Tue, Sep 16, 2014 at 6:39 AM, Ian Booth wrote:
>
>
> On 16/09/14 00:50, Eric Snow wrote:
>> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wr
On 16/09/14 00:50, Eric Snow wrote:
> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wrote:
>> Yeah, those steps are a lot, though keep in mind that effectively it's
>> only 2 steps more than before if you use the -p flag to rbt post and
>> were already keeping your local master up to date.
>
> Jus
On Mon, Sep 15, 2014 at 12:54 PM, Dimiter Naydenov
wrote:
> - From my meager experience with writing git plugins (any executable in
> $PATH with "git-" prefix), what are you describing can be easily
> achieved. If you write a git plugin, named e.g. "git-rbpropose", using
> the GitHub CLI (https://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yeah, sorry I forgot the pastebin links to the scripts:
git-sync: http://paste.ubuntu.com/8352455/
git-propose: http://paste.ubuntu.com/8352460/
git config -l | grep alias: http://paste.ubuntu.com/8352470/
(useful aliases I use)
On 15.09.2014 21:54,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Eric,
On 15.09.2014 21:18, Eric Snow wrote:
> On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday
> wrote:
>> Let me preface this by saying I like the Reviewboard style of
>> reviewing changes.
>>
>> It's somewhat concerning to me that our rev
...
>
> There is the possibility of pushing info from ReviewBoard back to
> github (e.g. "ship-it" -> "LGTM" comment), but I don't think it buys
> us enough to make it worth it (it's notably trickier).
>
> -eric
>
> I would think it would be just as easy to change the bot to merge based on
comment
On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday
wrote:
> Let me preface this by saying I like the Reviewboard style of reviewing
> changes.
>
> It's somewhat concerning to me that our reviews are now disconnected from
> what will actually be landed into trunk. In Github, you were reviewing t
Let me preface this by saying I like the Reviewboard style of reviewing
changes.
It's somewhat concerning to me that our reviews are now disconnected from
what will actually be landed into trunk. In Github, you were reviewing the
actual diff which would be landed. In reviewboard, we're now reviewi
On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits wrote:
> It looks like the TRACKING_BRANCH option in .reviewboardrc could be helpful.
> It defaults to "origin/master" but if we changed it to "upstream/master" I
> suspect Reviewboard will then generate diffs against the shared master
> branch instead
Really, rbt pull -p is the only new step. All the rest of that is stuff
you should already be doing as a normal part of writing code and making
pull requests. I guess adding the link on the PR to the review is also a
new step. If you really want to count that as a step.
On Mon, Sep 15, 2014 at
On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wrote:
> Yeah, those steps are a lot, though keep in mind that effectively it's
> only 2 steps more than before if you use the -p flag to rbt post and
> were already keeping your local master up to date.
Just to be clear, here are the steps again, slight
On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits wrote:
> Eric,
>
> Thanks for setting this up.
>
> Firstly, in your email you mention "rbt pull" several times. I think you
> mean "rbt post" right? I don't see a pull command documented anywhere.
Correct. I meant "rbt post". :)
>
> I've run in to o
>
> ...
> As things stand the workflow actually needs to be:
>
> 1. Ensure your feature branch is rebased against upstream/master
>
Having this be step 1 seems like a serious put-off for using the tool. Does
it seriously not know how to calculate the merge ancestor? Git even
provides an explicit c
Eric,
Thanks for setting this up.
Firstly, in your email you mention "rbt pull" several times. I think you
mean "rbt post" right? I don't see a pull command documented anywhere.
I've run in to one issue so far. When I tried to get my first review in to
Reviewboard today it took me a long time to
On Sun, Sep 14, 2014 at 2:59 PM, Jesse Meek wrote:
> Thank you for setting this up. Is it possible to add 'unpublished' review
> comments such that you can add/remove/edit comments until you've completed a
> review, at which point you 'publish' all review comments, making them
> visible to the aut
Thank you for setting this up. Is it possible to add 'unpublished'
review comments such that you can add/remove/edit comments until you've
completed a review, at which point you 'publish' all review comments,
making them visible to the author?
On 14/09/14 14:45, Eric Snow wrote:
Hi all,
Star
Hi all,
Starting now new code review requests should be made on
http://reviews.vapour.ws (see more below on creating review requests).
We will continue to use github for everything else (pull requests,
merging, etc.). I've already posted some of the below information
elsewhere, but am repeating i
28 matches
Mail list logo
