Git recommendations

Git recommendations

[Richard Riley]

I've just spent a short time giving the crash test dummy procedure to a
few git interfaces for emacs. All have their benefits. A lot have their
negatives, But my immediate favourite for anyone thinking of using emacs
interface to git for org is the following:

http://tsgates.cafe24.com/git/git-emacs.html#sec1

It doesn't come with a lot of default key bindings but the two most
important for those familiar with vc-backend are there:

C-x v v
and
C-x v =

git-diff interfaces nicely to ediff.

And the best thing is the one key press from git-status to bring up the
wonderful "gitk" GUI interface which I wasn't aware of! Truly brilliant
admin interface for git external to emacs.

The best part of all is that it provides simple easy to see icons in the
emacs status bar to show the git status. magic and egg tend to
git-status centric as opposed to file centric. emacs-git is a nice
mixture. It palms off the log/history interface to gitk - no need to
reinvent the wheel.

Simple, powerful, extensible. Recommended.

Oh, but missing staging .... which magit and egg support but vc-git,
git.el and emacs-git do not. I think ... 

Re: Git recommendations

[Ross Patterson]

Richard Riley <rileyrgdev@googlemail.com> writes:

> I've just spent a short time giving the crash test dummy procedure to a
> few git interfaces for emacs. All have their benefits. A lot have their
> negatives, But my immediate favourite for anyone thinking of using emacs
> interface to git for org is the following:
>
> http://tsgates.cafe24.com/git/git-emacs.html#sec1
>
> It doesn't come with a lot of default key bindings but the two most
> important for those familiar with vc-backend are there:
>
> C-x v v
> and
> C-x v =
>
> git-diff interfaces nicely to ediff.
>
> And the best thing is the one key press from git-status to bring up the
> wonderful "gitk" GUI interface which I wasn't aware of! Truly brilliant
> admin interface for git external to emacs.
>
> The best part of all is that it provides simple easy to see icons in the
> emacs status bar to show the git status. magic and egg tend to
> git-status centric as opposed to file centric. emacs-git is a nice
> mixture. It palms off the log/history interface to gitk - no need to
> reinvent the wheel.
>
> Simple, powerful, extensible. Recommended.
>
> Oh, but missing staging .... which magit and egg support but vc-git,
> git.el and emacs-git do not. I think ... 

I'm curious, did you evaluate dvc?

http://www.xsteve.at/prg/emacs_dvc/dvc.html

It aims to be a common emacs front end for most distributed version
control systems.

Ross

Re: Re: Git recommendations

[Richard Riley]

Ross Patterson <me@rpatterson.net> writes:

> Richard Riley <rileyrgdev@googlemail.com> writes:
>
>> I've just spent a short time giving the crash test dummy procedure to a
>> few git interfaces for emacs. All have their benefits. A lot have their
>> negatives, But my immediate favourite for anyone thinking of using emacs
>> interface to git for org is the following:
>>
>> http://tsgates.cafe24.com/git/git-emacs.html#sec1
>>
>> It doesn't come with a lot of default key bindings but the two most
>> important for those familiar with vc-backend are there:
>>
>> C-x v v
>> and
>> C-x v =
>>
>> git-diff interfaces nicely to ediff.
>>
>> And the best thing is the one key press from git-status to bring up the
>> wonderful "gitk" GUI interface which I wasn't aware of! Truly brilliant
>> admin interface for git external to emacs.
>>
>> The best part of all is that it provides simple easy to see icons in the
>> emacs status bar to show the git status. magic and egg tend to
>> git-status centric as opposed to file centric. emacs-git is a nice
>> mixture. It palms off the log/history interface to gitk - no need to
>> reinvent the wheel.
>>
>> Simple, powerful, extensible. Recommended.
>>
>> Oh, but missing staging .... which magit and egg support but vc-git,
>> git.el and emacs-git do not. I think ... 
>
> I'm curious, did you evaluate dvc?
>
> http://www.xsteve.at/prg/emacs_dvc/dvc.html

Nope. Damn. And why not? Because there was not a link on the Emacs Wiki
for Git interfaces. And it didnt turn up in my basic Google.

http://www.emacswiki.org/emacs/Git

:-(

>
> It aims to be a common emacs front end for most distributed version
> control systems.

Thanks for the pointer.

I'll take a look. I like common interfaces. There's enough key strokes
to remember in emacs as it is.

But I must say emacs-git impresses me the more I play with it. And git
itself just seems to be a solution that was waiting for a problem to
invent it. It's simply "nice and clean" from what i can gather of it.

regards

r.

Re: Git recommendations

[Ross Patterson]

Richard Riley <rileyrgdev@googlemail.com> writes:

> Ross Patterson <me@rpatterson.net> writes:
>
>> Richard Riley <rileyrgdev@googlemail.com> writes:
>>
>>> I've just spent a short time giving the crash test dummy procedure to a
>>> few git interfaces for emacs. All have their benefits. A lot have their
>>> negatives, But my immediate favourite for anyone thinking of using emacs
>>> interface to git for org is the following:
>>>
>>> http://tsgates.cafe24.com/git/git-emacs.html#sec1>>
>>> It doesn't come with a lot of default key bindings but the two most
>>> important for those familiar with vc-backend are there:
>>>
>>> C-x v v
>>> and
>>> C-x v =
>>>
>>> git-diff interfaces nicely to ediff.
>>>
>>> And the best thing is the one key press from git-status to bring up the
>>> wonderful "gitk" GUI interface which I wasn't aware of! Truly brilliant
>>> admin interface for git external to emacs.
>>>
>>> The best part of all is that it provides simple easy to see icons in the
>>> emacs status bar to show the git status. magic and egg tend to
>>> git-status centric as opposed to file centric. emacs-git is a nice
>>> mixture. It palms off the log/history interface to gitk - no need to
>>> reinvent the wheel.
>>>
>>> Simple, powerful, extensible. Recommended.
>>>
>>> Oh, but missing staging .... which magit and egg support but vc-git,
>>> git.el and emacs-git do not. I think ... 
>>
>> I'm curious, did you evaluate dvc?
>>
>> http://www.xsteve.at/prg/emacs_dvc/dvc.html
>
> Nope. Damn. And why not? Because there was not a link on the Emacs Wiki
> for Git interfaces. And it didnt turn up in my basic Google.
>
> http://www.emacswiki.org/emacs/Git
>
> :-(

Yeah, and I'll add the lack of a *.deb for DVC to that complaint.  :(
Maybe one of us ought to let the DVC folks know of our
complaints... Nah! :)

>> It aims to be a common emacs front end for most distributed version
>> control systems.
>
> Thanks for the pointer.
>
> I'll take a look. I like common interfaces. There's enough key strokes
> to remember in emacs as it is.
>
> But I must say emacs-git impresses me the more I play with it. And git
> itself just seems to be a solution that was waiting for a problem to
> invent it. It's simply "nice and clean" from what i can gather of it.

Well in all honesty, I've barely used git at all and I've only used DVC
for hg/mercurial, just thought you might want to get a look at it.  :)

Ross

Re: Re: Git recommendations

[Richard Riley]

Ross Patterson <me@rpatterson.net> writes:

> Richard Riley <rileyrgdev@googlemail.com> writes:
>
>> Ross Patterson <me@rpatterson.net> writes:
>>
>>> Richard Riley <rileyrgdev@googlemail.com> writes:
>>>
>>>> I've just spent a short time giving the crash test dummy procedure to a
>>>> few git interfaces for emacs. All have their benefits. A lot have their
>>>> negatives, But my immediate favourite for anyone thinking of using emacs
>>>> interface to git for org is the following:
>>>>
>>>> http://tsgates.cafe24.com/git/git-emacs.html#sec1>>
>>>> It doesn't come with a lot of default key bindings but the two most
>>>> important for those familiar with vc-backend are there:
>>>>
>>>> C-x v v
>>>> and
>>>> C-x v =
>>>>
>>>> git-diff interfaces nicely to ediff.
>>>>
>>>> And the best thing is the one key press from git-status to bring up the
>>>> wonderful "gitk" GUI interface which I wasn't aware of! Truly brilliant
>>>> admin interface for git external to emacs.
>>>>
>>>> The best part of all is that it provides simple easy to see icons in the
>>>> emacs status bar to show the git status. magic and egg tend to
>>>> git-status centric as opposed to file centric. emacs-git is a nice
>>>> mixture. It palms off the log/history interface to gitk - no need to
>>>> reinvent the wheel.
>>>>
>>>> Simple, powerful, extensible. Recommended.
>>>>
>>>> Oh, but missing staging .... which magit and egg support but vc-git,
>>>> git.el and emacs-git do not. I think ... 
>>>
>>> I'm curious, did you evaluate dvc?
>>>
>>> http://www.xsteve.at/prg/emacs_dvc/dvc.html
>>
>> Nope. Damn. And why not? Because there was not a link on the Emacs Wiki
>> for Git interfaces. And it didnt turn up in my basic Google.
>>
>> http://www.emacswiki.org/emacs/Git
>>
>> :-(
>
> Yeah, and I'll add the lack of a *.deb for DVC to that complaint.  :(
> Maybe one of us ought to let the DVC folks know of our
> complaints... Nah! :)

A Debian package? I gave up on them and installed CVS emacs 23. Why? The
debian installation setup is simply too complex and kind of got me a
blank stare from the gurus in irc #emacs. It's much nicer using a git
emacs repository and getting the stuff I need manually. Also much easier
to sync between different machines since each emacs directory is pretty
much self contained.

>
>>> It aims to be a common emacs front end for most distributed version
>>> control systems.
>>
>> Thanks for the pointer.
>>
>> I'll take a look. I like common interfaces. There's enough key strokes
>> to remember in emacs as it is.
>>
>> But I must say emacs-git impresses me the more I play with it. And git
>> itself just seems to be a solution that was waiting for a problem to
>> invent it. It's simply "nice and clean" from what i can gather of it.
>
> Well in all honesty, I've barely used git at all and I've only used DVC
> for hg/mercurial, just thought you might want to get a look at it.  :)
>
> Ross

I just started to read about git's history. You have to love
Torwalds. He shoots from the hip as well as being a smart sod.

http://www.infoworld.com/article/05/04/19/HNtorvaldswork_1.html

,----
| Torvalds seemed aware that his decision to drop BitKeeper would also be
| controversial. When asked why he called the new software, "git," British
| slang meaning "a rotten person," he said. "I'm an egotistical bastard,
| so I name all my projects after myself. First Linux, now git." 
`----

Sure. I bet there's someone at BitKeeper whose name begins with "g" ...

Although I notice the letters "git" are in the first 5 letters of
Tridgell too. Nah ...

,----
| Torvalds is clearly unhappy about being forced off BitMover. He called
| Tridgell's client a "bad project," and said that the software it
| produced has no benefit to Linux developers, BitMover, or even Tridgell
| himself.
| 
| "It ended up hurting people that didn't agree with (Tridgell)," he said
| of the software. "And it doesn't actually help anybody, since it only
| assured its own irrelevance by making BitKeeper no longer be available."
| 
| In the last week, Linux's creator has come under fire for publicly
| slamming Tridgell's efforts. Critics say that Tridgell's
| reverse-engineering of BitKeeper is analagous to the work Torvalds
| himself has done with Linux, which itself is based on Unix.
| 
| But in the e-mail interview Torvalds explained his perspective, using
| his usual brand of utilitarianism.
| 
| According to Torvalds, Tridgell's software was "bad" simply because it
| ultimately served no useful purpose. "To me, a program is only as good
| as what it does," he said. "In this case, it only caused problems."
`----

Re: Git recommendations

[Mykola Nikishov]

Ross Patterson <me@rpatterson.net> writes:

> Yeah, and I'll add the lack of a *.deb for DVC to that complaint.  :(
> Maybe one of us ought to let the DVC folks know of our
> complaints... Nah! :)

DVC's source tree contains debian/ directory and building .deb seems to
be a trivial task. Just run 'bzr-buildpackage' in the project's root ;-)

-- 
MAN-UANIC

Re: Git recommendations

[Ross Patterson]

Mykola Nikishov <mn@mn.com.ua> writes:

> Ross Patterson <me@rpatterson.net> writes:
>
>> Yeah, and I'll add the lack of a *.deb for DVC to that complaint.  :(
>> Maybe one of us ought to let the DVC folks know of our
>> complaints... Nah! :)
>
> DVC's source tree contains debian/ directory and building .deb seems to
> be a trivial task. Just run 'bzr-buildpackage' in the project's root ;-)

Awesome!  Thanks!

Ross

Re: Git recommendations

[Linh Dang]

Richard Riley <rileyrgdev <at> googlemail.com> writes:

> 
> 
> I've just spent a short time giving the crash test dummy procedure to a
> few git interfaces for emacs. All have their benefits. A lot have their
> negatives, But my immediate favourite for anyone thinking of using emacs
> interface to git for org is the following:
> 
> http://tsgates.cafe24.com/git/git-emacs.html#sec1
> 
> It doesn't come with a lot of default key bindings but the two most
> important for those familiar with vc-backend are there:
> 
> C-x v v
> and
> C-x v =

egg's file-oriented minor-mode also has those 2 mappings (as well as
other vc main keys such as C-x v u, C-x vl, etc.)

> 
> git-diff interfaces nicely to ediff.

if the egg's status buffer, if you type [RET] at a conflicting delta
(after a merge/rebase), egg will launch ediff3 to let you resolve the
conflict.

> magit and egg tend to
> git-status centric as opposed to file centric.

egg is has minor-mode which is fairly file-oriented. egg's "C-x v v"
sequence is customizable to match your personal workflow

> emacs-git is a nice
> mixture. It palms off the log/history interface to gitk - no need to
> reinvent the wheel.

egg uses the log buffer to do branch/tag creation/deletion as well
as pull/push/fetch etc.

http://github.com/bogolisk/egg/wikis

> 
> Simple, powerful, extensible. Recommended.
> 
> Oh, but missing staging .... which magit and egg support but vc-git,
> git.el and emacs-git do not. I think ... 

magit and egg main raison-d'etre was exactly that: hunk-by-hunk
staging/unstaging. 


I haven't touch egg for a while and of course I'm biased.

Re: Re: Git recommendations

[Richard Riley]

Linh Dang <linhd@nortel.com> writes:

> Richard Riley <rileyrgdev <at> googlemail.com> writes:
>
>> 
>> 
>> I've just spent a short time giving the crash test dummy procedure to a
>> few git interfaces for emacs. All have their benefits. A lot have their
>> negatives, But my immediate favourite for anyone thinking of using emacs
>> interface to git for org is the following:
>> 
>> http://tsgates.cafe24.com/git/git-emacs.html#sec1
>> 
>> It doesn't come with a lot of default key bindings but the two most
>> important for those familiar with vc-backend are there:
>> 
>> C-x v v
>> and
>> C-x v =
>
> egg's file-oriented minor-mode also has those 2 mappings (as well as
> other vc main keys such as C-x v u, C-x vl, etc.)
>
>> 
>> git-diff interfaces nicely to ediff.
>
> if the egg's status buffer, if you type [RET] at a conflicting delta
> (after a merge/rebase), egg will launch ediff3 to let you resolve the
> conflict.
>
>> magit and egg tend to
>> git-status centric as opposed to file centric.
>
> egg is has minor-mode which is fairly file-oriented. egg's "C-x v v"
> sequence is customizable to match your personal workflow
>
>> emacs-git is a nice
>> mixture. It palms off the log/history interface to gitk - no need to
>> reinvent the wheel.
>
> egg uses the log buffer to do branch/tag creation/deletion as well
> as pull/push/fetch etc.
>
> http://github.com/bogolisk/egg/wikis
>
>> 
>> Simple, powerful, extensible. Recommended.
>> 
>> Oh, but missing staging .... which magit and egg support but vc-git,
>> git.el and emacs-git do not. I think ... 
>
> magit and egg main raison-d'etre was exactly that: hunk-by-hunk
> staging/unstaging. 
>
>
> I haven't touch egg for a while and of course I'm biased.

Since then I discovered DVC.

http://richardriley.net/default/projects/emacs/dvc/tutorial/index

It's a shame so much effort is going into so many disjoint projects in
my view. They all cover different subsets and none appear to have a
large enough following to ensure interest and hence maintenance. Time
will tell.

Re: Re: Git recommendations

[Samuel Wales]

Do you know whether any of the git modes allow you to
preprocess the files that get diffed or ediffed?

For example, let's say that you want to ignore all line
moves.  In that case, you might run both files (e.g. an old
version and the current version) through "sort -u".

Then the diff will look funny if you made a lot of changes,
but if you only moved lines, it would show up as a zero
diff, which is exactly what you want if you don't care about
line moves.  If you made just a few changes and a lot of
line moves, those changes would show up.  A more
sophisticated algorithm could keep the changed lines in
place.

Likewise, you could preprocess org files to make diffs
cleaner by eliminating all level changes, etc.

I have done this in the shell for a long time and found it
useful; it would be nice in a git mode, if any support that.

Of course, perhaps it could be done in ediff, somehow.

I wonder if dvc will win because it has backends.

Re: Re: Git recommendations

[Alex Ott]

Re

>>>>> "SW" == Samuel Wales writes:
 SW> Do you know whether any of the git modes allow you to preprocess the
 SW> files that get diffed or ediffed?

in magit you can see diff for separate files

 SW> For example, let's say that you want to ignore all line moves.  In
 SW> that case, you might run both files (e.g. an old version and the
 SW> current version) through "sort -u".

 SW> Then the diff will look funny if you made a lot of changes, but if you
 SW> only moved lines, it would show up as a zero diff, which is exactly
 SW> what you want if you don't care about line moves.  If you made just a
 SW> few changes and a lot of line moves, those changes would show up.  A
 SW> more sophisticated algorithm could keep the changed lines in place.

 SW> Likewise, you could preprocess org files to make diffs cleaner by
 SW> eliminating all level changes, etc.

 SW> I have done this in the shell for a long time and found it useful; it
 SW> would be nice in a git mode, if any support that.

 SW> Of course, perhaps it could be done in ediff, somehow.

 SW> I wonder if dvc will win because it has backends.

You can look through modes, described in my article at
http://xtalk.msk.su/~ott/en/writings/emacs-vcs/EmacsGit.html 

In DVC, as i remember, support for Git is still very basic

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/           http://xtalk.msk.su/~ott/
http://alexott-ru.blogspot.com/

Re: Re: Git recommendations

[Richard Riley]

Alex Ott <alexott@gmail.com> writes:

> Re
>
>>>>>> "SW" == Samuel Wales writes:
>  SW> Do you know whether any of the git modes allow you to preprocess the
>  SW> files that get diffed or ediffed?
>
> in magit you can see diff for separate files
>
>  SW> For example, let's say that you want to ignore all line moves.  In
>  SW> that case, you might run both files (e.g. an old version and the
>  SW> current version) through "sort -u".
>
>  SW> Then the diff will look funny if you made a lot of changes, but if you
>  SW> only moved lines, it would show up as a zero diff, which is exactly
>  SW> what you want if you don't care about line moves.  If you made just a
>  SW> few changes and a lot of line moves, those changes would show up.  A
>  SW> more sophisticated algorithm could keep the changed lines in place.
>
>  SW> Likewise, you could preprocess org files to make diffs cleaner by
>  SW> eliminating all level changes, etc.
>
>  SW> I have done this in the shell for a long time and found it useful; it
>  SW> would be nice in a git mode, if any support that.
>
>  SW> Of course, perhaps it could be done in ediff, somehow.
>
>  SW> I wonder if dvc will win because it has backends.
>
> You can look through modes, described in my article at
> http://xtalk.msk.su/~ott/en/writings/emacs-vcs/EmacsGit.html 
>
> In DVC, as i remember, support for Git is still very basic

It has improved.

http://richardriley.net/default/projects/emacs/dvc/tutorial/index

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Re: Git recommendations

[Samuel Wales]

On Mon, Dec 1, 2008 at 07:25, Alex Ott <alexott@gmail.com> wrote:
> Re
>
>>>>>> "SW" == Samuel Wales writes:
>  SW> Do you know whether any of the git modes allow you to preprocess the
>  SW> files that get diffed or ediffed?
>
> in magit you can see diff for separate files

I don't know what this means.  Can you explain in more detail?

Thanks.

Re: Re: Git recommendations

[Tim O'Callaghan]

Has anyone had any luck with XEmacs and these git modes?

Tim.