Git for Dumb Patchers

So another project I’ve been working on where git was being used for a repo, but like every other time I’ve used it with multiple people it didn;t do what it says on the tin, and people were overwriting patches that shouldn’t. So can I suggest some tutorials for Dumb Patchers, which goes from how to setup a git in the first place, and through how to work on one as part of a team, how to merge branches, what to look out for and what not to do.
Many of us work alone mostly, so its not necessarily an issue, until you have a group project. So some rules, or suggestions for work flows, how to spearate patches, have multiple documents etc I think would be useful, especially as some libraries are becoming quite large and people should ideally be adding to them as they go.

1 Like

I think you are speaking about merging patches that have been changed by several people at the same time. This issue is addressed by this tool:

That does sound useful, but a git for v4 would be useful anyway, as what sounds like a simple clear tool for coders, is a weird obstacle course for people outisde of the creed, or at least it seem pretty wierd to me! Maybe its just me thats the dummie, who knows!

@catweasel have you tried it made it much clearer and easier for me.
Pairs really well with visual studio code as a text editor

We use Gitextensions and avoid using branches and all the bells and whistles. Just commit, push and merge.

Here an example of our workflow with many ppl

Very smooth collaborative workflow with almost no conflicts.

Thing is, when working with Git with multiple people, its all about communication. When you don’t set rules like : Who does what? which patch/code is owned by who? Stuff happens like you describe. We talk about stuff like that, several times a day and do updates depending on the progress of the project.

Git isn’t the problem, only lack of communication creates problems.

Once you are clear about what your concern (patch) of the project is, you can inspect the changes in Gitextension before pushing them. If there is something in the changes which should not be changed by you, just rightclick and “revert change”.

Gamma/VL will make this a bit more complicated but i think i’d split the tasks into libs /VL documents for each team member, and one member gets the right to pull it all together. we will see.


Good summary, communication and gitextensions is definitely the basis of a delightful life with git.

some additional info regarding gitextensions/git. i find it a bit painful to install gitextensions with separate installation for git and kdiff. something which might be confusing the first time.

and there are quite a few settings to tick, to get it to work. one thing which seems important (since it caused some weird errors in the past) is this window
this is the default setting in the screenshot but i always choose “Checkout as is - commit as is” to make sure git isn’t altering the code.

Whats your experience ? Important or not ?

it is recommended to leave the default there. the feeling that git will “alter the code” isn’t something you need to pay much attention to. it does this millions of times every minute, no worries there.

it is rather problematic, if you think about it, because you will then get linux file endings locally if you check out repos that use the default setting.

we also used “as-is” in the beginning, but we now switched back to the default, because of these kind of problems.

we had broken XML files aka v4p due to this, but this is years ago.

would any of these tutorials be helpful or would you say the git side is clear, it is really mostly about .vl documents specifically?

Also these are great references for recommended practices on:


Commit Messages:

Of course nothing is written in stone, take from these only what makes sense for your team and project.

@joreg I would still say a video for dummies would be good, given that nugets need them, and you I guess would like people to contribute to VL. A simple how to get started and how to make a nuget, and how to add someones update to your git, ie what to look for when you do it would be good. All the git tutorials are made by/for programmers, and if you are a lone patcher, then “take from these only what makes sense for your team and project.” isn’t a helpful suggestion ;)
I’d say define a best practice for patchers, demo it, and then maybe we will all have a similar method of working.

1 Like