[resending, as I forgot to include git@vger] Am 22.05.21 um 17:48 schrieb Andre Ulrich: > Let's say I have a .txt file on my master branch. I used > > git add . > > and > > git commit -m "blabla" > > so everything is staged and in the history. Now I check out a new branch > > git checkout -b testing > > and edit the .txt file. I add some new lines at the end, but I also > change some of the already existing lines. Then again I add and commit > everything. Then I use > > git checkout master > > and > > git merge testing > > I would expect git to tell me "hey, wait, you have changed some of the > first lines in the .txt file. When you merge, your code on master will > be altered". But git just merges everything in. > Just imagine this was working code, and changing some of the first lines > breaks everything in the following lines. > I think I have found out what is the problem: git considers this a fast > forward merge (since there were no commits on master between the > creation and the merging of the test branch). > But this is annoying. I want to be able to choose, what changes I want > to keep, when I do the merge (just as in case of a 3way merge, when you > can call a graphical merge tool to decide what lines to keep). But in a 3-way merge, you only get to choose which changes you take if there is a conflict. If, in your example, you had committed a change to a different file on master before the merge, you would get a non-fast-forward (3-way) merge, and still no opportunity to choose which changes you take because there would be no conflict. And why do you think we need a general warning "when you merge, your code on master will be altered"? Why would I want to make a merge into master if not to change the code on master? > I know, I could git diff the latest commits hashes of both branches and > then fix the file on testing branch accordingly. But those are two > separate steps, and I want everything to happen in one convenient step. Git encourages good practice, which is to make sure that all commits do not have known bugs. Your desired workflow is bad practice. If you want to follow bad practices, then *you* have to do the extra work, e.g., to fix up a merge that introduced a known-bad commit. -- Hannes
