Back to Website

Useful git settings

All development related issues welcome

Moderator: Moderator Team

Useful git settings

Postby Black_Fox » Thu Feb 16, 2017 6:27 pm

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.
Black_Fox
 
Posts: 1580
Joined: Fri Feb 15, 2008 9:44 pm
Location: Czechia

Re: Useful git settings

Postby hto » Thu Feb 16, 2017 7:58 pm

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.
hto
 
Posts: 2192
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Postby hbelusca » Thu Feb 16, 2017 7:59 pm

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.
hbelusca
 
Posts: 785
Joined: Sat Dec 26, 2009 10:36 pm
Location: Orsay, France

Re: Useful git settings

Postby hto » Thu Feb 16, 2017 8:32 pm

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.
hto
 
Posts: 2192
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Postby Black_Fox » Fri Feb 17, 2017 5:01 pm

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.
Black_Fox
 
Posts: 1580
Joined: Fri Feb 15, 2008 9:44 pm
Location: Czechia

Re: Useful git settings

Postby hto » Fri Feb 17, 2017 7:37 pm

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.
hto
 
Posts: 2192
Joined: Sun Oct 01, 2006 3:43 pm

Re: Useful git settings

Postby middings » Sat Feb 18, 2017 1:49 pm

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#_cutting_down_bisection_by_giving_more_parameters_to_bisect_start

Clever people can use "git bisect run" with a script or command to automate the hunt for a regression.
middings
 
Posts: 541
Joined: Tue May 07, 2013 9:18 pm
Location: California, USA

Re: Useful git settings

Postby hto » Sat Feb 18, 2017 5:35 pm

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.
hto
 
Posts: 2192
Joined: Sun Oct 01, 2006 3:43 pm


Return to Development Help

Who is online

Users browsing this forum: No registered users and 6 guests