Date: Sat, 25 Feb 2017 01:32:53 -0800 From: Alfred Perlstein <bright@mu.org> To: freebsd-git@freebsd.org Subject: Re: Reconsider switching from svn to git? Message-ID: <b4e30297-47a2-d6a3-75b7-ec810f44e251@mu.org> In-Reply-To: <931513c8-3247-3664-3958-c352400d0736@gjunka.com> References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> <CANCZdfpA-odwrpd=ya2NmjesDxZr1rcUhv%2BnaVWicpq7U_KT2w@mail.gmail.com> <CAPyFy2CKdHW_KkOOQozPW04jBDz8ZaNWSJLqFWAdzKcaDfSzcA@mail.gmail.com> <931513c8-3247-3664-3958-c352400d0736@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4e30297-47a2-d6a3-75b7-ec810f44e251>