Update of "Kernel/Dev/HowtoReviewPullRequests" by brad-figg
> 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
> 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.
kernel-team mailing list