Re: [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit

[1234dev <1234dev@protonmail.com>]

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