On Thu, Jul 08, 2021 at 10:43:45AM -0400, Christopher W. Ryan wrote: > Thank you for the help, Konstantin. > > (For clarity and simplicity of discussion, henceforth I am omitting > spaces from filenames) > > Just to clarify (my ASCII diagram may not have come through clearly), I > made and committed several changes to fileA *while* my colleague was > adding lines to her copy of fileA (under the new name fileQ) outside of > git's purview.
The diagram came through just OK - no worries ;-) > How do I get those external-to-git new lines in her fileQ into my > current fileA? Those lines exist only in fileQ, not in fileZ. This issue is, well, a non-issue as long as Git is concerned because reconciling changes made concurrently to the same set of files - including conflicting changes - is a part of any typical version control-based workflow; for software developers, it's so routine a part they usually do not even think of mentioning - just as I did. Well, after you will have completed the sequence I've proposed, you will have two states of DA/fileA recorded in the tip commits of two branches: one is "master" and another is "withindex". They share a common commit - the point of their divergence - it's the last commit in which they had identical contents. There are multiple ways of coercing the divergent lines of development into one but if you're not familiar with it, as it seems, I'd recommend to get accustomed with the concept of "merging" first. A good and easily accessible intro to it is given in [1]. Basically the idea is that when you merge "withindex" into "master" by running $ git checkout master $ git merge withindex Git will 1. Find the so-called "merge base" between these two branches; a merge base is the last commit the branches share, a fork point, that is. 2. For each branch, Git generates the difference between that branch's tip commit and the merge base. 3. Git compares the diffs and tries to figure out, if it can construct the new state of each file which has been changed on both branches since their merge base - in such a way that the new state includes all the changes from both branches. Sometimes the changes overlap (they touch the same places of the file as recorded in the merge base commit) and then Git declares a so-called conflict on that part of the file, throws up and requires you to manually reconcile both the changes before completing the merge operation. When declaring a conflict, Git modifies each conflicting place of the file in a special way so that it includes both changes, delimited with a special markup. If it's hard for you to manually tinker with such a markup, a host of visual tools exist which can help with resolving conflicts. 1. https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20210708174012.bk4l2g7q5xpzy7ic%40carbon.
