* [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit @ 2020-01-12 19:42 1234dev 2020-01-12 19:56 ` brian m. carlson 0 siblings, 1 reply; 5+ messages in thread From: 1234dev @ 2020-01-12 19:42 UTC (permalink / raw) To: git@vger.kernel.org Hello! I'm pretty new to all of this, but I was wondering. Is there an easier way of rebasing if you just want to force send a file back to a previous commit? Rebasing can get quite tiresome in the long run. It's like 7 steps, and that's without the merge conflicts someone with my luck is guaranteed to run into. For instance, say I've made changes to a file. Those changes are too tiny and insignificant to make a new commit out of - they actually ought to be part of a commit I made last night. If there just was a way to cheat :) I'm aware it would rewrite my entire history but that's okay, I haven't shared my repo with anybody yet. Maybe something along the lines of "git rebase --off-she-goes <file> <hash>"? As opposed to "git stash && git rebase --interactive '<hash>^' && <change pick => edit> && <apply changes manually> && git add <file> && git commit --amend && git rebase --continue && git stash pop && <merge conflict that requires manual intervention> && git rebase --continue && git stash pop && <still a conflict> && rm <file> && git checkout <file> && <repeat the whole process> && <still a conflict> && <go to IRC and ask for help> Might have gotten the above sequence of commands a bit wrong, I just learned how to rebase a few days ago. But hopefully y'all get my point. Thanks! Sent with ProtonMail Secure Email. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit 2020-01-12 19:42 [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit 1234dev @ 2020-01-12 19:56 ` brian m. carlson 2020-01-12 20:41 ` 1234dev 2020-01-12 20:45 ` Taylor Blau 0 siblings, 2 replies; 5+ messages in thread From: brian m. carlson @ 2020-01-12 19:56 UTC (permalink / raw) To: 1234dev; +Cc: git@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 1960 bytes --] On 2020-01-12 at 19:42:46, 1234dev wrote: > Hello! > > I'm pretty new to all of this, but I was wondering. Is there an easier way of rebasing if you just want to force send a file back to a previous commit? Rebasing can get quite tiresome in the long run. It's like 7 steps, and that's without the merge conflicts someone with my luck is guaranteed to run into. > > For instance, say I've made changes to a file. Those changes are too tiny and insignificant to make a new commit out of - they actually ought to be part of a commit I made last night. > > If there just was a way to cheat :) I'm aware it would rewrite my entire history but that's okay, I haven't shared my repo with anybody yet. Maybe something along the lines of "git rebase --off-she-goes <file> <hash>"? > > As opposed to "git stash && git rebase --interactive '<hash>^' && <change pick => edit> && <apply changes manually> && git add <file> && git commit --amend && git rebase --continue && git stash pop && <merge conflict that requires manual intervention> && git rebase --continue && git stash pop && <still a conflict> && rm <file> && git checkout <file> && <repeat the whole process> && <still a conflict> && <go to IRC and ask for help> The way I usually handle this is something like the following, although I have some helper aliases that wrap this: git add <file> git commit --fixup <hash> git stash # if necessary GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash That does use the interactive machinery to apply the fixup commit, but it also avoids prompting you to edit the interactive TODO list. It doesn't avoid the merge conflicts which can occur, but it is (IMO) the easiest way to go about it. If I'd like to edit the message, I use "git commit --squash" to add the comments I'd like to add and I'm only prompted to squash together those messages. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 868 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit 2020-01-12 19:56 ` brian m. carlson @ 2020-01-12 20:41 ` 1234dev 2020-01-12 20:45 ` Taylor Blau 1 sibling, 0 replies; 5+ messages in thread From: 1234dev @ 2020-01-12 20:41 UTC (permalink / raw) To: brian m. carlson, git@vger.kernel.org Very cool :-) Thank you so much for making my life easier! Have a good day :-) Best regards, Jonathan Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 12, 2020 7:56 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote: > On 2020-01-12 at 19:42:46, 1234dev wrote: > > > Hello! > > I'm pretty new to all of this, but I was wondering. Is there an easier way of rebasing if you just want to force send a file back to a previous commit? Rebasing can get quite tiresome in the long run. It's like 7 steps, and that's without the merge conflicts someone with my luck is guaranteed to run into. > > For instance, say I've made changes to a file. Those changes are too tiny and insignificant to make a new commit out of - they actually ought to be part of a commit I made last night. > > If there just was a way to cheat :) I'm aware it would rewrite my entire history but that's okay, I haven't shared my repo with anybody yet. Maybe something along the lines of "git rebase --off-she-goes <file> <hash>"? > > As opposed to "git stash && git rebase --interactive '<hash>^' && <change pick => edit> && <apply changes manually> && git add <file> && git commit --amend && git rebase --continue && git stash pop && <merge conflict that requires manual intervention> && git rebase --continue && git stash pop && <still a conflict> && rm <file> && git checkout <file> && <repeat the whole process> && <still a conflict> && <go to IRC and ask for help> > > The way I usually handle this is something like the following, although > I have some helper aliases that wrap this: > > git add <file> > git commit --fixup <hash> > > git stash # if necessary > GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash > > That does use the interactive machinery to apply the fixup commit, but > it also avoids prompting you to edit the interactive TODO list. It > doesn't avoid the merge conflicts which can occur, but it is (IMO) the > easiest way to go about it. > > If I'd like to edit the message, I use "git commit --squash" to add the > comments I'd like to add and I'm only prompted to squash together those > messages. > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > brian m. carlson: Houston, Texas, US > OpenPGP: https://keybase.io/bk2204 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit 2020-01-12 19:56 ` brian m. carlson 2020-01-12 20:41 ` 1234dev @ 2020-01-12 20:45 ` Taylor Blau 2020-01-13 14:13 ` 1234dev 1 sibling, 1 reply; 5+ messages in thread From: Taylor Blau @ 2020-01-12 20:45 UTC (permalink / raw) To: brian m. carlson, 1234dev, git@vger.kernel.org On Sun, Jan 12, 2020 at 07:56:46PM +0000, brian m. carlson wrote: > On 2020-01-12 at 19:42:46, 1234dev wrote: > > Hello! > > > > I'm pretty new to all of this, but I was wondering. Is there an easier way of rebasing if you just want to force send a file back to a previous commit? Rebasing can get quite tiresome in the long run. It's like 7 steps, and that's without the merge conflicts someone with my luck is guaranteed to run into. > > > > For instance, say I've made changes to a file. Those changes are too tiny and insignificant to make a new commit out of - they actually ought to be part of a commit I made last night. > > > > If there just was a way to cheat :) I'm aware it would rewrite my entire history but that's okay, I haven't shared my repo with anybody yet. Maybe something along the lines of "git rebase --off-she-goes <file> <hash>"? > > > > As opposed to "git stash && git rebase --interactive '<hash>^' && <change pick => edit> && <apply changes manually> && git add <file> && git commit --amend && git rebase --continue && git stash pop && <merge conflict that requires manual intervention> && git rebase --continue && git stash pop && <still a conflict> && rm <file> && git checkout <file> && <repeat the whole process> && <still a conflict> && <go to IRC and ask for help> > > The way I usually handle this is something like the following, although > I have some helper aliases that wrap this: > > git add <file> > git commit --fixup <hash> > git stash # if necessary > GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash > > That does use the interactive machinery to apply the fixup commit, but > it also avoids prompting you to edit the interactive TODO list. It > doesn't avoid the merge conflicts which can occur, but it is (IMO) the > easiest way to go about it. I couldn't quite tell one way or the other, but I think that the original poster was asking about the case in which one wants to move some hunks out of one commit and into an earlier one. I usually go about this with something like: h="$(git rev-parse HEAD)" git reset HEAD^ git add <file[s]> # re-stage the files that you want to move "up" git commit --fixup <hash> git add --all . git commit -C "$h" # "re-apply" the commit that you were moving out of GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash > If I'd like to edit the message, I use "git commit --squash" to add the > comments I'd like to add and I'm only prompted to squash together those > messages. My preference is usually to allow 'git rebase -i' to open my "$EDITOR" and change the todo list to "reword" for any commit(s) for which I want to change the message. > -- > brian m. carlson: Houston, Texas, US > OpenPGP: https://keybase.io/bk2204 Thanks, Taylor ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit 2020-01-12 20:45 ` Taylor Blau @ 2020-01-13 14:13 ` 1234dev 0 siblings, 0 replies; 5+ messages in thread From: 1234dev @ 2020-01-13 14:13 UTC (permalink / raw) To: git@vger.kernel.org Hi, On Sunday, January 12, 2020 8:45 PM, Taylor Blau <me@ttaylorr.com> wrote: > > I couldn't quite tell one way or the other, but I think that the > original poster was asking about the case in which one wants to move > some hunks out of one commit and into an earlier one. > > I usually go about this with something like: > > h="$(git rev-parse HEAD)" > git reset HEAD^ > git add <file[s]> # re-stage the files that you want to move "up" > git commit --fixup <hash> > git add --all . > git commit -C "$h" # "re-apply" the commit that you were moving out of > GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash I was just looking for a simpler way to either move the entire file back to a certain commit, other than the standard way of rebasing. Your suggestion looks even more complicated than the method I currently use which kinda defeats the purpose. I appreciate the help though! All the best, Jonathan Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 12, 2020 8:45 PM, Taylor Blau <me@ttaylorr.com> wrote: > On Sun, Jan 12, 2020 at 07:56:46PM +0000, brian m. carlson wrote: > > > On 2020-01-12 at 19:42:46, 1234dev wrote: > > > > > Hello! > > > I'm pretty new to all of this, but I was wondering. Is there an easier way of rebasing if you just want to force send a file back to a previous commit? Rebasing can get quite tiresome in the long run. It's like 7 steps, and that's without the merge conflicts someone with my luck is guaranteed to run into. > > > For instance, say I've made changes to a file. Those changes are too tiny and insignificant to make a new commit out of - they actually ought to be part of a commit I made last night. > > > If there just was a way to cheat :) I'm aware it would rewrite my entire history but that's okay, I haven't shared my repo with anybody yet. Maybe something along the lines of "git rebase --off-she-goes <file> <hash>"? > > > As opposed to "git stash && git rebase --interactive '<hash>^' && <change pick => edit> && <apply changes manually> && git add <file> && git commit --amend && git rebase --continue && git stash pop && <merge conflict that requires manual intervention> && git rebase --continue && git stash pop && <still a conflict> && rm <file> && git checkout <file> && <repeat the whole process> && <still a conflict> && <go to IRC and ask for help> > > > > The way I usually handle this is something like the following, although > > I have some helper aliases that wrap this: > > git add <file> > > git commit --fixup <hash> > > git stash # if necessary > > GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash > > That does use the interactive machinery to apply the fixup commit, but > > it also avoids prompting you to edit the interactive TODO list. It > > doesn't avoid the merge conflicts which can occur, but it is (IMO) the > > easiest way to go about it. > > I couldn't quite tell one way or the other, but I think that the > original poster was asking about the case in which one wants to move > some hunks out of one commit and into an earlier one. > > I usually go about this with something like: > > h="$(git rev-parse HEAD)" > git reset HEAD^ > git add <file[s]> # re-stage the files that you want to move "up" > git commit --fixup <hash> > git add --all . > git commit -C "$h" # "re-apply" the commit that you were moving out of > GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash > > > If I'd like to edit the message, I use "git commit --squash" to add the > > comments I'd like to add and I'm only prompted to squash together those > > messages. > > My preference is usually to allow 'git rebase -i' to open my "$EDITOR" > and change the todo list to "reword" for any commit(s) for which I want > to change the message. > > > -- > > brian m. carlson: Houston, Texas, US > > OpenPGP: https://keybase.io/bk2204 > > Thanks, > Taylor ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-01-13 14:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-12 19:42 [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit 1234dev 2020-01-12 19:56 ` brian m. carlson 2020-01-12 20:41 ` 1234dev 2020-01-12 20:45 ` Taylor Blau 2020-01-13 14:13 ` 1234dev
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).