FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 06-11-2010, 07:23 PM
Nicolas Pitre
 
Default Update of "Kernel/Dev/HowtoReviewPullRequests" by brad-figg

On Fri, 11 Jun 2010, Henrik Rydberg wrote:

> Nicolas Pitre wrote:
> > On Thu, 10 Jun 2010, Brad Figg wrote:
> >
> >> On 06/10/2010 12:00 PM, Tim Gardner wrote:
> >>> When I review a pull request it generally goes something like this:
> >>>
> >>> git fetch git://kernel.ubuntu.com/bradf/ubuntu-lucid-wiki lp666xxx
> >>> git log -p HEAD..FETCH_HEAD
> >>>
> >>> If I like what I see I either cherry-pick the chosen commits, or in
> >>> simple cases 'git reset --hard FETCH_HEAD', then push.
> >
> > I'd really recommend _not_ doing this. Using "git reset --hard" isn't
> > something you should be using lightly.
>
> Hello, I am really just a bystander regarding this, but as someone using git
> daily, perhaps a second voice might be of use, anyways.

Sure.

But just that people don't think I'm talking through my hat, I'm a
daily Git user as well as a Git developer.

> There is nothing wrong with using git reset --hard. In my experience, git forces
> you to know what you are doing, which IMHO is a good thing. Compared to the
> alternative, which could for instance be fuzzy merges, which puts your local
> tree somewhere in in limbo between the origin and what you would like it to be,
> using reset --hard gives you control. You know _exactly_ what sha1 applies to
> your tree.

But that's the problem. To use 'git reset --hard' you must know what
you're doing, which is best left to expert Git users and not something
you should expect the kind of people relying on a HowTo to do. Because
"git reset --hard" is bypassing a lot of safety measures which would
otherwise prevent you from unknowingly throwing commits away.

> In my mind, the "git pull" command was a mistake, since most contributors would
> ever only want to do "git fetch" follows by "git rebase", to avoid those weird
> merges.

There is "git pull --rebase" for that if you wish, which is smart enough
to find out the proper rebase boundaries in case you did a fetch more
than once.

I don't necessarily agree that "rebase" is always the good thing to do.
Sometimes it is but not always.


Nicolas

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-11-2010, 08:09 PM
Nicolas Pitre
 
Default Update of "Kernel/Dev/HowtoReviewPullRequests" by brad-figg

On Fri, 11 Jun 2010, Henrik Rydberg wrote:

> > I don't necessarily agree that "rebase" is always the good thing to do.
> > Sometimes it is but not always.
>
> For patch contributors, I would argue that a rebase from a feature branch or a
> merge of the feature branch from a clean master branch are your only options,
> wouldn't you say?

Yes. You should preferably develop your patches on top of a clean base,
and rebase it as you move along with progress happening on that base.
But some patchsets are large enough that it is sometimes best not to
rebase them so not to invalidate the testing that was done on them, as
rebasing is basically changing the testing conditions i.e. the
underlying base code.

> For a patch collector, merge is of course more appropriate.

Definitely. But in neither cases should "reset --hard" considered a
standard operation.


Nicolas

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 11:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org