From: Patrick Steinhardt <ps@pks.im>
To: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
Cc: "R. Diez" <rdiez-2006@rd10.de>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: Graphical tool to merge and reorder commits
Date: Tue, 19 Aug 2025 13:05:45 +0200 [thread overview]
Message-ID: <aKRaiaym7KsJ2Ojg@pks.im> (raw)
In-Reply-To: <260a97ce-2ab0-4920-9cea-078369c42f74@petrovitsch.priv.at>
On Tue, Aug 19, 2025 at 11:51:42AM +0200, Bernd Petrovitsch wrote:
> On 19.08.25 10:35, R. Diez wrote:
> [...]
> > I guess some "git history squash" command would be useful too.
> >
> > This is what frequently happens to me:
> > - I commit some code changes because the current project builds and tests fine.
> > - I start the "compile all projects" process, which takes about 1 hour.
> > - In the meantime, I commit other unrelated changes.
> > - After an hour, I realise that a silly mistake in the first commit makes compilation fail for some project.
> > I fix that and I trigger a "compile all projects" again, which takes 1 hour again.
> > - In the meantime, I commit yet another unrelated change.
> > - After yet another hour, the build process notifies me that I made yet another little mistake, and yet another project fails now.
> >
> > The commit history looks like this:
> >
> > - A - B - fixA1 - C - fixA2 - D - E
> >
> > I only do a "git push" when the 1-hour compilation process succeeds. Before the "git push", I want to reorganise that into:
> >
> > - A+fixA1+fixA2 - B - C - D - E
> >
> > I know I can work with branches, but branches make everything more complicated. A linear history is easier, especially when you are working alone. Besides, it is not often that I make such silly mistakes. ;-)
>
> - `git rebase -i HEAD~11` (or so;-)
> - move fixA1 and fixA2 under A and change "pick" to "fixup" for fixA1 and fixA2
> - save and exit the editor
>
> And done.
It's not really that this isn't doable. It's just not all that obvious
for people who aren't experts, and it's not a straight-forward thing to
do. I think the Git project could certainly use better tooling to make
common workflows obvious and easy.
Anyway, the patch series is out now and can be found at [1].
Patrick
[1]: https://lore.kernel.org/git/20250819-b4-pks-history-builtin-v1-0-9b77c32688fe@pks.im/T/#t
next prev parent reply other threads:[~2025-08-19 11:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-17 21:02 Graphical tool to merge and reorder commits R. Diez
2025-08-18 18:04 ` Konstantin Khomoutov
2025-08-18 18:34 ` Junio C Hamano
2025-08-19 8:07 ` Patrick Steinhardt
2025-08-19 8:35 ` R. Diez
2025-08-19 9:51 ` Bernd Petrovitsch
2025-08-19 11:05 ` Patrick Steinhardt [this message]
2025-08-19 11:14 ` R. Diez
2025-08-19 12:08 ` Ben Knoble
2025-08-19 16:33 ` Junio C Hamano
2025-08-19 19:09 ` Johannes Sixt
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKRaiaym7KsJ2Ojg@pks.im \
--to=ps@pks.im \
--cc=bernd@petrovitsch.priv.at \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rdiez-2006@rd10.de \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.