[LLVMdev] git Status

[Mark Lacey]

>
> > I have to ask as well - is a linear history really desired? That seems
> > to be the intent of your instructions.
>
> It is a stated requirement of the project.
>

Thanks - I hadn't seen that stated explicitly. I understand the points you
and others make wrt rebase vs. merging - I've seen many of the arguments
before. I tend to rebase a lot since I tend to not be publishing and
collaborating on feature branches (so I don't have the merges from mainline
to feature branch, even if the feature branch stays around).

As for 'git pull' vs. 'git fetch / git merge' - since this advice really
seems aimed at beginners, you might want to suggest 'git pull --ff-only' or
perhaps even go as far as suggesting 'git config merge.ff only' to
absolutely enforce linear history (setting the latter would be problematic
of course for people who want to create feature branches and merge, etc.
prior to doing some final rebase and submitting patches).

Reverting is just as easy with linear history, I think.  Chris has
> stated her wants reviews to be a simple as possible and linear history
> gets us that.
>

Reverting using 'git revert' when you have a separate branch that is merged
in requires a single revert of the merge commit, rather than reverting the
individual commits that make up the feature.

I don't see how having branches increases complexity of reviews - as long as
the submitted patches are rebased on top of the mainline, you still have the
appearance of linear history from the reviewers POV, but maintain a separate
branch that can be committed.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110823/d927da77/attachment.html>