[Ubuntu Wiki] Update of "Kernel/Dev/HowtoReviewPullRequests" by brad-figg

[Henrik Rydberg]

> 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.

Ah, then excuse my ignorance.

>> 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.

I see. But using a merge might still be wrong in that context, for said reasons.
Learning "git reflog" might not help there either, although that feature could
do with a bit more exposure.

>> 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.

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? For a patch collector, merge is of course more appropriate.

Anyways, sorry for the interruption.

Henrik