[LLVMdev] git Status

[FlyLanguage]

>>> I'd also recommand "git pull --rebase" if the goal is to keep history
>>> linear. Note that this has to go with a big, fat, warning, telling the
>>> user that rebasing published history is bad. Rebase is a very good tool
>>> to work with private history, but as soon as you've pushed it to some
>>> place visible by other people, you should stop using it.
>>
>> This is enormously important - once submodule maintainers starts
>> rebasing, we're screwed.
>
> Why do we care about the development history of a patch?  Patches sent to mainline should be simple, small, and obvious.  Any conversion to git doesn't change this.

'When you rebase a branch, you are changing its history in a way that 
will cause problems for anyone who already has a copy of the branch in 
their repository and tries to pull updates from you.'

So I guess it all depends on how submodules (will they have their own 
maintainers?) are organized into the workflow.