[Gambas-user] IDE Git Magic ....

Adrien Prokopowicz adrien.prokopowicz at gmail.com
Fri Feb 9 02:34:40 CET 2018


Le 08/02/2018 à 23:08, Benoît Minisini a écrit :
> Le 08/02/2018 à 21:39, Christof Thalhofer a écrit :
>> Am 08.02.2018 um 18:36 schrieb Benoît Minisini:
>>
>>> It's not easy to find a simple automatic behaviour with git.
>>
>> Yes. It is a little more complicated than SVN. The reason is: Git has a
>> staging area, but not for nothing. To try to simplify this would cut off
>> one of the main advantages of Git!
>>
>>> The logic behind is that the IDE add new files automatically, but
>>> that you have to commit as soon as possible if you want little
>>> commits.
>>
>> Ok. Maybe I can explain it by a story of my work, as I do it everyday
>> with Git:
>>
>> I am adding a new feature, maybe by adding a new module and a couple of
>> methods. These things usually rely on other things, which are spread
>> over other modules and classes and even projects (libraries). And while
>> I am developing the new feature, it is not unusual that I am detecting
>> some caveats in other parts of the software (things like misleading
>> comments, silly names of internal variables and so on), which I usually
>> fix on the fly. After an hour of working I normally do a couple of
>> commits, maybe three or four: The main feature and ... some commits of
>> the refactoring changes, which I did while coding and maybe another
>> commit of a new feature in a library, which resides in the same repo.
>>
>> For that I need a clean stage. In the stage I can collect all things
>> that have changed, that belong together(!), for one explicit commit.
>>
>> It is not helpful, when there are now all new files in the staging area,
>> automatically added by the IDE. In Git one is leaded to keep the commits
>> thematically consistent. For sure I prefer small commits. But it makes
>> no sense to commit things which do not belong together.
>>
>> As long as the IDE is not able to decide, which change or which new file
>> belongs to which topic, every automatism of adding things to the staging
>> area only disturbs the kind of work which is done best with Git.
>>
>>> I agree that you should be able to disable the automatic management
>>> if you want to do that yourself. By project maybe.
>>
>> Please not. I have about 20 projects I am constantly working on. These
>> are some main projects, and a lot more libraries and some components. As
>> I do not change my kind of working style per project, I would strongly
>> prefer a central switch in the IDE. And if I get a project of other
>> people there would be no reason, why I should change my style of work or
>> change theirs by pushing a switch in another ones project.
>>
>>> But I don't want to make it off by default, or I make the default an
>>> option, but then the default default would be enabling automatic
>>> management.
>>
>> As I think, and I repeat this, every automatic management of adding
>> things to the staging area destroys the great advantage of Git
>> (especially over SVN): Keeping things in commits together. And
>> especially beginners could be directed in the wrong way by this.
>>
>> If you want to support the usage of Git in the IDE in my experience it
>> would be far better if the IDE would provide a visual staging area,
>> where the programmer could collect changes and decide, which portion of
>> the changes to commit and when.
>>
>> Examples of such staging areas you can find in the programs tig or gitg.
>>
>> What I always miss is a very easy way to direct a small portion of
>> change to an explicit commit, while directing another change in the same
>> file nearby at the same time to another commit. It is possible in Git
>> and in tig but it is not really easy or intuitive. This could be a
>> killer feature.
>>
>>
>> Alles Gute
>>
>> Christof Thalhofer
>>
> 
> Let's first release the 3.11 version, and I will study the question.
> 
> I need help:
> 
> - How to make a 3.11 tag in the git repository.
> 
> - How to generate a source code archive from gitlab.
> 
> The old way for generating the source code archive was running the "make 
> dist-bz2" command from my machine, which has a hack for allowing 
> symbolic links in the generated archive.
> 
> If I use the download link provided by gitlab, I have an huge archive 
> that includes too many useless things. Moreover, the 3.10 tag has, for 
> any reason, a trunk sub-directory that seems to include the SVN 
> repository! (the 3.10 bzip2 archive is 65 Mo, whereas the 3.9.2 is 33 Mo).
> 
> I would have been cool if I was able to provide a gitlab url for 
> downloading the source. If I can't, I have to do as before, make it "by 
> hand", and uploading to sourceforge., making getting rid of sf more 
> difficult.
> 
> I will try to create another repository, and to move there the projects 
> that are not useful to build Gambas, and that make the source archive huge.
> 
> Regards,
> 

I just took a look at the commit the v3.10 tag points to : 
https://gitlab.com/gambas/gambas/tree/bd1b84afcdafd1961d50b0f809c45eecca5b90eb

It appears the trunk directory is present here, it probably is an 
artifact from when I cloned the repository from GitLab …

It appears only this particular version has the problem. Dince the 
current master branch doesn't have this directory, the generated archive 
for any new tag won't have it either, so that's nothing to worry about.

I also agree that only the components and project files needed to build 
Gambas should be in the repository. Ideally, the repository should have 
the same content as if you generated the archive manually, this way it 
would make the GitLab-generated archive equivalent to the ones you made 
on SourceForge, so nobody has to run extra commands to get a clean 
archive. :-)

Also, if you make a dedicated repository for the Gambas website, I think 
Gitlab should be able to automatically build it (with each commit) and 
then host the generated files, allowing us to get away from the 
sourceforge hosting.

-- 
Adrien Prokopowicz


More information about the User mailing list