git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	1234dev <1234dev@protonmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [Feature request] An easier way of rebasing if you just want to "force send" a file back to a previous commit
Date: Sun, 12 Jan 2020 12:45:11 -0800	[thread overview]
Message-ID: <20200112204511.GA4400@syl.local> (raw)
In-Reply-To: <20200112195646.GQ6570@camp.crustytoothpaste.net>

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

  parent reply	other threads:[~2020-01-12 20:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2020-01-13 14:13     ` 1234dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200112204511.GA4400@syl.local \
    --to=me@ttaylorr.com \
    --cc=1234dev@protonmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).