Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦. Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦. Stef
I think that we could also add such metadata in MCZ files and it would be great. This is an excellent topics for an intern. Stef On Nov 6, 2013, at 1:20 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
Stef
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
+100 My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools). In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data). What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On Nov 6, 2013, at 1:38 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Martin did not send a public mail to the list? Shame on him :)
Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
+100
My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
Yes you are right. But people now use git to browse changes and it only work for little edition. But you are right. I would like also to have that combined with Torch because the Torch visualziation was so great.
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
Why conflicting we will change it systematically.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 06/11/2013 13:39, Stéphane Ducasse a écrit :
On Nov 6, 2013, at 1:38 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Martin did not send a public mail to the list? Shame on him :)
Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
+100
My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
Yes you are right. But people now use git to browse changes and it only work for little edition. But you are right. I would like also to have that combined with Torch because the Torch visualziation was so great.
My proposal should offer both: see all operations with git without conflicts when merging / cherry picking, whatever. And let Pharo present more advanced views on the development history.
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
Why conflicting we will change it systematically.
Because if you merge with git, then you will get conflicts and those will be a pain to fix. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
Why conflicting we will change it systematically.
Because if you merge with git, then you will get conflicts and those will be a pain to fix.
may be they should be ignore while merging but we cannot compute them from git because there are semantics information so if in the future we want to use fully git we will have to have a solution. But for now indeed we should focus on putting that info in MCZ
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 2013-11-06, at 13:38, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
+100
Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_r... http://permalink.gmane.org/gmane.comp.version-control.git/217 Specially the last link is worth reading ;)
My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
If you attach the information to the commit itself that will be fine: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html because, as you say, each time metadata ends up in the sources part of the git repository we will have merge problems, since you can only properly merge such data if you fully understand the semantic meaning. Additionally I think, that the transition data should not go into the sources, technically they are no sources, but they belong on the commit itself.
Le 06/11/2013 14:01, Camillo Bruni a écrit :
On 2013-11-06, at 13:38, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
+100
Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_r... http://permalink.gmane.org/gmane.comp.version-control.git/217 Specially the last link is worth reading ;)
Yes, this seems probable, but we need to try to be sure.
My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
If you attach the information to the commit itself that will be fine: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
because, as you say, each time metadata ends up in the sources part of the git repository we will have merge problems, since you can only properly merge such data if you fully understand the semantic meaning.
Hum. Reading git notes say that there is a merge operation involved... I hope that a git merge can be done without touching at the notes, and then it becomes easy to rebuild the EPICEA history from scanning the git history and recovering the notes (and as long as we are not using MC approach to searching past versions, of course). I know I can make an equivalent proposal as a directory and files, i.e. not hidden in git notes (which makes it non-portable to other version control systems / non git).
Additionally I think, that the transition data should not go into the sources, technically they are no sources, but they belong on the commit itself.
I have no such limit :) And I suspect that in some formats (mcz), this metadata will have to appear as part of the source. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_r... http://permalink.gmane.org/gmane.comp.version-control.git/217 Specially the last link is worth reading ;)
Yes, this seems probable, but we need to try to be sure.
definitely, for now this sounds more like an optimization, sticking to the full metadata seems to be easier.
If you attach the information to the commit itself that will be fine: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
because, as you say, each time metadata ends up in the sources part of the git repository we will have merge problems, since you can only properly merge such data if you fully understand the semantic meaning.
Hum. Reading git notes say that there is a merge operation involved...
haha, yeah thought the same ;), though I never used notes, so I have to try that out first..
Le 06/11/2013 14:33, Camillo Bruni a écrit :
Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_r... http://permalink.gmane.org/gmane.comp.version-control.git/217 Specially the last link is worth reading ;)
Yes, this seems probable, but we need to try to be sure.
definitely, for now this sounds more like an optimization, sticking to the full metadata seems to be easier.
If you attach the information to the commit itself that will be fine: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
because, as you say, each time metadata ends up in the sources part of the git repository we will have merge problems, since you can only properly merge such data if you fully understand the semantic meaning.
Hum. Reading git notes say that there is a merge operation involved...
haha, yeah thought the same ;), though I never used notes, so I have to try that out first..
Yes, there is also a notes rewrite if rebase or amend :( I'll go to the sprint on 19/12; maybe we can look into what we have on that: new format / metadata / EPICEA-readiness. If anybody has a pointer on a log format suitable for git merging, I'm a taker :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution.
no :) you do not what to infer refactoring.
As a side note, git for instance does not track renames: https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_r... http://permalink.gmane.org/gmane.comp.version-control.git/217 Specially the last link is worth reading ;)
My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
If you attach the information to the commit itself that will be fine: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
because, as you say, each time metadata ends up in the sources part of the git repository we will have merge problems, since you can only properly merge such data if you fully understand the semantic meaning.
Additionally I think, that the transition data should not go into the sources, technically they are no sources, but they belong on the commit itself.
ok for now we hsould have a proto using MCZ and see how it goes.
Hi On Wed, Nov 6, 2013 at 1:38 PM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not
show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Nop, not ready for integration. I sent an email two weeks ago, but now the updated information is here: http://smalltalkhub.com/#!/~MartinDias/Epicea Any feedback is welcome.
Side questions: camillo and other giter, I was thinking that it would
make sense to publish on git metadata (may be in ston) representing the semantics of the operation that led to the changes) so that tools can take advantage of this information to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦.
+100
My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools).
In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data).
What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 07/11/2013 13:00, Martin Dias a écrit :
Hi
On Wed, Nov 6, 2013 at 1:38 PM, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
Le 06/11/2013 13:20, Stéphane Ducasse a écrit :
Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but take into account the actions that have been performed like rename class, splitâ¦.
Yes! I want that too! How do we try EPICEA? Is it already integrated?
Nop, not ready for integration. I sent an email two weeks ago, but now the updated information is here:
http://smalltalkhub.com/#!/~MartinDias/Epicea
Any feedback is welcome.
I'd dream of having enough time to study it in depth :( Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (4)
-
Camillo Bruni -
Goubier Thierry -
Martin Dias -
Stéphane Ducasse