Package: git
Version: 1:2.47.2-0.2
Severity: normal
File: /usr/lib/git-core/git-subtree
Tags: upstream


Steps

  # apply the patch from #1120063
  git clone https://gitlab.torproject.org/tpo/core/arti
  cd arti
  git checkout -b 87f0e385839c40df06d0abbacc4190cdacc14e01
  git subtree -P maint/rust-maint-common split
  # wait 10-20 minutes for it to churn away


Actual results

  3bf365f2fec6fb913b371b799ca913431f15dae2

  Observe that this commit has a48804f9a0770ab54a117a35c6ffdf4df9387950
  as an ancestor.  a48804f9a0770ab54a117a35c6ffdf4df9387950 is a
  commit from the main history of arti.git, and nothing to do with the
  subtree.


Expected results

  A split git history that has no Arti commits as ancestors.
  Specifically, the output should not contain
  bbcbf479024bd0f80faaf5f3a6665c1a09b25e54, which is the arti.git main
  root commit.


Observations

The history in arti.git is fairly complicated.  But such
back-and-forth merging is normal for a big project developed on a
forge.

The subtree upstream is be8ec72c0b0ced653c618af564387079d9ea8e5f.

I note that
   git-log be8ec72c0b0ced653c618af564387079d9ea8e5f.. maint/rust-maint-common/
prints, almost instantly, a list of the relevant changes that need to
go upstream.  IDK what git-subtree split is doing but it seems to be
much more complicated than it needs to be.


Workaround

I performed the following procedure:

 * In the source (downstream) repo, run
    rm -rf d; git-format-patch -o d be8ec72c0b0ced653c618af564387079d9ea8e5f.. 
-- :maint/rust-maint-common

 * In the destination repo, create a new branch based at the
   last-merged subtree.  In that branch, manually rename overything
   into the subtree prefix (and commit).

 * git-am the patches from above.  They applied cleanly.

 * Rebase away the renaming commit.  git's rename detection applies
   the changes to the right files.  I had to manually git add a new file.

 * Rebase the resulting branch onto upstream (subtree) mainline.

No doubt I will have to do some violence when I merge these changes
back down into the downstream, but I think I can produce a reasonable
result.


-- System Information:
Debian Release: 13.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.41+deb13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages git depends on:
ii  git-man             1:2.47.2-0.2
ii  libc6               2.41-12
ii  libcurl3t64-gnutls  8.14.1-2
ii  liberror-perl       0.17030-1
ii  libexpat1           2.7.1-2
ii  libpcre2-8-0        10.45-1
ii  perl                5.40.1-6
ii  zlib1g              1:1.3.dfsg+really1.3.1-1+b1

Versions of packages git recommends:
ii  ca-certificates              20250419
ii  less                         668-1
ii  openssh-client [ssh-client]  1:10.0p1-7
ii  patch                        2.8-2

Versions of packages git suggests:
ii  gettext-base   0.23.1-2
pn  git-cvs        <none>
pn  git-doc        <none>
ii  git-email      1:2.47.2-0.2
pn  git-gui        <none>
pn  git-mediawiki  <none>
pn  git-svn        <none>
ii  gitk           1:2.47.2-0.2
pn  gitweb         <none>

-- no debconf information

Reply via email to