From: jim.cromie@gmail.com
To: Sarah Langstrom <sarahklangstrom@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Organizing patches/build artifacts against multiple trees
Date: Wed, 26 Apr 2023 09:46:13 -0600 [thread overview]
Message-ID: <CAJfuBxwQfZK61ua0dYDUnjNXeDjtkCfJQEOxH-g4o-1706msOw@mail.gmail.com> (raw)
In-Reply-To: <CAB9B5ffZm=qm6KfoMPTUZ_==ad6G3--4Ab1S4EMQ40SzOKaYNg@mail.gmail.com>
On Sun, Feb 19, 2023 at 8:21 PM Sarah Langstrom
<sarahklangstrom@gmail.com> wrote:
>
> For developers that find themselves with multiple in progress
> patchsets against multiple trees, how do you organize them locally? I
> add each tree as a remote and use git-worktree for multiple streams of
> development.
I use worktrees as well. they all use the same repo, so its gotta save space.
I tend to reuse them too, and rarely need make clean between swaps.
[jimc@frodo f2]$ git worktree list
/home/jimc/projects/lx/linux.git 457391b03803 [master]
/home/jimc/projects/lx/wk-next 75eada68d460 [kmemleak-format-tweaks]
/home/jimc/projects/lx/wk-ref 89b88285f7ba [diet-x1b]
/home/jimc/projects/lx/wk-rpi b762dfa091f8 [maph]
/home/jimc/projects/lx/wk-suren 8660484ed1cf [modules-next]
/home/jimc/projects/lx/wk-test b61bb42d2cdc [dd-fix-1d]
FWIW, I have ./builds/* folders, each with a .config file and a 2 line makefile:
# Automatically generated by /home/jimc/projects/lx/wk-rpi/Makefile: don't edit
include /home/jimc/projects/lx/wk-rpi/Makefile
> I wish I had a little working area to go along with each
> tree/tracking branch where I could store patches and configs related
> to that tree without committing them, but still be able to back them
> up when I push the trees to my backup NAS. I am starting to lose track
> of which patchsets worked against which tree and which commit by
> sticking them all in one ~/patches dir.
have you seen git stash ?
it will do at least some of what you want.
>
> Another issue I have is that I put files to build a small initramfs
> inside of linux/usr and a Makefile of my own to build the initramfs
> and start up qemu. Again, I want to use git to store it with my
> branches on my NAS, but I don't want to check it in. Does anyone else
> have tips for dealing with adding personal scaffolding like this
> without having it get accidentally lost? Right now they are just
> untracked files that I sometimes delete by mistake.
>
I use virtme to do my testing.
It exposes your host machine inside a qemu vm,
so the env & tools in the vm are the same binaries that youre used to using.
Ive had to do ZERO messing with the qemu details
Id never even used qemu until virtme,
and other than some fiddling with its many --options
(some are pass thru to qemu)
it just works.
specifically, it does guest-tools setup, maybe its simple to reuse that..
virtme.guesttools 975097856 485798144 486818176 50% /run/virtme/guesttools
virtme.initmount0 975097856 485798144 486818176 50% /root
As to personal scaffolding, test scripts etc,
I keep them in the parent directory of all the worktrees,
and the vm's get it as the HOME dir via --cwd=../../..
[jimc@frodo f2]$ krun
vm --show-command --show-boot-console --kdir . --mods=auto --kopt
nokaslr --rwdir=/root=/home/jimc/projects/lx/boots-dump/v6.3-7-gb762dfa091f8
--cwd=../../.. --kopt dynamic_debug.verbose=3 --qemu-opts -m 2G --smp
3
then I can just source the shell tools I want
[ 21.770154] virtme-init: udev is done
virtme-init: console is ttyS0
bash-5.2# . test-funcs.rc
:#>
> Thanks,
> Sarah
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2023-04-26 15:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-20 3:20 Organizing patches/build artifacts against multiple trees Sarah Langstrom
2023-04-26 15:46 ` jim.cromie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJfuBxwQfZK61ua0dYDUnjNXeDjtkCfJQEOxH-g4o-1706msOw@mail.gmail.com \
--to=jim.cromie@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=sarahklangstrom@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).