Elijah Newren <newren@xxxxxxxxx> writes:
>> + go smoothly or have merge conflicts depending on the case. A pull
>> + does not allow you to review any changes made upstream but rather
>> + merge those changes on their own.
>
> I don't understand this last sentence. You can definitely review
> changes made upstream after a pull; e.g. git log @{u}@{1}..@{u}
>
>> ++
>> +This is the reason why it is sometimes advised to fetch the changes
>> +first and then merge them accordingly because not every change might
>> +be of utility to the user.
>
> I don't understand the purpose of this paragraph.
Readers who need to resort to a FAQ will be at loss when told "it is
sometimes advised to...", as they do not know enough to judge if the
advice applies to their situation themselves.
Don't we have a workflow document? Not the one that documents the
workflow I use to maintain this project, but outlines various ways
different projects work, describing centralized, triangular, merging
and rebasing, etc.? I do not think this single entry belongs to a
FAQ list that gives simple answers to common questions without
people having to think. Similar to the "merge or rebase?" question
(not part of this series), it belongs to "workflow guide", "concepts
manual", and "tutorial" kind of document, I would think.
