From nobody Tue Nov 25 12:46:58 2025 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dG2Ws5jPLz6J5vf for ; Tue, 25 Nov 2025 12:47:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dG2Ws1K6wz4Pqv; Tue, 25 Nov 2025 12:47:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5APCkwu5026572; Tue, 25 Nov 2025 21:46:59 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1764074819; bh=EZacK/M8q2+SLWpd6putGGHsP3VxsrcGDVtLbra399s=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Uq1x1BpBtPvDpqhJDXjb1poCWdSTzPtgGc/nluB6bkAkLCxM7shbcVtfbOKVVrylZ Xp3CJPsOyQNQLU/AE6Xp/Ayw13USWwPD7LNE6QtAjJzHK+8v89W077woTE5/W5yprw KXGsu3d1HW5tjT8EPLcEgYxPxCtXIq84ZyHygnTc= Date: Tue, 25 Nov 2025 21:46:58 +0900 From: Tomoaki AOKI To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: Mark Linimon , Warner Losh , Ankush Mondal , hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) Message-Id: <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> In-Reply-To: <86h5ui7qd5.fsf@ltc.des.dev> References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dG2Ws1K6wz4Pqv On Tue, 25 Nov 2025 04:17:26 +0100 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > The best way for code review with FreeBSD is Phablicator for me. > > The accounts are managed by FreeBSD project (or FreeBSD foundation), > > unlike github. > > The accounts are managed by the person you're replying to. Ah, thanks for maintaining the services you all! > > And works fine for me (with some difficulty, though, > > on opening review with adding files, but it can be overcome). > > There is no difficulty if you use git-arc (from the freebsd-git-devtools > port) like the committer's guide says you should. I cannot use devel/arcanist, which is called from git-arc.sh, as conflicting archivers/arc is pulled in by security/clamav. So my only choice is using web UI. And I'm not committing my local changes but stashing, as I'm not a committer and committing into local branch is not mandatory for me. I don't want n* number (in case src) to become different with official repo by missingly committing into officially existing branch instead of purely local one. git diff (with -U999999 for Phabricator) does good job unless any new files are added, but if anything are added, I need to 1. generate diff by git diff and manually add diffs for added files 2. reverse with the patch by 1. (Of course, dry-run first) 3. `git stash --include-untracked` to make unrelated diffs backed out 4. apply the patch of 1. 5. build (/ package for ports case) to be sure 6. `git stash --include-untracked` again to move the changes into stash 7. `git stash show -p --include-untracked -U999999 > path_to_patch` to obtain sanely applicable diff for Phabricator 8.`git stash pop` and reverse the patch of 6. to be sure. 9. `git stash pop` again to restore previous state without the patfh 10. apply the patch of 6. to restore actual previous state. Diff generated with above procedure are always sanely accepted by Phabricator web UI in my experience. (Hand crafted patch are often rejected.) Regards. > DES > -- > Dag-Erling Smørgrav - des@FreeBSD.org -- Tomoaki AOKI