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

[Christof Thalhofer]

Am 08.02.2018 um 22:07 schrieb Adrien Prokopowicz:

> I use the JetBrains IDEs a lot for work, and they provide a very good 
> interface to review and select changes to commit (see the attached 
> screenshot).
> 
> It seems quite close to what you're describing, and it would probably be 
> a very good source of inspiration. :-)

Yes, it seems so (I do not know JetBrains).

For a simple but very fast and effective representation of a staging
area I know there is:

*tig* (a management program for a Git repository in the terminal) I use
it together with Guake terminal and it is the fastest UI I know.

And

*gitg* (not very powerful but nice GUI to do commits)

(I could not translate the interface, it is german) The picture shows
the staging area on the left, another.txt is to be committed soon.
test.txt is a changed file and newest.txt is a new file.

On the right it shows the diff of the content of the highlighted
"another.txt".

See attached screenshots.

---------------------------------------------------------------------

Essential for the understanding of Git is the concept of the
"working directory" vs "staging area" vs "repository"

The *Working Directory* is the place where the work happens. Here you
can change text in files as usual. If you changed a lot you can select
which changes you want to commit under a topic. You bring only these
changes into the:

*Staging Area*. If you have 50 changes, but only 10 of them belong to
the topic "current feature", then you add only these 10 changes into the
Staging Area. After that you can:

*Commit* this collection of 10 changes together with a commit message
"this is my current feature" into the:

*Repository*. The repo resides in the hidden dir .git and is a very fast
database which contains all changes of the working dir since the first
commit.

Differences Git vs SVN (as I knew it):

In SVN a commit represents the current state of a working dir and the
repo contains all states of the working dir one after another.

In Git a commit is a set of changes of the working dir, labeled with a
sha1 hash and a commit message. Every state of the working dir can be
reconstructed by assembling all commits (sets of changes) one after another.

You can see a commit just like a patches. You can rearrange commits with
rebase (commits 1 then 2 can be rearranged to 2 then 1).

You can play around in a different branch, do this and that, there
commit an interesting feature and then merge only this one commit into
master. This is done by the command "git cherry-pick $hash"

As a commit is a change independent of the filesystem, you can even
distribute different changes in one file to several commits.

This is, what I meant, when I said, that I do refacturing while coding a
feature and then commit my work with different commits into the repo.

Everything unclear now?

;-)

Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tig-staging-area.png
Type: image/png
Size: 39722 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180209/c00da5fc/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gitg-staging-area.png
Type: image/png
Size: 37401 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180209/c00da5fc/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180209/c00da5fc/attachment-0001.sig>