General thread about GIT

[CM630]

Maybe it is not completely off-topic to have a thread about GIT.
I have to do some things with GIT, maybe somebody knows a good tool with a GUI (I am not interested in proprietary SW)?
I have installed TortoiseGit, but its Repo-Browser is a disaster - I cannot type the address of the repository!?
I tried GitHub Desktop - it is also Windows only, but it cannot even clone
Maybe some working tutorials will be useful.

[Martin_fr]

its Repo-Browser is a disaster - I cannot type the address of the repository!?

1) Why would you?
2) I don't think any other GUI (or command line) would.

Technically: The address of the repo is the local folder.
What you mean (I guess) is the "remote address" (or rather any one of the possible many / if any, as it can be zero).

With GIT, if you want to work on a remote repo, you enter the address (GUI or command line) when you do a "git clone". (You can add more than one, but lets ignore that).

Once you have done that, you work on the local copy.
You can sync the local copy with the remote using "git push", "git pull", "git fetch", "git remote update".

"git log" always shows what is in your current local copy. There is no way to show the commits on the remote (there may be a way to list the branches, but not the commits in it / not sure / would have to check).

You will find on google things like
  git log remotes/origin/main
But that logs your local (as off when you last synchronised) knowledge of what was on that remote. It does not check if the remote has since been updated.

But "git remote update" will sync, without changing your local branches. (So you can keep your "main" on a possible older commit, while getting the "remotes/origin/main" to whatever is on the remote.


For training you can use a local folder as remote.

Code: Bash  [Select][+][-]

1. cd /test/
2. mkdir remote
3. cd remote
4. git init
5. # maybe make an initial commit / avoid later warning of cloning empty repo
6. cd ..
7. mkdir local
8. cd local
9. git clone ../remote .
10.  

Tortoise is IMHO very easy to use.

It does however hide the "git add" / "git commit" distinction a bit (thought to an extend that depends on config), and make it look a bit more like it used to be in svn.  In some cases that can make it a bit easier, though of course if you go word by word for the git documentation ....

You can use the above local example with tortoise. You can even do the init, and all other steps in tortoise.

[CM630]

its Repo-Browser is a disaster - I cannot type the address of the repository!?

1) Why would you?
...

In TortoiseSVN I open the repo browser, type the remote address of the repository, create there what is necessary (folder of the project or feature). I can drag and drop the contents for the inital commit.
I do not have to download anything that I do not need.
From you explanation I get the idea that in GIT I need do clone the entire repository locally, before starting to work with it. Or I need to download the content of the parent folder at least?


Meanwhile, I installed LazyGit ( the name looked promising) and Guitar... does not seem like tools for users with very basic GIT needs.

[JuhaManninen]

From you explanation I get the idea that in GIT I need do clone the entire repository locally, before starting to work with it.

Yes, the entire repository with all its history. That makes Git so good. Everything happens quickly with a local data, including bisecting an old nasty bug. Git compresses its history data well, don't worry about disk usage.

Meanwhile, I installed LazyGit ( the name looked promising) and Guitar... does not seem like tools for users with very basic GIT needs.

I use gitk and "git gui" for viewing and committing. Everything else from cmd line. Works very well for me.
IMO gitk and "git gui" are underrated. Their usability is super good. I don't know why people download some fancy external tools instead.

[Martin_fr]

In TortoiseSVN I open the repo browser, type the remote address of the repository, create there what is necessary (folder of the project or feature). I can drag and drop the contents for the inital commit.
I do not have to download anything that I do not need.

But you do have do download the same revision(s) over and over again, if you switch between them. (Well, svn may cache a bit, but still).
Of course in svn you would not do that very often. You would likely always be on the top commit. And only change if you switched branches (which in svn is not that common).

In git, I switch branches often, very often. I also switch to non-top commits, to check behaviour before a specific change.
(And I can search for changes in commits without relaying on the server)

But yes, in as Juha answered, in git you need to download the repo first.
It is possible to do that shallow (e.g only last 1000 commits), but then your log will also only show that.
I would not recommend that, really not...

The advantage, you can still work if you are offline. I know in some regions that rarely happens...

The download size, depends on how well the data is packed on the remote.
The local storage size can be less, if you spent the cpu cycles to repack (unless it came well packed in the download).

My local lazarus git
- The checked out files of the current top commit are appox 255MB
- A well packed .git dir (the gits internal storage of all commits, all history, ...) 262MB
- A "working" .git dir (not well packed, fair amount of additional local commits, 12 month of internal recycle-bin...) 400MB

The last one will go down, if I do a manual repack. It does get automated ones.
It also has every trashed commit (local work that turned out bad, and was replaced) of the last 12 month in the internal recycle bin (normally only 6 weeks but I changed my settings).

[ALLIGATOR]

Interestingly, I consider TortoiseGit to be the best graphical interface for Git, and I am so used to it that I don't want to switch to the command line (because I find the command line inconvenient)

And that's why it's very sad under Linux that I haven't found a Git GUI client that's as convenient, but there's hope for

https://gitlab.com/jramx/lazgitgui

[CM630]

My main complaint about it is that I cannot type the URL/ address of the repository, like I can do in TortoiseSVN... I usually start a repository exactly that way.
But it occurs that I can edit the GitLab repository from the web interface, so maybe I should file a feature request.
@Martin_fr and @JuhaManninen talk about features that I might never use, all I need is to commit, restore a previous version, if I have damaged something in a later release and create pull requests. Pull requests are for a person who does not know how to apply patches, but knows how to apply pull requests. I do not need branches, etc.

[Martin_fr]

My main complaint about it is that I cannot type the URL/ address of the repository, like I can do in TortoiseSVN...

Well git works fundamentally different than svn. That reflects in the frontends.

git needs to do a clone. Otherwise it wont have the info to show the log.
(git refers to what the tool git does // Websites like gitlab/github are not git, they are based on git, offering an infrastructure build on git with lots of other stuff)

In theory (and I don't know / but also don't expect) someone could write a GUI that
- has a "url" field in the log
- automatically clones any git that you haven't gotten yet
- maybe also automatically "remote updates" (though that may not be what many git users expect)
- then shows that log.

And yes, you can clone 2 or more different remotes into one local folder. That works.

As I said, I don't expect such a gui to exist. Simply because if it did, it would not be a "frontend to git", but a "new tool using git internally" (and do something different).

But it occurs that I can edit the GitLab repository from the web interface, so maybe I should file a feature request.

For what and to whom?

GitLab is not git. Of course they could do stuff in there own clients (whatever they have...). If they feel its useful.

@Martin_fr and @JuhaManninen talk about features that I might never use, all I need is to commit, restore a previous version, if I have damaged something in a later release and create pull requests. Pull requests are for a person who does not know how to apply patches, but knows how to apply pull requests. I do not need branches, etc.

Actually, a pull request is a branch. Always.
It may just have the same name. And be the only one you use.

You need to make a fork. By that you get all the existing branches, including the "main" branch. Your main branch is then an independent branch (independent of the original main branch).
And git will tell you, because it will always have "main" (your local branch) "remotes/origin/main" the one that you forked, and (if you update the fork) containing the new commits of the original project.

If you plan to do more than one pull request (over time), then I do recommend to create a branch of your own for that (a branch other than main).
Otherwise, your main branch has the unmerged changes, until they get merged. And that blocks you from using it for making a second pull request.

And even if they are merged, the will (in some case) cause a diversion between your main and the original main. And then you have to reset, to get on track again.

Also, if it takes you some time to do your pull request, you may want (or need) to update from the original git (and "rebase" your work on that), so your changes are against the latest commit.
You can do that using main. But during that process you have 2 branches with differences: main (aka heads/main) and remotes/origin/main. So why not make that clear from the beginning, and call your work branch different?
Though yes, you don't have to. It (update/rebase) works with main vs remote/main too.


For all else that I wrote about my workflow: I was guessing you might not (plan to) use all that. I was simply illustrating that the diffs between git and svn can be used as advantages. And yes, I am aware that goes both ways. Depending on needs, svn can be the more advantageous choice for someone.

Of course, if you contribute to some existing project, you are forced to follow their choice of git/svn/other.
Well either follow, or download otherwise and do patches. But if you don't want to do patches...

As for download by other means, afaik GitHub offers (or did offer?) an svn interface to the git repos hosted on them. (Gitlab afaik does not). I haven't used that, so I can't comment on how far that would get you (e.g. if you would be able to: fork, svn update/commit, and then online create a merge request...)

[Martin_fr]

Also if you don't want to download (reducing your used data volume / not sure if by much), then you can do a shallow clone. Just clone only one (the latest) commit. That commit you would need anyway to work on.

Of course, over time - if you update - your disk will have several commits starting from that one commit.

I strongly recommend NOT to do that... Unless you are forced by e.g. the company on whose connection you download, or your ISP.

[CM630]

I found a decent tool for Linux - Git Cola, and I have successfully created several pull requests for a project in Github.
I would write how to do it in the wiki, but I actually did not understand how I managed to authenticate - it refused to work with username and password, I created some tokens, but I could not apply them.
Then I suddenly started pushing successfully without providing credentials...

And there is another odd thing - in TortoiseSVN there is a setting “Global ignore pattern”, which is missing in TortoiseGit and in Git Cola‽

[Martin_fr]

Both GitLab and GitHub require tokens. Tokens are essentially purpose bound passwords (often with enforced expiry date).

When you create the token, you specify that it is for repo access.

That ensures, that if you have a git repo with stored token/password, and someone steals those credentials, they only have access to the repo, but not to your online account. I.e. the web password to your account is your master password, and reserved for login to the web (ideally with 2 factor).

Then depending on OS there are different credential managers that your local "git" program can use. Windows has a system wait storage. IIRC on Linux there is a hidden file in the user dir. But not sure.

If you don't have a user/pass set for an URL, then usually you should get ask for it. And it will then be stored in your credential file/storage. You use your username, and then for the password you use the token.

If you have an old one, that is no longer valid, then it depends on the tool. Some ask, other just give an error.
In the latter case, some tools can be forced by specifying the URL as https|git://user:token@server.com/path  And when you done that once, the user/password will updated in your credentials, and you can change the url to be without user/pass. Mind, those tools should have some other way, but you need to find out for each frontend.

[marcov]

Interestingly, I consider TortoiseGit to be the best graphical interface for Git, and I am so used to it that I don't want to switch to the command line (because I find the command line inconvenient)

Still an update that was two clicks with svn  (right click on folder, than update), is now umpteen things with stash etc. tortoisegit doesn't feel as solid as tortoisesvn did.

[Martin_fr]

Still an update that was two clicks with svn  (right click on folder, than update), is now umpteen things with stash etc. tortoisegit doesn't feel as solid as tortoisesvn did.

Not really a UI matter so. More a matter of the underlaying "engine".

Git can do more, but you need some extra steps for some basic tasks, so you can (or "are forced to") chose the way you want.

If you don't need the extras of git, then that is paying more and getting nothing for it.
If you do benefit of the extras, then that is a small price.

You can create a script (or git alias) for some of those steps. And then have one command that does the work (of course not through the GUI / but you could have a sh/bat file to do the update, and stash and force the fast forward (or rebase), and stash pop => and leave you with either a merged or conflicted result / but conflicts did exist in svn too)
=> Of course setting all that up, if you don't need git => still paying for nothing.


The one part where git needs extra steps, but I think it was a huge design flaw in svn not to need them: pull and merge locally, if the server has changes you don't.
NOTE: this is not the separation of commit and push. (that falls in the "pay for feature if you need them")
But if you had a "commit and push" => svn would do that, and the server would try to merge the changes, and just accept them, without you even knowing that the data you pushed was modified. That imho is a major flaw in svn (even though it has never bitten me). The fact that you have to merge local, and commit+push the result is imho a better approach.  (though it has new problems, if there are high frequent updates to a server).

For all else, I benefit of the extras that git offers, so to me personally the extra steps are pennies, even if accumulated over long time.
E.g. for me
- separation of commit and push: Probably less than 10% of my commits are pushed right away
- stash / pull => most of the time I am on a local branch. So I just get the updates to see them in the log, then when I want/need them I rebase my local branch.
- If I am not on a local branch then I am mostly lucky and my changes don't block an ff. But, yes, that is being lucky.

---

Btw, tortoisegit can automaticall run the pull + rebase, if your push failed (but I don't recall the settings). However, once done, one needs to trigger a new push (it doesn't offer that on its own)>
And there may be some git config "autostash" , that may get honored. I haven't researched that, just seen it mention somewhere. Not sure how tortoise then reacts to that.

[Martin_fr]

ok slightly flawed memory ...

When tortoise fails to push (server is ahead), then the error window has a button, that says "pull".

My git has

Code: Text  [Select][+][-]

1. git config pull.rebase true

And I think that is the part that tortoise honours, tortoise will automatically run a rebase after the pull.
I have to check if I have any settings to stash automatically....

[CM630]

I need to get the latest version of a source from a git repository, abandoning all my changes.
Which command shall I use?
PULL complains and says to use STASH, the documentation for STASH says it will not remove my changes, but save them for a possible future use, and I do not need them stored.
FETCH seems to do nothing.
Switch/ Checkout seems to do nothing.
I can delete the entire folder and CLONE again, but maybe there is an easier way?