[Gambas-devel] Fwd: Cloned and edited. How do I get the changes staged, committed, and then uploaded to GitLab?

[adamnt42 at ...176...]

Try something along the lines of this

	$ <edit/compile/test>	
	$ cd [your local repository] <1>
	$ git add * <2>
	$ git commit -a -s <3>
	$ git format-patch master <4>
	$ git send-email --to="<person> <email at ...773...>" 00*.patch <5>

This is what is known colloquially as a "git WorkFlow". In other words it's all the stuff that needs to be done to make some "other stuff" happen.

The <?> bits are explanations of what is happening here. Don't type them.
The [?] bits are needed see below.

<edit/compile/test> As in use the IDE, whatever, to make your changes. Try them out, fix, etc, etc. This is not really a command line but is part of what you do "every-day", so to speak. Nor is it anything to do with git.

<1> OK, so the fix is looking good. Now we want to get into "git" mode.  (This was the hardest thing I had to come to terms with. git is actually just a "source code manager" aka "SCM". Some may wish to call it a "VCS" (Version Control Manager) which it is - if and only if you are the administrator of the pure source base. If you are as old as I am perhaps the following may jog some memories "PCVS", "PVCS", etc.) "git", as in your locally installed "git" only works at the command line level with the current working directory, i.e. what you get with $ pwd
So,
[your local repository] is the directory where you cloned the original gambas source down to. 
We are now somewhere where "git" commands can be used.

<2> This is only "really" necessary if you have added any new files to your local repository. File deletions and modifications to existing files are taken care of automagically in the following. You could also use $ git add [my new file] to tell git about a specific new file, but "git add *" does take care of any of those little things we may have forgotten.  And by the way it doesn't do any damage. If there are no new files then it will tell you so. If there are some then it will tell you that anyway.
 
So, where are we at now.  In short, "git" now knows that there is new "stuff" in your local repository.  This "stuff" is in the files that EXIST in your local repository.  In other words, if you were to open one of those files in a text editor, then what you would see is the file exactly as you left it. BUT we now have to start thinking in "git" mode.  ...

How can I state this. ... ah, bugger political correctness.
"git" is like your 16 year old son who can't find his football boots on Saturday morning, but he is "sure" they "should" be exactly where he left them last Saturday afternoon (i.e. in the middle of the laundry floor).
So we have to tell him, "No, I cleaned them, polished them and put them back in your cupboard last Sunday." 
Likewise, we have to tell "git" the same type of thing.  Hey "git", your boots are back in the supboard!
This is called a "commit". 
So now we know what it is we will 

<3> Then make a commit to your local repository. 
	-a means that all (sorry, ALL) your local changes will be committed to your local repository. 
        -s means that the commit will be signed with your (local or "global" email name and address)
	
So, now the "son", sorry the "git" now knows that you are serious. In it's tiny little mind it compares it's idea of what the file should look like to what it actually looks like and comes up with a set of "differences".  Sort of like "son" comparing his mental image of the laundry floor and the actual contents of the cupboard... thinks "Hmm, that's strange, the laundry fairies must have moved them?"
Which is why the -s is kind of important.

<4> 

Woops! I gotta go do stuff.
I'll finish this ;ater.

b
-- 
B Bruen <adamnt42 at ...769... (sort of)>