Reconsider switching from svn to git?

[Alfred Perlstein]

On 2/21/17 2:41 PM, Grzegorz Junka wrote:
> I am not the recipients of these questions but would like to add some 
> comments.
>
> On 21/02/2017 20:22, Ed Maste wrote:
>> On a different (non-public) list we've been discussing git in FreeBSD,
>> and I wanted to discuss one of Warner's points further. Before asking
>> I asked for approval to quote the message here.
>>
>> On 21 February 2017 at 11:36, Warner Losh <imp at bsdimp.com> wrote:
>>> However, there's one big drawback we don't have with svn: it destroys
>>> history. Rebasing branches destroys history, as does deleting
>>> branches. In svn, you can always get that information back, but not so
>>> with git. It's very easy to do these operations and quite difficult to
>>> undo them.
>> I'd like to understand this better. In my opinion, in general
>> commit(s) should stand alone -- any metadata associated with the
>> commit (PR numbers, review links, etc.) should be in the commit
>> message itself. The fact that they were originally done on a branch
>> should only be an "implementation detail." So I agree rebasing and
>> committing loses that history, but think in general it should not
>> matter.
>>
>
> Rebasing doesn't destroy history, just rewrites them. It creates as 
> many commits as the original branch, but they are applied on top of 
> the changed branch, so may differ from the original commits depending 
> on what changes were in the original branch. However, this shouldn't 
> matter since rebasing should NOT be used with branches that are public 
> (were pushed to the remote server). That's precisely because rebase 
> rewrites commits - if someone rebased 5 last commits in a branch which 
> someone else already pulled, when merging these 5 commits back 
> together there will be conflicts because the rebased commits don't 
> match the original ones.
>
> So, any public branches should be merged rather than rebased, and 
> merge preserves all history, including the previous and next commits 
> in the chain of changes. In order to reduce amount of commits it's 
> also a good practice to squash the commits before merging. For 
> example, someone works on a feature in a separate branch, then instead 
> of merging that branch to the integration branch directly they create 
> a squashed commit that contains all changes from that separate branch.

Yes!

-Alfred