From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Carl Baldwin <carl@ecbaldwin.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Bring together merge and rebase
Date: Sat, 23 Dec 2017 19:59:35 +0100 [thread overview]
Message-ID: <877etds220.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CALiLy7pBvyqA+NjTZHOK9t0AFGYbwqwRVD3sZjUg0ZLx5y1h3A@mail.gmail.com>
On Sat, Dec 23 2017, Carl Baldwin jotted:
> The big contention among git users is whether to rebase or to merge
> changes [2][3] while iterating. I used to firmly believe that merging
> was the way to go and rebase was harmful. More recently, I have worked
> in some environments where I saw rebase used very effectively while
> iterating on changes and I relaxed my stance a lot. Now, I'm on the
> fence. I appreciate the strengths and weaknesses of both approaches. I
> waffle between the two depending on the situation, the tools being
> used, and I guess, to some extent, my mood.
>
> I think what git needs is something brand new that brings the two
> together and has all of the advantages of both approaches. Let me
> explain what I've got in mind...
>
> I've been calling this proposal `git replay` or `git replace` but I'd
> like to hear other suggestions for what to name it. It works like
> rebase except with one very important difference. Instead of orphaning
> the original commit, it keeps a pointer to it in the commit just like
> a `parent` entry but calls it `replaces` instead to distinguish it
> from regular history. In the resulting commit history, following
> `parent` pointers shows exactly the same history as if the commit had
> been rebased. Meanwhile, the history of iterating on the change itself
> is available by following `replaces` pointers. The new commit replaces
> the old one but keeps it around to record how the change evolved.
>
> The git history now has two dimensions. The first shows a cleaned up
> history where fix ups and code review feedback have been rolled into
> the original changes and changes can possibly be ordered in a nice
> linear progression that is much easier to understand. The second
> drills into the history of a change. There is no loss and you don't
> change history in a way that will cause problems for others who have
> the older commits.
>
> Replay handles collaboration between multiple authors on a single
> change. This is difficult and prone to accidental loss when using
> rebase and it results in a complex history when done with merge. With
> replay, collaborators could merge while collaborating on a single
> change and a record of each one's contributions can be preserved.
> Attempting this level of collaboration caused me many headaches when I
> worked with the gerrit workflow (which in many ways, I like a lot).
>
> I blogged about this proposal earlier this year when I first thought
> of it [1]. I got busy and didn't think about it for a while. Now with
> a little time off of work, I've come back to revisit it. The blog
> entry has a few examples showing how it works and how the history will
> look in a few examples. Take a look.
>
> Various git commands will have to learn how to handle this kind of
> history. For example, things like fetch, push, gc, and others that
> move history around and clean out orphaned history should treat
> anything reachable through `replaces` pointers as precious. Log and
> related history commands may need new switches to traverse the history
> differently in different situations. Bisect is a interesting one. I
> tend to think that bisect should prefer the regular commit history but
> have the ability to drill into the change history if necessary.
>
> In my opinion, this proposal would bring together rebase and merge in
> a powerful way and could end the contention. Thanks for your
> consideration.
>
> Carl Baldwin
>
> [1] http://blog.episodicgenius.com/post/merge-or-rebase--neither/
> [2] https://git-scm.com/book/en/v2/Git-Branching-Rebasing
> [3] http://changelog.complete.org/archives/586-rebase-considered-harmful
I think this is a worthwhile thing to implement, there are certainly
use-cases where you'd like to have your cake & eat it too as it were,
i.e. have a nice rebased history in "git log", but also have the "raw"
history for all the reasons the fossil people like to talk about, or for
some compliance reasons.
But I don't see why you think this needs a new "replaces" parent pointer
orthagonal to parent pointers, i.e. something that would need to be a
new field in the commit object (I may have misread the proposal, it's
not heavy on technical details).
Consider a merge use case like this:
A---B---C topic
/ \
D---E---F---G---H master
Here we worked on a topic with commits A,B & C, maybe we regret not
squashing B into A, but it gives us the "raw" history. Instead we might
rebase it like this:
A+B---C topic
/
G---H master
Now we can push "topic" to master, but as you've noted this loses the
raw history, but now consider doing this instead:
A---B---C A2+B2---C2 topic
/ \ /
D---E---F---G---G master
I.e. you could have started working on commit A/B/C, now you "git
replace" them (which would be some fancy rebase alias), and what it'll
do is create a merge commit that entirely resolves the conflict so that
hte tree is equivalent to what "master" was already at. Then you rewrite
them and re-apply them on top.
If you run "git log" it will already ignore A,B,C unless you specify
--full-history, so git already knows to ignore these sort of side
histories that result in no changes on the branch they got merged
into. I don't know about bisect, but if it's not doing something similar
already it would be easy to make it do so.
You could even add a new field to the commit object of A2+B2 & C2 which
would be one or more of "replaces <sha1 of A/B/C>", commit objects
support adding arbitrary new fields without anything breaking.
But most importantly, while I think this gives you the same things from
a UX level, it doesn't need any changes to fetch, push, gc or whatever,
since it's all stuff we support today, someone just needs to hack
"rebase" to create this sort of no-op merge commit to take advantage of
it.
next prev parent reply other threads:[~2017-12-23 18:59 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-23 6:10 Bring together merge and rebase Carl Baldwin
2017-12-23 18:59 ` Ævar Arnfjörð Bjarmason [this message]
2017-12-23 21:01 ` Carl Baldwin
2017-12-23 22:09 ` Ævar Arnfjörð Bjarmason
2017-12-26 0:16 ` Carl Baldwin
2017-12-26 1:28 ` Jacob Keller
2017-12-26 23:30 ` Igor Djordjevic
2017-12-26 17:49 ` Ævar Arnfjörð Bjarmason
2017-12-26 19:44 ` Carl Baldwin
2017-12-26 20:19 ` Paul Smith
2017-12-26 21:07 ` Carl Baldwin
2017-12-23 22:19 ` Randall S. Becker
2017-12-25 20:05 ` Carl Baldwin
2017-12-23 23:01 ` Johannes Schindelin
2017-12-24 14:13 ` Alexei Lozovsky
2018-01-04 15:44 ` Johannes Schindelin
2017-12-25 23:43 ` Carl Baldwin
2017-12-26 0:01 ` Randall S. Becker
2018-01-04 19:49 ` Martin Fick
2017-12-23 22:30 ` Johannes Schindelin
2017-12-25 3:52 ` Theodore Ts'o
2017-12-26 1:16 ` Carl Baldwin
2017-12-26 1:47 ` Jacob Keller
2017-12-26 6:02 ` Carl Baldwin
2017-12-26 8:40 ` Jacob Keller
2018-01-04 19:19 ` Martin Fick
2018-01-05 0:31 ` Martin Fick
2018-01-05 5:09 ` Carl Baldwin
2018-01-05 5:20 ` Carl Baldwin
2017-12-26 18:04 ` Theodore Ts'o
2017-12-26 20:31 ` Carl Baldwin
2018-01-04 20:06 ` Martin Fick
2018-01-05 5:06 ` Carl Baldwin
2018-01-04 19:54 ` Martin Fick
2018-01-05 4:08 ` Carl Baldwin
2018-01-05 20:14 ` Junio C Hamano
2018-01-06 17:29 ` Carl Baldwin
2018-01-06 17:32 ` Carl Baldwin
2018-01-06 21:38 ` Theodore Ts'o
2017-12-27 4:35 ` Carl Baldwin
2017-12-27 13:35 ` Alexei Lozovsky
2017-12-28 5:23 ` Carl Baldwin
2017-12-26 4:08 ` Mike Hommey
2017-12-27 2:44 ` Carl Baldwin
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=877etds220.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=carl@ecbaldwin.net \
--cc=git@vger.kernel.org \
/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).