![]() If your rewrite starts by emptying things out and then replacing, a simple git merge of the experimental branch will give you conflicts of the form "modified by them, deleted by us" for each file with changes in it. If that experimentation proves successful, it might be nice, some time later, to bring some or all of that work back into the rewrite as well. Suppose, for instance, that the project in question has one major branch, and this is the one you intend to rewrite, but it also has one side branch for some experimentation. Moreover, it will allow you to merge this into other branches, with Git showing you conflicts for files modified or created since the "fresh start" point. If you make, as a non-root commit, a commit that empties out the previous version (and has nothing at all, or a simple skeleton, or perhaps even a new, rewritten implementation), you will, in the future, be able to scan back in time, to a point before this fresh start. Sure, it's a rewrite-but there was something before. ![]() This may be true of a rewrite ( massive overhaul, in the original problem description). It was created from scratch it has no preceding history. It has descendents-commits that come after it, that are derived from it-but it has no ancestors. (Then it goes on to ruin this sensible behavior by sorting commits by date, but that's a different problem, and if the dates themselves are sensible, this "ruining" has basically no effect and it's actually all still sensible.) Hence we start with the current, or most recent on some branch(es), commits, and work backwards in time to a root commit.Ī root commit is simply a commit with no parents. When you view Git's commit graph, git log starts with the current commit by default, or the tip-most commit of any named branch. Read on to see what I am talking about.) An orphan branch is a new root commit (To spoil the effect somewhat, but be more useful as an answer, I'd say "go with orphan" since you may need to defer this decision, and "orphan" gives you more options later. ![]() The key is, as usual, Git's commit graph. So which one should you use? The answer to that depends not on what you want to do right now, but rather what you want to do and see later. ), and going on from there.īoth methods are valid and workable. In a comment, exxecc suggested creating a branch from some existing commit, deleting all the contents (e.g., git rm -r. Gregg's answer and the linked possible-duplicate both suggest using git checkout -orphan (the linked question dates back to when -orphan was relatively new).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |