Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Since we are talking about Emacs features now, I will move this to emacs-devel. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts - pain felt with git
RMS: I'd like to note that I too have had annoying problems with git regarding merge conflicts, in the past. My solution was to hand patch everything. I know the code much better now! On 2019-11-10 03:49, Richard Stallman wrote: [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > How about adding a user option to enable or disable the creation of > > the multiple windows? > > > > (Is it Smerge mode which does that?) > Smerge mode doesn't, so we need first to figure out what feature did > that. > When you got the merge conflict, was that by invoking "git pull" from > the shell prompt, or did you do it in some other way? I don't actually remember -- I can only try to reconstruct what happened. But I think it must have been a VC operation done in Emacs. I probably did git pull with the shell, not with VC, because it is not a per-file operation. > And once you got the indication of the conflict, did you simply visit > the file with conflicts, or did you do something else? IOW, what can > you remember about the commands and actions you did before those > windows popped up? I don't know.
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > How about adding a user option to enable or disable the creation of > > the multiple windows? > > > > (Is it Smerge mode which does that?) > Smerge mode doesn't, so we need first to figure out what feature did > that. > When you got the merge conflict, was that by invoking "git pull" from > the shell prompt, or did you do it in some other way? I don't actually remember -- I can only try to reconstruct what happened. But I think it must have been a VC operation done in Emacs. I probably did git pull with the shell, not with VC, because it is not a per-file operation. > And once you got the indication of the conflict, did you simply visit > the file with conflicts, or did you do something else? IOW, what can > you remember about the commands and actions you did before those > windows popped up? I don't know. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
Eli Zaretskii wrote: > Richard Stallman wrote: >> When I got the conflict, it displayed several windows. I did not know what >> these windows were showing me, so I was totally unable to proceed. I did >> not dare try to find out by trial and error what those windows were showing, >> not when committing something to the Emacs master! All I could do was stop >> and touch nothing. >> >> Was it Smerge mode which put up those windows? Or was it something else? > > It couldn't have been Smerge mode, because that one doesn't show any windows, > AFAIK. Maybe, it was ediff-mode? signature.asc Description: PGP signature
Re: Making git as easy as CVS, for handling merge conflicts
> From: Richard Stallman > Cc: psm...@gnu.org, gnu-system-discuss@gnu.org > Date: Sat, 09 Nov 2019 13:04:23 -0500 > > How about adding a user option to enable or disable the creation of > the multiple windows? > > (Is it Smerge mode which does that?) Smerge mode doesn't, so we need first to figure out what feature did that. When you got the merge conflict, was that by invoking "git pull" from the shell prompt, or did you do it in some other way? And once you got the indication of the conflict, did you simply visit the file with conflicts, or did you do something else? IOW, what can you remember about the commands and actions you did before those windows popped up?
Re: Making git as easy as CVS, for handling merge conflicts
> From: Richard Stallman > Cc: psm...@gnu.org, gnu-system-discuss@gnu.org > Date: Sat, 09 Nov 2019 13:04:19 -0500 > > > Smerge mode is a minor mode, so I don't see why you'd want to turn it > > off, it doesn't get in the way of your editing in any way. > > When I got the conflict, it displayed several windows. I did not know > what these windows were showing me, so I was totally unable to > proceed. I did not dare try to find out by trial and error what those > windows were showing, not when committing something to the Emacs > master! All I could do was stop and touch nothing. > > Was it Smerge mode which put up those windows? > Or was it something else? It couldn't have been Smerge mode, because that one doesn't show any windows, AFAIK. It just fontifies the conflicted area specially, and enables several specialized commands, bound to "C-c ^ X", where X is a character (e.g., "C-c ^ n" moves to the next conflict). Maybe you invoked some command without meaning it; the only command that I can imagine showing additional windows is smerge-ediff, which runs Ediff to show the revisions involved in the conflict. > Was one of those windows a buffer I could simply edit > manually? If so, which one is it? If I delete the other windows > and edit manually, will that enable me to proceed by msnusl merging? Yes, you should simply edit the buffer visiting the file with the merge conflicts normally, then save it; any other windows can be deleted, and shouldn't affect the conflict resolution in the first place. After resolving the conflicts, remember to commit the results by saying "git commit".
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > If smerge mode is useful in this situation, how about making its use > > into an option supported for all back-ends for which conflicts are possible? > It already is used by all back-ends, and they all work the same wrt > conflicts, at the level we are talking here. How about adding a user option to enable or disable the creation of the multiple windows? (Is it Smerge mode which does that?) -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > The only difference is that after resolving the conflicts you need to > > > say "git commit", so that the conflict resolution is recorded in your > > > local repository. > > > > That would be easy enough, but I did not get that far. > Can you remember what stopped you? Was that the fact that Emacs > turned on smerge-mode, or was it something else? Smerge mode certainly stopped me from proceeding along that path. But I think I next tried looking at the file itself, and did not see how to proceed from there. It is a shame that it is so hard to reproduce this situation intentionally. I can't do it by myself. A confl8ict is sheer (bad) luck. > Smerge mode is a minor mode, so I don't see why you'd want to turn it > off, it doesn't get in the way of your editing in any way. When I got the conflict, it displayed several windows. I did not know what these windows were showing me, so I was totally unable to proceed. I did not dare try to find out by trial and error what those windows were showing, not when committing something to the Emacs master! All I could do was stop and touch nothing. Was it Smerge mode which put up those windows? Or was it something else? Was one of those windows a buffer I could simply edit manually? If so, which one is it? If I delete the other windows and edit manually, will that enable me to proceed by msnusl merging? -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
> From: Richard Stallman > Cc: psm...@gnu.org, gnu-system-discuss@gnu.org > Date: Fri, 08 Nov 2019 22:26:51 -0500 > > > The only difference is that after resolving the conflicts you need to > > say "git commit", so that the conflict resolution is recorded in your > > local repository. > > That would be easy enough, but I did not get that far. Can you remember what stopped you? Was that the fact that Emacs turned on smerge-mode, or was it something else? > > This is already happening. The merge conflict markers are identical, > > at least by default. When you edit a file with the markers, Emacs > > automatically turns on the smerge-mode, which stages the files for > > commit when you save them after resolving the conflicts. > > I have never used smerge mode, and when I was dropped into it without > warning or explanation, I couldn't figure out what to. It's a minor mode that simplifies handling of merge conflicts, so you could just ignore it and edit the conflicted parts by hand. That'd do in the first approximation, although I'd urge you to look at the mode's documentation, because it has some handy commands for moving between conflicts and semi-automatically resolving them. > Can I turn that off? What would it do if it didn't go into smerge mode? > Would it give me an ordinary file showing the conflicts in the CVS way? Smerge mode is a minor mode, so I don't see why you'd want to turn it off, it doesn't get in the way of your editing in any way. If you never invoke any of its commands, its only manifestation will be the faces it puts on conflict markers and the conflicted parts of the file. You get an ordinary file with CVS-style conflict markers with or without Smerge mode. The markers are inserted by Git, so they are there once Git detected a merge conflict. In fact, it's by detecting these markers that vc-git.el realizes the file you visit has merge conflicts and turns on smerge-mode; see vc-git.el:vc-git-find-file-hook. > If smerge mode is useful in this situation, how about making its use > into an option supported for all back-ends for which conflicts are possible? It already is used by all back-ends, and they all work the same wrt conflicts, at the level we are talking here. The Git back-end additionally registers an after-save-hook that stages the file for you if all the conflict markers were removed (which it takes to mean you resolved all the conflicts).
Re: Making git as easy as CVS, for handling merge conflicts
> From: Richard Stallman > Cc: psm...@gnu.org, gnu-system-discuss@gnu.org > Date: Thu, 07 Nov 2019 14:29:47 -0500 > > Before checking in changes, I do cvs update to merge in any changes in > the repository. (I can't remember whether attempting to do checkin > does an update first; if not, then it tells you you should do an > update.) cvs update indicates conflicts in the text of the source > file. > > I edit that file to resolve the conflicts, then save the file. > Then checkin works. The same procedure works with Git. Instead of "cvs up", you do "git pull". If there are conflicts, you are told so, and need to resolve the conflicts. The only difference is that after resolving the conflicts you need to say "git commit", so that the conflict resolution is recorded in your local repository. This difference is due to the fact that with a dVCS you "commit twice": once in your local copy of the repository, and then you "push" to propagate your commits to the upstream master repository. > If there is a way to make git pull indicate conflicts in the file that way, > so I could resolve them, save, pull again, then commit, then I could use > git the way I use cvs. This is already happening. The merge conflict markers are identical, at least by default. When you edit a file with the markers, Emacs automatically turns on the smerge-mode, which stages the files for commit when you save them after resolving the conflicts. The only extra action is to "git commit" after you have resolved all the conflicts. > What happens with git push if some conflicting other change has been > installed in the repository in the mean time? In that case, the push is rejected with a suitable error message. When you see that message, you need to "git pull", then "git push" again right away. (If "git pull" reports merge conflicts, you need again to resolve them, "git commit", then "git push".) Bottom line: it's actually very similar to CVS, with two differences: a need to commit locally after resolving conflicts, and the need to push to propagate your commits to upstream.
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Would you mind describing in detail your workflow for handling merge > conflicts with CVS, including VC commands you invoke and commands you > invoke from the shell (if there are any)? Before checking in changes, I do cvs update to merge in any changes in the repository. (I can't remember whether attempting to do checkin does an update first; if not, then it tells you you should do an update.) cvs update indicates conflicts in the text of the source file. I edit that file to resolve the conflicts, then save the file. Then checkin works. If there is a way to make git pull indicate conflicts in the file that way, so I could resolve them, save, pull again, then commit, then I could use git the way I use cvs. What happens with git push if some conflicting other change has been installed in the repository in the mean time? Maybe that is what fell on the floor. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
> Date: Thu, 7 Nov 2019 14:51:26 + > From: Adam Spiers > Cc: gnu-system-discuss@gnu.org > > >I wonder when did you last took a look at Emacs's VC. It was > >completely revamped several years ago to support dVCSes, and I'd be > >surprised to learn that its functionality is only 5% of what Magit > >offers; I think it's much more than that. > > Apologies if my knowledge is out of date. I did a quick check before > writing the above, and in the Version Control section of manual for > 26.1 I cannot find a single mention of staging, nor any obvious way to > selectively stage hunks, let alone selected links within a hunk. That's because VC stages files silently behind the scenes when appropriate, and doesn't support interactive staging (because it's a Git-only feature). > I could well be missing something, but it seems that maybe the > manual hasn't kept pace, even if the code has. No, the manual is reasonably up to date. You just expect too deep support of Git-specific features, which is not what VC strives to do. It supports selectivity on file level, via vc-dir, but doesn't support interactive staging and committing of individual hunks. > Yeah, based on another quick glance I'd revise my estimate to maybe 20 > or 30%. Thank you. > It seems that there are still huge gaps, for example support > for rebase/squash/amend/cherrypick/bisect workflows, management of > branches and remotes, and options for standard operations such > logging. Logging is supported (if I understand correctly what you mean by that), see "C-x v l" and "C-x v L", and commands available in the log buffer these commands produce. These and other related facilities are described under "VC Change Log".
Re: Making git as easy as CVS, for handling merge conflicts
> Date: Fri, 1 Nov 2019 14:52:21 + > From: Adam Spiers > Cc: Taylan Kammer , gnu-system-discuss@gnu.org > > git uses fundamentally different paradigm to the model on which VC was > designed. One of many examples of this is that it requires staging changes > before committing them. My personal opinion is that it makes no sense to use > a > version control frontend which is totally outdated relative to the backend in > question. I enjoyed using VC for many years (and hacked various extensions > to > it), but it hasn't kept pace with the evolution of modern VCS frontends. I > estimate that its functionality is probably about 5% of what magit offers. I wonder when did you last took a look at Emacs's VC. It was completely revamped several years ago to support dVCSes, and I'd be surprised to learn that its functionality is only 5% of what Magit offers; I think it's much more than that. Many active Emacs developers routinely use VC, and since our VCS is Git, that gives us some evidence about the functionality VC provides for Git. If you indeed didn't look at VC for several years, I urge you to take another look. You probably won't want to switch from Magit, especially if you use only Git in your VCS-related work, but you might change your mind regarding the current functionality of VC, including when Git is the backend.
Re: Making git as easy as CVS, for handling merge conflicts
> From: Richard Stallman > Cc: gnu-system-discuss@gnu.org > Date: Wed, 06 Nov 2019 23:43:56 -0500 > > > I'll just say, for posterity, that avoiding staging is not difficult if > > you have simple requirements. A single command that creates a commit > > containing all modified files without having to stage them first: > > > > git commit -a I actually have a Git alias, called "ci", which does exactly that, because in the vast majority of cases I do want to commit all of the changed files. (It's a pity Git's default is to require manual staging; IMO, it should reverse its defaults, or at least have a config setting to do that.) However, this is not really related to the issue at hand, because Emacs automatically stages a file when you save it after resolving merge conflicts. > > You can also give a set of specific files to put into the commit, which > > do not need to be staged first: > > > > git commit ... > > That is what I did. Sometimes it worked fine. Sometimes it failed. > > I can't remember for certain whether the failures occurred > on commit or on pull. But I think they happened on pull > when there were othehr changes in the repo. I'm almost positive that it happened on pull. Creating a conflict on commit is quite hard, because nothing changes the files in your local repository simultaneously with your work on your changes. Anyway, I think it is important to understand the details of your difficulties to which you alluded when you said: > Is it possible to write a front-end for Git which reliably handles > merge conflicts the way CVS handles them? Would you mind describing in detail your workflow for handling merge conflicts with CVS, including VC commands you invoke and commands you invoke from the shell (if there are any)? In general, with Git it should be the same, modulo the need to say "git push" after committing, but maybe you have some specifics in mind that I'm missing. Without these details, I feel that the job of making a front end like you asked for is not really well defined.
Re: Making git as easy as CVS, for handling merge conflicts
On Thu, Nov 07, 2019 at 03:54:23PM +0200, Eli Zaretskii wrote: Date: Fri, 1 Nov 2019 14:52:21 + From: Adam Spiers Cc: Taylan Kammer , gnu-system-discuss@gnu.org git uses fundamentally different paradigm to the model on which VC was designed. One of many examples of this is that it requires staging changes before committing them. My personal opinion is that it makes no sense to use a version control frontend which is totally outdated relative to the backend in question. I enjoyed using VC for many years (and hacked various extensions to it), but it hasn't kept pace with the evolution of modern VCS frontends. I estimate that its functionality is probably about 5% of what magit offers. I wonder when did you last took a look at Emacs's VC. It was completely revamped several years ago to support dVCSes, and I'd be surprised to learn that its functionality is only 5% of what Magit offers; I think it's much more than that. Apologies if my knowledge is out of date. I did a quick check before writing the above, and in the Version Control section of manual for 26.1 I cannot find a single mention of staging, nor any obvious way to selectively stage hunks, let alone selected links within a hunk. I could well be missing something, but it seems that maybe the manual hasn't kept pace, even if the code has. Many active Emacs developers routinely use VC, and since our VCS is Git, that gives us some evidence about the functionality VC provides for Git. I was of course aware of the emacs source moving to git, but it's good to know that dogfooding on VC is occurring. If you indeed didn't look at VC for several years, I urge you to take another look. You probably won't want to switch from Magit, especially if you use only Git in your VCS-related work, but you might change your mind regarding the current functionality of VC, including when Git is the backend. Yeah, based on another quick glance I'd revise my estimate to maybe 20 or 30%. It seems that there are still huge gaps, for example support for rebase/squash/amend/cherrypick/bisect workflows, management of branches and remotes, and options for standard operations such logging.
Re: Making git as easy as CVS, for handling merge conflicts
> From: Adam Spiers > Date: Wed, 6 Nov 2019 10:24:09 + > Cc: Dmitry Alexandrov <321...@gmail.com>, gnu-system-discuss@gnu.org > > A wild guess, based on previous conversation in this thread, is that > maybe you resolved the conflict in emacs but didn't stage the > resolution before attempting to commit it. No, that is unlikely to be the reason, because when you save your edits in files that had merge conflict markers, and the VC backend is Git, Emacs automatically stages each such file as you save it. P.S. Please CC me on any replies, as I'm not subscribed to this list.
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I'll just say, for posterity, that avoiding staging is not difficult if > you have simple requirements. A single command that creates a commit > containing all modified files without having to stage them first: > git commit -a > You can also give a set of specific files to put into the commit, which > do not need to be staged first: > git commit ... That is what I did. Sometimes it worked fine. Sometimes it failed. I can't remember for certain whether the failures occurred on commit or on pull. But I think they happened on pull when there were othehr changes in the repo. > Anyway, it doesn't seem that you're looking for > help with this. I've learned that when people offer me help with git it does not address the problem I actually encountered, 3 or 4 years ago. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > A wild guess, based on previous conversation in this thread, is that > maybe you resolved the conflict in emacs but didn't stage the > resolution before attempting to commit it. Standard VC workflow does not include anything called "staging". The instructions I got did not include it either. I am sure someone sent me instructions for "staging". For some reason, it was too hard to do, and I gave up on it. I don't remember details. > git has been handling merges extremely well for many years now. I > believe this is one of the main reasons it is now used by tens of > millions of developers. If you are soliciting endorsements for git, ask those people. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
On Wed, 6 Nov 2019 at 04:11, Richard Stallman wrote: > That's what people told me: that i could use the same vc commands > with git and they would work. > > But that was not so. When there was a merge conflict, git fell on the > floor and I was stuck. I'm not sure what you mean exactly by falling on the floor in this case, but I'm very sure that if it happened again there would be no shortage of people willing and able to help you resolve it very quickly (myself included). A wild guess, based on previous conversation in this thread, is that maybe you resolved the conflict in emacs but didn't stage the resolution before attempting to commit it. git has been handling merges extremely well for many years now. I believe this is one of the main reasons it is now used by tens of millions of developers. There is also an abundance of excellent documentation and tutorials.
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Whatever it is, you absolutely do not need to deal with > awkwardness of git on daily basis if you use vc.el, where basic > workflow is exactly the same with any VCS it supports. That's what people told me: that i could use the same vc commands with git and they would work. But that was not so. When there was a merge conflict, git fell on the floor and I was stuck. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
On Mon, 2019-11-04 at 22:14 -0500, Richard Stallman wrote: > However, it meant that my simple recipe for committing my changes > did not work. Without knowing what your recipe tries to do or what did not work about it, we cannot comment. Anyway, it doesn't seem that you're looking for help with this. I'll just say, for posterity, that avoiding staging is not difficult if you have simple requirements. A single command that creates a commit containing all modified files without having to stage them first: git commit -a You can also give a set of specific files to put into the commit, which do not need to be staged first: git commit ... You can also use interactive mode: git commit --interactive (probably not what you are looking for). > I will stick to CVS. Of course people should use what they want. The problem comes when the other people working on the same project would prefer a different tool. I don't know if that is, in practice, a limiting factor to anyone at this point.
Re: Making git as easy as CVS, for handling merge conflicts
Richard Stallman wrote: > Adam Spiers wrote: > > git uses fundamentally different paradigm to the model on which VC was > designed. One of many examples of this is that it requires staging changes > before committing them. > > Maybe that is the aspect that convinced me to give up on using git. Or maybe > it was "stashing". Whatever it is, you absolutely do not need to deal with awkwardness of git on daily basis if you use vc.el, where basic workflow is exactly the same with any VCS it supports. And you already do that, do not you? signature.asc Description: PGP signature
Re: Making git as easy as CVS, for handling merge conflicts - Don't give up yet
You could make a script to automate it into one command: git add [FILE] git commit -m "x" [FILE] torify git push Don't give up on git yet. Otherwise what if you want to make large sweeping additions to the fully-free 3d videogame I contribute to? ( libregamewiki.org/Chaos_Esque_Anthology ) The engine is in C, the game code in QuakeC: which has No arrays! And no memory pointers! Doesn't that sound good? It only has floats, strings, and entities. Now there is a hack to add "arrays" but they are global in scope and 1 dimensional (so what's the point...), and static (can't be dynamically allocated). RMS: don't you like QuakeC? Please? On 2019-11-05 03:14, Richard Stallman wrote: [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] If you like the staging feature, I am glad that git pleases you. However, it meant that my simple recipe for committing my changes did not work. I will stick to CVS.
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] If you like the staging feature, I am glad that git pleases you. However, it meant that my simple recipe for committing my changes did not work. I will stick to CVS. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts - Simple git instructions
If RMS is new to git you can make it simple:
You update a file you edited to git (example: updating some QuakeC code
and some 3d models and textures):
git add file1.qc file2.qc
../../models/bots/girls/12yrold_latemodel_lod1.iqm
../../models/bots/girls/12yr*iqm*skin* ../../textures/grlcutepnk*.tga
You then commit the files (with the only message the internet users
deserve):
git commit -m "X"
You then push it to the remote server (over tor):
torify git push
Oh and before all this: /etc/init.d/tor start
("X" being the commit message, which should just be "X" so you don't
have to bother)
You can just copy your git repos to bluerays
Git allows you to _always_ be on a war footing; thus if someone deletes
your project on the remote server you just set up an accepting git repo
somewhere else and push there, or just distribute amongst your friends
in real life the blueray discs.
Also: I never auto-merge anything: everything is hand merged. This helps
you learn what is going on at all times.
Re: Making git as easy as CVS, for handling merge conflicts
On Sun, Nov 03, 2019 at 11:55:51PM -0500, Paul Smith wrote: On Sun, 2019-11-03 at 22:50 -0500, Richard Stallman wrote: git uses fundamentally different paradigm to the model on which VC was designed. One of many examples of this is that it requires staging changes before committing them. Maybe that is the aspect that convinced me to give up on using git. Or maybe it was "stashing". I am not sure what the difference is. [snipped] I'm sure that the issue you ran into was with staging. It does take some getting used to, the idea that there's an intermediate step between "modified" and "committed". However, the staging state is immensely useful once you get accustomed to it, and it's critical because Git is not a file-based tool. Each commit represents a coherent state of the entire directory tree. Thus, you need a way to choose which changes should go into each commit. It would be a very painful workflow if the only option was "make a commit of all the changes in my workspace". Then if you wanted to commit just some of the changes, you'd have to copy the other ones somewhere else and undo those changes, etc. The staging area allows Git to help you with this: you pick and choose which modifications you want to stage and when you make a commit it will be created from only the staged changes, leaving the other modifications alone so you can make another commit of those later. Of course, there are simple options to just commit all the modifications if that's what you want to do. I concur 100%. Staging did seem slightly odd at first, but I grew to love the enormous power it brings to workflows. With hindsight, going back to a VCS which doesn't support it would feel like a huge regression. It also doesn't help that Linus originally called the staging area "the index", which is IMO a confusing name, and there's a lot of documentation still floating around out there that uses this name instead :). Right. Terrible name for a great feature ;-)
Re: Making git as easy as CVS, for handling merge conflicts
On Sun, 2019-11-03 at 22:50 -0500, Richard Stallman wrote:
> > git uses fundamentally different paradigm to the model on which VC
> > was designed. One of many examples of this is that it requires
> > staging changes before committing them.
>
> Maybe that is the aspect that convinced me to give up on using git.
> Or maybe it was "stashing". I am not sure what the difference is.
It was likely not stashing.
Stashing is an extra command (git stash ...) that you can run if you
want, but is not part of a simple workflow and is not needed for normal
commit creation.
Stashing allows you to save away ("stash") your modifications without
making a commit or branch. This is useful if you want to switch to
another branch or pull changes from somewhere else, or even put away
some changes and work on something else, without the cognitive overhead
of making a new branch, committing content there, then switching back,
etc. Think of stashes as a set of patches (with a comment) that are
managed by Git, that you can view, apply, or throw away as you wish.
I'm sure that the issue you ran into was with staging.
It does take some getting used to, the idea that there's an
intermediate step between "modified" and "committed". However, the
staging state is immensely useful once you get accustomed to it, and
it's critical because Git is not a file-based tool. Each commit
represents a coherent state of the entire directory tree.
Thus, you need a way to choose which changes should go into each
commit. It would be a very painful workflow if the only option was
"make a commit of all the changes in my workspace". Then if you wanted
to commit just some of the changes, you'd have to copy the other ones
somewhere else and undo those changes, etc.
The staging area allows Git to help you with this: you pick and choose
which modifications you want to stage and when you make a commit it
will be created from only the staged changes, leaving the other
modifications alone so you can make another commit of those later.
Of course, there are simple options to just commit all the
modifications if that's what you want to do.
It also doesn't help that Linus originally called the staging area "the
index", which is IMO a confusing name, and there's a lot of
documentation still floating around out there that uses this name
instead :).
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > git uses fundamentally different paradigm to the model on which VC > was designed. One of many examples of this is that it requires > staging changes before committing them. Maybe that is the aspect that convinced me to give up on using git. Or maybe it was "stashing". I am not sure what the difference is. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
On Fri, Nov 01, 2019 at 03:01:16PM +0300, Dmitry Alexandrov wrote: Adam Spiers wrote: On Mon, 28 Oct 2019 at 00:12, Taylan Kammer wrote: On 28.10.2019 00:51, Richard Stallman wrote: I don't know how CVS handles merge conflicts, but the Emacs extension Magit is a very nice front-end to Git I strongly recommend any emacs user who switches to git to try it as the learning curve is very gentle and the gains in efficiency are huge. On the other hand, one may strongly recommend anyone who switches to git _not_ to try it, as there no reason to complicate the process by switching both backend and frontend at once, when he has Emacs, which transparently provides a uniform interface to all VCSes. There *are* reasons, including the gains in efficiency I mentioned. It's a tradeoff between complexity and efficiency. Each person should be empowered to judge what is best for them personally, based on factors like how important it is to them individually to have a single interface for all VCSes, vs. having arguably the most powerful git frontend out there. Therefore IMHO it is more helpful in these discussions to offer alternatives to consider rather than to recommend ignoring alternatives. Maybe if rms is too busy to spend a little bit of effort learning a new interface, and still regularly needs to operate with CVS etc., then VC might be the right choice for him. But an informed decision would include consideration of reasonable alternatives like magit. git uses fundamentally different paradigm to the model on which VC was designed. One of many examples of this is that it requires staging changes before committing them. My personal opinion is that it makes no sense to use a version control frontend which is totally outdated relative to the backend in question. I enjoyed using VC for many years (and hacked various extensions to it), but it hasn't kept pace with the evolution of modern VCS frontends. I estimate that its functionality is probably about 5% of what magit offers.
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Would someone like to do the work required to get Magit included in GNU Emacs? It has to do mainly with copyright assignments. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
Adam Spiers wrote: > On Mon, 28 Oct 2019 at 00:12, Taylan Kammer wrote: >> >> On 28.10.2019 00:51, Richard Stallman wrote: >> I don't know how CVS handles merge conflicts, but the Emacs extension Magit >> is a very nice front-end to Git > > I strongly recommend any emacs user who switches to git to try it as the > learning curve is very gentle and the gains in efficiency are huge. On the other hand, one may strongly recommend anyone who switches to git _not_ to try it, as there no reason to complicate the process by switching both backend and frontend at once, when he has Emacs, which transparently provides a uniform interface to all VCSes. signature.asc Description: PGP signature
Re: Making git as easy as CVS, for handling merge conflicts
On Mon, 28 Oct 2019 at 00:12, Taylan Kammer wrote: > > On 28.10.2019 00:51, Richard Stallman wrote: > > Is it possible to write a front-end for Git which reliably handles > > merge conflicts the way CVS handles them? Given that, I expect I > > could use Git. > > I don't know how CVS handles merge conflicts, but the Emacs extension > Magit is a very nice front-end to Git "Very nice" is perhaps an understatement; I'd call it superb ;-) It's also GPL v3. I strongly recommend any emacs user who switches to git to try it, as the learning curve is very gentle and the gains in efficiency are huge. > and aides with merging as well. > > https://magit.vc/manual/magit/Resolving-Conflicts.html Right. It also integrates nicely with Ediff: https://magit.vc/manual/magit/Ediffing.html#Ediffing and I believe that since emacs 26.1 it should be possible to do 3-way merges with ancestor, although I have not tried this yet: https://stackoverflow.com/questions/15587595/can-ediff-merge-simultaneously-show-the-ancestor-a-b-and-merge-buffers
Re: Making git as easy as CVS, for handling merge conflicts
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I will try to do some research this weekend if no one finds an answer > first. Thank you. What front-ends do you use for CVS? I'm assuming emacs vcs mode > and the command line? Yes. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Making git as easy as CVS, for handling merge conflicts
Richard Stallman writes: > Is it possible to write a front-end for Git which reliably handles > merge conflicts the way CVS handles them? Given that, I expect I > could use Git. I will try to do some research this weekend if no one finds an answer first. What front-ends do you use for CVS? I'm assuming emacs vcs mode and the command line? -- Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org
Re: Making git as easy as CVS, for handling merge conflicts
Personally, I use smerge-mode in Emacs for Git. Dmitry Alexandrov writes: > Taylan Kammer wrote: >> On 28.10.2019 00:51, Richard Stallman wrote: >>> Is it possible to write a front-end for Git which reliably handles merge >>> conflicts the way CVS handles them? >> >> I don't know how CVS handles merge conflicts > > Well, IIRC, the same way git-merge(1) does¹: by creating a file with <<< > === >>> marks. > > - > ¹ Speaking historically, the other way round, of course. -- GNU Powered it GPL Protected it GOD Blessed it HFG - NalaGinrut Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058 signature.asc Description: PGP signature
Re: Making git as easy as CVS, for handling merge conflicts
Taylan Kammer wrote: > On 28.10.2019 00:51, Richard Stallman wrote: >> Is it possible to write a front-end for Git which reliably handles merge >> conflicts the way CVS handles them? > > I don't know how CVS handles merge conflicts Well, IIRC, the same way git-merge(1) does¹: by creating a file with <<< === >>> marks. - ¹ Speaking historically, the other way round, of course. signature.asc Description: PGP signature
Re: Making git as easy as CVS, for handling merge conflicts
Taylan Kammer wrote: > Magit is a very nice front-end to Git and aides with merging as well. > https://magit.vc/manual/magit/Resolving-Conflicts.html The linked manual says: | Magit does not provide its own tools for conflict resolution signature.asc Description: PGP signature
Re: Making git as easy as CVS, for handling merge conflicts
On 28.10.2019 00:51, Richard Stallman wrote: > Is it possible to write a front-end for Git which reliably handles > merge conflicts the way CVS handles them? Given that, I expect I > could use Git. I don't know how CVS handles merge conflicts, but the Emacs extension Magit is a very nice front-end to Git and aides with merging as well. https://magit.vc/manual/magit/Resolving-Conflicts.html - Taylan
