I've split git repos before and using filter-branch is the key to keep the
desired and purge the rest.

>From my notes, these two posts helped me:
*
https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
*
https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/

These are my shortcut notes for doing so, hope they are clear enough for
you and help. In a new repo, locally convert a current source subdirectory
to the root directory and purge everything else; then push to remote and
locally cleanup:

   1.

   Make directory for new repo from current repo:

git clone current-repo to-new-directory

   1.

   Disconnect from current remote immediately to prevent catastrophe and
   verify none set

git remote rm origin

git remote -v

   1.

   Keep desired dir and move it to top level, remove the rest
   1.

      FOLDER-NAME: which one to keep and move to top level
      2.

      BRANCH-NAME: which branch to do this on (must exist, e.g. master)

git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
BRANCH-NAME

   1.

   Setup remote repo and verify set

git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
<https://host-stuff.com/NEW-REPOSITORY-NAME.git>

git remote -v

   1.

   Push to new repo

git push -u origin BRANCH-NAME

   1.

   Further cleanup: delete all tags (locally only (Powershell))

git tag | foreach-object -process { git tag -d $_ }

   1.

   Further cleanup: remove local unreachable/recyclable commits (remnants
   of prior)

git reflog expire --expire-unreachable=now --all

git gc --prune=now


On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <herve.bout...@free.fr> wrote:

> nice work done
> I published the result to https://maven.apache.org/ref/caching-LATEST/
>
> now, on moving source to a separate Git repository, I did a basic test
> pushing
> to a new repository:
> https://github.com/hboutemy/maven-build-cache-extension
>
> this leads to getting quite a lot of Maven history
>
> I'm not a Git wizard: is there a way to cut down the history to keep only
> the
> interesting part when the build cache code donation was done?
>
> Regards,
>
> Hervé
>
> Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <herve.bout...@free.fr> a
> écrit :
> > > we have most plugins that are simple with only 1 mono-module build
> > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > see https://maven.apache.org/components/plugins/ for full list
> > >
> > > we have a few components that have a plugin as part of a larger
> > > multi-module
> > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > release, and
> > > soon wrapper
> > >
> > > And from experience, it makes documentation harder because there is
> always
> > > the
> > > question of what to write in the plugin pages and what to write in
> other
> > > modules. Not talking of navigation from /plugins/maven-xxx-plugin to
> /xxx/
> > > maven-xxx-plugin (we have a trick for redirecting...)
> > >
> > > In caching case, I see that there is only one submodule, that is done
> for
> > > ITs
> > > with Surefire: is it necessary? isn't maven-invoker-plugin usable, like
> > > for
> > > plugins?
> >
> > Yes, that's actually a good point.  I thought about that when I read
> Tamás
> > answer.  I'll double check if the integration tests can be merged into a
> > single module.
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > I think the repository name should not contain 'extension', similar
> to
> > > > surefire which provides a plugin, but it a bit more complex
> > > > The fact that it is provided as an extension is a technicality in
> this
> > >
> > > case
> > >
> > > > imho.
> > > > No big deal though...
> > > >
> > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a
> > >
> > > écrit :
> > > > > Howdy,
> > > > >
> > > > > I'd rather group ASF extensions (are there any existing ones aside
> of
> > > > > caching?),
> > > > > to be clear... so GH repo could be something like
> > > > > apache/maven-caching-extension
> > > > > apache/maven-foobar-extension
> > > > > etc?
> > > > >
> > > > > T
> > > > >
> > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gno...@apache.org>
> > >
> > > wrote:
> > > > > > Following the recent work done to integrate the maven caching /
> > > > >
> > > > > incremental
> > > > >
> > > > > > build system into maven, I think it's now time to discuss where
> we
> > >
> > > want
> > >
> > > > > its
> > > > >
> > > > > > long-term location to be.
> > > > > >
> > > > > > This extension was donated a few months ago and provides local
> and
> > > > > > remote
> > > > > > caching of maven project's output, based on computed hashes of
> the
> > > > >
> > > > > inputs.
> > > > >
> > > > > > It's defined as a maven extension and can be used as a core or
> build
> > > > > > extension.  This avoids building the project and speeds up
> builds a
> > >
> > > lot
> > >
> > > > > > !
> > > > > >
> > > > > > The current status of this work resides in 3 branches:
> > > > > >   * MNG-7129-3.8.x (PR at
> https://github.com/apache/maven/pull/622)
> > > > > >   * MNG-7129-master (PR at
> https://github.com/apache/maven/pull/607)
> > > > > >   * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > >
> > > > > > The two first PRs include the required changes to integrate the
> > > > > > extension
> > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch
> is
> > >
> > > the
> > >
> > > > > one
> > > > >
> > > > > > that should be moved to a separate repository and contain the
> code
> > >
> > > for
> > >
> > > > > the
> > > > >
> > > > > > extension.  The goal is to agree on the location and the final
> name
> > >
> > > for
> > >
> > > > > the
> > > > >
> > > > > > repository (it can't be changed easily).
> > > > > >
> > > > > > I propose maven-caching as the repository / subproject name, but
> any
> > > > >
> > > > > better
> > > > >
> > > > > > name is welcomed of course.
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Reply via email to