Date: Tue, 21 Feb 2017 19:46:09 -0500 From: Ed Maste <emaste@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org> Subject: Re: Reconsider switching from svn to git? Message-ID: <CAPyFy2BeS5uRC4KUzNizNuALj%2BY3AYuVcirKjbcD_FJn0CfQ-w@mail.gmail.com> In-Reply-To: <CANCZdfqxydVvcJMqLPfbok9gOjdWjOGrAzN0_mrc-3r7j60ipA@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> <CANCZdfqxydVvcJMqLPfbok9gOjdWjOGrAzN0_mrc-3r7j60ipA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 February 2017 at 18:47, Warner Losh <imp@bsdimp.com> wrote: > > For small commits, I agree. For longer lived project branches, > however, there can be issues. Specifically, in svn, when you delete a > branch, it just marks it as empty, but you can get back to it at any > point in the branch. In git, however, deleting a branch deletes the > meta-data needed to get back to the branch (as does rebasing). We'd > need some way to administratively prohibit this, perhaps, for the > source of truth repo. I have no clue if this is possible with git, > just putting it out there. Ok, we could easily disallow any destructive activity on a source-of-truth git repo, including force (non-fast-forward) pushes and branch deletion. > There's also a number of advantages / disadvantages to merging vs > rebasing + fast-foward to pushing changes upstream. I'm curious what > people are thinking here. For relatively short-lived work-in-progress branches that are destined for upstream FreeBSD I prefer the rebase model, where changes are regularly rebased on HEAD. It might be more work in aggregate, and might occasionally require repeating some portions of work. But I like having a set of changes as a logical sequence ready to apply to head. I hope others who maintain long-lived divergent branches not destined for upstream FreeBSD can weigh in on their experiences. > As one of the users that would be affected by hash changes, I'm > finding that argument less persuasive given the pain I know it will > cause. Note that I'm explicitly advocating for us to keep the old hashes as long as is practical, avoiding any imposed pain on a "flag day." > If there were tools to help migrate, that would be useful. But I'm > unsure what those might be since many of git's most powerful features > don't work when you don't have a proper shared ancestor that's recent. I'm not sure what tooling exists today to support this, but if it doesn't exist today it's conceptually easy to write. We'd have a 1:1 correspondence between hashes in the "legacy" and "ng" sets, and so it will be possible to perform an automatic migration without any human intervention. This assumes the data is identical in the "legacy" and "ng" git history, but if it's not we have larger problems. > As for switching source of truth, what's the thinking on $FreeBSD$ and > the currently nice property of it that it includes the branch / > release in the path. Good question! IMO it's premature to worry about the issues inherent in switching the source of truth (as it's currently not on the table). Personally, I'd prefer that we lose $FreeBSD$ altogether. For the way I interact with FreeBSD it causes grief more than solves any problem I have. > Anyway, don't take concerns I have for opposition to a switch, just > nerves that need to be quelled a bit first :) Not at all, this is one of the reasons I wanted to migrate this discussion to the freebsd-git list. It's something that can't be undertaken lightly. Any change needs to be planned, tested, and deployed with ample advance notice and opportunity for discussion beforehand.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2BeS5uRC4KUzNizNuALj%2BY3AYuVcirKjbcD_FJn0CfQ-w>