all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* comparing code on different branches
@ 2017-07-04  0:53 Jean-Christophe Helary
  2017-07-04  0:57 ` John Wiegley
  2017-07-04 17:51 ` Stephen Leake
  0 siblings, 2 replies; 16+ messages in thread
From: Jean-Christophe Helary @ 2017-07-04  0:53 UTC (permalink / raw)
  To: emacs-devel

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 


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  0:53 comparing code on different branches Jean-Christophe Helary
@ 2017-07-04  0:57 ` John Wiegley
  2017-07-04  1:14   ` Jean-Christophe Helary
                     ` (2 more replies)
  2017-07-04 17:51 ` Stephen Leake
  1 sibling, 3 replies; 16+ messages in thread
From: John Wiegley @ 2017-07-04  0:57 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: emacs-devel

>>>>> "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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  0:57 ` John Wiegley
@ 2017-07-04  1:14   ` Jean-Christophe Helary
  2017-07-04  5:17   ` Tino Calancha
  2017-07-04  5:53   ` Marcin Borkowski
  2 siblings, 0 replies; 16+ messages in thread
From: Jean-Christophe Helary @ 2017-07-04  1:14 UTC (permalink / raw)
  To: John Wiegley; +Cc: emacs-devel


> 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


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  0:57 ` John Wiegley
  2017-07-04  1:14   ` Jean-Christophe Helary
@ 2017-07-04  5:17   ` Tino Calancha
  2017-07-04  5:53   ` Marcin Borkowski
  2 siblings, 0 replies; 16+ messages in thread
From: Tino Calancha @ 2017-07-04  5:17 UTC (permalink / raw)
  To: John Wiegley; +Cc: Emacs developers



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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  0:57 ` John Wiegley
  2017-07-04  1:14   ` Jean-Christophe Helary
  2017-07-04  5:17   ` Tino Calancha
@ 2017-07-04  5:53   ` Marcin Borkowski
  2017-07-04  9:30     ` Yuri Khan
  2 siblings, 1 reply; 16+ messages in thread
From: Marcin Borkowski @ 2017-07-04  5:53 UTC (permalink / raw)
  To: John Wiegley; +Cc: Jean-Christophe Helary, emacs-devel


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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  5:53   ` Marcin Borkowski
@ 2017-07-04  9:30     ` Yuri Khan
  2017-07-04 23:05       ` Richard Stallman
  0 siblings, 1 reply; 16+ messages in thread
From: Yuri Khan @ 2017-07-04  9:30 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: John Wiegley, Jean-Christophe Helary, emacs-devel

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.)



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  0:53 comparing code on different branches Jean-Christophe Helary
  2017-07-04  0:57 ` John Wiegley
@ 2017-07-04 17:51 ` Stephen Leake
  1 sibling, 0 replies; 16+ messages in thread
From: Stephen Leake @ 2017-07-04 17:51 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04  9:30     ` Yuri Khan
@ 2017-07-04 23:05       ` Richard Stallman
  2017-07-04 23:48         ` Jean-Christophe Helary
  2017-07-05  5:54         ` Etienne Prud’homme
  0 siblings, 2 replies; 16+ messages in thread
From: Richard Stallman @ 2017-07-04 23:05 UTC (permalink / raw)
  To: Yuri Khan; +Cc: jwiegley, jean.christophe.helary, emacs-devel

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




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04 23:05       ` Richard Stallman
@ 2017-07-04 23:48         ` Jean-Christophe Helary
  2017-07-05 22:59           ` Richard Stallman
  2017-07-05  5:54         ` Etienne Prud’homme
  1 sibling, 1 reply; 16+ messages in thread
From: Jean-Christophe Helary @ 2017-07-04 23:48 UTC (permalink / raw)
  To: rms; +Cc: jwiegley, emacs-devel, Yuri Khan


> 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


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04 23:05       ` Richard Stallman
  2017-07-04 23:48         ` Jean-Christophe Helary
@ 2017-07-05  5:54         ` Etienne Prud’homme
  2017-07-05 15:55           ` Yann Hodique
  1 sibling, 1 reply; 16+ messages in thread
From: Etienne Prud’homme @ 2017-07-05  5:54 UTC (permalink / raw)
  To: Richard Stallman; +Cc: jwiegley, jean.christophe.helary, emacs-devel, Yuri Khan

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-05  5:54         ` Etienne Prud’homme
@ 2017-07-05 15:55           ` Yann Hodique
  2017-07-05 16:07             ` Kaushal Modi
  2017-07-05 19:56             ` Etienne Prud'homme
  0 siblings, 2 replies; 16+ messages in thread
From: Yann Hodique @ 2017-07-05 15:55 UTC (permalink / raw)
  To: Etienne Prud’homme
  Cc: Jonas Bernoulli, Richard Stallman, jwiegley,
	jean.christophe.helary, Yuri Khan, emacs-devel

>>>>> "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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-05 15:55           ` Yann Hodique
@ 2017-07-05 16:07             ` Kaushal Modi
  2017-07-05 19:56             ` Etienne Prud'homme
  1 sibling, 0 replies; 16+ messages in thread
From: Kaushal Modi @ 2017-07-05 16:07 UTC (permalink / raw)
  To: Yann Hodique, Etienne Prud’homme
  Cc: Jonas Bernoulli, Richard Stallman, jwiegley,
	jean.christophe.helary, Yuri Khan, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-05 15:55           ` Yann Hodique
  2017-07-05 16:07             ` Kaushal Modi
@ 2017-07-05 19:56             ` Etienne Prud'homme
  2017-07-06 15:58               ` Richard Stallman
  1 sibling, 1 reply; 16+ messages in thread
From: Etienne Prud'homme @ 2017-07-05 19:56 UTC (permalink / raw)
  To: Yann Hodique
  Cc: Jonas Bernoulli, Richard Stallman, jwiegley,
	Jean-Christophe Helary, emacs-devel, Yuri Khan

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-04 23:48         ` Jean-Christophe Helary
@ 2017-07-05 22:59           ` Richard Stallman
  0 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2017-07-05 22:59 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: jwiegley, yuri.v.khan, emacs-devel

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




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-05 19:56             ` Etienne Prud'homme
@ 2017-07-06 15:58               ` Richard Stallman
  2017-07-13 21:48                 ` Etienne Prud’homme
  0 siblings, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2017-07-06 15:58 UTC (permalink / raw)
  To: Etienne Prud'homme
  Cc: jonas, yann.hodique, jwiegley, jean.christophe.helary,
	emacs-devel, yuri.v.khan

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




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: comparing code on different branches
  2017-07-06 15:58               ` Richard Stallman
@ 2017-07-13 21:48                 ` Etienne Prud’homme
  0 siblings, 0 replies; 16+ messages in thread
From: Etienne Prud’homme @ 2017-07-13 21:48 UTC (permalink / raw)
  To: Richard Stallman; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-07-13 21:48 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-04  0:53 comparing code on different branches Jean-Christophe Helary
2017-07-04  0:57 ` John Wiegley
2017-07-04  1:14   ` Jean-Christophe Helary
2017-07-04  5:17   ` Tino Calancha
2017-07-04  5:53   ` Marcin Borkowski
2017-07-04  9:30     ` Yuri Khan
2017-07-04 23:05       ` Richard Stallman
2017-07-04 23:48         ` Jean-Christophe Helary
2017-07-05 22:59           ` Richard Stallman
2017-07-05  5:54         ` Etienne Prud’homme
2017-07-05 15:55           ` Yann Hodique
2017-07-05 16:07             ` Kaushal Modi
2017-07-05 19:56             ` Etienne Prud'homme
2017-07-06 15:58               ` Richard Stallman
2017-07-13 21:48                 ` Etienne Prud’homme
2017-07-04 17:51 ` Stephen Leake

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.