The Ten Git-mmandments - Revision history

Ajwt3 at 17:14, 15 September 2022

2022-09-15T17:14:57Z

← Older revision		Revision as of 17:14, 15 September 2022
Line 30:		Line 30:
	#::> This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.		#::> This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.
	#*As a maxim, you do not ever want to add a file to a repository that you did not create.		#*As a maxim, you do not ever want to add a file to a repository that you did not create.
	#'''Thou shalt NOT think once when having to modify someone else's code.'''		#'''Thou shalt NOT think only once when having to modify someone else's code.'''
	#*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.		#*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.
	#*Moving on, what you can do here is:		#*Moving on, what you can do here is:

Zz376 at 14:44, 2 September 2022

2022-09-02T14:44:50Z

Tkl35 at 14:23, 25 August 2022

2022-08-25T14:23:30Z

← Older revision		Revision as of 14:23, 25 August 2022
Line 11:		Line 11:
	#*They do not exist for no reason, create one to satisfy the above rules.		#*They do not exist for no reason, create one to satisfy the above rules.
	#*Visit https://git-scm.com/docs/gitignore for more information on formatting one.		#*Visit https://git-scm.com/docs/gitignore for more information on formatting one.
	#*Do not skip the following example:		#*Do not skip the following (bad) example:
	#::> Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code.		#::> Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code.
	#::> As expected, you run into an error, nano into the file with the error and make the necessary changes.		#::> As expected, you run into an error, nano into the file with the error and make the necessary changes.

Tkl35 at 14:14, 25 August 2022

2022-08-25T14:14:39Z

← Older revision		Revision as of 14:14, 25 August 2022
Line 39:		Line 39:
	#::> But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.		#::> But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.
	#::> Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.		#::> Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.
	#'''Do NOT ~~included~~ autogenerated files in your git repository.'''		#'''Do NOT include autogenerated files in your git repository.'''
	#*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.		#*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.
	#*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.		#*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.

Tkl35 at 14:14, 25 August 2022

2022-08-25T14:14:27Z

← Older revision		Revision as of 14:14, 25 August 2022
Line 34:		Line 34:
	#*Moving on, what you can do here is:		#*Moving on, what you can do here is:
	#::> Create a new repository separate from your '''present repository'''.		#::> Create a new repository separate from your '''present repository'''.
	#::> Branch the (target) person's project into your new repository. The term for such a "cross-repository" branch is ~~```~~fork~~```~~.		#::> Branch the (target) person's project into your new repository. The term for such a "cross-repository" branch is fork.
	#::> Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.		#::> Inside your new repository, make a '''new branch''' where you make your modifications to their code as git commits with a merge request back into the ```main``` (of your new repository) at the end.
	#::> If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.		#::> If you are in the mood, you can even make a ```pull request``` back to the (target) person's project branch with your new code.

Tkl35 at 14:12, 25 August 2022

2022-08-25T14:12:14Z

← Older revision		Revision as of 14:12, 25 August 2022
Line 30:		Line 30:
	#::> This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.		#::> This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.
	#*As a maxim, you do not ever want to add a file to a repository that you did not create.		#*As a maxim, you do not ever want to add a file to a repository that you did not create.

	#'''Do NOT think once when having to modify someone else's code.'''		#'''Do NOT think once when having to modify someone else's code.'''
	#*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.		#*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.

Tkl35 at 14:12, 25 August 2022

2022-08-25T14:12:03Z

@@ Line 1: / Line 1: @@
-Herein lies precious Git-related wisdom, do not disregard at your own risk!
+Herein lies precious Git-related wisdom, do not disregard at your own convenience!
 #'''Do NOT treat Git repositories like Google Drive'''.
-#*Git repositories do not exist to for you to backup all your files (e.g., cache, output and log files).
+#*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).
 #*Do not be trigger happy with ```git add --all```.
-#*In other words, do not add whole directories.
+#*Do not add whole directories.
 #*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.
 #'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''
@@ Line 19: / Line 19: @@
 #*Do not forget that little and often with code review is better than the former.
 #*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.
-#'''Do NOT foster a habit '''
+#'''Do NOT forget the concept and importance of source control.'''

Tkl35 at 13:11, 25 August 2022

2022-08-25T13:11:00Z

← Older revision		Revision as of 13:11, 25 August 2022
Line 1:		Line 1:
	Herein lies precious Git-related wisdom, disregard at your own risk!		Herein lies precious Git-related wisdom, do not disregard at your own risk!

	# '''Do NOT treat Git repositories like Google Drive'''.		#'''Do NOT treat Git repositories like Google Drive'''.
			#*Git repositories do not exist to for you to backup all your files (e.g., cache, output and log files).
			#*Do not be trigger happy with ```git add --all```.
			#*In other words, do not add whole directories.
			#*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.
			#'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''
			#*Basically, you have been warned.
			#'''Do NOT ignore .gitignore.'''
			#*They do not exist for no reason, create one to satisfy the above rules.
			#*Visit https://git-scm.com/docs/gitignore for more information on formatting one.
			#*Do not skip the following example:
			#::> Sometimes, you might want to code using an IDE on your personal computer, git push and then git pull onto a workstation to run the code.
			#::> As expected, you run into an error, nano into the file with the error and make the necessary changes.
			#::> The code now works and you happily git push from the workstation, with all your output and cached folders.
			#'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''
			#*Do not operate with the mentality of only submitting completed working code.
			#*Do not forget that little and often with code review is better than the former.
			#*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.
			#'''Do NOT foster a habit '''




			"Do not" counter: 12+

Tkl35 at 12:47, 25 August 2022

2022-08-25T12:47:47Z

← Older revision		Revision as of 12:47, 25 August 2022
Line 1:		Line 1:
	Herein lies precious Git-related wisdom, disregard at your own risk!		Herein lies precious Git-related wisdom, disregard at your own risk!

	* Do NOT treat Git repositories like ~~your~~ Google Drive.		# '''Do NOT treat Git repositories like Google Drive'''.

Tkl35: Created page with "Herein lies precious Git-related wisdom, disregard at your own risk! * Do NOT treat Git repositories like your Google Drive."

2022-08-25T12:46:29Z

Created page with "Herein lies precious Git-related wisdom, disregard at your own risk! * Do NOT treat Git repositories like your Google Drive."

New page

Herein lies precious Git-related wisdom, disregard at your own risk!

* Do NOT treat Git repositories like your Google Drive.

← Older revision		Revision as of 14:44, 2 September 2022
Line 1:		Line 1:
	Herein lies precious Git-related wisdom, do not disregard at your own convenience!		Herein lies precious Git-related wisdom, do not disregard at your own convenience!

	#'''Do NOT treat Git repositories like Google Drive'''.		#'''Thou shalt NOT treat Git repositories like Google Drive'''.
	#*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).		#*Git repositories do not exist for you to backup all your files (e.g., cache, output and log files).
	#*Do not be trigger happy with ```git add --all```.		#*Do not be trigger happy with ```git add --all```.
	#*Do not add whole directories.		#*Do not add whole directories.
	#*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.		#*Maintain a minimalistic mentality, i.e., carefully consider what files are important with the focus on successfully allowing the user to run your code.
	#'''Do NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''		#'''Thou shalt NOT include .pyc files, the entire __pycache__ folder and .DS_Store files.'''
	#*Basically, you have been warned.		#*Basically, you have been warned.
	#'''Do NOT ignore .gitignore.'''		#'''Thou shalt NOT ignore .gitignore.'''
	#*They do not exist for no reason, create one to satisfy the above rules.		#*They do not exist for no reason, create one to satisfy the above rules.
	#*Visit https://git-scm.com/docs/gitignore for more information on formatting one.		#*Visit https://git-scm.com/docs/gitignore for more information on formatting one.
Line 15:		Line 15:
	#::> As expected, you run into an error, nano into the file with the error and make the necessary changes.		#::> As expected, you run into an error, nano into the file with the error and make the necessary changes.
	#::> The code now works and you happily git push from the workstation, with all your output and cached folders.		#::> The code now works and you happily git push from the workstation, with all your output and cached folders.
	#'''Do NOT send a merge request with over 453 changed files - this is impossible to review!'''		#'''Thou shalt NOT send a merge request with over 453 changed files - this is impossible to review!'''
	#*Do not operate with the mentality of only submitting completed working code.		#*Do not operate with the mentality of only submitting completed working code.
	#*Do not forget that little and often with code review is better than the former.		#*Do not forget that little and often with code review is better than the former.
	#*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.		#*Besides the mundane rationale of catching your mistakes and getting feedback quicker rather than letting than accumulate, it allows the reviewer to better track and follow your changes.
	#'''Do NOT forget the concept and importance of source control.'''		#'''Thou shalt NOT forget the concept and importance of source control.'''
	#*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.		#*This is a big one. Basically, when you are coding as a team, or if your work is derived from another user, or needs to be passed on to future users, you must consider code maintenance and management.
	#*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.		#*For example, as much as possible, do not explicitly include other people's code in your own repository, because when they update their code, you do not want to repeat the cloning or downloading process again, or have to sieve through all your and their code to find what has changed and needs to be updated. What you do want is to simply perform a ```git pull```. To that end, do not forget git submodules exist for a very good reason. See https://git-scm.com/book/en/v2/Git-Tools-Submodules.
Line 30:		Line 30:
	#::> This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.		#::> This segregation of '''your''' and '''their unedited''' code makes life way easier since you effectively only have to deal with '''your''' own code.
	#*As a maxim, you do not ever want to add a file to a repository that you did not create.		#*As a maxim, you do not ever want to add a file to a repository that you did not create.
	#'''Do NOT think once when having to modify someone else's code.'''		#'''Thou shalt NOT think once when having to modify someone else's code.'''
	#*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.		#*The previous rule does not consider the case when you have no choice but to modify someone else's code in order to make it work. This might happen when you are trying to integrate their software with other pieces of software, and a mere wrapper function will not suffice. By the way, side tracking a little, do not use the horrible shortcut of writing code to convert a .py file to .txt file, edit it like a text file before converting it back to a .py file and importing it. Do not forget wrapper functions exist for a reason. Moreover, when importing user-defined variables into your program, please do not format it as a text file and execute it like a .py file. It makes future integration and extension an absolute nightmare. Do not forget the literal eval function exists too.
	#*Moving on, what you can do here is:		#*Moving on, what you can do here is:
Line 39:		Line 39:
	#::> But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.		#::> But considering your own needs first, you can then add this '''new branch''' as a submodule in your '''present repository'''.
	#::> Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.		#::> Again, do not forget that untangling other people's code is a horrible process, so you want to keep yours and their code as separate as possible.
	#'''Do NOT include autogenerated files in your git repository.'''		#'''Thou shalt NOT include autogenerated files in your git repository.'''
	#*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.		#*Do not forget that autogenerated files, e.g., .o and .d files, will change when you recompile them even if their source files have not.
	#*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.		#*Instead, add the compilation instructions to your README and leave that to the user. Again, do not forget ```make``` files exist.
	#'''Do NOT forget to test your code on a workstation.'''		#'''Thou shalt NOT forget to test your code on a workstation.'''
	#*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.		#*It is not a matter of making sure your code runs on a specific workstation, but to remember that the end user will have a different machine with a different setup.
	#*For example, your code may require a compiler GLIBC >= 2.29 that in turn requires Ubuntu >=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.		#*For example, your code may require a compiler GLIBC >= 2.29 that in turn requires Ubuntu >=20.04. A quick check will reveal, as of August 2022, that most machines are running an older version.
Line 48:		Line 48:
	#*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.		#*You do not want your reviewer (and therefore you) to spend ages just to debug software requirement related errors.
	#*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.		#*As such, do not miss an opportunity to test your code on a 'fresh' machine. It may be helpful to even record the system specifications when your code runs successfully to aid with that.
	#'''Do NOT be afraid to clarify git related concepts as early as possible.'''		#'''Thou shalt NOT be afraid to clarify git related concepts as early as possible.'''
	#*Especially when it is your first time using Git.		#*Especially when it is your first time using Git.
	#'''Do NOT forget to share your mistakes and helpful pointers with your colleagues.'''		#'''Thou shalt NOT forget to share your mistakes and helpful pointers with your colleagues.'''
	#*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.		#*We certainly do not wish to entertain the situation of multiple people making the same mistakes with the same reviewer.