Can Monticello version message be a Text?
Hi, in gitfiletree there is a piece of code like this: aVersion info message convertToSystemString But if you commit using Komitter `aVersion info message` is an instance of Text. Is this ok? I.e. should we fix Komitter to assign String as version message, or should gitfiletree convert message to string explicitly?
Le 06/04/2015 13:44, Yuriy Tymchuk a écrit :
Hi, in gitfiletree there is a piece of code like this:
aVersion info message convertToSystemString
But if you commit using Komitter `aVersion info message` is an instance of Text. Is this ok? I.e. should we fix Komitter to assign String as version message, or should gitfiletree convert message to string explicitly?
I can add an asString to gitfiletree, this is probably the easiest. Thierry
please fix Komitter :) Le 6/4/15 13:44, Yuriy Tymchuk a écrit :
Hi, in gitfiletree there is a piece of code like this:
aVersion info message convertToSystemString
But if you commit using Komitter `aVersion info message` is an instance of Text. Is this ok? I.e. should we fix Komitter to assign String as version message, or should gitfiletree convert message to string explicitly?
Actually there is a bigger problem⦠Because of hot gitfiletree finds the ancestor (which is one of the previous ancestors) Komitter commits the changes related to that ancestor. E.g. it shows you that youâve added two methods (while in fact youâve modified them, but they were not present in the previous ancestor) and you select to commit only one of them, then one method will be committed and one deleted. Uko
On 06 Apr 2015, at 17:51, stepharo <stepharo@free.fr> wrote:
please fix Komitter :)
Le 6/4/15 13:44, Yuriy Tymchuk a écrit :
Hi, in gitfiletree there is a piece of code like this:
aVersion info message convertToSystemString
But if you commit using Komitter `aVersion info message` is an instance of Text. Is this ok? I.e. should we fix Komitter to assign String as version message, or should gitfiletree convert message to string explicitly?
Hi Uko, Le 06/04/2015 18:48, Yuriy Tymchuk a écrit :
Actually there is a bigger problem⦠Because of hot gitfiletree finds the ancestor (which is one of the previous ancestors) Komitter commits the changes related to that ancestor.
E.g. it shows you that youâve added two methods (while in fact youâve modified them, but they were not present in the previous ancestor) and you select to commit only one of them, then one method will be committed and one deleted.
Can you explain a bit? Is it because GitFileTree only uses git to determine the ancestors? Thierry
I guess so. Also partially because how monticello works and how komitter uses it. As far as I understand, Komitter generates a diff, then you select which changes you want to commit and then it somehow commits the ancestor with selected changes applied. So if you say that the actual ancestor in a wrong one and user will deselect some changes - Komitter will commit the old thing + selected new changes. Maybe itâs a problem of Komitter. On the other hand maybe doing it correctly is too complicated because of how monticello works. Uko
On 06 Apr 2015, at 18:58, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Uko,
Le 06/04/2015 18:48, Yuriy Tymchuk a écrit :
Actually there is a bigger problem⦠Because of hot gitfiletree finds the ancestor (which is one of the previous ancestors) Komitter commits the changes related to that ancestor.
E.g. it shows you that youâve added two methods (while in fact youâve modified them, but they were not present in the previous ancestor) and you select to commit only one of them, then one method will be committed and one deleted.
Can you explain a bit? Is it because GitFileTree only uses git to determine the ancestors?
Thierry
Le 06/04/2015 19:37, Yuriy Tymchuk a écrit :
I guess so. Also partially because how monticello works and how komitter uses it. As far as I understand, Komitter generates a diff, then you select which changes you want to commit and then it somehow commits the ancestor with selected changes applied. So if you say that the actual ancestor in a wrong one and user will deselect some changes - Komitter will commit the old thing + selected new changes.
Then I don't understand, because: - git, and gitfiletree, doesn't give a damn about the ancestry. The full package is written to disk; ancestry and diff is determined later, by reading from the repository. - The only thing I could understand would be that komitter shows you the diff to a given version (say v.X), let you select which changes are applied, then read the top version from a repo (say v.Y) and apply the diff to it.
Maybe itâs a problem of Komitter. On the other hand maybe doing it correctly is too complicated because of how monticello works.
As described, I don't see any difficulty, really. I'll look into Komitter to see what it does (and how it does it). Thierry
Hi Uko, I had a look at Komitter and couldn't find anything wrong there. Yes, it base the patch on an ancestor as per Monticello, prepare the snapshot and save it to the repository; but the only way the repository would loose some methods is that inside MC, the ancestor is already wrong. Could you show me or help me reproduce the effect? Thierry Le 06/04/2015 19:37, Yuriy Tymchuk a écrit :
I guess so. Also partially because how monticello works and how komitter uses it. As far as I understand, Komitter generates a diff, then you select which changes you want to commit and then it somehow commits the ancestor with selected changes applied. So if you say that the actual ancestor in a wrong one and user will deselect some changes - Komitter will commit the old thing + selected new changes.
Maybe itâs a problem of Komitter. On the other hand maybe doing it correctly is too complicated because of how monticello works.
Uko
On 06 Apr 2015, at 18:58, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Uko,
Le 06/04/2015 18:48, Yuriy Tymchuk a écrit :
Actually there is a bigger problem⦠Because of hot gitfiletree finds the ancestor (which is one of the previous ancestors) Komitter commits the changes related to that ancestor.
E.g. it shows you that youâve added two methods (while in fact youâve modified them, but they were not present in the previous ancestor) and you select to commit only one of them, then one method will be committed and one deleted.
Can you explain a bit? Is it because GitFileTree only uses git to determine the ancestors?
Thierry
Hi, thank you very much for investigating this. These are the steps to reproduce: 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git <https://github.com/Uko/VnaExporter.git>) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo. Uko
On 07 Apr 2015, at 07:26, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Uko,
I had a look at Komitter and couldn't find anything wrong there. Yes, it base the patch on an ancestor as per Monticello, prepare the snapshot and save it to the repository; but the only way the repository would loose some methods is that inside MC, the ancestor is already wrong.
Could you show me or help me reproduce the effect?
Thierry
Le 06/04/2015 19:37, Yuriy Tymchuk a écrit :
I guess so. Also partially because how monticello works and how komitter uses it. As far as I understand, Komitter generates a diff, then you select which changes you want to commit and then it somehow commits the ancestor with selected changes applied. So if you say that the actual ancestor in a wrong one and user will deselect some changes - Komitter will commit the old thing + selected new changes.
Maybe itâs a problem of Komitter. On the other hand maybe doing it correctly is too complicated because of how monticello works.
Uko
On 06 Apr 2015, at 18:58, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Uko,
Le 06/04/2015 18:48, Yuriy Tymchuk a écrit :
Actually there is a bigger problem⦠Because of hot gitfiletree finds the ancestor (which is one of the previous ancestors) Komitter commits the changes related to that ancestor.
E.g. it shows you that youâve added two methods (while in fact youâve modified them, but they were not present in the previous ancestor) and you select to commit only one of them, then one method will be committed and one deleted.
Can you explain a bit? Is it because GitFileTree only uses git to determine the ancestors?
Thierry
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course). Can you show a screenshot at step 5? Thierry
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov Uko
Thierry
Hi Uko, Thanks, I'll have a look this afternoon (if I'm not doing some D4D support :)) Thierry 2015-04-08 9:44 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
I've done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov
Uko
Thierry
Uko, you seem to have the same bug Johan is describing. MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff. I've seen it happen at times, but rarely enough so I didn't pay attention to it. Thierry Le 08/04/2015 09:44, Yuriy Tymchuk a écrit :
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov
Uko
Thierry
Sad. It happens to me quite a lot. So is this an issue in monticello?
On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Uko,
you seem to have the same bug Johan is describing.
MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff.
I've seen it happen at times, but rarely enough so I didn't pay attention to it.
Thierry
Le 08/04/2015 09:44, Yuriy Tymchuk a écrit :
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov
Uko
Thierry
Le 09/04/2015 23:34, Yuriy Tymchuk a écrit :
Sad. It happens to me quite a lot. So is this an issue in monticello?
I don't know. Something is happening somewhere with the source code, and as a consequence Monticello test for finding the changes mark everything as changed. I'm pushing a solution for that symptom. https://pharo.fogbugz.com/default.asp?15321 But I haven't found the reason. Something is switching the line endings on some of the MC definitions, and I don't know who or what is doing that (and not everytime). Thierry
On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Uko,
you seem to have the same bug Johan is describing.
MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff.
I've seen it happen at times, but rarely enough so I didn't pay attention to it.
Thierry
Le 08/04/2015 09:44, Yuriy Tymchuk a écrit :
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov
Uko
Thierry
Can this be because my git name is different from monticello name? Uko
On 09 Apr 2015, at 23:40, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 09/04/2015 23:34, Yuriy Tymchuk a écrit :
Sad. It happens to me quite a lot. So is this an issue in monticello?
I don't know.
Something is happening somewhere with the source code, and as a consequence Monticello test for finding the changes mark everything as changed.
I'm pushing a solution for that symptom.
https://pharo.fogbugz.com/default.asp?15321
But I haven't found the reason. Something is switching the line endings on some of the MC definitions, and I don't know who or what is doing that (and not everytime).
Thierry
On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Uko,
you seem to have the same bug Johan is describing.
MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff.
I've seen it happen at times, but rarely enough so I didn't pay attention to it.
Thierry
Le 08/04/2015 09:44, Yuriy Tymchuk a écrit :
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov
Uko
Thierry
2015-04-15 14:06 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
Can this be because my git name is different from monticello name?
No ;) Is it still happening to you? I fixed a bug I could see with a case submitted by Johan; it may not have fixed yours. Thierry
Uko
On 09 Apr 2015, at 23:40, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 09/04/2015 23:34, Yuriy Tymchuk a écrit :
Sad. It happens to me quite a lot. So is this an issue in monticello?
I don't know.
Something is happening somewhere with the source code, and as a consequence Monticello test for finding the changes mark everything as changed.
I'm pushing a solution for that symptom.
https://pharo.fogbugz.com/default.asp?15321
But I haven't found the reason. Something is switching the line endings on some of the MC definitions, and I don't know who or what is doing that (and not everytime).
Thierry
On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier@gmail.com>
wrote:
Uko,
you seem to have the same bug Johan is describing.
MC seems to loose the contents of a package working copy, and hence is
unable to build a correct diff.
I've seen it happen at times, but rarely enough so I didn't pay
attention to it.
Thierry
Le 08/04/2015 09:44, Yuriy Tymchuk a écrit :
On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier@gmail.com>
wrote:
Le 07/04/2015 11:01, Yuriy Tymchuk a écrit :
Hi, thank you very much for investigating this.
You're working on it too :)
These are the steps to reproduce:
1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo.
I did, and I don't see anything suspicious. Browsing the repository
at each step gave me the complete package as expected (minus the unsaved changes, of course).
Can you show a screenshot at step 5?
I've done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov
Uko
Thierry
participants (3)
-
stepharo -
Thierry Goubier -
Yuriy Tymchuk