![]() ![]() Just take a look at this Stack Overflow question which is about a similar requirement but in reverse-moving from the engine folder to the root. I have used it, on occasion, but the syntax is janky, you typically have to incorporate a lot of bash, it's often slow, and you could mess up your whole repository. This is a complex git command, that frankly, scares me. That's great for when you're massaging a PR, but it's really not designed for wholesale rewriting of an entire repository.įor those scenarios, git filter-branch is a better option. This lets me squash commits together, pause to split them apart, reorder them, or remove them entirely. Normally when I'm rewriting history I use git rebase -i in combination with git reset HEAD~. You will likely break all sorts of people's work! This sort of wholesale rewriting of your main/ master branch is definitely not advisable if you are sharing the repo publicly. The history shows them as always having been in the engine folder. With rewriting history, we update the git branches to make it look like all the files were originally committed to the engine subfolder. So what's the alternative? Rewriting history! Rewriting history: the options If the odd file has moved, that's not a big deal, but if literally every file has moved, that's not a great experience. However, if the file has moved, you'll get a 404. The downside to that is that while git itself is ok at tracking file moves (it sometimes gets things wrong), it can cause some other issues.įor example, if you're looking at a file on GitHub, and you want to see what it looks like at a particular commit, then you can use the branch selector to change it. The simplest way to do this is to just move all the files, and create a new commit with the changes, job done. gitignore files, which are still at the top level. Everything has been moved to an engine subfolder.So I started with a directory that looked like this:Īnd I wanted a directory that looked like this: So rather than having all the existing code in the root directory, I wanted to move it to a child directory. I was working on a small side project the other day, when I realised it would really make sense for it to effectively be a "monorepo". There's a whole world of pain there, as other people will likely have started branches from the branch, and they can easily end up in a complete mess. What I don't do is rewrite the history of my main/ master branch. I use git push origin -force-with-lease so much, that I have it aliased as git pof. ![]() I like to make lots of small commits and tidy them up later using interactive rebase, and to rewrite my PRs to make them easier to understand (and review). Background: rewriting git historyĪs a git user, I like to Rebase. The "pop" option will reapply the last saved state and, at the same time, delete and clean it from the Stash.In this post I describe how I used git-filter-repo to rewrite the history of a git repository to move files into a subfolder. Running this command will result in a clean Working Copy, but the changes are saved on Git's "Stash" so you can restore them at a later point if you need them: $ git stash pop That's when - instead of discarding them - you can choose to save them temporarily: $ git stash -include-untracked Sometimes, you won't be 100% sure if you really don't need your local changes anymore. If, additionally, you have untracked (= new) files in your Working Copy and want to get rid of those, too, then the git clean command is your friend: $ git clean -fĪgain: please be careful with these commands! Once you've discarded your local changes, you won't be able to get them back! Saving Changes on the Stash If you want to undo all of your current changes, you can use the git restore command with the "." parameter (instead of specifying a file path): $ git restore. In case you are using the Tower Git client, you can discard local changes in a file simply from its contextual menu - or even discard only parts of your changes, while keeping the rest: Discarding All Local Changes Please be careful because you cannot get these changes back once you've discarded them! This will undo all uncommitted local changes in the specified file. If you want to discard this type of changes, you can use the git restore command: git restore index.html They exist in your Working Copy, but you haven't wrapped them in a commit, yet. Changes that haven't been committed to the local repository are called "local" changes in Git. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |