From owner-freebsd-git@freebsd.org Tue Feb 21 20:23:14 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A31E8CE831D for ; Tue, 21 Feb 2017 20:23:14 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CDB7201; Tue, 21 Feb 2017 20:23:14 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x235.google.com with SMTP id k200so36074661itb.1; Tue, 21 Feb 2017 12:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=2cYbRkU6q1aVvqoaQkZjZuI/7xHjpU83A+outN4MNpg=; b=LUlfZ3emZcXI7Uy6VYqIrLNntBbBNkaejatQzFVxOG09Wfnp+vJ7n08xEOsGIIBZM3 DfgwXRn+N5aqo+I5tmJ3z9NioB9uFfB/wT4gI1wgS5jdiPcshhJL1/cqATVyVjUFjmCp EZS1+7OD5iWHXMTqPruhozhvMYWlTSoJh/BOsKRoIKQBZ4P5lpLJWSrMEr1xJYDymur9 NTvN0XtyeyaaXBnp4mgfPqRHpwjGgkJsUQ4A3XTEGjXUReCcpVuZG1rykt0b8A9lmSDf QDZ8HPSO7CjB2Esx769c6CDhxCGFbdkzslchYYqisr0xdVMg1EK7bqU+mcQIKSsNuAI7 0cwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=2cYbRkU6q1aVvqoaQkZjZuI/7xHjpU83A+outN4MNpg=; b=ib2hrvJSUfqrP/kD3GlUEvAGxtMeLf1Lk/OxQqn9mv+P15c9i8Od4GJJS3eZvy3IoP pF73of1WGrP8yJd7L7j5OvoLkzUnF/5kL6CMj/nMwfxPrYg5GbrG+nHytr4gRAbSpulH gaxGc9GRQWquYfdpRyMvykpzgmtR1G+K6ku7JZ2x2B9XzSB/cbCL2GTaHitelDXspFfn bauCZnr5n4jfyRUVWt1hU9T84X5IUzpA01YxWP2wj3pHKkMFSU7Jgykpl037JBoJdOB6 pfv5dqxIeu3xW9hoVknIAn+Sw8bxUa/JObtBzerxEgB64BoQfLZ5AVp0twWpGcSykhtG z82w== X-Gm-Message-State: AMke39l4dW6PaPuP2RYCT7cx8gFchRuu/zY46ntRN/XrycaHOWZeaL/WrcdLsVBqAYClnwD+584qmFH0NewsVw== X-Received: by 10.36.3.73 with SMTP id e70mr15192700ite.14.1487708593846; Tue, 21 Feb 2017 12:23:13 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.17 with HTTP; Tue, 21 Feb 2017 12:22:53 -0800 (PST) In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Ed Maste Date: Tue, 21 Feb 2017 15:22:53 -0500 X-Google-Sender-Auth: MrYaMQp8FNPzkm8cCoyRVeRX3AY Message-ID: Subject: Re: Reconsider switching from svn to git? To: Warner Losh , freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:23:14 -0000 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 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. > 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 From owner-freebsd-git@freebsd.org Tue Feb 21 23:47:57 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFD27CE865F for ; Tue, 21 Feb 2017 23:47:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 915101E0E for ; Tue, 21 Feb 2017 23:47:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id l66so33415160ioi.1 for ; Tue, 21 Feb 2017 15:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XNqiQzoInTVBj+HNNDNc7HIOWVPd9XdAtxTTtbbZzVA=; b=Takvo8fw4sRDPQP4q467nia3yncdXF3YHoiYfTLif3txllog8dtT2QvUT/p0pErJD2 8FfUdMOKByfJpR2EklLhUflzWpOnWe6C77+jQpOj/M+N+d+T8ZnU3AaowvdVZdKKxK+c OYrW8AQnoWh3MWtXj9lwyt51EL2WyQaFrZit1r3XXFJaiB1KWnKYaCOM3s/MgJRpTujP cFUqOBLWQ1tt65hHSsYwWMr4D4ZpAppPrsYgHEj/TZ265wPKET9rLD/Uj3UF46zZOZE+ E2jFztgwEmfP+ryiWTMMPmt1D0U/aZfv1bFTupWOyuSbX2Ehq2mz5Tr4PF+YnCYPQN9E kNww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XNqiQzoInTVBj+HNNDNc7HIOWVPd9XdAtxTTtbbZzVA=; b=a1HKxg52OoIGmv5DHHemW1/1lREToKVG2/BbMbiDtARraqmCLugmzhvkGzN4Ef80ac KrYZWR9gpJRalP8azkYj+uwycJvlwqmofrSUPVUBgPCI6+W6245ZMwVlF28142fiiFBe 7ok0J9Lku50Fw/8WtUzy9A4gI73bEocyclCJbeyTCelbL243ddSWKt+0iJ5dmswdos1H 5XrySzvgH3K09psFhbZiAy7GkDR43bQQ211/rbWqlTG+2M2bqUbF0FQjMg3eTTDT00ZD 9HpGbY5dYIHlQwvDN3RCL/UzRlx1XuhvLRpbQ0paSRulD+axrozkLt/+VjhKAKgFsUm7 axWw== X-Gm-Message-State: AMke39ncPfh/q9lVaMYxBEbHBpCCoKsYXUCbmSuiYtJFchAEr36KBZ6P8bGCacNQ6tUWqIRYwcLYyzjatn3kQA== X-Received: by 10.107.198.195 with SMTP id w186mr21916135iof.19.1487720876618; Tue, 21 Feb 2017 15:47:56 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.132 with HTTP; Tue, 21 Feb 2017 15:47:56 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Warner Losh Date: Tue, 21 Feb 2017 16:47:56 -0700 X-Google-Sender-Auth: Uo-k4zClGE_E63U6BRPbztGLoSQ Message-ID: Subject: Re: Reconsider switching from svn to git? To: Ed Maste Cc: freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 23:47:57 -0000 On Tue, Feb 21, 2017 at 1:22 PM, 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 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. 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. 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. >> 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. I know. I know the pain it will cause for Netflix should that issue be resolved. > 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. 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. > 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 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. Though a plan like that might be able to mitigate some of our concerns given the rather quirky way we import sources at Netflix (we do them as a subtree and do odd things to create merge points). It would take some experimentation to be able to know if this is a viable path forward. Our master tree is a twisty maze of commits, merges, etc that bedevil automation. 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. Anyway, don't take concerns I have for opposition to a switch, just nerves that need to be quelled a bit first :) Warner From owner-freebsd-git@freebsd.org Wed Feb 22 00:46:30 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74180CE5D9D for ; Wed, 22 Feb 2017 00:46:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D1781C6E; Wed, 22 Feb 2017 00:46:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id g18so34039503ioe.0; Tue, 21 Feb 2017 16:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iU4dRkei/CiaT2Cb8jiTmEwOUAnY5CADLCYv4BJ2Kv8=; b=KpI5Rm82rv6eLtE02vczrtvccolJfnkEyJKCe5daq1dXSTKUkmkUstD+nyJmMhpzj8 P4AvDLjmpRlx4JfYxaDoCPc41+KWYwuDu158biXWR9rcVd7nh24v469R8TvceR+Kf4DZ Ml8Xya8gHep0aApLWeGj1tOgHAMIzfp4qeKnRI1HJWe94GtKkdV46gWtxQ801Kf5Iek+ I4BY8+kWZXIeBWUnEyGwBCEyK2hOE8cAfln86tBVDvSGK1L3s439OeI75+NF13zvMJN/ mPZmOxV8ZWM7T4Xh1S6W/rIa+Jm7lIW79TIk8okh3UBgBjIr4LJfppi+5/f0h+ReXhHn pZ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iU4dRkei/CiaT2Cb8jiTmEwOUAnY5CADLCYv4BJ2Kv8=; b=qXIMp6ibrqJkXtvMRoFcTMDy/Za82vzCd+/V2pjgaDzsWcRSRnVWJfeILJYRfx0PDS xMDeHzNgkLSCa2sQjMNhdytbVbxkwuqj1MnuATF/hxA9WGPKKiGnDGu864vrr760jbZx HX84ggyWfMY7UKRKlEhbmFBo/kC/4P1v2k99G9Ju6DU2o0Upf5kD8mraJOozuCaPp1CQ zhrx2m/kH999tHXneu2UcPvCrs8GSzSSMZinX91WtYwbE9qdzD7N0scvsW0DEcuexku2 5hFbSb51WXnqdICFfTy8GTwPbnKzkt5+9LBJlJiOFWBlnkUt62YoZJ8HOFTar6sEq7mq OR+g== X-Gm-Message-State: AMke39nACot6GzJ6Kgc8ORJDmFwQr1mONqugOA0Pqz46Zl9s9EsCm6oqweQilpVoPqaQGD2Fwz44n4HjH7vOtw== X-Received: by 10.107.195.73 with SMTP id t70mr5248344iof.155.1487724389580; Tue, 21 Feb 2017 16:46:29 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.17 with HTTP; Tue, 21 Feb 2017 16:46:09 -0800 (PST) In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Ed Maste Date: Tue, 21 Feb 2017 19:46:09 -0500 X-Google-Sender-Auth: tQkm057uRHrobST2NLD6Egb6nTA Message-ID: Subject: Re: Reconsider switching from svn to git? To: Warner Losh Cc: freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 00:46:30 -0000 On 21 February 2017 at 18:47, Warner Losh 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. From owner-freebsd-git@freebsd.org Wed Feb 22 14:53:43 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F3ADCE917E for ; Wed, 22 Feb 2017 14:53:43 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27BC31923; Wed, 22 Feb 2017 14:53:43 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mail-it0-x241.google.com with SMTP id w185so514120ita.3; Wed, 22 Feb 2017 06:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=58E2YVcYSSWMVfOB+nxM/zIsB5K8+tmK42m7GuA0fZw=; b=pMP2GO+n3+V6Q2qIfRZ/ed4FwAqa/6O0jgkZAP2Ir+aOBYYfUPHz8z2fUsNmAUChQ2 htst5m4yVpHG6vNwwkgUfUfCGbc/cwPErlzraDG92boN4yeKa7ZodlAoo7amiZTfYN55 QmMGRZUFaxT+btGw2/Qi2xmjP5N2lwDWhwkYfoVZ5PX+arWVt52ahzMncfBxCczQJKxA Btsfv50qCOSnftEeM/XfEBpL6MBOggN2gZb6LTH6u4NSlkn3dIjQvjuImoIlVWMtHBvD teDst2HyL9ZfLTCJ6SGIuiGygHZF+BPaa5FZ0jQcl22Lme+GfxmN6GqEvqKOA5VOyqCs VnOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=58E2YVcYSSWMVfOB+nxM/zIsB5K8+tmK42m7GuA0fZw=; b=GNdTSRD/4E7K6rbvdPlzaNw3rdwrGEdZEjKB3h1DshxBFewFwF51ChMniKo5aamC6T pSshNN10wiFLMji7Mk89YbVX1F/JIgrGERG9Emr/vmJH6e8NpP121YLeUO0DZqNGGD3O uGKsIKb6lnS5cj2zniQXt/oLE2Vq3N9KqHdgdEb8neUvPS1x14BMW6Q+6ZSpchaE9qgd /HAwvbEQsakHV4jjItqGV6tXTLOfVYtkLFpXgipJEjqhqMibvRLaBw+tJvq0aOqVLwJF a+gq5NWg39Fs3KV9X6YxForAdEFnfqcWYuDqei/PUjWM1KEDCF8JmdKi1Y20tzYD4lqD +Fxw== X-Gm-Message-State: AMke39mlkEWmhUc3tCnmfIlS+V0DwGwEMRcoVE+/zhIlBfOCG7eceaG/joqUy1Sl7DPfGGZAbHff6RR4va7I6g== X-Received: by 10.36.28.85 with SMTP id c82mr2209635itc.49.1487775221469; Wed, 22 Feb 2017 06:53:41 -0800 (PST) MIME-Version: 1.0 Sender: uspoerlein@gmail.com Received: by 10.107.132.83 with HTTP; Wed, 22 Feb 2017 06:53:40 -0800 (PST) In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Date: Wed, 22 Feb 2017 15:53:40 +0100 X-Google-Sender-Auth: b2rsS4t-vNDkH5Qz1fwKPfx2Lnc Message-ID: Subject: Re: Reconsider switching from svn to git? To: Warner Losh Cc: Ed Maste , freebsd-git@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:53:43 -0000 2017-02-22 0:47 GMT+01:00 Warner Losh : > On Tue, Feb 21, 2017 at 1:22 PM, Ed Maste wrote: >>> 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. > > I know. I know the pain it will cause for Netflix should that issue be resolved. Zero pain, really. If I give you the commit hashes of broken-repo and new-repo at the same state you can instruct git to merge these two commits, preferring the tree of whichever side. You can then continue to pull/merge from the new-repo's master. There's probably a magic three-line incantation required, but really it's no biggy (albeit annoying). If even that surgery is too much, you can also export a complete diff of your-branch to origin/master in the old repo, and that would apply w/o conflicts to new-repo, as long as you sync them both to the same tree-object (which they would have, as the problem is only in the metadata). >> 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. > > 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. > >> 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 Before doing any re-roll of the repository, it would be nice if we could actually restore the CVS part of the history that got brutally mangled with the cvs2svn conversion. Or, we say fuck it, and only convert the SVN history (starting 2008) and tell people to use graft-points into https://github.com/dspinellis/unix-history-repo/ if they are interested in what "git blame" produces. > > 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. > > Though a plan like that might be able to mitigate some of our concerns > given the rather quirky way we import sources at Netflix (we do them > as a subtree and do odd things to create merge points). It would take > some experimentation to be able to know if this is a viable path > forward. Our master tree is a twisty maze of commits, merges, etc that > bedevil automation. > > 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. "Nice property"? If there was something I could kill it would be this. Have you ever migrated a system from stable/9 to stable/10 and then dealt with all the mergemaster fallout because the frigging IDs change w/o any content changes? That is a totally useless feature. I would much prefer we had CVS IDs back, so that you could at least see how many revisions there were to the file in between. > > Anyway, don't take concerns I have for opposition to a switch, just > nerves that need to be quelled a bit first :) > > Warner From owner-freebsd-git@freebsd.org Wed Feb 22 15:26:59 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87B02CE9BB5 for ; Wed, 22 Feb 2017 15:26:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2241946; Wed, 22 Feb 2017 15:26:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id g18so4143467ioe.0; Wed, 22 Feb 2017 07:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=gXLMMzR//HLIjF1VKKyOJIOBg4TkMAsb46xpLqgQaAQ=; b=YuFswzxLdvOoD/hdFqR+A3KLNNmpfBmYdqMDi1auH2itHZkD7g1bD7P5AZee0zYtaV x+ne0OGZT7/Z9xfRkm4VFPoOm29hQuu4xwIgN7Ym3dXhSTirzGe7O6bSd2UasT5nA+6b m+7av6fMpGPmbXLXBua40jbAc2ZBzu+x7YXUPcALI6NrJd7iLOXxWZpQtEkQQp6UsOHL pBOv9Kybe3V/kmEJTa/r2ccoWex05b5GJbAXNCUFwovh0vY36+bmBGV4nBl9e1wBpgGM jV0nySWVU+5EVEgAII032gKm/pbGlEeAr3zVjr2sArDVo7kuHy7Z9+Cia1o62u0jPSkh B2Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=gXLMMzR//HLIjF1VKKyOJIOBg4TkMAsb46xpLqgQaAQ=; b=AC9Qno1AKRsrzZZGnbzM1mCjUfleSyIo/AniCifffJpFwjocY0r0WSQsFwR01/3s1w +lPNuN7mKzgEhnt489RFioU58+f8Atgi0Rr6xiTJug7u6VJA0bLXxI1zBuGlai85QYwJ WT7hd9aJPJNIHCyUSZUpA/beA4sK466iUcHfodEkN+H03svVieoSNptxMIQu8qy5V/av D43nKe9SeuvV2v3rmQBKwuPkY+64HvhGKy9ATIXLqwZhQbP+giLqX4C1cpPhNlnF2p2Y R+2Al1UjpBlzBCfOBHOWx5s8V6Pl6+uYtz1Cvg3O41TM0u+YpdwJXMAFAn7Ouu9MoiDh Mv9A== X-Gm-Message-State: AMke39kOm4l4zDdurgpJRyI9yRB1pQbOSq6juNlMHwNmirP4XG0jEn/CW8tSDLZsX9a/g8wFpzB8CPMoCd8LVg== X-Received: by 10.107.12.40 with SMTP id w40mr19006372ioi.162.1487777218798; Wed, 22 Feb 2017 07:26:58 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.17 with HTTP; Wed, 22 Feb 2017 07:26:38 -0800 (PST) In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Ed Maste Date: Wed, 22 Feb 2017 10:26:38 -0500 X-Google-Sender-Auth: 1EYHNQY8_xvhrT6ffDeuBxo6-s8 Message-ID: Subject: Re: Reconsider switching from svn to git? To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Cc: Warner Losh , freebsd-git@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 15:26:59 -0000 On 22 February 2017 at 09:53, Ulrich Sp=C3=B6rlein wrote: > > Before doing any re-roll of the repository, it would be nice if we > could actually > restore the CVS part of the history that got brutally mangled with the cv= s2svn > conversion. Can you give some examples of the mangled history? I'm not really sure what's broken here. From owner-freebsd-git@freebsd.org Thu Feb 23 22:35:53 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CEA8CEB247 for ; Thu, 23 Feb 2017 22:35:53 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 460B51F73 for ; Thu, 23 Feb 2017 22:35:53 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 41E11CEB246; Thu, 23 Feb 2017 22:35:53 +0000 (UTC) Delivered-To: git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F9BDCEB245 for ; Thu, 23 Feb 2017 22:35:53 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D47B81F72 for ; Thu, 23 Feb 2017 22:35:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v1NMZfPi054770; Thu, 23 Feb 2017 22:35:41 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v1NMZfuA054769; Thu, 23 Feb 2017 14:35:41 -0800 (PST) (envelope-from david) Date: Thu, 23 Feb 2017 14:35:41 -0800 From: David Wolfskill To: git@freebsd.org Subject: Reality-checking the github repository...? Message-ID: <20170223223541.GX1280@albert.catwhisker.org> Reply-To: git@freebsd.org, David Wolfskill MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hGS0LDae7EcdHMuB" Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:35:53 -0000 --hGS0LDae7EcdHMuB Content-Type: multipart/mixed; boundary="eliZzZKkJKZsQYaJ" Content-Disposition: inline --eliZzZKkJKZsQYaJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [I've set Reply-To, as I'm not subscribed; please keep me on the recipient list. -- dhw] Given the shattered.io demonstration of SHA-1 collision-creation, one of my colleagues at work (where we use the github repo) asked if I might try comparing a pristine svn head working copy against a (purportedly) corresponding git repo. For my first try, I created a shiny new local clone of the repo we actually use internally, checked the latest entry (from "git log") that showed a "Notes" field: =2E.. Notes: svn path=3D/head/; revision=3D313813 and accordingly used "svn up -r 313813" to update the svn working copy to (what shohld be) the same point. I then issued: diff -ru -I '\$FreeBSD.*\$' ../svn/src FreeBSD >/tmp/svn_git@313813_diff.txt While I rather expected the first "difference" identified: Only in ../svn/src: .svn I was quote surprised to find 64 more "Only in ../svn/src/...." lines. (I have attached a copy of the file.) Is this expected? Then, after some discussion with my colleague, I directed a Web browser to , selected "Clone or download"; saw that "Download ZIP" was an option, and then -- on the command line -- ran: fetch https://github.com/freebsd/freebsd/archive/master.zip which ran uneventfully. A subsequent: unzip master.zip nattered on at some length about inflating, creating, extracting various file system-resident objects rather uneventfully... until the end, which looked like this: =2E.. inflating: freebsd-master/usr.sbin/zzz/zzz.8 =20 inflating: freebsd-master/usr.sbin/zzz/zzz.sh =20 finishing deferred symbolic links: freebsd-master/contrib/tcpdump/README -> README.md freebsd-master/share/i18n/csmapper/APPLE/INUIT%UCS.src -> # $FreeBSD$^J# = $NetBSD: INUIT%UCS.src,v 1.1 2006/03/13 19:45:36 tnozaki Exp $^J^JTYPE^I^IR= OWCOL^JNAME^I^IINUIT/UCS^JSRC_ZONE^I0x00-0xFF^JOOB_MODE^IILSEQ^JDST_ILSEQ^I= 0xFFFE^JDST_UNIT_BITS^I16^J^JBEGIN_MAP^J#^J# This mapping data is made from= the mapping data provided by Unicode, Inc.^J# Original notice:^J#^J#=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D^J# File name: = INUIT.TXT^J#^J# Contents: Map (external version) from Mac OS Inuit^J# = character set to Unicode 3.0 and later^J#^J# Contacts: cha= rsets@apple.com, everson@evertype.com^J#^J# Changes:^J#^J# c01 200= 5-Apr-01 First posted version. Matches internal xml^J# = and Text Encoding Converter 2.0.^J#^J# Standard header:^J# = ----------------^J#^J# Apple, the Apple logo, and Macintosh are trademark= s of Apple^J# Computer, Inc., registered in the United States and other c= ountries.^J# Unicode is a trademark of Unicode Inc. For the sake of brevi= ty,^J# throughout this document, "Macintosh" can be used to refer to^J# = Macintosh computers and "Unicode" can be used to refer to the^J# Unicode= standard.^J#^J# Apple Computer, Inc. ("Apple") makes no warranty or repr= esentation,^J# either express or implied, with respect to this document a= nd the^J# included data, its quality, accuracy, or fitness for a particul= ar^J# purpose. In no event will Apple be liable for direct, indirect,^J# = special, incidental, or consequential damages resulting from any^J# def= ect or inaccuracy in this document or the included data.^J#^J# These mapp= ing tables and character lists are subject to change.^J# The latest table= s should be available from the following:^J#^J# ^J#^J# For general information about Mac OS= encodings and these mapping^J# tables, see the file "README.TXT".^J#^J# = Format:^J# -------^J#^J# Three tab-separated columns;^J# '#' begins a c= omment which continues to the end of the line.^J# Column #1 is the Mac = OS Inuit code (in hex as 0xNN)^J# Column #2 is the corresponding Unicod= e (in hex as 0xNNNN)^J# Column #3 is a comment containing the Unicode n= ame^J#^J# The entries are in Mac OS Inuit code order.^J#^J# Control cha= racter mappings are not shown in this table, following^J# the conventions= of the standard UTC mapping tables. However, the^J# Mac OS Inuit charact= er set uses the standard control characters^J# at 0x00-0x1F and 0x7F.^J#^= J# Notes on Mac OS Inuit (partly from Michael Everson):^J# ----------------= ------------------------------------^J#^J# This is a legacy Mac OS encodi= ng; in the Mac OS X Carbon and Cocoa^J# environments, it is only supporte= d via transcoding to and from^J# Unicode.^J#^J# This character set was = developed by Michael Everson of Everson^J# Typography (everson@evertype.c= om) and was used for the Inuktitut^J# localizations of Mac OS, as well as= for the Inuktitut utilities^J#^Ipackage from Everson Typography. Note that= while Apple authorized^J# the Inuktitut localization mentioned above, it= was not shipped with^J# Apple hardware, and was not otherwise supported = by Apple. Fonts^J# conforming to the Mac OS Inuit character set are avail= able from^J# Everson Typography (http://www.evertype.com/software/apple/)= =2E^J# Information about the use of this character set is available at ^J= # http://www.evertype.com/standards/iu/.^J#^J# The Mac OS Inuit charact= er set shares the script code smEthiopic^J# (28) with the Ethiopic encodi= ng. To determine if the Inuktitut^J# encoding is being used, you must als= o check if the system region^J# code is 78, verNunavut.^J#^J# The Mac O= S Inuit character set includes the full syllabic letter^J# repertoire req= uired for Inuktitut; it is a subset of the Unified^J# Canadian Aboriginal= Syllabics set encoded in Unicode. The encoding^J# is InuitSCII, designed= by Doug Hitch for the Government of the ^J# Northwest Territories.^J#^J#= The Mac OS Inuit character set also includes a number of characters^J# = that were needed for the classic Mac OS user interface and^J# localizati= on (e.g. ellipsis, bullet, copyright sign). All of the^J# characters in M= ac OS Inuit that are also in the Mac OS Roman^J# encoding are at the same= code point in both; this improves^J# application compatibility.^J#^J# Un= icode mapping issues and notes:^J# ---------------------------------^J#^J# = Details of mapping changes in each version:^J# ----------------------------= ---------------^J#^J##################^J0x00 - 0x7E =3D 0x0000 -^J0x80 =3D = 0x1403^J0x81 =3D 0x1404^J0x82 =3D 0x1405^J0x83 =3D 0x1406^J0x84 =3D 0x140A^= J0x85 =3D 0x140B^J0x86 =3D 0x1431^J0x87 =3D 0x1432^J0x88 =3D 0x1433^J0x89 = =3D 0x1434^J0x8A =3D 0x1438^J0x8B =3D 0x1439^J0x8C =3D 0x1449^J0x8D =3D 0x1= 44E^J0x8E =3D 0x144F^J0x8F =3D 0x1450^J0x90 =3D 0x1451^J0x91 =3D 0x1455^J0x= 92 =3D 0x1456^J0x93 =3D 0x1466^J0x94 =3D 0x146D^J0x95 =3D 0x146E^J0x96 =3D = 0x146F^J0x97 =3D 0x1470^J0x98 =3D 0x1472^J0x99 =3D 0x1473^J0x9A =3D 0x1483^= J0x9B =3D 0x148B^J0x9C =3D 0x148C^J0x9D =3D 0x148D^J0x9E =3D 0x148E^J0x9F = =3D 0x1490^J0xA0 =3D 0x1491^J0xA1 =3D 0x00B0^J0xA2 =3D 0x14A1^J0xA3 =3D 0x1= 4A5^J0xA4 =3D 0x14A6^J0xA5 =3D 0x2022^J0xA6 =3D 0x00B6^J0xA7 =3D 0x14A7^J0x= A8 =3D 0x00AE^J0xA9 =3D 0x00A9^J0xAA =3D 0x2122^J0xAB =3D 0x14A8^J0xAC =3D = 0x14AA^J0xAD =3D 0x14AB^J0xAE =3D 0x14BB^J0xAF =3D 0x14C2^J0xB0 =3D 0x14C3^= J0xB1 =3D 0x14C4^J0xB2 =3D 0x14C5^J0xB3 =3D 0x14C7^J0xB4 =3D 0x14C8^J0xB5 = =3D 0x14D0^J0xB6 =3D 0x14EF^J0xB7 =3D 0x14F0^J0xB8 =3D 0x14F1^J0xB9 =3D 0x1= 4F2^J0xBA =3D 0x14F4^J0xBB =3D 0x14F5^J0xBC =3D 0x1505^J0xBD =3D 0x14D5^J0x= BE =3D 0x14D6^J0xBF =3D 0x14D7^J0xC0 =3D 0x14D8^J0xC1 =3D 0x14DA^J0xC2 =3D = 0x14DB^J0xC3 =3D 0x14EA^J0xC4 =3D 0x1528^J0xC5 =3D 0x1529^J0xC6 =3D 0x152A^= J0xC7 =3D 0x152B^J0xC8 =3D 0x152D^J0xC9 =3D 0x2026^J0xCA =3D 0x00A0^J0xCB = =3D 0x152E^J0xCC =3D 0x153E^J0xCD =3D 0x1555^J0xCE =3D 0x1556^J0xCF =3D 0x1= 557^J0xD0 =3D 0x2013^J0xD1 =3D 0x2014^J0xD2 =3D 0x201C^J0xD3 =3D 0x201D^J0x= D4 =3D 0x2018^J0xD5 =3D 0x2019^J0xD6 =3D 0x1558^J0xD7 =3D 0x1559^J0xD8 =3D = 0x155A^J0xD9 =3D 0x155D^J0xDA =3D 0x1546^J0xDB =3D 0x1547^J0xDC =3D 0x1548^= J0xDD =3D 0x1549^J0xDE =3D 0x154B^J0xDF =3D 0x154C^J0xE0 =3D 0x1550^J0xE1 = =3D 0x157F^J0xE2 =3D 0x1580^J0xE3 =3D 0x1581^J0xE4 =3D 0x1582^J0xE5 =3D 0x1= 583^J0xE6 =3D 0x1584^J0xE7 =3D 0x1585^J0xE8 =3D 0x158F^J0xE9 =3D 0x1590^J0x= EA =3D 0x1591^J0xEB =3D 0x1592^J0xEC =3D 0x1593^J0xED =3D 0x1594^J0xEE =3D = 0x1595^J0xEF =3D 0x1671^J0xF0 =3D 0x1672^J0xF1 =3D 0x1673^J0xF2 =3D 0x1674^= J0xF3 =3D 0x1675^J0xF4 =3D 0x1676^J0xF5 =3D 0x1596^J0xF6 =3D 0x15A0^J0xF7 = =3D 0x15A1^J0xF8 =3D 0x15A2^J0xF9 =3D 0x15A3^J0xFA =3D 0x15A4^J0xFB =3D 0x1= 5A5^J0xFC =3D 0x15A6^J0xFD =3D 0x157C^J0xFE =3D 0x0141^J0xFF =3D 0x0142^JEN= D_MAP^J symlink error: File name too long lchmod (file attributes) error: No such file or directory lgld-dhw(11.0-S)[6] echo $? 0 lgld-dhw(11.0-S)[7] =20 Are the whines expected? Is it also expected that the exit status will be 0 when whines are issued? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org How could one possibly "respect" a misogynist, racist, bullying con-man??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --eliZzZKkJKZsQYaJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="svn_git@313813_diff.txt" Only in ../svn/src: .svn Only in ../svn/src/cddl/contrib/opensolaris/common: avl Only in ../svn/src/contrib/apr/include: private Only in ../svn/src/contrib/compiler-rt/lib/builtins: arm64 Only in ../svn/src/contrib/compiler-rt/lib/builtins: armv6m Only in ../svn/src/contrib/ipfilter: net Only in ../svn/src/contrib/libxo: m4 Only in ../svn/src/contrib/llvm/include/llvm/MC: MCAnalysis Only in ../svn/src/contrib/llvm/lib/ExecutionEngine: JIT Only in ../svn/src/contrib/llvm/lib/MC: MCAnalysis Only in ../svn/src/contrib/llvm/tools/clang/lib/Headers: cuda Only in ../svn/src/contrib/llvm/tools/lld/tools: linker-script-test Only in ../svn/src/contrib/llvm/tools/lld: utils Only in ../svn/src/contrib/llvm/tools/lldb/source/Plugins/Process: win-minidump Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: bf Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: bn Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: cast Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: des Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: dh Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: dsa Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: ec Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: ecdh Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: ecdsa Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: engine Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: evp Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: hmac Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: idea Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: lhash Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: md2 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: md4 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: md5 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: mdc2 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: rand Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: rc2 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: rc4 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: rc5 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: ripemd Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: rsa Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: sha Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: sha1 Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: srp Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: threads Only in ../svn/src/contrib/netbsd-tests/crypto/libcrypto: x509v3 Only in ../svn/src/contrib/netbsd-tests/dev/usb: libhid Only in ../svn/src/contrib/netbsd-tests/dev/usb: t_hid Only in ../svn/src/contrib/netbsd-tests/lib/libposix: bsd Only in ../svn/src/contrib/netbsd-tests/lib/libposix: posix1 Only in ../svn/src/contrib/netbsd-tests/lib/libposix: posix2 Only in ../svn/src/contrib/netbsd-tests/lib: libtre Only in ../svn/src/contrib/ofed/libibverbs: config Only in ../svn/src/contrib/ofed/libmlx4: config Only in ../svn/src/contrib/ofed/libmthca: config Only in ../svn/src/contrib/traceroute: lbl Only in ../svn/src/contrib/wpa/src: hlr_auc_gw Only in ../svn/src/lib/libthr/arch: common Only in ../svn/src/sys/amd64: compile Only in ../svn/src/sys/arm: compile Only in ../svn/src/sys/dev: ieee488 Only in ../svn/src/sys/i386: compile Only in ../svn/src/sys/mips: compile Only in ../svn/src/sys/modules: random Only in ../svn/src/sys/powerpc: compile Only in ../svn/src/sys/sparc64: compile Only in ../svn/src/tools/tools/nanobsd/rescue: Pkg Only in ../svn/src/usr.sbin/bsdconfig: fdisk --eliZzZKkJKZsQYaJ-- --hGS0LDae7EcdHMuB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYr2O9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XmZIIALouG66vrhs0tDSPcJLS88mZ 33BIaVNUUYFFNuOmSuqylo7MYVz99slyjDBO/+Gbp4QCxgr0NVFm51Clt5z1ZoO+ 6o7Qle63EzyfrIR8JMraj56BRzXknqqUJxjH85rsH+rh924mGd3/ANLabVL+5hXJ 0plkpMJaQjD5Cf//TuEgVZbyt5UnFM38XcvQvrWIOdeN54ZX362TgyMxqsu+teLC 28KHAlliAyKsKUCJGIseYS1z+TjyuB7v052OsWU7RlnIg3aLijXie2ND3CtrAhP7 lrx4RW7oOdn1DeSzM12tNyitCYCRMZxYyVIk+Qzm8DZ2V9rcyZYN5hhtPwNotZ8= =Ir7R -----END PGP SIGNATURE----- --hGS0LDae7EcdHMuB-- From owner-freebsd-git@freebsd.org Fri Feb 24 00:39:34 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C3DCCE8229 for ; Fri, 24 Feb 2017 00:39:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 069701F40 for ; Fri, 24 Feb 2017 00:39:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0313BCE8228; Fri, 24 Feb 2017 00:39:34 +0000 (UTC) Delivered-To: git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0115DCE8226 for ; Fri, 24 Feb 2017 00:39:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B584A1F3F for ; Fri, 24 Feb 2017 00:39:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v1O0dVIq055593 for ; Fri, 24 Feb 2017 00:39:31 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v1O0dV5A055592 for git@freebsd.org; Thu, 23 Feb 2017 16:39:31 -0800 (PST) (envelope-from david) Date: Thu, 23 Feb 2017 16:39:31 -0800 From: David Wolfskill To: git@freebsd.org Subject: Re: Reality-checking the github repository...? Message-ID: <20170224003931.GY1280@albert.catwhisker.org> Reply-To: git@freebsd.org, David Wolfskill References: <20170223223541.GX1280@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XNGFwoZhfRV9+O3/" Content-Disposition: inline In-Reply-To: <20170223223541.GX1280@albert.catwhisker.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 00:39:34 -0000 --XNGFwoZhfRV9+O3/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 02:35:41PM -0800, David Wolfskill wrote: > ... > For my first try, I created a shiny new local clone of the repo we > actually use internally,... >=20 > While I rather expected the first "difference" identified: >=20 > Only in ../svn/src: .svn >=20 > I was quote surprised to find 64 more "Only in ../svn/src/...." lines. > (I have attached a copy of the file.) >=20 > Is this expected? > .... Further investigation reveals that each of the cited file system objects (other than .svn) either is an empty directory or only contains empty directories. Does that information have an effect on whether or not the result is "expected?" Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org How could one possibly "respect" a misogynist, racist, bullying con-man??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --XNGFwoZhfRV9+O3/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYr4DDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XTE8H/0O04IcK6t+7en6HYxlTN08W zNVLMQpaGy58Bbrzj4w8zDU+qFnGv3gI5UzWuBlZAGUEzNtIxafzCK2vCkHPt2xZ V2bj0bkAFfeX4bIEgm503o1M2Ddfv5AegFZr3LF+hsj1xj9dv/T5XLoCSC3VbDje +wJAO3SVONxG9ifr0xyVifbEDlMWAr5GkklB40BuQsQFJoMYiNeAnByOXr/3CAA/ ef23UeJwv+E43mxkU7vbrxq4xw8t1bbvQPQajbFSDm3VQvBWnNyKWKrnrRK3GQpj PVwVuI4QOzhAUU5amLaXhSyeoJ0KcCNePuwL1IC9V7kar4vxm1E01OKsdbXv/bc= =8Hfp -----END PGP SIGNATURE----- --XNGFwoZhfRV9+O3/-- From owner-freebsd-git@freebsd.org Fri Feb 24 03:44:05 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69449CEB1A7 for ; Fri, 24 Feb 2017 03:44:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4907719F1 for ; Fri, 24 Feb 2017 03:44:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 45949CEB1A6; Fri, 24 Feb 2017 03:44:05 +0000 (UTC) Delivered-To: git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 439F8CEB1A5 for ; Fri, 24 Feb 2017 03:44:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 035EF19F0 for ; Fri, 24 Feb 2017 03:44:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id y135so9375776itc.1 for ; Thu, 23 Feb 2017 19:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=W3dhjdO7l6s/Ttr+pHGG/+PEG9MseDb1QhtrPbYINQY=; b=qWSOVOOqNZqeOHF2zA4xQaOimi+lYs2UESLpe273XgVwulnupAZXE8snj784WpCdpK XjzokQo+oERF/l1z0fw4iehzV/7cVXurYbFu0Vtl+xrFKLIJ0KIFxYf3Qz+0fFrsI3YZ UNi66Nb2eSKLIbS1zsvZbSloT8OaAOFyjI+9OzU4LJUxVzKha4vmcryu1fRd7r5d/gVH w4dHZhqFO4vs6SkDTXtkxmpvqwTuksArUR48VAXNnlazsiHsWW5TITsHOTahlC5G95Q5 1mejepUaPtIrHx4jBuc8Njrt4tPsuo908JjsAICWlinK+K88ABKpa9wJf9Pd4UaCcHZd Jirw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=W3dhjdO7l6s/Ttr+pHGG/+PEG9MseDb1QhtrPbYINQY=; b=U8P65nzdb0msuw+uvwccVCeQFj1YOxz0yQycL+W7RnSn9ATmHu4UFmJhtzK5c335ls W/CHOiukxQJHCb0irn287PF0Vwnp8u0NzVUx2AR+elD+vva6vugS5od5+CnTKMLft4MD pQIWL13v/mvsQqzxIIKL7/sFkvOl+kJBStqmnwV0qGLLE0Si5FMKLpvQ1JRj80W+5xC8 ZUY88YlvySiStxj2Dy4trh2ub+ru4ISU5GBtolxaR7TS7zC+zyAW51GL+H3g4Y/nuL7E Z5Xz+7AZk5OaXBdrgQYCydI8veN+hUunPt15X4nFlInN82Ak3qDd1SZcuv/nHAm8MuKX mbGA== X-Gm-Message-State: AMke39kHSrBnA486zKAtxpKN5jeUBcj4FjyqnojC0dirbV8+7A9kNT5KP3EP1NOaZvzgHwWu6pFY9Z/lWEt7+w== X-Received: by 10.36.25.83 with SMTP id b80mr888202itb.98.1487907844351; Thu, 23 Feb 2017 19:44:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.190.71 with HTTP; Thu, 23 Feb 2017 19:44:03 -0800 (PST) In-Reply-To: <20170224003931.GY1280@albert.catwhisker.org> References: <20170223223541.GX1280@albert.catwhisker.org> <20170224003931.GY1280@albert.catwhisker.org> From: Ryan Stone Date: Thu, 23 Feb 2017 22:44:03 -0500 Message-ID: Subject: Re: Reality-checking the github repository...? To: git@freebsd.org, David Wolfskill Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:44:05 -0000 Yes, that's expected. Due to details in how git represents directory trees, it is unable to represent empty directories. On Thu, Feb 23, 2017 at 7:39 PM, David Wolfskill wrote: > On Thu, Feb 23, 2017 at 02:35:41PM -0800, David Wolfskill wrote: > > ... > > For my first try, I created a shiny new local clone of the repo we > > actually use internally,... > > > > While I rather expected the first "difference" identified: > > > > Only in ../svn/src: .svn > > > > I was quote surprised to find 64 more "Only in ../svn/src/...." lines. > > (I have attached a copy of the file.) > > > > Is this expected? > > .... > > Further investigation reveals that each of the cited file system objects > (other than .svn) either is an empty directory or only contains empty > directories. > > Does that information have an effect on whether or not the result is > "expected?" > > Thanks! > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > How could one possibly "respect" a misogynist, racist, bullying con-man??!? > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-git@freebsd.org Fri Feb 24 03:48:17 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B871CEB1D1 for ; Fri, 24 Feb 2017 03:48:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 154091A93 for ; Fri, 24 Feb 2017 03:48:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 11D61CEB1D0; Fri, 24 Feb 2017 03:48:17 +0000 (UTC) Delivered-To: git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FD56CEB1CF for ; Fri, 24 Feb 2017 03:48:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA7391A92 for ; Fri, 24 Feb 2017 03:48:16 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v1O3mEM2057104; Fri, 24 Feb 2017 03:48:14 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v1O3mEOM057103; Thu, 23 Feb 2017 19:48:14 -0800 (PST) (envelope-from david) Date: Thu, 23 Feb 2017 19:48:14 -0800 From: David Wolfskill To: Ryan Stone Cc: git@freebsd.org Subject: Re: Reality-checking the github repository...? Message-ID: <20170224034814.GZ1280@albert.catwhisker.org> Reply-To: David Wolfskill References: <20170223223541.GX1280@albert.catwhisker.org> <20170224003931.GY1280@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="meJFx28uqmeTUb3U" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:48:17 -0000 --meJFx28uqmeTUb3U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 10:44:03PM -0500, Ryan Stone wrote: > Yes, that's expected. Due to details in how git represents directory > trees, it is unable to represent empty directories. > .... Ah; interesting. Thanks. Peace, david --=20 David H. Wolfskill david@catwhisker.org How could one possibly "respect" a misogynist, racist, bullying con-man??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --meJFx28uqmeTUb3U Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYr6z+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X9qMH/iUhgxnGuexIh4xeeqnU3Ryq e2+hn4Q2HDNUsT3ws57f7vhfWPyBPcbwv1/pRksgMV7T0dz7HO7iQEa2fvxgcnJV YfdBmaCduDyleB7ZQIFonn9+mus9L07ZOrpaau4EGdUVZzDoDe7aqMXwp75bKjJi 9VFvmykGRuDRqik+g5LbuGfukI8T2e6x3AiloLXASlVNek/CV4recZQnCF+qF3NJ hzGiLhPFGvkLYsasQ9PgPou2xf8LtS470f1BcviG1NbOkOZVYvYmq5O2m9RtOiye +1WtsEQcWXE2f/UDFdpGxQT+hcIQW4ekqQIaJHFLHIoQsGGDXrf/OKZCecgm9UQ= =uqCG -----END PGP SIGNATURE----- --meJFx28uqmeTUb3U-- From owner-freebsd-git@freebsd.org Sat Feb 25 00:36:53 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 213C8CECF97 for ; Sat, 25 Feb 2017 00:36:53 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2180FA0 for ; Sat, 25 Feb 2017 00:36:52 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from ultrabook.yoonka.com (p5DC0FA85.dip0.t-ipconnect.de [93.192.250.133]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id v1LMf9B9015215 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 21 Feb 2017 22:41:10 GMT (envelope-from list1@gjunka.com) X-Authentication-Warning: msa1.earth.yoonka.com: Host p5DC0FA85.dip0.t-ipconnect.de [93.192.250.133] claimed to be ultrabook.yoonka.com Subject: Re: Reconsider switching from svn to git? To: freebsd-git@freebsd.org References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Grzegorz Junka Message-ID: <931513c8-3247-3664-3958-c352400d0736@gjunka.com> Date: Tue, 21 Feb 2017 22:41:04 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 00:36:53 -0000 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 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 From owner-freebsd-git@freebsd.org Sat Feb 25 00:36:52 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4579FCECF94 for ; Sat, 25 Feb 2017 00:36:52 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF687F9F for ; Sat, 25 Feb 2017 00:36:51 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from ultrabook.yoonka.com (ip-109-84-3-58.web.vodafone.de [109.84.3.58]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id v1M8BHXn030417 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 22 Feb 2017 08:11:22 GMT (envelope-from list1@gjunka.com) X-Authentication-Warning: msa1.earth.yoonka.com: Host ip-109-84-3-58.web.vodafone.de [109.84.3.58] claimed to be ultrabook.yoonka.com Subject: Re: Reconsider switching from svn to git? To: freebsd-git@freebsd.org References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Grzegorz Junka Message-ID: <562a721d-731d-5302-a2c9-df51d0328124@gjunka.com> Date: Wed, 22 Feb 2017 08:11:12 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 00:36:52 -0000 On 22/02/2017 00:46, Ed Maste wrote: > On 21 February 2017 at 18:47, Warner Losh 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. This could be also easily solved by having a backup server with restricted access. The main server could be a remote for that backup server. Then the backup server wold periodically pull all changes (git fetch main_server). This would backup all branches ever pushed to the remote server. Grzegorz From owner-freebsd-git@freebsd.org Sat Feb 25 09:32:53 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7C32C90116 for ; Sat, 25 Feb 2017 09:32:53 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id C91E115DD for ; Sat, 25 Feb 2017 09:32:53 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:d8bf:e990:4c4e:16c0]) by elvis.mu.org (Postfix) with ESMTPSA id 3C837346DE24 for ; Sat, 25 Feb 2017 01:32:53 -0800 (PST) Subject: Re: Reconsider switching from svn to git? To: freebsd-git@freebsd.org References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> <931513c8-3247-3664-3958-c352400d0736@gjunka.com> From: Alfred Perlstein Message-ID: Date: Sat, 25 Feb 2017 01:32:53 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <931513c8-3247-3664-3958-c352400d0736@gjunka.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 09:32:53 -0000 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 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