Date: Tue, 21 Feb 2017 22:41:04 +0000 From: Grzegorz Junka <list1@gjunka.com> To: freebsd-git@freebsd.org Subject: Re: Reconsider switching from svn to git? Message-ID: <931513c8-3247-3664-3958-c352400d0736@gjunka.com> In-Reply-To: <CAPyFy2CKdHW_KkOOQozPW04jBDz8ZaNWSJLqFWAdzKcaDfSzcA@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> If, and this is a big if, we go to using git, I'd like to *STRONGLY* >> request that we not change the hashes we have on github today. There's >> lots of people with branches from that and changing the hashes would >> make them all useless. Well, not completely useless, but quite >> difficult to recover from unless the branches were simple without >> merges. > This is a very tricky issue. I agree that there's a(n incredibly) > large cost with changing existing hashes, and previously argued that > it was an absolute nonstarter. Also, I think this is independent of > switching to git as the source of truth: we have the same open issue > with the current svn2git mirror. > > That said, I also strongly believe that, as long as SVN is the "source > of truth" repo, the git conversion must be reproducible by third > parties. I believe developers and others who consume FreeBSD via git > must be able to validate that the data and metadata are consistent > between svn and git. Unfortunately today even the subversion mirrors > (svn.freebsd.org) have inconsistent metadata relative to > repo.freebsd.org, so it's not currently possible for end users to > validate the svn2git conversion. > > I've briefly discussed with uqs@ what it would entail to migrate to a > "fixed" view of the history, and believe it's possible to facilitate a > relatively painless migration. It could look roughly like: > > 1. Broadly announce the plan > 2. Make a new alias for current master (e.g. master-legacy) > 3. Start a new, reproducible conversion and push to a new master (master-ng) > 4. As new commits are made to SVN update both master-ng and master-legacy > 5. Provide guidance on migrating both rebase- and merge-based > workflows to master-ng > 6. Give notice of upcoming switch in what master points to > 7. Switch master from master-legacy to master-ng > 8. Stop updating master-legacy if/when it becomes infeasible to > continue doing so, or when it's no longer used > Grzegorz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?931513c8-3247-3664-3958-c352400d0736>