Jump to content
CamDawg

A Basic Modder's Guide to Git and Github

Recommended Posts

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.)

Share this post


Link to post

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/topics/4985/~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

Share this post


Link to post

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/Gibberlings3/immutable/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

Share this post


Link to post

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.

Share this post


Link to post

 

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

Share this post


Link to post

 

 

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.

Share this post


Link to post

 

 

 

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.

Share this post


Link to post

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

Share this post


Link to post

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).

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...