comparing code on different branches

comparing code on different branches

[Jean-Christophe Helary]

Sorry, it is more a git question than an emacs question:

I have created a branch where I do my work.

Now, when I test my code modifications, I do eval-buffer etc. But what if I also want to test what master does to compare the results?

Do I have to go through a stash/checkout/test/checkout stash apply cycle?

I thought I could actually do my modifications in the scratch buffer and keep the original file clean, so that I can always compare, but that seems a bit convoluted. Any better idea?

Jean-Christophe 

Re: comparing code on different branches

[John Wiegley]

>>>>> "JH" == Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

JH> Now, when I test my code modifications, I do eval-buffer etc. But what if
JH> I also want to test what master does to compare the results?

JH> Do I have to go through a stash/checkout/test/checkout stash apply cycle?

If it's just one file, you can use C-x v ~ master RET to open master's version
in another buffer, and then eval-buffer there to compare.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: comparing code on different branches

[Jean-Christophe Helary]

> On Jul 4, 2017, at 9:57, John Wiegley <jwiegley@gmail.com> wrote:
> 
> JH> Now, when I test my code modifications, I do eval-buffer etc. But what if
> JH> I also want to test what master does to compare the results?
> 
> JH> Do I have to go through a stash/checkout/test/checkout stash apply cycle?
> 
> If it's just one file, you can use C-x v ~ master RET to open master's version
> in another buffer, and then eval-buffer there to compare.

Thank you *so* much.

Jean-Christophe

Re: comparing code on different branches

[Tino Calancha]

On Mon, 3 Jul 2017, John Wiegley wrote:

>>>>>> "JH" == Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
>
> JH> Now, when I test my code modifications, I do eval-buffer etc. But what if
> JH> I also want to test what master does to compare the results?
>
> JH> Do I have to go through a stash/checkout/test/checkout stash apply cycle?
>
> If it's just one file, you can use C-x v ~ master RET to open master's version
> in another buffer, and then eval-buffer there to compare.
Nice tip! Thanks.
I used to go to the shell for that (less convenient):
M-! git show version:path RET
M-x rename-buffer blah RET

Re: comparing code on different branches

[Marcin Borkowski]

On 2017-07-04, at 02:57, John Wiegley <jwiegley@gmail.com> wrote:

>>>>>> "JH" == Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
>
> JH> Now, when I test my code modifications, I do eval-buffer etc. But what if
> JH> I also want to test what master does to compare the results?
>
> JH> Do I have to go through a stash/checkout/test/checkout stash apply cycle?
>
> If it's just one file, you can use C-x v ~ master RET to open master's version
> in another buffer, and then eval-buffer there to compare.

Nice indeed!

BTW, is there a Magit way of doing this?

Best,

-- 
Marcin Borkowski

Re: comparing code on different branches

[Yuri Khan]

On Tue, Jul 4, 2017 at 12:53 PM, Marcin Borkowski <mbork@mbork.pl> wrote:

> BTW, is there a Magit way of doing this?

There is.

* M-x magit-find-file asks for a revision and a file name, and opens
what you ask for.

* In a buffer visiting a file in work tree, you can invoke M-x
magit-blob-previous and it will open a new buffer with the last
committed revision of the same file. Repeating M-x magit-blob-previous
(or pressing p) from that buffer opens the same file as of the
previous commit where it was modified. M-x magit-blob-next (or n)
travels in the other direction.

* In a buffer showing a diff, you can press RET on any source code
line and it will take you to that file at the relevant revision. (But
not in a diff to the working tree.)

Re: comparing code on different branches

[Richard Stallman]

[[[ 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 wish someone would write a package comparable to Magit that
we could get legal papers for and include it in Emacs.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: comparing code on different branches

[Jean-Christophe Helary]

> On Jul 5, 2017, at 8:05, Richard Stallman <rms@gnu.org> 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. ]]]
> 
> I wish someone would write a package comparable to Magit that
> we could get legal papers for and include it in Emacs.

You also just wrote "It might be good if Emacs could refill lines automatically the way some other ediors do."

Could you put your list of "request for enhancements" somewhere visible on the web?

That's 2 important usability features and all able emacs programmers may not be following this list.

Jean-Christophe

Re: comparing code on different branches

[Richard Stallman]

[[[ 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. ]]]

  > Could you put your list of "request for enhancements" somewhere visible on the web?

I don't have one, but I will start making one.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: comparing code on different branches

[Etienne Prud’homme]

Richard Stallman <rms@gnu.org> writes:

> I wish someone would write a package comparable to Magit that
> we could get legal papers for and include it in Emacs.

Although I really like Magit, I’m all for it. Could we make an official
project with GNU Emacs contributors?

I could try to contribute to some parts of it.

Writing it alone would be insane (I need to eat).  I see that there’s
more than 8k commits on their repository.  Also worth noting the project
had 200 contributors.  I seriously wonder if hunting down for them would
be easier than writing it from scratch!

--
Etienne

Re: comparing code on different branches

[Yann Hodique]

>>>>> "Etienne" == Etienne Prud’homme <e.e.f.prudhomme@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>> I wish someone would write a package comparable to Magit that
>> we could get legal papers for and include it in Emacs.

> Although I really like Magit, I’m all for it. Could we make an official
> project with GNU Emacs contributors?

> I could try to contribute to some parts of it.

> Writing it alone would be insane (I need to eat).  I see that there’s
> more than 8k commits on their repository.  Also worth noting the project
> had 200 contributors.  I seriously wonder if hunting down for them would
> be easier than writing it from scratch!

As a former Magit maintainer myself, I would really hate to see much
effort going into rewriting it instead of improving it :)

A few more datapoints, for what it's worth:

- at most ~100 contributors fall in the non-trivial contribution bucket
  if I'm using a total of less than 15 lines changed (even just moved
  around) as a naive threshold.

- probably more that half of the remaining individual contributions (the
  1- or 2-commits bucket) can be either very easily rewritten or have
  already been nuked from the current state of Magit. Not that we
  shouldn't try to collect the paperwork for those, but I suspect the
  occasional failure would be highly manageable.
  So that leaves probably 40 to 50 authors that really need to agree
  before it gets more complicated (if my overall understanding of the
  process is correct).

- eyeballing the top ~20 contributors, it seems to me the vast majority
  of us already have code in Emacs proper, so I assume most of us are
  not opposed to the idea, and have similar paperwork in place.

- the `dash' and `async' dependencies are already in ELPA, leaving only
  packages closely related to `magit' (mostly by the same authors) to be
  taken care of.

So while I'm not trying to diminish the effort needed to get the
paperwork in order (actually the task seems pretty daunting to me :)),
I think it's worth at least asking the question, if that hasn't been
done already.
CC-ing Jonas for a more current perspective.

Thanks

Yann.

-- 
What is each man but a memory for those who follow?

  -- DUKE LETO ATREIDES

Re: comparing code on different branches

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Wed, Jul 5, 2017 at 11:56 AM Yann Hodique <yann.hodique@gmail.com> wrote:

> As a former Magit maintainer myself, I would really hate to see much
> effort going into rewriting it instead of improving it :)


+1 on "let's not re-invent the wheel (and re-find the same bugs and fixes
and fixes to fix the bug introduced by those fixes)". Let's optimize the
developer time in making things better and writing new things.

I agree with the datapoints that followed.

CC-ing Jonas for a more current perspective.
>

If Jonas is on-board with making Magit an official part of Emacs, then half
the problem is solved :)
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1183 bytes --]

Re: comparing code on different branches

[Etienne Prud'homme]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

Thanks for the comments.  I wasn't aware of the view of current
contributors.

Last time asked if a project could be included in elpa (with paper work),
it was not a nice experience.

I'm not even mentionning non conformance to GPL in some MELPA packages
(using a license weak to no copyleft license).

--
Etienne


Le 2017-07-05 11:56, "Yann Hodique" <yann.hodique@gmail.com> wrote :

>>>>> "Etienne" == Etienne Prud’homme <e.e.f.prudhomme@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>> I wish someone would write a package comparable to Magit that
>> we could get legal papers for and include it in Emacs.

> Although I really like Magit, I’m all for it. Could we make an official
> project with GNU Emacs contributors?

> I could try to contribute to some parts of it.

> Writing it alone would be insane (I need to eat).  I see that there’s
> more than 8k commits on their repository.  Also worth noting the project
> had 200 contributors.  I seriously wonder if hunting down for them would
> be easier than writing it from scratch!

As a former Magit maintainer myself, I would really hate to see much
effort going into rewriting it instead of improving it :)

A few more datapoints, for what it's worth:

- at most ~100 contributors fall in the non-trivial contribution bucket
  if I'm using a total of less than 15 lines changed (even just moved
  around) as a naive threshold.

- probably more that half of the remaining individual contributions (the
  1- or 2-commits bucket) can be either very easily rewritten or have
  already been nuked from the current state of Magit. Not that we
  shouldn't try to collect the paperwork for those, but I suspect the
  occasional failure would be highly manageable.
  So that leaves probably 40 to 50 authors that really need to agree
  before it gets more complicated (if my overall understanding of the
  process is correct).

- eyeballing the top ~20 contributors, it seems to me the vast majority
  of us already have code in Emacs proper, so I assume most of us are
  not opposed to the idea, and have similar paperwork in place.

- the `dash' and `async' dependencies are already in ELPA, leaving only
  packages closely related to `magit' (mostly by the same authors) to be
  taken care of.

So while I'm not trying to diminish the effort needed to get the
paperwork in order (actually the task seems pretty daunting to me :)),
I think it's worth at least asking the question, if that hasn't been
done already.
CC-ing Jonas for a more current perspective.

Thanks

Yann.

--
What is each man but a memory for those who follow?

  -- DUKE LETO ATREIDES

[-- Attachment #2: Type: text/html, Size: 3883 bytes --]

Re: comparing code on different branches

[Richard Stallman]

[[[ 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. ]]]

  > (using a license weak to no copyleft license).

I am not sure what those words mean, so this may (or may not) be an
important problem.  Could you please describe more concretely a few of
cases?

Is there any package in MELPA with a license that is nonfree?

Is there any package in MELPA with no license?
(A program with no license is automatically nonfree.)

Is there any package in MELPA with a license that is incompatible with
the GPL?  Or where you are not sure whether it is compatible with the
GPL?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: comparing code on different branches

[Etienne Prud’homme]

Sorry, I just saw your replay.

Richard Stallman <rms@gnu.org> writes:

> I am not sure what those words mean, so this may (or may not) be an
> important problem.  Could you please describe more concretely a few of
> cases?

I don’t really want to point people.  My understanding is that any
package using Emacs components are subject to the GPL license as it
would fall (in my understanding) as a derivative work.

Some people are not happy with the GPL and remove the copyleft by using
licenses such as MIT, Simplified BSD and WTFPL[1].  Some people go even
further by publishing it in the public domain (unlicense).

I wouldn’t say those licenses are GPL incompatible, but they do not
abide to the GPL (still in my understanding).  GPL incompatibility can
mean a project with licence A can safely become a GPL project.  While
non GPL abiding would mean a project with a GPL license cannot become a
project with license A.

> is there any package in MELPA with a license that is nonfree?

I’ve not seen packages with proprietary licenses (that is software with
license incompatible with the GPL in the sense I said above).

> Is there any package in MELPA with no license?
> (A program with no license is automatically nonfree.)

I’ve seen packages with no license in the past.  It might not be the
case anymore, but I would need to check again.

I think most people using a non GPL abiding license simply don’t know
that their derivative projects is still subject to the GPL license.

A few of them simply don’t care or dislike the GPL license.  They are
aware of the GPL conditions, but don’t consider packages using language
standards (like common lisp) to be subject to the GPL.

That’s a tricky point since Emacs has both an interpreter and its own
functionality.  Having code being interpreted by Emacs doesn’t
necessarily make it GPL.  Someone could use Common Lisp procedures with
Emacs’ interpreter.

Also some Emacs code is in the Public Domain.  From my understanding of
the law it’s illegal to copyright things in the public domain and that
might be the reason why this is so.

I’m not a lawyer, I may be totally wrong on that.

[1] One example is El-get found at https://github.com/dimitri/el-get.
Worth noting it was discussed with
“Please change license from WTFPL (e.g. to GPL)”:
https://github.com/dimitri/el-get/issues/474 and the maintainer rejected
it.

--
Etienne

Re: comparing code on different branches

[Stephen Leake]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

> Sorry, it is more a git question than an emacs question:
>
> I have created a branch where I do my work.
>
> Now, when I test my code modifications, I do eval-buffer etc. But what
> if I also want to test what master does to compare the results?
>
> Do I have to go through a stash/checkout/test/checkout stash apply cycle?
>
> I thought I could actually do my modifications in the scratch buffer
> and keep the original file clean, so that I can always compare, but
> that seems a bit convoluted. Any better idea?

Workspaces are cheap; I keep a full checkout of master, and one of each
branch I'm working on, at all times.

You can use 'git worktree' to minimize fetch and push operations to the
central repository.


-- 
-- Stephe