fast forward merge overwriting my code

fast forward merge overwriting my code

[Andre Ulrich]

Hello community,

I am new to git, and at the moment I am learning the basics. There are  
loads of good videos on the internet, but I have one specific  
question, I haven't found the answer yet:

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).
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.

Is there any possibility to do so?

Many thanks for any help in advance!
Many greetings
André Ulrich
-- 
**********************************************************************
**  Fachhochschule Koeln / Cologne University of Applied Sciences
**
**  Andre Ulrich
**  E-Mail: andre.ulrich@smail.fh-koeln.de
**********************************************************************

Re: fast forward merge overwriting my code

[Philip Oakley]

On 22/05/2021 16:48, Andre Ulrich wrote:
>
> Hello community,
>
> I am new to git, and at the moment I am learning the basics. There are
> loads of good videos on the internet, but I have one specific
> question, I haven't found the answer yet:
>
> 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).

maybe `git merge --no-ff testing` for use of a command line option

or setup your .gitconfig e.g. `git config --global merge.ff no`,
but also `git config --global pull.ff yes` if you are using `git pull`
(=fetch + merge)

As always, check the manual to ensure understanding.

> 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).
> 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.
>
> Is there any possibility to do so?
>
> Many thanks for any help in advance!
> Many greetings
> André Ulrich
Philip

Re: fast forward merge overwriting my code

[Johannes Sixt]

[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

Re: fast forward merge overwriting my code

[Junio C Hamano]

Philip Oakley <philipoakley@iee.email> writes:

> On 22/05/2021 16:48, Andre Ulrich wrote:
>> .... 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.
> ...
> maybe `git merge --no-ff testing` for use of a command line option
>
> or setup your .gitconfig e.g. `git config --global merge.ff no`,
> but also `git config --global pull.ff yes` if you are using `git pull`
> (=fetch + merge)

I didn't get an impression that this has anything to do with
fast-forwarding, though.  The file in question has changes on the
"testing" branch since it forked from "master", and the user is
merging, i.e. the user _assumes_ that the tip of each branch suits
his/her purpose better than the tip of the other branch, hence wants
to take improvements on both branches incorporated into a single
history--- which is the point of "merging" the testing branch into
the master branch.  The result of merging might reveal that the tip
of the other branch wasn't as great as s/he earlier thought, in
which case s/he may want to undo the merge.  But if the result of
merging better suites his/her purpose, it would be an improvement
over where 'master' used to be (and it would also be an improvement
over where 'testing' used to be), and the world makes a progress.

In this particular case, the "master" side did not move since the
two branches forked, so the merge was to take improvements made on
"testing" into "master", and if the edit to the file in question
made on "testing" were bogus, the merging operation of course will
bring that breakage in, together with all the other changes.  Since
the lack of any progress on the "master" side does not change this
picture, I do not think fast-forwardness has anything to do with
what Andre is complaining about.

"git merge" cannot be expected to inspect the file and point out
"no, the edit they made on the testing branch is totally bogus,
don't merge it".  That is left for humans and tools other than Git
(like test suite) may help them.

Re: fast forward merge overwriting my code

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: fast forward merge overwriting my code

[Andre Ulrich]

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
**********************************************************************

Re: fast forward merge overwriting my code

[Philip Oakley]

On 23/05/2021 16:01, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> On 22/05/2021 16:48, Andre Ulrich wrote:
>>> .... 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.
>> ...
>> maybe `git merge --no-ff testing` for use of a command line option
>>
>> or setup your .gitconfig e.g. `git config --global merge.ff no`,
>> but also `git config --global pull.ff yes` if you are using `git pull`
>> (=fetch + merge)
> I didn't get an impression that this has anything to do with
> fast-forwarding, though.  

Andre had (in the body of the text) explicitly said that it was the fast
forward that was the problem for him.

I suspect he had a mental model / world view / weltanshauung that was
more aligned to a swim lane model of branches (named lines of
development) and that, possibly in a GUI, the loss two lanes was rather
confusing.

> The file in question has changes on the
> "testing" branch since it forked from "master", and the user is
> merging, i.e. the user _assumes_ that the tip of each branch suits
> his/her purpose better than the tip of the other branch, hence wants
> to take improvements on both branches incorporated into a single
> history--- which is the point of "merging" the testing branch into
> the master branch.  

In his description it's not always clear "also change some of the
already existing lines" what happened elsewhere that could lead to the
confusion. It will have been tricky for Andre, as someone new to git, to
really know what was going on. We can't assume the new user knows what
Git will do.

> The result of merging might reveal that the tip
> of the other branch wasn't as great as s/he earlier thought, in
> which case s/he may want to undo the merge.  But if the result of
> merging better suites his/her purpose, it would be an improvement
> over where 'master' used to be (and it would also be an improvement
> over where 'testing' used to be), and the world makes a progress.
>
> In this particular case, the "master" side did not move since the
> two branches forked, so the merge was to take improvements made on
> "testing" into "master", and if the edit to the file in question
> made on "testing" were bogus, the merging operation of course will
> bring that breakage in, together with all the other changes.  Since
> the lack of any progress on the "master" side does not change this
> picture, I do not think fast-forwardness has anything to do with
> what Andre is complaining about.
>
> "git merge" cannot be expected to inspect the file and point out
> "no, the edit they made on the testing branch is totally bogus,
> don't merge it".  That is left for humans and tools other than Git
> (like test suite) may help them.
>
>
The changes to mental models that are needed to understand Git can take
some time, especially for those who haven't grown up with it.

Philip

Re: fast forward merge overwriting my code

[Bagas Sanjaya]

Hi Andre,

On 24/05/21 13.13, Andre Ulrich wrote:
> 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.

When you run git merge, when Git decided that automerging with 3-way
merge can be done without conflicts, the editor will be fired up for
you to enter commit message. Delete or comment all the message lines
to abort the commit by "empty message" mechanism.

Now you can view diff (git diff) or edit the merged files as you
wish. Of course, you can coordinate with author of branch you're
merging from to get consensus. After then, git commit.

Similar steps can be done for merge conflicts. Git will pause merging
process when conflicts occur, and you need to edit to resolve them.
Again, coordinating with original branch author is helpful to decide
the resolution.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: fast forward merge overwriting my code

[Philip Oakley]

Hi André, In-line and bottom posting is preferred.

On 24/05/2021 07:13, Andre Ulrich wrote:
> 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
I've not used jupyter notebooks so below is more about the general process..

> - 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
GiLab noted here
>
> 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
but GitHub here..
> - 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

So this is using the on-line web UI?

There is some contention between the GitHub/GitLab pull/merge request
process (on-line) and the local command line (cli) approach to merging
as they can be at cross-purposes...

Most earlier responses have been about using the command line rather
than the web-UI.

The Git-for-Windows (GfW) development does use the GitHub PR approach,
leveraging the email notifications, and the ability (of the developer,
in response to maintainer comments) to force push an updated branch
(i.e. using the same branch name) to re-run the approval and on-line
merging.

> - my prof reviews the changes and accepts them (if I have done
> acceptable work)
i.e. the PR was/will be taken verbatim, (or with minor amendments if the
prof is the maintainer and you've allowed that), at least on GitHub..
>
> 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. 
Hmm, do you mean the prof is viewing your changes in the diff-view of
the web-UI? (likely as that's the notification link;-).
You/The prof can switch to views with more context if needed.

If the prof has truly fetched the branch from your remote e.g.
"Ulrich/testing" it can be checked out locally as a detached head for
testing, local changes made, etc, and then the prof can either create a
fresh branch to hold those comments, and push them to a place you can
see, or directly make the edits on the web-UI.

Often in the GfW PR reviews the comments are made via the web-UI, with
code suggestions, and the developer than updates & tests their local
branch, and force pushes the update for a follow up review.

> 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)?

I'm not aware of such a mechanism (as simply described) but I'm sure
there are ways to use the "staging area" view (e.g. via the Git-gui) to
selectively pick out hunks and lines that are staged (and non-selected
hunk/lines stashed) to give a testable worktree during the 'merge'.
Merge is commonly seen/discussed as a single continuous step, rather
than being a fully uninterruptible process.

> 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.

The key here is probably to clarify which parts are being done on the
server's web-UI, and which parts are from a local fetch/checkout viewpoint.

Philip

>
> 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
>
>

Re: fast forward merge overwriting my code

[Andre Ulrich]

Hi Philip, thanks for your detailed answer!
Zitat von Philip Oakley <philipoakley@iee.email>:

> Hi André, In-line and bottom posting is preferred.
>

Oh ok, thanks for the tip.

> On 24/05/2021 07:13, Andre Ulrich wrote:
>> 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
> I've not used jupyter notebooks so below is more about the general process..
>
>> - 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
> GiLab noted here
>>
>> 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
> but GitHub here..

sorry, I have mixed it up. It meant GitLab

>> - 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
>
> So this is using the on-line web UI?

Yes, I press the button "Create merge request" (it autmatically  
appears, as soon as I have pushed a new branch into the forked repo).  
But all the other steps (besides the forking)
are done in the Git-for-Windows bash command line.
Then my prof receives a notification (also UI button in GitLab). At  
this point, my prof could even view the changes on GitLab, BUT...  
(GOTO1)

>
> There is some contention between the GitHub/GitLab pull/merge request
> process (on-line) and the local command line (cli) approach to merging
> as they can be at cross-purposes...
>
> Most earlier responses have been about using the command line rather
> than the web-UI.
>

Yes, the merging is done locally via command line. After locally  
mergin, the resulting master is pushed back to GitLab

> The Git-for-Windows (GfW) development does use the GitHub PR approach,
> leveraging the email notifications, and the ability (of the developer,
> in response to maintainer comments) to force push an updated branch
> (i.e. using the same branch name) to re-run the approval and on-line
> merging.
>
>> - my prof reviews the changes and accepts them (if I have done
>> acceptable work)
> i.e. the PR was/will be taken verbatim, (or with minor amendments if the
> prof is the maintainer and you've allowed that), at least on GitHub..
>>
>> 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.
> Hmm, do you mean the prof is viewing your changes in the diff-view of
> the web-UI? (likely as that's the notification link;-).
> You/The prof can switch to views with more context if needed.

(FROM1) ... diffing jupyter notebooks in the GitLab web UI looks  
horrible (because common diff tools can't really handle the notebooks  
underlying json structure).
Thats why my prof diffs the notebooks locally via command line. And  
then also the merging happens locally via command line. After mergin,  
the master is beeing pushed back to GitLab

>
> If the prof has truly fetched the branch from your remote e.g.
> "Ulrich/testing" it can be checked out locally as a detached head for
> testing, local changes made, etc, and then the prof can either create a
> fresh branch to hold those comments, and push them to a place you can
> see, or directly make the edits on the web-UI.
>

Yes, that fetching and checking out is exactly what's happening.  
That's how my prof locally reviews my changes to decide whether they  
are good or not.

> Often in the GfW PR reviews the comments are made via the web-UI, with
> code suggestions, and the developer than updates & tests their local
> branch, and force pushes the update for a follow up review.
>
>> 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)?
>
> I'm not aware of such a mechanism (as simply described) but I'm sure
> there are ways to use the "staging area" view (e.g. via the Git-gui) to
> selectively pick out hunks and lines that are staged (and non-selected
> hunk/lines stashed) to give a testable worktree during the 'merge'.

Ah ok, this could be an idea (it would requiere some more research, as  
I haven't used the git gui before (I want to learn everything from the  
scratch using the command line))
But to be honest, I think even this approach might already be too  
cumbersome (as this selectively picking and stashing sounds like a lot  
of work itself).
But maybe I'm looking for a workflow too simple (that doesn't even  
exist like that), and my prof just has to accept a little more effort  
for diffing and merging?

> Merge is commonly seen/discussed as a single continuous step, rather
> than being a fully uninterruptible process.
>
>> 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.
>
> The key here is probably to clarify which parts are being done on the
> server's web-UI, and which parts are from a local fetch/checkout viewpoint.
>

both the viewing (diff) and the editing (separate editor) are beeing  
done locally

Anyway, Philip, thanks again for the detailed answer and your time!

Many Greetings
André Ulrich

> Philip
>
>>
>> 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
**********************************************************************

Re: fast forward merge overwriting my code

[Igor Djordjevic]

On 24/05/2021 08:13, Andre Ulrich wrote:
> 
> 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).

I think that last point highlights the issue you guys are having - 
using `merge` for doing both (1) actual merge, but also (2) review and 
edit at the same time, which is wrong (or very unconventional, to say 
the least).

In ideal case (meaning no conflicts, no matter if 3-way merge or a 
fast-forward one), merge should accept all the changes being merged 
in from the side branch and incorporate them into the main branch. 

From this basic and the most common scenario alone it is visible that 
merge should not "keep some changes, but not all" - the very point of 
a merge is to (try to) keep _all the changes_, period.

Now, as for the "try to" part - in some cases not all changes can be 
kept as they are, like when both branches changed same files and same 
lines (or close to), so that's when Git hands over the resolution to 
the user, to determine what is the desired outcome of a conflicting 
merge.

Still, even in this case, the final outcome should be considered a 
sum of all the changes, even though some might have been altered or 
rearranged in order to better work with each other (as different 
branches might have done the same thing in a different way).

In any case, it should not be up to the merge (process nor commit) to 
discard (nor add!) some of the non-conflicting changes you have made on 
your 'update' branch - it is possible to do (something usually called 
an "evil merge", and for a reason), yet is not a good practice.

As an example, imagine you have commits 1, 2 and 3 on your 'update' 
branch, and upon merging your professor decides to accept changes 
from commit 2 only, completely discarding changes from commits 1 and 3. 
Your history will end up looking something like this:

(1) ---X-----------M 'master'
        \         /
         1---2---3 'update'

... where M is the merge commit, merging branch 'update' into 'master'. 
As it is, it's reasonable to expect of M to contain all the changes 
brought in by 1, 2 and 3 - yet it is not the case, which could be 
rather confusing (on later history review).

What would be a more common/usual scenario is, after trying a local 
merge M and seeing some changes should not be accepted (like commits 
1 and 3), have your professor communicate the problem with you so you 
can fix the issues yourself, inside 'update' branch, and iteratively 
repeat this process as long as 'update' branch is not "perfect" - at 
which point it can be accepted _as a whole_, that is.

You professor should not accept to merge your changes as long as they 
are not all correct, and he specifically should not be using the 
merge to correct the issues himself.

Depending on your preference, he _could_ be doing the changes himself, 
too - but again doing so through standalone commits (on your 'update' 
branch, for example), _not_ through a merge commit.

Based on example (1) above, the finally merged changes history could 
instead look like this:

(2) ---X-------------------M1 'master'
        \                 /
         1---2---3---4---5 'update'

..., where commits 4 and 5 are fixes made on 'update' after your 
professor's comments on commits 1, 2 and 3, and M1 is the merge which 
finally accepts all the changes from 'update'.

Alternatively, if you use rebase, you can alter problematic commits 1 
and 3 directly instead, so the history would look something like this:

(3) ---X-----------M2 'master'
        \         /
         1'--2'--3' 'update'

..., where original commits 1 and 3 are changed in order to be 
acceptable for the merge, becoming commits 1' and 3', while commit 2' 
would stay the same as original commit 2. Again, merge commit M2 
accepts all the changes as they now are (all correct).

Also, if commits 1 and 3 are completely wrong and not required in the 
first place, yet another alternative (using rebase) would be to drop 
them altogether, ending up with a history like this:

(4) ---X----M3 'master'
        \  /
         2" 'update'

..., where commit 2" would be exactly the same as original commit 2, 
and commits 1 and 3 are dropped from the history completely - and 
transparently, _not_ using the merge to do so, as in original example (1)
(and your explained scenario).

I hope these examples somewhat help, the main point remaining that 
merge should not be used to discard/disapprove certain (especially 
non-conflicting) changes, but only to finally accept/approve _all_ 
the changes, possibly modified in the meantime as a result of an 
iterative review and additional work.

Note that there's nothing wrong in having your professor do his own 
local merges as part of this review process, but those should be only 
temporary, to be discarded and not accepted until everything can be 
merged (and accepted) as-is.

Regards, Buga

Re: fast forward merge overwriting my code

[Philip Oakley]

adding Pratyush for the Git Gui stash suggestion..

On 24/05/2021 16:06, Andre Ulrich wrote:
> Hi Philip, thanks for your detailed answer!
> Zitat von Philip Oakley <philipoakley@iee.email>:
>
>> Hi André, In-line and bottom posting is preferred.
>>
>
> Oh ok, thanks for the tip.
>
>> On 24/05/2021 07:13, Andre Ulrich wrote:
>>> 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
>> I've not used jupyter notebooks so below is more about the general
>> process..
>>
>>> - 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
>> GiLab noted here
>>>
>>> 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
>> but GitHub here..
>
> sorry, I have mixed it up. It meant GitLab
>
>>> - 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
>>
>> So this is using the on-line web UI?
>
> Yes, I press the button "Create merge request" (it autmatically
> appears, as soon as I have pushed a new branch into the forked repo).
> But all the other steps (besides the forking)
> are done in the Git-for-Windows bash command line.
> Then my prof receives a notification (also UI button in GitLab). At
> this point, my prof could even view the changes on GitLab, BUT... (GOTO1)
-> (FROM1)..
>
>>
>> There is some contention between the GitHub/GitLab pull/merge request
>> process (on-line) and the local command line (cli) approach to merging
>> as they can be at cross-purposes...
>>
>> Most earlier responses have been about using the command line rather
>> than the web-UI.
>>
>
> Yes, the merging is done locally via command line. After locally
> mergin, the resulting master is pushed back to GitLab

You could use --no-commit, so that the merge can be inspected and the
relevant parts picked or updated, but beware losing the second parent
link, and that you could be creating an "evil merge" (in Git terminology
that's content that was in neither parent.., rather than an automated
conflict free merge..)

For your pushing (as opposed to the professor's) look ate the
remote.pushDefault config setting allowing you to have the prof's repo
as your upstream, but your own fork as the place you naturally push to
(see
https://lore.kernel.org/git/?q=%3C20191031154217.GA30187%40sigill.intra.peff.net%3E).

Are others also doing development in the same notebook or on the same
repo during this review cycle? This can affect how any overlaps in the
changes affect each other

>
>> The Git-for-Windows (GfW) development does use the GitHub PR approach,
>> leveraging the email notifications, and the ability (of the developer,
>> in response to maintainer comments) to force push an updated branch
>> (i.e. using the same branch name) to re-run the approval and on-line
>> merging.
>>
>>> - my prof reviews the changes and accepts them (if I have done
>>> acceptable work)
>> i.e. the PR was/will be taken verbatim, (or with minor amendments if the
>> prof is the maintainer and you've allowed that), at least on GitHub..
>>>
>>> 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.
>> Hmm, do you mean the prof is viewing your changes in the diff-view of
>> the web-UI? (likely as that's the notification link;-).
>> You/The prof can switch to views with more context if needed.
>
> (FROM1) ... diffing jupyter notebooks in the GitLab web UI looks
> horrible (because common diff tools can't really handle the notebooks
> underlying json structure).
> Thats why my prof diffs the notebooks locally via command line. 
Are these 'large' a commit/changeset, or many smaller commits? And does
your project need good fine detail history (so you can reason about
small changes from months ago)? Some projects benefit from the fine
detail, while for others it's a waste. It will depend on whether it will
help the prof for selecting which commits to accept and which to reject
(rather than having to pick apart a large commit)

> And then also the merging happens locally via command line. After
> mergin, the master is beeing pushed back to GitLab

The --no-commit may be useful here to enable that early inspection
before the actual commit.

>
>>
>> If the prof has truly fetched the branch from your remote e.g.
>> "Ulrich/testing" it can be checked out locally as a detached head for
>> testing, local changes made, etc, and then the prof can either create a
>> fresh branch to hold those comments, and push them to a place you can
>> see, or directly make the edits on the web-UI.
>>
>
> Yes, that fetching and checking out is exactly what's happening.
> That's how my prof locally reviews my changes to decide whether they
> are good or not.

It's worth ensuring that the `rtb` (branch that tracks a remote's branch
- remote tracking branch) concept manages to stick in your head (and the
profs) - you don't need a local branch of the same name as the remote
;-) It took me a few years to get that into my head!

>
>> Often in the GfW PR reviews the comments are made via the web-UI, with
>> code suggestions, and the developer than updates & tests their local
>> branch, and force pushes the update for a follow up review.
>>
>>> 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)?
>>
>> I'm not aware of such a mechanism (as simply described) but I'm sure
>> there are ways to use the "staging area" view (e.g. via the Git-gui) to
>> selectively pick out hunks and lines that are staged (and non-selected
>> hunk/lines stashed) to give a testable worktree during the 'merge'.
>
> Ah ok, this could be an idea (it would requiere some more research, as
> I haven't used the git gui before (I want to learn everything from the
> scratch using the command line))

I commonly use the Gui when picking apart a large commit into smaller
ones when I'm happy that there's no overlaps. Small patches make for
easier merging and fault finding, and better commit messages (good
thesis practice)

> But to be honest, I think even this approach might already be too
> cumbersome (as this selectively picking and stashing sounds like a lot
> of work itself).

Unfortunately the Git Gui doesn't have a menu for stashing remaining
changes, but it's simple to flip over to the terminal to stash from
there to do the testing, and un-stash the remainder afterwards - I'll
maybe suggest the gui could include that capability for these types of
workflows (cc Pratyush Yadav <pratiy0100@gmail.com>).
> But maybe I'm looking for a workflow too simple (that doesn't even
> exist like that), and my prof just has to accept a little more effort
> for diffing and merging?

Often it is a case of tweaking the workflow to use a capability
you/she/he wasn't aware of to give you that improved review process. It
doesn't help that I'm ignorant of how the jupyter notebooks are
internally formatted and how your diffing tool shows it (have you set up
the difftool options for command line use?

>
>> Merge is commonly seen/discussed as a single continuous step, rather
>> than being a fully uninterruptible process.
>>
>>> 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.
>>
>> The key here is probably to clarify which parts are being done on the
>> server's web-UI, and which parts are from a local fetch/checkout
>> viewpoint.
>>
>
> both the viewing (diff) and the editing (separate editor) are beeing
> done locally
>
> Anyway, Philip, thanks again for the detailed answer and your time!

No problem. As an engineer, real world workflows are an interest;-)

Philip
>
> Many Greetings
> André Ulrich
>
>> Philip
>>
>>>
>>> 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
>>>
>>>
>
>

Re: fast forward merge overwriting my code

[Philip Oakley]

On 24/05/2021 19:48, Philip Oakley wrote:
> adding Pratyush for the Git Gui stash suggestion..
Ultimately it's what is described at the end of the stash man page [1]

However that didn't work as expected, having a conflict when doing the
stash pop step, which I hadn't expected.
> On 24/05/2021 16:06, Andre Ulrich wrote:
>> Hi Philip, thanks for your detailed answer!
>> Zitat von Philip Oakley <philipoakley@iee.email>:
>>
>>> Hi André, In-line and bottom posting is preferred.
>>>
>> Oh ok, thanks for the tip.
>>
>>> On 24/05/2021 07:13, Andre Ulrich wrote:
>>>> 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
>>> I've not used jupyter notebooks so below is more about the general
>>> process..
>>>
>>>> - 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
>>> GiLab noted here
>>>> 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
>>> but GitHub here..
>> sorry, I have mixed it up. It meant GitLab
>>
>>>> - 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
>>> So this is using the on-line web UI?
>> Yes, I press the button "Create merge request" (it autmatically
>> appears, as soon as I have pushed a new branch into the forked repo).
>> But all the other steps (besides the forking)
>> are done in the Git-for-Windows bash command line.
>> Then my prof receives a notification (also UI button in GitLab). At
>> this point, my prof could even view the changes on GitLab, BUT... (GOTO1)
> -> (FROM1)..
>>> There is some contention between the GitHub/GitLab pull/merge request
>>> process (on-line) and the local command line (cli) approach to merging
>>> as they can be at cross-purposes...
>>>
>>> Most earlier responses have been about using the command line rather
>>> than the web-UI.
>>>
>> Yes, the merging is done locally via command line. After locally
>> mergin, the resulting master is pushed back to GitLab
> You could use --no-commit, so that the merge can be inspected and the
> relevant parts picked or updated, but beware losing the second parent
> link, and that you could be creating an "evil merge" (in Git terminology
> that's content that was in neither parent.., rather than an automated
> conflict free merge..)
>
> For your pushing (as opposed to the professor's) look ate the
> remote.pushDefault config setting allowing you to have the prof's repo
> as your upstream, but your own fork as the place you naturally push to
> (see
> https://lore.kernel.org/git/?q=%3C20191031154217.GA30187%40sigill.intra.peff.net%3E).
>
> Are others also doing development in the same notebook or on the same
> repo during this review cycle? This can affect how any overlaps in the
> changes affect each other
>
>>> The Git-for-Windows (GfW) development does use the GitHub PR approach,
>>> leveraging the email notifications, and the ability (of the developer,
>>> in response to maintainer comments) to force push an updated branch
>>> (i.e. using the same branch name) to re-run the approval and on-line
>>> merging.
>>>
>>>> - my prof reviews the changes and accepts them (if I have done
>>>> acceptable work)
>>> i.e. the PR was/will be taken verbatim, (or with minor amendments if the
>>> prof is the maintainer and you've allowed that), at least on GitHub..
>>>> 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.
>>> Hmm, do you mean the prof is viewing your changes in the diff-view of
>>> the web-UI? (likely as that's the notification link;-).
>>> You/The prof can switch to views with more context if needed.
>> (FROM1) ... diffing jupyter notebooks in the GitLab web UI looks
>> horrible (because common diff tools can't really handle the notebooks
>> underlying json structure).
>> Thats why my prof diffs the notebooks locally via command line. 
> Are these 'large' a commit/changeset, or many smaller commits? And does
> your project need good fine detail history (so you can reason about
> small changes from months ago)? Some projects benefit from the fine
> detail, while for others it's a waste. It will depend on whether it will
> help the prof for selecting which commits to accept and which to reject
> (rather than having to pick apart a large commit)
>
>> And then also the merging happens locally via command line. After
>> mergin, the master is beeing pushed back to GitLab
> The --no-commit may be useful here to enable that early inspection
> before the actual commit.
>
>>> If the prof has truly fetched the branch from your remote e.g.
>>> "Ulrich/testing" it can be checked out locally as a detached head for
>>> testing, local changes made, etc, and then the prof can either create a
>>> fresh branch to hold those comments, and push them to a place you can
>>> see, or directly make the edits on the web-UI.
>>>
>> Yes, that fetching and checking out is exactly what's happening.
>> That's how my prof locally reviews my changes to decide whether they
>> are good or not.
> It's worth ensuring that the `rtb` (branch that tracks a remote's branch
> - remote tracking branch) concept manages to stick in your head (and the
> profs) - you don't need a local branch of the same name as the remote
> ;-) It took me a few years to get that into my head!
>
>>> Often in the GfW PR reviews the comments are made via the web-UI, with
>>> code suggestions, and the developer than updates & tests their local
>>> branch, and force pushes the update for a follow up review.
>>>
>>>> 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)?
>>> I'm not aware of such a mechanism (as simply described) but I'm sure
>>> there are ways to use the "staging area" view (e.g. via the Git-gui) to
>>> selectively pick out hunks and lines that are staged (and non-selected
>>> hunk/lines stashed) to give a testable worktree during the 'merge'.
>> Ah ok, this could be an idea (it would requiere some more research, as
>> I haven't used the git gui before (I want to learn everything from the
>> scratch using the command line))
> I commonly use the Gui when picking apart a large commit into smaller
> ones when I'm happy that there's no overlaps. Small patches make for
> easier merging and fault finding, and better commit messages (good
> thesis practice)
>
>> But to be honest, I think even this approach might already be too
>> cumbersome (as this selectively picking and stashing sounds like a lot
>> of work itself).
> Unfortunately the Git Gui doesn't have a menu for stashing remaining
> changes, but it's simple to flip over to the terminal to stash from
> there to do the testing, and un-stash the remainder afterwards

as described in [1], though perhaps imperfectly.
>  - I'll
> maybe suggest the gui could include that capability for these types of
> workflows (cc Pratyush Yadav <pratiy0100@gmail.com>).
>> But maybe I'm looking for a workflow too simple (that doesn't even
>> exist like that), and my prof just has to accept a little more effort
>> for diffing and merging?
> Often it is a case of tweaking the workflow to use a capability
> you/she/he wasn't aware of to give you that improved review process. It
> doesn't help that I'm ignorant of how the jupyter notebooks are
> internally formatted and how your diffing tool shows it (have you set up
> the difftool options for command line use?
>
>>> Merge is commonly seen/discussed as a single continuous step, rather
>>> than being a fully uninterruptible process.
>>>
>>>> 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.
>>> The key here is probably to clarify which parts are being done on the
>>> server's web-UI, and which parts are from a local fetch/checkout
>>> viewpoint.
>>>
>> both the viewing (diff) and the editing (separate editor) are beeing
>> done locally
>>
>> Anyway, Philip, thanks again for the detailed answer and your time!
> No problem. As an engineer, real world workflows are an interest;-)
>
> Philip
>> Many Greetings
>> André Ulrich
>>
>>> Philip
>>>
>>>> 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
>>>>
>>
[1]
https://git-scm.com/docs/git-stash#Documentation/git-stash.txt-Testingpartialcommits

Re: fast forward merge overwriting my code

[Felipe Contreras]

Andre Ulrich wrote:
> 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 for example after fetching your changes your professor sees this:

  % git diff --cached
  --- a/README
  +++ b/README
  @@ -1,5 +1,7 @@
   This is an example document. Lot's of things to fill in.
   
  -[[ insert formula]]
  +The fromula is:
  +
  +  y[1], mu * (1 - y[0] ** 2) * y[1] - y[0]
   
   This will help students jump straight in with simple examples.

The professor can then open the file, fix the typo, do some other
changes, type `git add --update`, then do `git diff --cached` again to
see if that's the output she wants:

  --- a/README
  +++ b/README
  @@ -1,5 +1,7 @@
   This is an example document. Lot's of things to fill in.
   
  -[[ insert formula]]
  +The formula is:
  +
  +  x[1], mu * (1 - x[0] ** 2) * x[1] - x[0]
   
   This will help students jump straight in with simple examples.


What you are saying is that it would be better to do `git $cmd` and in
that command you would be able to view the staged diff, edit the diff,
and after quitting the editor the diff is applied to the stage.

Essentially leaving everything ready for a commit.

Sort of like a combination of: `git diff --cached`,
`vim $problematic_file`, `git add $problematic_file`, `git diff --cached`.

Correct?

> 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.

You are describing `git stage edit`, a subcommand I suggested back in
2014 and went completely ignored [1].

Your professor just types `git stage edit`, fixes any problems she sees,
quits the editor, `git commit`.

Done.

I just rebased the patches from 2016 and they seem to work fine. If you
are interested let me know.

Cheers.

[1] https://lore.kernel.org/git/1398449567-16314-3-git-send-email-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: fast forward merge overwriting my code

[Philip Oakley]

On 26/05/2021 03:53, Felipe Contreras wrote:
> Andre Ulrich wrote:
>> 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 for example after fetching your changes your professor sees this:

Part of Andre's problem was that this diff wasn't stable because the
underlying file format is said to be json so items can move around
without issue (e.g. key value pairs swapping position) and that they
aren't really working on the json file (it may as well be binary..) but
on the jupytper notebook display view, so one step removed from the 'diff'.
>
>   % git diff --cached
>   --- a/README
>   +++ b/README
>   @@ -1,5 +1,7 @@
>    This is an example document. Lot's of things to fill in.
>    
>   -[[ insert formula]]
>   +The fromula is:
>   +
>   +  y[1], mu * (1 - y[0] ** 2) * y[1] - y[0]
>    
>    This will help students jump straight in with simple examples.
>
> The professor can then open the file, fix the typo, do some other
> changes, type `git add --update`, 

  type `git add --update`,
Useful suggestion. Maybe need a corresponding `stash --update --keep-index` command 
(https://git-scm.com/docs/git-stash#Documentation/git-stash.txt-Testingpartialcommits)

> then do `git diff --cached` again to
> see if that's the output she wants:
>
>   --- a/README
>   +++ b/README
>   @@ -1,5 +1,7 @@
>    This is an example document. Lot's of things to fill in.
>    
>   -[[ insert formula]]
>   +The formula is:
>   +
>   +  x[1], mu * (1 - x[0] ** 2) * x[1] - x[0]
>    
>    This will help students jump straight in with simple examples.
>
>
> What you are saying is that it would be better to do `git $cmd` and in
> that command you would be able to view the staged diff, edit the diff,
> and after quitting the editor the diff is applied to the stage.
>
> Essentially leaving everything ready for a commit.
I see it as a two part problem - diff isn't an appropriate tool (the
files are binary-like) but also that it's a review not a resolution of
the issues, which has to pick apart, and comment on, the proposed changes.

I also suspect that it's part of the small commit - large commit
disparity (patches to be as small as possible but no smaller, so most
patches end up too big..)
>
> Sort of like a combination of: `git diff --cached`,
> `vim $problematic_file`, `git add $problematic_file`, `git diff --cached`.
>
> Correct?
I think they have a need for a `git stash` that works when there is an
intervening commit of the staged files (i.e. clean wrt the stash's
staged files).
>
>> 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.
> You are describing `git stage edit`, a subcommand I suggested back in
> 2014 and went completely ignored [1].
>
> Your professor just types `git stage edit`, fixes any problems she sees,
> quits the editor, `git commit`.
>
> Done.
>
> I just rebased the patches from 2016 and they seem to work fine. If you
> are interested let me know.
>
> Cheers.
>
> [1] https://lore.kernel.org/git/1398449567-16314-3-git-send-email-felipe.contreras@gmail.com/
>

Re: fast forward merge overwriting my code

[Felipe Contreras]

Philip Oakley wrote:
> On 26/05/2021 03:53, Felipe Contreras wrote:
> > Andre Ulrich wrote:
> >> 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 for example after fetching your changes your professor sees this:
> 
> Part of Andre's problem was that this diff wasn't stable because the
> underlying file format is said to be json so items can move around
> without issue (e.g. key value pairs swapping position) and that they
> aren't really working on the json file (it may as well be binary..) but
> on the jupytper notebook display view, so one step removed from the 'diff'.

Andre said they use the diff view, and he wants to be able to edit it.
Not sure how else would you interpret "But in this diff view you can't
edit the files".

-- 
Felipe Contreras

Re: fast forward merge overwriting my code

[Philip Oakley]

On 26/05/2021 19:33, Felipe Contreras wrote:
> Philip Oakley wrote:
>> On 26/05/2021 03:53, Felipe Contreras wrote:
>>> Andre Ulrich wrote:
>>>> 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 for example after fetching your changes your professor sees this:
>> Part of Andre's problem was that this diff wasn't stable because the
>> underlying file format is said to be json so items can move around
>> without issue (e.g. key value pairs swapping position) and that they
>> aren't really working on the json file (it may as well be binary..) but
>> on the jupytper notebook display view, so one step removed from the 'diff'.
> Andre said they use the diff view, and he wants to be able to edit it.
> Not sure how else would you interpret "But in this diff view you can't
> edit the files".
>
In
https://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de/
Abdre did say they used the special jupyter notebook diff viewer.

> ..diffing and merging of notebooks is another story (but we can handle
that with nbdime)

[...]

> - 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 while the notebook format is internally text based json, it's not
suitable for real review and editing *in context*, so a different diff
mechanism is used.

Their other problem is the splitting apart of the changes, so the
worktree needs to hold only the staged part of the changes, but with the
other unstaged changes being restorable.

I'm rather interested in this are as it is a common engineering tool
workflow problem.

Philip

Re: fast forward merge overwriting my code

[Felipe Contreras]

Philip Oakley wrote:
> On 26/05/2021 19:33, Felipe Contreras wrote:
> > Philip Oakley wrote:
> >> On 26/05/2021 03:53, Felipe Contreras wrote:
> >>> Andre Ulrich wrote:
> >>>> 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 for example after fetching your changes your professor sees this:
> >> Part of Andre's problem was that this diff wasn't stable because the
> >> underlying file format is said to be json so items can move around
> >> without issue (e.g. key value pairs swapping position) and that they
> >> aren't really working on the json file (it may as well be binary..) but
> >> on the jupytper notebook display view, so one step removed from the 'diff'.
> > Andre said they use the diff view, and he wants to be able to edit it.
> > Not sure how else would you interpret "But in this diff view you can't
> > edit the files".
> >
> In
> https://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de/
> Abdre did say they used the special jupyter notebook diff viewer.

Yes, but that is a separate issue.

Right now they are able to resolve conflicts with a jupyter mergetool.
The tool gets rid of all the extra noise so the user is able to focus
only on the actual important changes. When they exit the tool, their
changes are properly staged.

The problem Andre described in [1] appears when mergetool does *not*
run. In that case the user is forced to run `git diff` (jupyter difftool
will be used), edit the file manually with some viewer, `git add
--update`, and then run `git diff --cached` to verify the changes.

In case an unwanted change sneaks by, the user would have to edit the
file again, or do `git checkout --patch` to selectively remove chunks
(and since this tools presents the diffs in reverse, it's
counterintuitive and error-prone).

This is far from ideal.


The problem is that there is no `git stage edit`, in order to launch the
mergetool.

I just wrote an example `git stage-edit` [2] that does launch the
mergetool even if there are no merge conflicts, allowing the user to
modify the stage directly and with no hassle.

Cheers.

[1] https://lore.kernel.org/git/20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de/
[2] https://dpaste.com/62XS8TTXP

-- 
Felipe Contreras

Re: fast forward merge overwriting my code

[Philip Oakley]

On 27/05/2021 00:34, Felipe Contreras wrote:
> Philip Oakley wrote:
>> On 26/05/2021 19:33, Felipe Contreras wrote:
>>> Philip Oakley wrote:
>>>> On 26/05/2021 03:53, Felipe Contreras wrote:
>>>>> Andre Ulrich wrote:
>>>>>> 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 for example after fetching your changes your professor sees this:
>>>> Part of Andre's problem was that this diff wasn't stable because the
>>>> underlying file format is said to be json so items can move around
>>>> without issue (e.g. key value pairs swapping position) and that they
>>>> aren't really working on the json file (it may as well be binary..) but
>>>> on the jupytper notebook display view, so one step removed from the 'diff'.
>>> Andre said they use the diff view, and he wants to be able to edit it.
>>> Not sure how else would you interpret "But in this diff view you can't
>>> edit the files".
>>>
>> In
>> https://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de/
>> Abdre did say they used the special jupyter notebook diff viewer.
> Yes, but that is a separate issue.
>
> Right now they are able to resolve conflicts with a jupyter mergetool.

I don't believe that ("resolve") is true in the sense they would like. I
don't think they are really 'merging' in an all-in-one `git merge`
sense, rather they are [trying to] splitting and patching and commenting
the changes.

Aside: In my previous employment it just wasn't possible to diff a
tool's save output (MathCAD, a graphic maths whiteboard) because the
structure of their XML file was not conventionally 'linear' -
rearranging object position on the canvas did not move them in the file,
you had to 'guess' (try and visualise) the objects movement and effect
on computational order. It just wasn't worth the effort as the supplier
didn't have useful diff tool. I Feel that Jupyter is better than that,
but still awkward.

> The tool gets rid of all the extra noise so the user is able to focus
> only on the actual important changes. When they exit the tool, their
> changes are properly staged.
>
> The problem Andre described in [1] appears when mergetool does *not*
> run. 

Here they are (in my mind) highlighting the GitLab server side merge
process, which only (IIUC) showing the git diff, and not the jupyter
diff, meaning they have to fetch and then work in the jupyter tool, not Git.

> In that case the user is forced to run `git diff` (jupyter difftool
> will be used), edit the file manually with some viewer, `git add
> --update`, and then run `git diff --cached` to verify the changes.

I'd misremembered the --update option, and it possibly doesn't do what
the user expects if they expect just the staged files (rather than all
the tracked index files) updated to take on-board their tweaks (i.e. mid
review)
>
> In case an unwanted change sneaks by, the user would have to edit the
> file again, or do `git checkout --patch` to selectively remove chunks
> (and since this tools presents the diffs in reverse, it's
> counterintuitive and error-prone).
I'd agree that the whole process for such tools (because they break
linear code conventions) is, as you say, "counter-intuitive and error-prone"
>
> This is far from ideal.
>
>
> The problem is that there is no `git stage edit`, in order to launch the
> mergetool.

I see it the other way around (I think). I see it as Git getting out of
the way for a period and supporting that other tool's review process,
rather than assuming that the git-way is the-right-way.

> I just wrote an example `git stage-edit` [2] that does launch the
> mergetool even if there are no merge conflicts, allowing the user to
> modify the stage directly and with no hassle.
>
> Cheers.
>
> [1] https://lore.kernel.org/git/20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de/
> [2] https://dpaste.com/62XS8TTXP
>
Hopefully, Andre can put a little information about just how the mid
'merge/review' process actually happens, and the pain points, to avoid
the discussion talking in thin air...

There may be terminology confusion because of the way that *server based
cooperation* goes via _Pull/Merge Requests_, when really they are
*Review Requests*, and no one (in that situation) actually expects them
to be accepted as-is anyway, rather they are 'returned with comments for
rework' or 'reworked before merge'.

Philip

Re: fast forward merge overwriting my code

[Felipe Contreras]

Philip Oakley wrote:
> On 27/05/2021 00:34, Felipe Contreras wrote:
> > Yes, but that is a separate issue.
> >
> > Right now they are able to resolve conflicts with a jupyter mergetool.
> 
> I don't believe that ("resolve") is true in the sense they would like. I
> don't think they are really 'merging' in an all-in-one `git merge`
> sense, rather they are [trying to] splitting and patching and commenting
> the changes.

He explicitly mentioned a merge, but ultimately it doesn't matter, the
mergetool can be used in other scenarios, like `git am`.

I did try to setup those tools, nbdime does setup a merge tool [1].

Cheers.

[1] https://nbdime.readthedocs.io/en/latest/

-- 
Felipe Contreras

Re: fast forward merge overwriting my code

[Philip Oakley]

On 27/05/2021 15:00, Felipe Contreras wrote:
> Philip Oakley wrote:
>> On 27/05/2021 00:34, Felipe Contreras wrote:
>>> Yes, but that is a separate issue.
>>>
>>> Right now they are able to resolve conflicts with a jupyter mergetool.
>> I don't believe that ("resolve") is true in the sense they would like. I
>> don't think they are really 'merging' in an all-in-one `git merge`
>> sense, rather they are [trying to] splitting and patching and commenting
>> the changes.
> He explicitly mentioned a merge, but ultimately it doesn't matter, the
> mergetool can be used in other scenarios, like `git am`.

True, though I see the server side aspects as also an important part of
the process pain.
>
> I did try to setup those tools, nbdime does setup a merge tool [1].
>
> Cheers.
>
> [1] https://nbdime.readthedocs.io/en/latest/
>
Thanks for that reference. I did like that the picture of the 'problem'
example was the same as the nbdime diff's solution ;-) [1]

The article does give a good start for thinking about the wider diffing
& merging problems for tools with more complex conceptual 'abstract
syntax trees'  and file representations.

Philip
[1] https://nbdime.readthedocs.io/en/latest/_images/nbdiff-web.png

Re: fast forward merge overwriting my code

[David Aguilar]

On Mon, May 24, 2021 at 11:51 AM Philip Oakley <philipoakley@iee.email> wrote:
>
> adding Pratyush for the Git Gui stash suggestion..
> [...]
> >>> 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)?
> >>
> >> I'm not aware of such a mechanism (as simply described) but I'm sure
> >> there are ways to use the "staging area" view (e.g. via the Git-gui) to
> >> selectively pick out hunks and lines that are staged (and non-selected
> >> hunk/lines stashed) to give a testable worktree during the 'merge'.
> >
> > Ah ok, this could be an idea (it would requiere some more research, as
> > I haven't used the git gui before (I want to learn everything from the
> > scratch using the command line))
>
> I commonly use the Gui when picking apart a large commit into smaller
> ones when I'm happy that there's no overlaps. Small patches make for
> easier merging and fault finding, and better commit messages (good
> thesis practice)
>
> > But to be honest, I think even this approach might already be too
> > cumbersome (as this selectively picking and stashing sounds like a lot
> > of work itself).
>
> Unfortunately the Git Gui doesn't have a menu for stashing remaining
> changes, but it's simple to flip over to the terminal to stash from
> there to do the testing, and un-stash the remainder afterwards - I'll
> maybe suggest the gui could include that capability for these types of
> workflows (cc Pratyush Yadav <pratiy0100@gmail.com>).

Tangential, and doesn't apply in this use case, but I should mention
that Git Cola[1] has had this feature for a while now.

Cola's Stash dialog allows you to do a regular stash and the "keep
index" stash alluded to here. "keep index" retains whatever has
already been staged.

One feature unique to cola is its "stash the index" feature, which
will only stash stuff that you've selectively staged. That's for the
cases where you just want to stash away a small bit, and selectively
choosing the inverse is a lot of work, so instead you can select just
the bits you want to be stashed away and stash 'em.

There's no shame in using a GUI for interactive editing. Cola is
designed to be driven through keyboard interactions so it's easy to
interactively edit the index without having to use a mouse.

Cola also has affordances that can make learning core Git easier
(enable its GIT_COLA_TRACE=1 mode in the environment and it'll print
out every git command it runs).

[1] https://git-cola.github.io/
[1] https://github.com/git-cola/git-cola

cheers,
-- 
David

Re: fast forward merge overwriting my code

[Philip Oakley]

On 30/05/2021 06:31, David Aguilar wrote:
> On Mon, May 24, 2021 at 11:51 AM Philip Oakley <philipoakley@iee.email> wrote:
>> adding Pratyush for the Git Gui stash suggestion..
>> [...]
>>>>> 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)?
>>>> I'm not aware of such a mechanism (as simply described) but I'm sure
>>>> there are ways to use the "staging area" view (e.g. via the Git-gui) to
>>>> selectively pick out hunks and lines that are staged (and non-selected
>>>> hunk/lines stashed) to give a testable worktree during the 'merge'.
>>> Ah ok, this could be an idea (it would requiere some more research, as
>>> I haven't used the git gui before (I want to learn everything from the
>>> scratch using the command line))
>> I commonly use the Gui when picking apart a large commit into smaller
>> ones when I'm happy that there's no overlaps. Small patches make for
>> easier merging and fault finding, and better commit messages (good
>> thesis practice)
>>
>>> But to be honest, I think even this approach might already be too
>>> cumbersome (as this selectively picking and stashing sounds like a lot
>>> of work itself).
>> Unfortunately the Git Gui doesn't have a menu for stashing remaining
>> changes, but it's simple to flip over to the terminal to stash from
>> there to do the testing, and un-stash the remainder afterwards - I'll
>> maybe suggest the gui could include that capability for these types of
>> workflows (cc Pratyush Yadav <pratiy0100@gmail.com>).
> Tangential, and doesn't apply in this use case, but I should mention
> that Git Cola[1] has had this feature for a while now.

+1. I haven't used/tried Cola myself, so..

>
> Cola's Stash dialog allows you to do a regular stash and the "keep
> index" stash alluded to here. "keep index" retains whatever has
> already been staged.
>
> One feature unique to cola is its "stash the index" feature, which
> will only stash stuff that you've selectively staged. That's for the
> cases where you just want to stash away a small bit, and selectively
> choosing the inverse is a lot of work, so instead you can select just
> the bits you want to be stashed away and stash 'em.

Sounds good.
When I did a quick test (Git-Gui & cli) with staging one line of a two
line change and then stashing, I found that the stash pop failed with a
conflict (your 'lot of work') which I hadn't expected, which to me is
totally wrong (against the spirit of the stash command).

>
> There's no shame in using a GUI for interactive editing. Cola is
> designed to be driven through keyboard interactions so it's easy to
> interactively edit the index without having to use a mouse.
>
> Cola also has affordances that can make learning core Git easier
> (enable its GIT_COLA_TRACE=1 mode in the environment and it'll print
> out every git command it runs).
>
> [1] https://git-cola.github.io/
> [1] https://github.com/git-cola/git-cola
>
> cheers,
Thanks