Advantage to rebasing a file?
-
I have a file that I have already pushed. I now wish to revert the file to the previous version. The way I would prefer to do it is to simply copy and paste the code of the previous version over my file in eclipse, save, commit and push that, which leads to Gerrit. However, I think that the proper way is to do a rebase of the file or something. Git has punished me so many times for wrongs lost in the mists of time that I would prefer to avoid that, unless there is a good reason for it.
As far as my overlords looking at my reviews in Gerrit, would you think there would any reason that they would even notice that I simply committed and pushed the old version rather than doing a rebase?
-
@jinpa said in Advantage to rebasing a file?:
However, I think that the proper way is to do a rebase of the file or something.
Rebases are an alternative to merges, not a way to rewind history.
It sounds to me like you're either trying to reset to a particular state, or maybe create a new branch starting at a particular state.
-
@jinpa What workflow are you using? Are these commits on a shared branch or on their own and are being merged into the feature branch? If the latter, are you the only person to have pulled code from this branch?
@dkf is somewhat correct. Normally you use rebase to change the base of the branch to a new commit, however an interactive rebase can be used to rewrite history and is what I assume you meant.
In that case, as long as you're the only person who has those commits, then it is safe to do an interactive rebase, edit the commit you want to revert the change in, finish the rebase, and then force push to the remote branch to update it. I work in a forking workflow, so changes are merged from my fork into the shared repo, so this is generally always safe for me to do. Most places are using shared feature branches where it's less safe.
@jinpa said in Advantage to rebasing a file?:
As far as my overlords looking at my reviews in Gerrit, would you think there would any reason that they would even notice that I simply committed and pushed the old version rather than doing a rebase?
I haven't used Gerrit, but BitBucket/Stash explicitly states that you've removed commits a/b/c and added commits x/y/z to the PR when you do the push, as well as unapproving the PR if it had any approvals. You can still access those commits through the hash in the automated comment. I'd assume Gerrit is similar.
-
@JazzyJosh said in Advantage to rebasing a file?:
@jinpa What workflow are you using? Are these commits on a shared branch or on their own and are being merged into the feature branch? If the latter, are you the only person to have pulled code from this branch?
Locally, I created a branch for the ticket. But it is pushed to a version branch, which will later be merged to the shared branch. I'm the only one to have pulled code for this ticket. But others could have pulled code for other tickets. Almost certainly not for this file, though.
@dkf is somewhat correct. Normally you use rebase to change the base of the branch to a new commit, however an interactive rebase can be used to rewrite history and is what I assume you meant.
In that case, as long as you're the only person who has those commits, then it is safe to do an interactive rebase, edit the commit you want to revert the change in, finish the rebase, and then force push to the remote branch to update it. I work in a forking workflow, so changes are merged from my fork into the shared repo, so this is generally always safe for me to do. Most places are using shared feature branches where it's less safe.
-
@jinpa Reverting the changes and creating a new commit on top without any history rewriting? Should show you as the author of the change. Only lines that should show as changed in that specific commit are the lines that were reverted. The change should just disappear from the PR as a change, as there's no difference in those lines when you run a diff.
-
@jinpa It sounds like you want a revert. This is effectively the same as overwriting the new version with the old one and pushing it, complete with a new commit with text explaining the reason for reverting.
Undoing public changes
When working on a team with remote repositories, extra consideration needs to be made when undoing changes. Git reset should generally be considered a 'local' undo method. A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits.The preferred method of undoing shared history is git revert. A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.
Edit: Wouldn't you know, as soon as I post this, I have to figure out how to undo a commit to the wrong branch (but not pushed, so I can use reset).
There's a reason the "undoing changes" tutorial is my number 1 git bookmark.
-
@HardwareGeek said in Advantage to rebasing a file?
There's a reason the "undoing changes" tutorial is my number 1 git bookmark.Care to share it?
-
@jinpa Share what? The tutorial? It's the link in the previous post. The reason it's my favorite tutorial? That's left as an exercise for the reader.
-
@jinpa said in Advantage to rebasing a file?:
Gerrit
Having done a bit more research, if you're using Gerrit and others haven't pulled that specific version of the file (ask around to find that out), just pushing the file contents that you want to be there as a new version of the file should be OK. It's only potentially a problem if you're trying to remove the file version because it contains problem content (e.g., unencrypted credentials!).
Gerrit is very much not how I use git…
-
@HardwareGeek said in Advantage to rebasing a file?:
@jinpa It sounds like you want a revert. This is effectively the same as overwriting the new version with the old one and pushing it, complete with a new commit with text explaining the reason for reverting.
Undoing public changes
When working on a team with remote repositories, extra consideration needs to be made when undoing changes. Git reset should generally be considered a 'local' undo method. A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits.The preferred method of undoing shared history is git revert. A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.
Edit: Wouldn't you know, as soon as I post this, I have to figure out how to undo a commit to the wrong branch (but not pushed, so I can use reset).
There's a reason the "undoing changes" tutorial is my number 1 git bookmark.I like this one:
It's sort of an inverse Choose-Your-Own-Adventure where you make choices that detail how you fucked up and wind up with a usually good ending.
-
-
@HardwareGeek The good ending is convincing your team to switch to a decent VC system
-
@HardwareGeek said in Advantage to rebasing a file?:
@MZH said in Advantage to rebasing a file?:
git ... good ending
How is that possible?
Live happily ever after... you and the repo you maintain.
-
-
@Gąska said in Advantage to rebasing a file?:
Is there such a thing?
TFVC. (Alas, Microsoft drank the Git Kool-aid; I expect them to remove support in their next TFs release - whatever the next one after 2019 is - like they killed XAML builds in 2018.)
-
@Unperverted-Vixen said in Advantage to rebasing a file?:
like they killed XAML builds in 2018
Wait, what? Is WPF impossible to compile now?
-
@Gąska No, it's an older way of specifying a build process (which has nothing to do with WPF in this case).
Do note that they're apparently keeping it alive for the people who still use it.
-
@JBert XAML builds were removed in the RTM version of TFS 2018. They were eventually restored six months later in
Service PackUpdate 2.(Which is unfortunate, because that was the main cudgel I had to get users to upgrade to "visual designer" builds.)
Admittedly, TFVC has not been officially deprecated yet like XAML builds were. But they're making new features like YAML build scripts Git-only. Seems like the writing is on the wall.
-
-
@pie_flavor CodeBuild, you'll hate it.
Undoing Changes in Git | Atlassian Git Tutorial
