Validating every file as you describe makes sense if there is no common ancestor. In the case of trees with a common ancestor, however, only files changed in subsequent commits should require checking. I went digging around git/fs and I don't see a way to get the files associated with a given commit. @Ori Bernstein <o...@eigenstate.org> Is there a tool in 9git that lets me list which files were changed at a given commit hash?
Paul On Sun, Jan 12, 2025 at 1:58 PM Noam Preil <n...@pixelhero.dev> wrote: > git/merge might work a bit faster, but making it smarter was on the list > of things I wanted to get to right before my 9front laptop broke :P > > Both merge and rebase, IIRC, will try comparing every path on either > side (or all three sides for 3-way merges, rather), even if e.g. the > parent directory doesn't exist. > > So if you do e.g. > > % mkdir /tmp/foo > % cd /tmp/foo > % git/init > % touch foo > % git/add foo > % git/commit -m 'initial commit' foo > % git/branch -nb front tmp > # Copy the entire Go tree in here > % clone -v /tmp/go/* . > % git/add go > % git/commit -m 'add go' go > % git/branch front > > Any merge you do between these two branchs will check EVERY PATH IN THE > GO TREE, even though go only exists on one side. > > What we basically need is for diff3 or merge to take in the roots, and > walk the tree intelligently, writing off entire directories rather than > attempting every child. > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mf7d5e4599a717ca072cb06ed Delivery options: https://9fans.topicbox.com/groups/9fans/subscription