DavidW Posted September 27, 2018 Share Posted September 27, 2018 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.) Quote Link to comment
AL|EN Posted September 27, 2018 Share Posted September 27, 2018 (edited) 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 September 27, 2018 by ALIENQuake Quote Link to comment
AL|EN Posted September 27, 2018 Share Posted September 27, 2018 (edited) 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 September 27, 2018 by ALIENQuake Quote Link to comment
Wisp Posted September 27, 2018 Share Posted September 27, 2018 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. Quote Link to comment
AL|EN Posted September 27, 2018 Share Posted September 27, 2018 (edited) 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 September 27, 2018 by ALIENQuake Quote Link to comment
Wisp Posted September 27, 2018 Share Posted September 27, 2018 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. Quote Link to comment
AL|EN Posted September 27, 2018 Share Posted September 27, 2018 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. Quote Link to comment
Gwendolyne Posted October 14, 2018 Share Posted October 14, 2018 (edited) 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... Edited October 14, 2018 by Gwendolyne Quote Link to comment
lynx Posted October 14, 2018 Share Posted October 14, 2018 How are you making the pre-release? Quote Link to comment
Mike1072 Posted October 14, 2018 Share Posted October 14, 2018 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). Quote Link to comment
Gwendolyne Posted October 14, 2018 Share Posted October 14, 2018 (edited) 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 October 14, 2018 by Gwendolyne Quote Link to comment
Wisp Posted October 14, 2018 Share Posted October 14, 2018 (edited) 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 October 14, 2018 by Wisp Quote Link to comment
Luke Posted November 8, 2020 Share Posted November 8, 2020 Does someone know why under my commit messages appear something like <First Name Last Name> authored and <First Name Last Name> committed X days ago instead of just <GitHub nickname> committed X days ago? I'm not sure how I enabled that change... Quote Link to comment
AL|EN Posted November 10, 2020 Share Posted November 10, 2020 @Luke Blind shot: Assuming that you don't do anything than simple commit, check if .gitconfig user.name and user.email match the GitHub username and email. Quote Link to comment
Luke Posted November 15, 2020 Share Posted November 15, 2020 On 11/10/2020 at 10:15 AM, AL|EN said: @Luke Blind shot: Assuming that you don't do anything than simple commit, check if .gitconfig user.name and user.email match the GitHub username and email. Yes, I had to reset them in Terminal, thanks. I'm not sure what I messed with, probably something related to "git-fetch" in VSCode... Separately, do you know how to remove commits (and their related content) from a repo (both local and remote)? I tried with "git reset --hard HEAD~5" but they keep reappearing as soon as I make a new commit... Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.