Jump to content

Photo

A Basic Modder's Guide to Git and Github


26 replies to this topic

#16 DavidW

DavidW
  • Gibberlings
  • 4632 posts
  • Gender:Male

Posted 26 September 2018 - 09:26 PM

follow up question: how do I get at that command-line interface?

(My sum knowledge of all this is contained in Cam's original post, and that uses TortoiseGit, not the command line.)

#17 ALIENQuake

ALIENQuake
  • Modders
  • 629 posts
  • Gender:Male
  • Location:Poland

Posted 26 September 2018 - 11:26 PM

follow up question: how do I get at that command-line interface?

(My sum knowledge of all this is contained in Cam's original post, and that uses TortoiseGit, not the command line.)

Please don't start with CLI. You will loose time and eventually be frustrated. The GUI will  give you very nice flexibility and extra features like diff's across branches/taks without being git cli master.

 

Take look at this: https://www.slant.co...visual-git-guis and choose any GUI

 

My personal suggestion would be:

1. SmartGit - it's free, cross-platform, every git operation is also presented as commandline version, simple operations take one click, advanced operations are easy, every time that something was fuckedup, I manage to recover without using CLI

2. SourceTree - almost exactly as above, key difference is interface

3. GItKraken - if you like dark interface

 

If you really want CLI: https://gitforwindows.org


Edited by ALIENQuake, 26 September 2018 - 11:33 PM.


#18 ALIENQuake

ALIENQuake
  • Modders
  • 629 posts
  • Gender:Male
  • Location:Poland

Posted 27 September 2018 - 12:10 AM

Cam (or anyone): how does one revert a set of pushed changes?

(It’s hypothetical, I don’t need to do it right now.)

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

 

Example: https://github.com/G.../commits/master

Suppose that you want to revert this commit: 6189a9f

 

1. You need to preform "git reset" for the one commit before: "Minimal content in the readme" 915f587

2. Then, you need to "git push --force" to rewrite online history, you basically replacing the online version of the repo with modified local copy

3. Depends on the type of the "reset" operation (mixed, soft,hard), you can also reset all local changes to files - it's like restoring local full backup

 

What is the effect of such operation? When people will try to "pull" from you repo, they will get the error that mismatch history and they can't pull it anymore. So how software devs are dealing with such unwanted side effects? They never rewrite history: they simply revert commits and pushed new one where the changes are reverted. Rewriting history is used only when repo contain sensitive private data like passwords etc.

 

Consider the nature of you project, I won't be a big deal when you rewrite history once a while if you really wanted to do so.


Edited by ALIENQuake, 27 September 2018 - 02:02 AM.


#19 Wisp

Wisp
  • Modders
  • 1142 posts
  • Gender:Male

Posted 27 September 2018 - 03:58 AM

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

#20 ALIENQuake

ALIENQuake
  • Modders
  • 629 posts
  • Gender:Male
  • Location:Poland

Posted 27 September 2018 - 04:08 AM

 

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

 

Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.


Edited by ALIENQuake, 27 September 2018 - 04:09 AM.


#21 Wisp

Wisp
  • Modders
  • 1142 posts
  • Gender:Male

Posted 27 September 2018 - 04:58 AM

 

 

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

 

Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.

 

No, it's not. `revert` is the proper way to undo a pushed commit. It creates an inverted commit that undoes the targeted commit entirely.

 

The thing you are talking about, rewriting history, is arguably a bad way to work with pushed commits. It's fine for local stuff, knock yourself out, but once the commit is pushed, you should not rewrite it unless you have very good reason. Beyond `revert`, you "alter" a pushed commit by pushing a new commit that makes the desired changes.



#22 ALIENQuake

ALIENQuake
  • Modders
  • 629 posts
  • Gender:Male
  • Location:Poland

Posted 27 September 2018 - 05:38 AM

 

 

 

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

 

Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.

 

No, it's not. `revert` is the proper way to undo a pushed commit. It creates an inverted commit that undoes the targeted commit entirely.

 

The thing you are talking about, rewriting history, is arguably a bad way to work with pushed commits. It's fine for local stuff, knock yourself out, but once the commit is pushed, you should not rewrite it unless you have very good reason. Beyond `revert`, you "alter" a pushed commit by pushing a new commit that makes the desired changes.

 

wisp, The recommended way is ofc to create next commit where you simply revert changes. I'm just explaining how to remove/alter already pushed commits. Is not desired and should not be generally used but it's good to know why and how to eventually do it.



#23 Gwendolyne

Gwendolyne
  • Members
  • 220 posts
  • Gender:Male
  • Location:France

Posted 13 October 2018 - 08:29 PM

Another technical question on releases:

 

In my local repo, I created a 'legacy' folder that gathers

  • All the former files that have been modified (I am updating a very old mod, so I fix all bug reports I found AND I provide EE compatibility)
  • All the content that was unused and therefore not installed

If I push them in the remote repo, then create a pre-release for testing, this folder is included in the release, what I don't want. I really need to keep track of the latest version in the repo, but I don't wan't to release this stuff.

 

Is there an easy way to exclude the legacy folder from the release? I am not sure gitignore is the right thing to do it... :hm:


Edited by Gwendolyne, 13 October 2018 - 08:29 PM.

CARPE DIEM...



In progress : Menace sur le Royaume de Diamant Éternel

#24 lynx

lynx
  • Modders
  • 3144 posts
  • Gender:Male
  • Location:Ljubljana, Slovenija

Posted 13 October 2018 - 10:48 PM

How are you making the pre-release?


GemRB - IE anywhere.
Mages needed! Looking for Planescape: Torment testers
Play android version IS NOT SUPPORTED ANYMORE: reported bugs will be ignored! Still looking for builders ...


#25 Mike1072

Mike1072
  • Gibberling Poobah
  • 2531 posts
  • Gender:Male
  • Location:Canada

Posted 13 October 2018 - 10:58 PM

If you're creating releases via the Mod Packaging tool, it doesn't have any explicit support for excluding files or folders (and it won't ignore stuff you specify in .gitignore).

 

However, you could go in and modify it to exclude your specific folder.  It already excludes some predetermined files depending on whether it is packaging Windows, OS X, or Linux versions (see the -x flags on lines 83, 95, and 106 here).



#26 Gwendolyne

Gwendolyne
  • Members
  • 220 posts
  • Gender:Male
  • Location:France

Posted 13 October 2018 - 11:04 PM

I used the release tab on github and tagged the release as pre-release for testing. I don't care if the testing release contains the legacy folder, but I would prefer no packaging it in the final release.

 

Edit: and I thought the Mod Packaging Tool was created to provide G3 formated release (exe).


Edited by Gwendolyne, 14 October 2018 - 02:19 AM.

CARPE DIEM...



In progress : Menace sur le Royaume de Diamant Éternel

#27 Wisp

Wisp
  • Modders
  • 1142 posts
  • Gender:Male

Posted 14 October 2018 - 01:20 AM

You need to exclude the legacy files from version control. Tags (and github releases are tags) you create include all tracked files; they are essentially a snapshot of the project. Alternatively, do like Mike suggested and do not mind having the legacy files present in the tag, but exclude them when you create the archive you intend to distribute.


Edited by Wisp, 14 October 2018 - 01:22 AM.




Reply to this topic



  


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users