git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Ulrich <andre.ulrich@smail.fh-koeln.de>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Johannes Sixt <j6t@kdbg.org>, Git Mailing List <git@vger.kernel.org>
Subject: Re: fast forward merge overwriting my code
Date: Mon, 24 May 2021 06:13:55 +0000	[thread overview]
Message-ID: <20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de> (raw)
In-Reply-To: <YKrsC9CaG/KDvDBi@camp.crustytoothpaste.net>

Hello everybody, thanks for your help, I really appreciate it!

What I have described was only an abstract example, because I did not  
want to bother you with the whole story. I will try to explain my  
actual situation:
- first: there is no txt. file, it is jupyter notebooks (.ipynb) and  
they are not only about programming, there are also lots of markdown
- second: I am working with my professor over GitLab and I look for  
options to further improve these notebooks
- third: I have to develope a nice GitLab workflow

I know, diffing and merging of notebooks is another story (but we can  
handle that with nbdime).
And I know, there are lots of guides on git workflows on the internet  
(and that is pretty much just what I have adopted).

So this is how we proceed:
- my prof has a repo on GitHub
- I have forked the repo
- I have cloned the forked repo
- I have created a branch 'update' in my local clone
- I edit a notebook on the branch 'update' and commit
- I push 'update' to my forked repo on GitHub
- I create a merge request
- my prof reviews the changes and accepts them (if I have done  
acceptable work)

So the last point is where we still want to do some fine tuning. Right  
now this looks about: my prof fetches my edits and locally checks out  
a branch to compare the changes with git diff.
But in this diff view you can't edit the files. So you have to  
separately open up another window to edit the changes (lets say my  
prof only wants to keep some of my changes, but not all).

So my Question is: is there any possibility, to be able to view (and  
even edit, if necessary) the changed notebook in the merging process  
(as in my example with the 3way merge)?
Or is the only option to separately view the diff and edit the  
notebook (two seperate steps instead of one)?

The latter would also be acceptable, if it really is the only way. Bu  
it would be nice, if viewing and editing could be done in one  
convenient step during merging.

Many greetings
André Ulrich


Zitat von "brian m. carlson" <sandals@crustytoothpaste.net>:

> 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


-- 
**********************************************************************
**  Fachhochschule Koeln / Cologne University of Applied Sciences
**
**  Andre Ulrich
**  E-Mail: andre.ulrich@smail.fh-koeln.de
**********************************************************************


  reply	other threads:[~2021-05-24  6:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22 15:48 fast forward merge overwriting my code Andre Ulrich
2021-05-22 17:12 ` Philip Oakley
2021-05-23 15:01   ` Junio C Hamano
2021-05-24  9:50     ` Philip Oakley
2021-05-23  9:48 ` Johannes Sixt
2021-05-23 23:58   ` brian m. carlson
2021-05-24  6:13     ` Andre Ulrich [this message]
2021-05-24 11:13       ` Bagas Sanjaya
2021-05-24 13:16       ` Philip Oakley
2021-05-24 15:06         ` Andre Ulrich
2021-05-24 18:48           ` Philip Oakley
2021-05-25 15:14             ` Philip Oakley
2021-05-30  5:31             ` David Aguilar
2021-05-30 11:00               ` Philip Oakley
2021-05-24 17:47       ` Igor Djordjevic
2021-05-26  2:53       ` Felipe Contreras
2021-05-26 11:06         ` Philip Oakley
2021-05-26 18:33           ` Felipe Contreras
2021-05-26 20:35             ` Philip Oakley
2021-05-26 23:34               ` Felipe Contreras
2021-05-27 12:05                 ` Philip Oakley
2021-05-27 14:00                   ` Felipe Contreras
2021-05-27 15:12                     ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de \
    --to=andre.ulrich@smail.fh-koeln.de \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).