Ads by Google

Showing posts with label Git. Show all posts
Showing posts with label Git. Show all posts

Friday, November 29, 2013

Updated Instructions for Installng AucTeX on Windows and Cygwin

I had written about installing AucTeX earlier and it seems to work most of the time for people based on the emails to me.  Since then AucTeX has been developed further and there's a git repository too for it.  Here's a new set of instructions for the combination of Emacs 24.3, Cygwin and AucTeX.  Now you need git too to clone the repository and follow the instructions by Tassilo Horn here.

It's missing only one bit of instruction; you need to run
$./autogen.sh
before you start the ./configure script like
 $ ./configure --prefix=c:/gnu/ --with-emacs=c:/gnu/emacs-24.3/bin/emacs --with-texmf-dir=c:/MiKTeX2.9/

I prefer the in situ use of AucTeX and so you'd definitely need to follow Tassilo's instructions on the directory customisations especially

;; AUC TeX
;;;lines below are needed as we are calling auctex in situ inside the
;;;git repo instead of installing it.  See
;;; http://permalink.gmane.org/gmane.emacs.auctex.general/5127
(setq TeX-data-directory "C:/gnu/elisp/auctex/")
(setq TeX-lisp-directory "C:/gnu/elisp/auctex/")
(setq preview-datadir (expand-file-name "preview" TeX-data-directory)
      preview-lispdir preview-datadir)
(add-to-list 'load-path "C:/gnu/elisp/auctex/")
(add-to-list 'load-path "C:/gnu/elisp/auctex/preview/")
(setq Info-default-directory-list 
      (cons "c:/gnu/elisp/auctex/doc" Info-default-directory-list))

So, there you have it,using the git version of AucTeX.  And a big thanks to Tassilo for helping me sort out my installation woes.

Thursday, January 1, 2009

Applying the same patch again and again

I sync up my org-mode code using git by issuing git pull. And I keep getting the same error every time the one file I edit is modified.

$ git pull
remote: Counting objects: 98, done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 85 (delta 57), reused 82 (delta 54)
Unpacking objects: 100% (85/85), done.
From git://repo.or.cz/org-mode
8915859..cd92610 master -> origin/master
Updating 8915859..cd92610
error: Entry 'Makefile' not uptodate. Cannot merge.

That's because the Makefile has been edited to point to the correct Emacs binary path and other customisations. So I had to rename the Makefile and then redo the command.

$ mv Makefile m
$ git pull
Updating 8915859..cd92610
Fast forward
ChangeLog | 6 +
Makefile | 2 +
ORGWEBPAGE/Changes.org | 140 ++++++++++++++++-
doc/ChangeLog | 12 ++
doc/org.texi | 170 +++++++++++++++-----
lisp/ChangeLog | 51 ++++++
lisp/org-exp.el | 291 +++++++++++++++++++++--------
lisp/org-export-latex.el | 37 +++--
lisp/org-footnote.el | 391+++++++++++++++++++++++++++++++
lisp/org.el | 81 ++++++++--
10 files changed, 1042 insertions(+), 139 deletions(-)
create mode 100644 lisp/org-footnote.el

And then edit the Makefile to re-apply the changes again. Specifically the diff lines highlighted is what I have to change everytime.

$ diff Makefile m
14c14
< EMACS=emacs
---
> EMACS=c:/gnu/emacs-22.2/bin/emacs
17c17
< prefix=/usr/local
---
> prefix=c:/gnu
76d75
< org-footnote.el \
102c101
< DOCFILES = doc/org.texi doc/org.pdf doc/org doc/dir doc/.nosearch
---
> DOCFILES = doc/org.texi doc/org.pdf doc/org doc/dir
316d314
< lisp/org-footnotes.elc: lisp/org-macs.elc lisp/org-compat.elc

Well, a simpler way to do it is as follows.

  1. Issue a git pull
  2. If the Makefile has a conflict, rename the file and issue a git pull again
  3. Generate a patch file by issuing diff -e NEWfile OLDfile > foo.patch
  4. apply the patch on the Makefile as patch Makefile foo.patch
  5. The edits that one has made is re-applied on the new Makefile
$ diff -e Makefile m
316d
102c
DOCFILES = doc/org.texi doc/org.pdf doc/org doc/dir
.
76d
17c
prefix=c:/gnu
.
14c
EMACS=c:/gnu/emacs-22.2/bin/emacs
.
$ diff -e Makefile m > b.patch
$ patch Makefile b.patch
$ make

Since I don't make any changes to org-mode codebase and the only thing that has to be changed everytime Makefile changes is the path info, this is a bit faster than editing the Makefile everytime.

Though it took me sometime to figure it out and there's still this nagging doubt whether there's a even simpler way.

Any ideas?

EDIT: Just realised that the patch file will have to edited to have ONLY the changes you want else it will remove the newer lines added to other parts of the Makefile. So, this post is kind of wrong and displays a slightly addled view of patching AND version control.

Looks like PUBLIC FAIL!


Monday, March 24, 2008

Using Git; more unlearning CVS

So, I trip up again when using git; Thinking that the commit works the same way as in CVS.

Of course it doesn't!

you need to do a git add and then follow it up with a git commit every time. In CVS, you need to do an add only when creating a new file. But in Git, every time the contents of the file changes you need to add before you commit.

A quick google check reveals that git tracks content not the file names. And this blogpost was even more clearer on how assuming things from other SCM versions will confuse you with Git.

To be honest, git does warn you about it and as usual, I took it to be background noise. :)

Thursday, March 13, 2008

Wrapping my head around the distributed version control model

Reading and playing with Git, I keep comparing it with CVS and predictably end up confused. So when Kate offered to answer any questions on Git, I jumped at the chance.

One that bothered me was how the main repository was identified; Kate's explanation was good enough to clear my doubts.

Thursday, February 7, 2008

Learning Git or rather how not to learn it

Seems like it's not a good idea to have a pre-conceived notion of CVS SCM model in mind while learning Git.

Going through the kernel.org links, especially this one, I kept waiting for the explanation of the central repository.

Kept reading and kept waiting.

Till I read this which left me nonplussed. Especially this part

Git differs from CVS in that every working tree contains a repository with a full copy of the project history, and no repository is inherently more important than any other.

Ack!

OK, now it appears I have to unlearn a couple of things before I can fully grasp Git. (There goes my perception, you know one SCM tool, all others are a variation of that)

Let's see how much I get sorted out.