On 8 August 2014 10:52, Yuriy Taraday wrote:
> I don't dislike rebases because I sometimes use a bit longer version of it.
> I would be glad to avoid them because they destroy history that can help me
> later.
rebase doesn't destroy any history. gc destroys history.
See git reflog - you can rec
On Fri, Aug 8, 2014 at 3:03 AM, Chris Friesen
wrote:
> On 08/07/2014 04:52 PM, Yuriy Taraday wrote:
>
> I hope you don't think that this thread was about rebases vs merges.
>> It's about keeping track of your changes without impact on review process.
>>
>
> But if you rebase, what is stopping yo
On 08/07/2014 04:52 PM, Yuriy Taraday wrote:
I hope you don't think that this thread was about rebases vs merges.
It's about keeping track of your changes without impact on review process.
But if you rebase, what is stopping you from keeping whatever private
history you want and then rebase t
On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec wrote:
> On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec
> wrote:
> >> You keep mentioning detached HEAD and reflog. I have never had to deal
> >> with either when doing a rebase, so I think there's a disconne
On Thu, Aug 7, 2014 at 10:28 AM, Chris Friesen
wrote:
> On 08/06/2014 05:41 PM, Zane Bitter wrote:
>
>> On 06/08/14 18:12, Yuriy Taraday wrote:
>>>
>>> Well, as per Git author, that's how you should do with not-CVS. You have
>>> cheap merges - use them instead of erasing parts of history.
>>>
>>
On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
> Oh, looks like we got a bit of a race condition in messages. I hope you
> don't mind.
>
>
> On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec wrote:
>
>> On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
>>> On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec
>> wrote:
On 08/06/2014 05:41 PM, Zane Bitter wrote:
On 06/08/14 18:12, Yuriy Taraday wrote:
2. since hacking takes tremendous amount of time (you're doing a Cool
>>Feature (tm), nothing less) you need to update some code from
master, so
>>you're just merging master in to your branch (i.e. using Git as yo
On 06/08/14 18:12, Yuriy Taraday wrote:
2. since hacking takes tremendous amount of time (you're doing a Cool
>>Feature (tm), nothing less) you need to update some code from master, so
>>you're just merging master in to your branch (i.e. using Git as you'd
>>use it normally);
>>
>
>This is not h
Oh, looks like we got a bit of a race condition in messages. I hope you
don't mind.
On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec wrote:
> On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec
> wrote:
> >
> >> On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
> >>
I'll start using pictures now, so let's assume M is the latest commit on
the master.
On Wed, Aug 6, 2014 at 9:31 PM, Zane Bitter wrote:
> On 04/08/14 19:18, Yuriy Taraday wrote:
>
>> Hello, git-review users!
>>
>> I'd like to gather feedback on a feature I want to implement that might
>> turn ou
On 08/06/2014 01:14 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec mailto:openst...@nemebean.com>> wrote:
Again, this is why the tests should pass against all of your commits.
If that's the case, you can verify your changes as you rebase before you
update the c
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec wrote:
> On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec
> wrote:
> >
> >> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> >>> On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
> >> wrote:
> >>>
> On 08/05/2014 10
On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
> On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec wrote:
>
>> On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
>>> I'd like to stress this to everyone: I DO NOT propose squashing together
>>> commits that should belong to separate change requests. I DO NOT propo
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec wrote:
> On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
> > I'd like to stress this to everyone: I DO NOT propose squashing together
> > commits that should belong to separate change requests. I DO NOT propose
> to
> > upload all your changes at once. I DO
On 04/08/14 19:18, Yuriy Taraday wrote:
Hello, git-review users!
I'd like to gather feedback on a feature I want to implement that might
turn out useful for you.
I like using Git for development. It allows me to keep track of current
development process, it remembers everything I ever did with
On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
> On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec wrote:
>
>> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
>>> On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
>> wrote:
>>>
On 08/05/2014 10:51 AM, ZZelle wrote:
> Hi,
>
>
> I like the idea .
On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
> I'd like to stress this to everyone: I DO NOT propose squashing together
> commits that should belong to separate change requests. I DO NOT propose to
> upload all your changes at once. I DO propose letting developers to keep
> local history of all ite
On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza wrote:
>
> Le 06/08/2014 10:35, Yuriy Taraday a écrit :
>
> I'd like to stress this to everyone: I DO NOT propose squashing together
>> commits that should belong to separate change requests. I DO NOT propose to
>> upload all your changes at once. I
Le 06/08/2014 10:35, Yuriy Taraday a écrit :
I'd like to stress this to everyone: I DO NOT propose squashing
together commits that should belong to separate change requests. I DO
NOT propose to upload all your changes at once. I DO propose letting
developers to keep local history of all iterat
I'd like to stress this to everyone: I DO NOT propose squashing together
commits that should belong to separate change requests. I DO NOT propose to
upload all your changes at once. I DO propose letting developers to keep
local history of all iterations they have with a change request. The
history
Ben Nemec writes:
> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
>>
>> When you're developing some big change you'll end up with trying
>> dozens of different approaches and make thousands of mistakes. For
>> reviewers this is just unnecessary noise (commit title "Scratch my
>> last CR, that was
On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec wrote:
> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> > On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
> wrote:
> >
> >> On 08/05/2014 10:51 AM, ZZelle wrote:
> >>> Hi,
> >>>
> >>>
> >>> I like the idea ... with complex change, it could useful for the
> >
>What I really hate is having to throw away my (local, precious for me)
history for all change requests because I need to upload a change to Gerrit.
+1
>3. and now you get the first version that deserves to be seen by
community, so you run 'git review', it asks you for desired commit message,
and
On Aug 6, 2014 7:21 AM, "Ben Nemec" wrote:
>
> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> > On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
wrote:
> >
> >> On 08/05/2014 10:51 AM, ZZelle wrote:
> >>> Hi,
> >>>
> >>>
> >>> I like the idea ... with complex change, it could useful for the
> >>> unde
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec wrote:
>
>> On 08/05/2014 10:51 AM, ZZelle wrote:
>>> Hi,
>>>
>>>
>>> I like the idea ... with complex change, it could useful for the
>>> understanding to split it into smaller changes during development.
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec wrote:
> On 08/05/2014 10:51 AM, ZZelle wrote:
> > Hi,
> >
> >
> > I like the idea ... with complex change, it could useful for the
> > understanding to split it into smaller changes during development.
>
> I don't understand this. If it's a complex ch
On Tue, Aug 5, 2014 at 7:51 PM, ZZelle wrote:
> Hi,
>
>
> I like the idea ... with complex change, it could useful for the
> understanding to split it into smaller changes during development.
>
>
> Do we need to expose such feature under git review? we could define a new
> subcommand? git review
On Tue, Aug 5, 2014 at 6:49 PM, Ryan Brown wrote:
> On 08/05/2014 09:27 AM, Sylvain Bauza wrote:
> >
> > Le 05/08/2014 13:06, Ryan Brown a écrit :
> > -1 to this as git-review default behaviour. Ideally, branches should be
> > identical in between Gerrit and local Git.
>
> Probably not as default
On Tue, Aug 5, 2014 at 5:27 PM, Sylvain Bauza wrote:
>
> -1 to this as git-review default behaviour.
I don't suggest to make it the default behavior. As I wrote there will
definitely be a config option that would turn it on.
> Ideally, branches should be identical in between Gerrit and local G
On Tue, Aug 5, 2014 at 3:06 PM, Ryan Brown wrote:
>
> On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
> >
>
> +1, this is definitely a feature I'd want to see.
>
> Currently I run two branches "bug/LPBUG#-local" and "bug/LPBUG#" where
> the local is my full history of the change and the other branc
On Tue, Aug 5, 2014 at 5:15 AM, Angus Salkeld
wrote:
> On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote:
> > Hello, git-review users!
> >
> >
> > I'd like to gather feedback on a feature I want to implement that
> > might turn out useful for you.
> >
> >
> > I like using Git for development
On 08/05/2014 10:51 AM, ZZelle wrote:
> Hi,
>
>
> I like the idea ... with complex change, it could useful for the
> understanding to split it into smaller changes during development.
I don't understand this. If it's a complex change that you need
multiple commits to keep track of locally, why
Hi,
I like the idea ... with complex change, it could useful for the
understanding to split it into smaller changes during development.
Do we need to expose such feature under git review? we could define a new
subcommand? git reviewflow?
Cédric,
ZZelle@IRC
On Tue, Aug 5, 2014 at 4:49 PM,
On 08/05/2014 09:27 AM, Sylvain Bauza wrote:
>
> Le 05/08/2014 13:06, Ryan Brown a écrit :
> -1 to this as git-review default behaviour. Ideally, branches should be
> identical in between Gerrit and local Git.
Probably not as default behaviour (people who don't want that workflow
would be drive
Le 05/08/2014 13:06, Ryan Brown a écrit :
On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
Hello, git-review users!
all changes from your branch is
uploaded to Gerrit as _one_ change request;
master: M---N-O-...
\\\E* <= uploaded
feature: A-B-...-C-D-...-E
+1, this
On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
> Hello, git-review users!
>
> 0. create new local branch;
>
> master: M--
> \
> feature: *
>
> 1. start hacking, doing small local meaningful (to you) commits;
>
> master: M--
> \
> feature: A-B-...-C
>
> 2. since hac
On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote:
> Hello, git-review users!
>
>
> I'd like to gather feedback on a feature I want to implement that
> might turn out useful for you.
>
>
> I like using Git for development. It allows me to keep track of
> current development process, it rem
Hello, git-review users!
I'd like to gather feedback on a feature I want to implement that might
turn out useful for you.
I like using Git for development. It allows me to keep track of current
development process, it remembers everything I ever did with the code (and
more).
I also really like us
38 matches
Mail list logo
