Need help cleaning up git repository
joel at rtems.org
Thu Nov 5 16:16:42 UTC 2020
On Thu, Nov 5, 2020 at 9:51 AM <dufault at hda.com> wrote:
> > On Nov 5, 2020, at 09:40 , Jan.Sommer at dlr.de wrote:
> > Ok, I hope I understand everything correctly.
> > Still, best to make a local copy of your repository directory.
> I shall do that.
> >> You can see that my master is ahead of origin/master, and my local
> >> that I'd like to clean up (e.g. mvme5500-final, atsam-fixes) also
> include those
> >> changes.
> >> I think I want to do something like:
> >> - Rename my local master branch to a branch name that is related to the
> >> changes I put in;
> > # Create a new branch from your local master branch under a new name
> > $ git branch NewBranchName master
> > # Reset the local master branch to be in line with origin/master (your
> changes will still be in NewBranchName)
> > $ git checkout master
> > $ git reset --hard origin/master
> This sounds straight-forward.
> >> - Drop the changes I made that on that branch in the other branches, e.g
> >> mvme5500-final, atsam-fixes etc so that those branches are now based on
> >> origin/master and only have the changes related to what I was working
> > You might achieve that with a rebase in the respective branch, e.g. for
> > $ git checkout mvme5500-final
> > $ git rebase -i origin/master
> > This should open a terminal with all commits in this branch since
> origin/master with the oldest commit at the top.
> > Simply, delete the full lines of all the commits you don't want to keep
> in the branch, i.e. the one from your old master, save and close.
> > If you are lucky and no conflicts appear, you end up with a branch which
> is based on origin/master with only the commits you want.
> > Another option would be to create a new branch based on origin master
> and cherry-pick the commits you want to keep from mvme5500-final using git
> > $ git branch mvme5500-new mvme5500-final
> > $ git checkout mvme5500-new
> > # Cherry-pick a single commit
> > $ git cherry-pick <commit hash>
> > # Cherry-pick a set of continuous commits
> > § git cherry-pick <first commit>~..<last commit> # make sure to have
> the "~" after the first hash
> > That's what I could come up with so far.
> I'll try your first suggestion "rebase in the respective branch".
> "mvme5500-final" has too many changes to submit in one chunk. Next I'll
> need to figure out the best way to split those up into manageable,
> reviewable pieces.
Sometimes I merge and reorder patches using "git rebase -i master" as a
Then if it is bad enough, I do a format-patch and start another branch.
Some patches I
apply with git am. Others I apply using patch and commit pieces. This helps
until you get coherent and discrete patches.
This works well if you have changes scattered across files. But if you have
to a single file for multiple purposes you want to submit as separate
patches, I have
stooped to editing the diff file and using patch to apply it in pieces.
This sounds tedious but after you do it a few times, it will become second
I try to be careful never to commit unrelated changes and then use rebase
combine as needed before submitting.
As to your first problem, my procedure is to export the changes as patches,
the git repo with the mess, reclone, make a working branch in the new
pick away. I'm scared of destroying work and the new clone makes me more
conformatable that I am not screwing up something with git magic.
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
> users mailing list
> users at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users