On Thu, Aug 7, 2014 at 10:28 AM, Chris Friesen chris.frie...@windriver.com
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
On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec openst...@nemebean.com
wrote:
You keep mentioning detached HEAD and reflog. I have never had to deal
with either when doing a
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
On Fri, Aug 8, 2014 at 3:03 AM, Chris Friesen chris.frie...@windriver.com
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,
On 8 August 2014 10:52, Yuriy Taraday yorik@gmail.com 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
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 you'd
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 openst...@nemebean.com wrote:
On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 6:20 PM, Ben
Ben Nemec openst...@nemebean.com 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
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
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
On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza sba...@redhat.com 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
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
On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com
wrote:
On 08/05/2014 10:51 AM, ZZelle wrote:
Hi,
I like
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 Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com 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
On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com 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
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com
wrote:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
On 08/06/2014 01:14 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com
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
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 zbit...@redhat.com 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
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 openst...@nemebean.com wrote:
On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com
wrote:
On 08/06/2014
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 how I'd
On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
Hello, git-review users!
snip
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 hacking
Le 05/08/2014 13:06, Ryan Brown a écrit :
On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
Hello, git-review users!
snip
0. create new local branch;
master: M--
\
feature: *
1. start hacking, doing small local meaningful (to you) commits;
master: M--
\
feature:
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 driven
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 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
On Tue, Aug 5, 2014 at 5:15 AM, Angus Salkeld angus.salk...@rackspace.com
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
On Tue, Aug 5, 2014 at 3:06 PM, Ryan Brown rybr...@redhat.com wrote:
On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
snip
+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
On Tue, Aug 5, 2014 at 5:27 PM, Sylvain Bauza sba...@redhat.com 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
On Tue, Aug 5, 2014 at 6:49 PM, Ryan Brown rybr...@redhat.com 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
On Tue, Aug 5, 2014 at 7:51 PM, ZZelle zze...@gmail.com 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?
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com 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
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com 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
On Aug 6, 2014 7:21 AM, Ben Nemec openst...@nemebean.com wrote:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com
wrote:
On 08/05/2014 10:51 AM, ZZelle wrote:
Hi,
I like the idea ... with complex change, it could useful
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 Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com
wrote:
On 08/05/2014 10:51 AM, ZZelle wrote:
Hi,
I like the idea ... with complex change, it
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 remembers
37 matches
Mail list logo
