Useful git settings

All development related issues welcome

Moderator: Moderator Team

Post Reply
User avatar
Black_Fox
Posts: 1584
Joined: Fri Feb 15, 2008 9:44 pm
Location: Czechia

Useful git settings

Post by Black_Fox »

Right now on the mailing list there are mainly two issues people are having with git:
- pulling and pushing creates merge commits
- can't pull with local changes

As is already in the mailing list solved here for pulling:

Code: Select all

git config --global pull.rebase true
(enable automatic rebase of your local commits when pulling = pull and then try to put your local commits on top of that)

let me also add another setting that will allow pulls with local changes (preserving them):

Code: Select all

git config --global rebase.autoStash true
(combined with the previous setting, automatically stash before pull and automatically stash pop after pull.... stash = a special stack dedicated to storing local changes)

That's it! That solves two most discussed issues! The only remaining issue that I remember from the earlier discussions is that you can't have sequential numerical commit IDs. That a design decision, I'm not knowledgeable enough to explain it properly. Of course, you can try numbering the commits in the commit messages themselves, but of all the Github projects I know that did it, none do it anymore; they've all dropped the approach, probably because it doesn't bring much use.

For me the TortoiseGit is a bit convoluted (especially when compared to TortoiseSVN) for the user while actually limiting the possible options. At work I handle git 95 % of time in the Linux terminal (we only use Git), for my pet projects at home I use GitKraken on Windows. If there is any user info you'd like to know about Git, I can try to answer. I'm self-taught, but can try.

To add a little bit on the weights in favour of Git (as nobody or not many seems to be doing this on the mailing lists) -
- branches are cheap, simple and quick
- interactive rebase is a great tool for coding your stuff now and reorganizing it into better shape later (just before you push/send a PR)
- the inclusion of local repo is ingenious - you can code on the bus or on the plane (or on a conference that has spotty connection)
- you can have e.g. 3 different parts of one file being worked on and commit only one part you want, keeping the rest for later commits (git add -p)
- tons of small projects, but also large operating systems use git as a version control system

My last sentence: Git feels extremely weird and unwieldy if you want to use it like SVN. SVN is outright impossible to use like Git.
There is a learning curve to Git. I only had experience with SVN and it took me about 3 days in Git to learn the basic everyday stuff. There is a great free book Pro Git that can teach you a lot.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Post by hto »

Of course, you can try numbering the commits in the commit messages themselves, but of all the Github projects I know that did it, none do it anymore; they've all dropped the approach, probably because it doesn't bring much use.
Sequential IDs are quite useful for numbering ISO images and test results. Perhaps a server-side Git hook could be used for assigning IDs automatically. Another solution would be a database running at build.reactos.org to map Git hash IDs to sequential IDs, and vice versa.
hbelusca
Developer
Posts: 1204
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Useful git settings

Post by hbelusca »

The point with the numerical commit IDs is that, on SVN, when you see e.g. "commit r73245" and "commit r61232", you know automatically without consulting the history, that r61232 came before r73245, and you can find them really easily in the history list. With Git, the commit "numbers" (if we can call them like that), are the SHA-1 hashes. So for example, if you see "commit e641e6e49b658efec8ede5a6402de3ce591ee7c2" and "commit cc373223b0803d19bc3b2bb315000e1e31274b86", you cannot say whether the first commit came after or before the second one (in this example, they are two different commits from Wine; the first one came before the second one), and because of this you need to browse the history and enumerate all the list to find the commits. This is something that I don't really enjoy. It might be possible, using Git hooks or whatever (I'm not an expert on that) to attribute sequential commit number IDs to these SHA-1 hashes (aka. create a map), providing the Git commits to the master are done in a linear (sequential) manner. As soon as you have non-linear (parallel) Git histories, this becomes impossible.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Post by hto »

The point with the numerical commit IDs is that, on SVN, when you see e.g. "commit r73245" and "commit r61232", you know automatically without consulting the history, that r61232 came before r73245, and you can find them really easily in the history list.
Yet another solution is to use timestamps for numbering commits, ISO images, test results.
User avatar
Black_Fox
Posts: 1584
Joined: Fri Feb 15, 2008 9:44 pm
Location: Czechia

Re: Useful git settings

Post by Black_Fox »

It's possible to force a fast-forward history (a linear one, without merge commits) in a Git repo, so combined with the sequentially numbering server-side hook this could work.

I can't help with use cases such as "what happened 1500 commits ago" or "do we already have 75000 commits so that we can celebrate", because they don't have simple GUI answers (but you can still get those answers with CLI one-liners, the first one is solved by "git log HEAD~1500" and the second one by "git rev-list HEAD | wc -l").

A use case that might be interesting is the hunting for regressions done by binary search. In git there is a mechanism built specifically to solve this problem - git bisect. You start with a range enclosed between last known good commit ID and a first known bad commit ID and then it does the commit searching work for you, you just say "this one is good, this one was bad", until you narrow it down.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Post by hto »

Some people are hunting for regressions by downloading and installing ISO images from iso.reactos.org. Better to keep them numbered sequentially / monotonically (like bootcd-73817-dbg.7z or bootcd-201702171641-dbg.7z). Also, it's good to know what kind of changes were made for each build. If you hunt for a networking regression, it makes no sense to test a Notepad change.
middings
Posts: 1073
Joined: Tue May 07, 2013 9:18 pm
Location: California, USA

Re: Useful git settings

Post by middings »

hto wrote:Some people are hunting for regressions by downloading and installing ISO images from iso.reactos.org. Better to keep them numbered sequentially / monotonically (like bootcd-73817-dbg.7z or bootcd-201702171641-dbg.7z).
The "git bisect" tool makes sequential numbering unnecessary when hunting for regressions. Unfortunately some people will not want to learn yet another tool.
Also, it's good to know what kind of changes were made for each build. If you hunt for a networking regression, it makes no sense to test a Notepad change.
Give "git bisect" a path and it will restrict its bisection to that part of the source tree.
https://git-scm.com/docs/git-bisect#_cu ... sect_start

Clever people can use "git bisect run" with a script or command to automate the hunt for a regression.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Post by hto »

Unfortunately some people will not want to learn yet another tool.
Unfortunately, yes; I remember that some ReactOS translators had difficulties with creating patches.

Perhaps a Web frontend to "git bisect" on the ReactOS site could help.
vgal
Posts: 88
Joined: Mon Jan 26, 2015 7:38 am

Re: Useful git settings

Post by vgal »

Find regression conveniently and quickly when using TortoiseGit and bisect.
[ external image ]
[ external image ]
[ external image ]
But the GitHub ReactOS repository has not always updated.
My question: is it possible that similar with SVN and TortoiseSVN?
hbelusca
Developer
Posts: 1204
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Useful git settings

Post by hbelusca »

@vgal: As far as I know, SVN doesn't have such a functionality built-in. However there certainly exists tools out there, that can help you doing the bisecting job. The last resort being to do the bisection by hand ^^
vgal
Posts: 88
Joined: Mon Jan 26, 2015 7:38 am

Re: Useful git settings

Post by vgal »

hbelusca wrote:The last resort being to do the bisection by hand ^^
Of course, nails can be clogged with bricks. I still like the hammer more, or better yet. :geek:
I've heard about App-SVN-Bisect, but there's no time to mess around. Maybe someone knows a "ready-made recipe".
Serge Gautherie
Posts: 11
Joined: Mon Nov 07, 2016 3:29 am

Re: Useful git settings

Post by Serge Gautherie »

vgal wrote:But the GitHub ReactOS repository has not always updated.
See ONLINE-661.
Post Reply

Who is online

Users browsing this forum: No registered users and 11 guests