symlinks and git-commit-file
Opened this issue · 4 comments
Sometimes I have to edit files via a symlink, and then I want git-commit-file to commit the original file, not the symlink itself. A simple tweak is have git-commit-file (in git-emacs.el) use true-filename, i.e., change the second git-commit call to
(git-commit amend (list (file-relative-name (file-truename buffer-file-name))))
In status mode, I'd leave the current behavior unchanged.
Thoughts?
Probably not -- committing symlinks to git, as symlinks, is a valid thing to do.
Doesn't emacs ask you to follow the symlink when you edit, anyway? I think it's precisely for this reason (common to VCs).
Ovy
Okay, thanks.
Yes, emacs handles the symlinks dandily. The awkwardness has to do with
using literate programming, and with each tool in my toolchain making
independently sensible choices that work badly together for my workflow.
In case you're curious: I write literate Haskell code embedded in markdown.
The Emacs support for communicating between my source code and the
read-eval-print loop wants me to be sitting in a .lhs (literate Haskell)
file, while the markdown rendering system (gitit) wants me to be in a .page,
and only works when the .page is the real deal (not a symlink). So I end up
editing via the symlink, and I want "C-x g c f" to check in the symlinked-to
file rather than the symlink.
There are some other possibilities at your end:
- If a symlink is being committed, and the link itself hasn't changed, only
then commit the linked-to file. - Ditto, but first confirm with the user to commit the linked file
- Add a customization variable to determine the policy.
Regards, - Conal
On Wed, May 18, 2011 at 6:41 PM, ovy <
reply@reply.github.com>wrote:
Probably not -- committing symlinks to git, as symlinks, is a valid thing
to do.Doesn't emacs ask you to follow the symlink when you edit, anyway? I think
it's precisely for this reason (common to VCs).Ovy
Reply to this email directly or view it on GitHub:
#6 (comment)
It sounds like something better fixed in the haskell toolchain, to be honest. It shouldn't make you jump through these symlink hoops.
As for the options:
- is surprising to the user
- is doable
- is doable, and maybe the best option (var that starts as false)
... but for both 2) and 3), I'm rather uncomfortable with this popping up in many places in the code and making it more complex. git-log-files comes to mind, maybe others (actually, you'd know best since you encounter this on a daily basis).
In summary, I'd pull a patch with this change if it's not too verbose (single function git--maybe-dereference-file) and you can't manage the LHS stuff at the source in other ways.
Thanks for the offer. I'll first try to fix things at the Haskell end.
Probably just as easy, once I find the right spot.
Regards, - Conal
On Thu, May 19, 2011 at 12:06 PM, ovy <
reply@reply.github.com>wrote:
It sounds like something better fixed in the haskell toolchain, to be
honest. It shouldn't make you jump through these symlink hoops.As for the options:
- is surprising to the user
- is doable
- is doable, and maybe the best option (var that starts as false)
... but for both 2) and 3), I'm rather uncomfortable with this popping up
in many places in the code and making it more complex. git-log-files comes
to mind, maybe others (actually, you'd know best since you encounter this on
a daily basis).In summary, I'd pull a patch with this change if it's not too verbose
(single function git--maybe-dereference-file) and you can't manage the LHS
stuff at the source in other ways.Reply to this email directly or view it on GitHub:
#6 (comment)