git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's in git.git (stable)

From
Theodore Tso <tytso@mit.edu>
Date
Jul 29, 2007, 03:16 UTC
Message-ID
<20070729031612.GB17204@thunk.org>
In-Reply-To
<85bqdw27mb.fsf@lola.goethe.zz>
On Sat, Jul 28, 2007 at 11:35:40AM +0200, David Kastrup wrote:
Show 12 quoted lines
> David Kastrup <dak@gnu.org> writes:
> 
> > If you use the desktop package, this means that you get a bear of a
> > startup time while a _new_ instance of Emacs gets loaded against the
> > wishes of the setup, and the command line parameters will be
> > interpreted relatively to the last file restored into the desktop
> > rather than the current directory (arguably a bug in the desktop
> > package which I plan to fix eventually, but in the meantime the
> > current package is farspread).
> 
> I can't reproduce anything similar outside of mergetool, so it appears
> more likely that mergetool is passing wrong relative file names.

See my recent posting on this issue. The problem is that the desktop package fundamentally changes how emacs behaves when it starts up. And in order to fix it we will need to change git-mergetool to do an "emacs --version", parse the version number, and then start changing how it calls emacs (and if you *really* want to use emacsclient, whether it can use emacsclient) based on the version of emacs which is installed as the default for the user. It's going to be really messy, and fundamentally, emacs as used by people who are using the desktop package really wants to be the center of the universe, instead of something which gets called to run a "merge application". Testing to make sure this works on every single emacs version/variant, and every single user's weird-sh*t startup scripts isn't something I'm looking forward to.

So I really am beginning to think the right answer is to give up on using git-mergetool to support anything other than basic emacs users (who just use emacs as an editor, what a concept), and for the H4rd C0re emacs l33t, they can use a contrib/git-mergetool.el that does everything inside emacs. Since these are the people who want emacs to be their desktop, their shell, *and* their window manager, they will probably be happier that way....

						- Ted
Previous: David KastrupNext: David Kastrup
Message 26 of 34 in “What's in git.git (stable)”
  1. Junio C HamanoMay 13, 2007
  2. Junio C HamanoMay 17, 2007
  3. Junio C HamanoMay 19, 2007
  4. Junio C HamanoMay 23, 2007
  5. Junio C HamanoMay 29, 2007
  6. Junio C HamanoJun 2, 2007
  7. Junio C HamanoJun 7, 2007
  8. Junio C HamanoJun 13, 2007
  9. Johannes SchindelinJun 13, 2007
  10. Johannes SixtJun 14, 2007
  11. Junio C HamanoJun 21, 2007
  12. Junio C HamanoJun 25, 2007
  13. Junio C HamanoJul 2, 2007
  14. What's in git.gitJunio C Hamano, Jul 13, 2007
  15. Draft release notes for v1.5.3, as of -rc1Junio C Hamano, Jul 13, 2007
  16. Sven VerdoolaegeJul 13, 2007
  17. Johannes SchindelinJul 14, 2007
  18. Junio C HamanoJul 14, 2007
  19. Johannes SchindelinJul 15, 2007
  20. Brian DowningJul 13, 2007
  21. Junio C HamanoJul 13, 2007
  22. Junio C HamanoJul 28, 2007
  23. David KastrupJul 28, 2007
  24. Junio C HamanoJul 28, 2007
  25. David KastrupJul 28, 2007
  26. Theodore TsoJul 29, 2007
  27. David KastrupJul 29, 2007
  28. Theodore TsoJul 29, 2007
  29. Johannes SchindelinJul 29, 2007
  30. [Untested! proposal] git-mergetool.sh: introduce ediff optionDavid Kastrup, Jul 29, 2007
  31. Theodore TsoJul 29, 2007
  32. David KastrupJul 29, 2007
  33. Thomas GlanzmannJul 28, 2007
  34. Junio C HamanoAug 7, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.