neromono.blogg.se

1. #GIT IT DONE HOW TO#
2. #GIT IT DONE INSTALL#
3. #GIT IT DONE UPDATE#
4. #GIT IT DONE MANUAL#
5. #GIT IT DONE CODE#

Instead of installing Python, I'll run a Docker image that already has Python installed, map the drive to my project, and work inside the docker image! Docker to the rescue!ĭocker is such a great use-case for something like this, where I want to quickly try a tool, and don't want to risk messing up my machine.

#GIT IT DONE INSTALL#

Python on Windows can be problematic (even the install instructions make that clear) and while you can install Python from the Microsoft Store, I really didn't want to go through that. The only problem from my point of view, is that git-filter-repo is a Python module.

#GIT IT DONE MANUAL#

I think you'll agree that's much clearer! The manual is also very good, with lots of examples. That whole git filter-branch expression in the previous section could be rewritten with git-filter-repo to be something like this: git filter-repo -path-rename engine/: And the really nice thing is that the API is so much nicer. In fact, it's a single Python file, but it's written to feel like a git plugin. Git-filter-repo isn't built-in to git itself. "Installing" git-filter-repo using Docker

#GIT IT DONE HOW TO#

So instead of trying to figure out how to mangle git filter-branch to my liking, I decided to look at at a suggestion I saw elsewhere: git-filter-repo. Would you want to write your own? Almost certainly not. Then mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE" \ One of the suggested answers suggests running the following command: git filter-branch -f -index-filter 'PATHS=`git ls-files -s | sed "s/^engine//"` \ 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.

#GIT IT DONE UPDATE#

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.

#GIT IT DONE CODE#

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. 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.