Re: fast forward merge overwriting my code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx/

-- 
Felipe Contreras



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux