The itch this idea is supposed to scratch is the problem that a rebase
or a amended commit is no longer a fast-forward, so cannot be easily
pulled.
While this is not a problem in most workflows, as one can either merge
or keep everything private and rebase until published, it would be nice
to have a way for cases in between, where both a clean presentable
commit order is to be maintained and people (or yourself from different
repositories) should be able to easily upgrade to newer versions without
an error-prone not-fast-forward.
My idea to solve this is combining both histories, the rebased/revised
history and the actualy history, marking with some "equal-tree-merge"
the point where they have the same result.
The following mails show some patches to implement this by means of
a merge where all parents have the same tree and some special casing
when encountering such a thing. This has the advantage that older git
version will just see strange merges and may present both histories,
but otherwise just work.
Example 1:
Let's assume you maintain such a regularily-rebased branch that you
want to be able to publish (or pull from other repositories for example
on your laptop):
o=m=o=o=master
\
a=b=c=d=e=feature
with this patch you can do "git rebase -eqt master" and get:
a'=b'=c'=d'=e'=feature'=eqt
/ /
o=m=o=o=master-------- /
\ \ /
a=b=c=d=e=feature--merge-------
i.e: the new feature branch has both histories:
- "feature'" where everything is cleanly rebased and in a form where
format-patch is suitable to send it upstream
- "merge" which is both a descendant from feature (so one can see what
changed since that time and can just pull when one had had cloned feature)
Example 2:
Let's assume you have a feature branch like
o=master
\
a=b=c=d=e=f
Assume you just commited "f" which fixes a bug introduced by "b".
Now you of course do not want to send it that way upstream (as it will
make reviewing harder, may force people bisecting to skip some versions
every time they hit this region and so on), so you want to
bisect -i and squash "f" into "b".
o=master
\
a=b+f=c'=d'=e'
But if you had already cloned at state "d" to your laptop (or made a backup
of that branch at some server, or published it for use of some collegues)
it will not be a fast-forward, so you have to be very carefull to not
accidentially lose a commit that is already there.
So with this patches you can do "git rebase -i --eqt" and squash f into b
and get:
o=master
\
a=b=c=d=e=f---
\ \
b+f=c'=d'=e'=eqt
which means that you can just pull from your laptop and get the new head
as fast-forward, but still have a proper history ready for submitting.
The only downsize of this approach is that an unpatched/old git of course
does not know about that it can just choose one of both histories but think
it has to look at both, so git-format-patch will return patches multiple times
and git-rebase will also try to apply both branches, which the patched version
no longer does, only showing the 'presentable' in this case.
Those patches are a bit rough and mostly intended to show how it could work
and to allow experimenting with it. I think the biggest thing still missing
(apart from documentation, error handling, better commit messages) is making
git bisect take advantage of this and only looking at the nice branch.
Bernhard R. Link (7):
add new command git equal-tree-marker
add option to only visit the first parent of a equal tree merge
format-patch defaults to --first-equal-tree-only
support equal tree merges in interactive rebase
make rebase -m equal tree marker aware
add support for creating equal tree markers after rebase
add support for creating equal tree markers to rebase -i
.gitignore | 1 +
Makefile | 1 +
builtin-log.c | 1 +
git-equal-tree-marker.sh | 50 ++++++++++++++++++++++++++++++++++++++
git-rebase--interactive.sh | 33 +++++++++++++++++++++++++
git-rebase.sh | 35 ++++++++++++++++++++++++--
revision.c | 57 +++++++++++++++++++++++++++++++++++++-------
revision.h | 1 +
8 files changed, 167 insertions(+), 12 deletions(-)
create mode 100644 git-equal-tree-marker.sh
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html