Reconsider switching from svn to git?
bright at mu.org
Sat Feb 25 09:32:53 UTC 2017
On 2/21/17 2:41 PM, Grzegorz Junka wrote:
> I am not the recipients of these questions but would like to add some
> 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
> 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.
More information about the freebsd-git