On 2021-05-23 at 09:48:55, Johannes Sixt wrote: > [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). Yes. However, if Git did an actual merge, the result would be the same. In a three-way merge, if one side changes, and the other does not, the change is adopted. A fast-forward merge just avoids the merge commit. > > 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 suspect Andre has a goal here or a specific use case that we're not understanding. If we got some more explanation about what's going on, we could probably offer a more useful response addressing that specific use case or goal. It might not be a use case we support, but at least we could address it directly. -- brian m. carlson (he/him or they/them) Houston, Texas, US