From: "David Jeske" <jeske@willowmail.com>
To: "Robert Anderson" <rwa000@gmail.com>
Cc: "Git Mailing List" <git@vger.kernel.org>
Subject: Re: An alternate model for preparing partial commits
Date: Fri, 27 Jun 2008 20:29:15 -0000 [thread overview]
Message-ID: <willow-jeske-01l7Zen6FEDjCbjR> (raw)
In-Reply-To: <9af502e50806262350t6e794a92g7751147f1882965@mail.gmail.com>
Robert, I'm new to git, but I understand where you are going.
Why limit it only to working tree changes? For me, the stash machinery is of no
help here, because I commit super-often. What I end up with is 30 commits in a
topic branch, but where not every point passes 100% of tests. I want to go back
through and order them properly, and decide which points are sensible as
upstream committs. (especially as I read more about bisect).
git has all the concepts I want except one. However, it makes the process
pretty manual. Here is an idea about automating it. I'll talk about that one
new concept at the bottom.
I think of this as reorder/merge/split...
reorder: Picture that a list of commits on this branch opens in an editor. You
are free to rearrange the lines in any order you want, but you have to keep all
the lines. When you are done reordering the lines, the tool creates a new topic
branch and applies the changes (probably with cherrypick) to the new topic
branch. If there are no conflicts, you're done.
merge: Picture now that in your editor you can create groupings of those
individual commits that should make up separate topic-branches. The operation
can still be performed automatically, and at the end, it can compose those
topic branches into a single branch just like your original. At this point, you
can "isolate" any one of those topic branches and test/push that topic branch.
split: Picture now that you can list the same commit in more than one of the
topic-branches. This is a little more tricky, and there is no way to do it
automatically.. It drops you into an editor and asks you to select the lines of
the diff for the first topic. The remaining lines are put in the next topic.
This can continue for multiple topics.
This seems like something that could be assembled pretty easily on top of the
current git mechanisms, except for one thing.
If you use merge, the history will be a mess. If you use rebase, anyone else
who pulled your topic branch will be in a world of hurt.
I've been thinking about a solution for this I think of as "supercede".
Once you have completed the above reorder/merge/split, your new topic branch
should be EXACTLY the same as your old topic branch. (if it's not, it needs to
be trued up to be so). At that point, it is safe to ask for that new line of
commits to supercede the old line. Other people who have pulled in your older
ordered topic branch would then be able to pull/rebase/etc, and the merge
machinery would be able to back out their set of changes, and supercede them
with your new ordering.
This mechanism is intended to combine the benefits of rebase-clean-history and
the benefits of the dag-links for merging. I find it convenient to think of it
as stack push/pop for portions of the dag. Because of the supercede - the
history knows it can avoid showing you all the superceded dag nodes, however,
because those nodes are there, it can still use them to compute merges.
If this behaves the way I think, this has another powerful effect. You can pull
in a set of draft changes; you can build off them; you can periodically rebase
them, and if those draft changes end up in the mainline, because the
merge-history is still there, git can 'do the right thing' and remove those
changes from your topic branch. In fact, because of the SHA1 strong naming, it
doesn't even matter where you got them from. You could apply a patch from the
mailing list and as long as everyone applies that patch as only a single
commit, when the string of supercedes shows up on the main branch git will just
'do-the right thing' to remove them from your topic branch when you rebase (or
skip them during a merge down to your topic branch).
next prev parent reply other threads:[~2008-06-27 20:38 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <willow-jeske-01l7H4tHFEDjCgPV-01l7H4sOFEDjCbyi>
2008-06-27 6:50 ` An alternate model for preparing partial commits Robert Anderson
2008-06-27 7:10 ` Björn Steinbrink
2008-06-27 14:37 ` [PATCH/RFC] stash: introduce 'stash save --keep-index' option SZEDER Gábor
2008-06-27 18:26 ` Junio C Hamano
2008-06-27 16:54 ` An alternate model for preparing partial commits Robert Anderson
2008-06-27 17:27 ` Björn Steinbrink
2008-06-27 17:34 ` Robert Anderson
2008-06-27 8:35 ` Johannes Sixt
2008-06-27 17:01 ` Robert Anderson
2008-06-27 8:50 ` Petr Baudis
2008-06-27 17:02 ` Robert Anderson
2008-06-27 13:33 ` Johannes Schindelin
2008-06-27 13:49 ` Miklos Vajna
2008-06-27 17:14 ` Robert Anderson
2008-06-27 17:45 ` Johannes Schindelin
2008-06-27 17:49 ` Robert Anderson
[not found] ` <alpine.DEB.1.00.0806271854120.9925@racer>
2008-06-27 18:07 ` Robert Anderson
2008-06-27 18:20 ` Dana How
2008-06-27 20:31 ` Stephen Sinclair
2008-06-27 20:45 ` David Jeske
2008-06-28 17:23 ` Wincent Colaiuta
2008-06-27 20:45 ` David Jeske
2008-06-28 2:14 ` Dmitry Potapov
2008-06-28 2:57 ` Robert Anderson
2008-06-28 4:03 ` Dmitry Potapov
[not found] ` <9af502e50806272320p23f01e8eo4a67c5f6f4476098@mail.gmail.com>
2008-06-28 6:31 ` Fwd: " Robert Anderson
2008-06-28 12:38 ` Dmitry Potapov
[not found] ` <20080628123522.GL5737@dpotapov.dyndns.org>
2008-06-28 15:53 ` Robert Anderson
2008-06-28 16:52 ` Dmitry Potapov
2008-06-27 18:15 ` Junio C Hamano
2008-06-27 18:43 ` Robert Anderson
2008-06-28 5:03 ` Jeff King
2008-06-28 7:03 ` Robert Anderson
2008-06-28 8:53 ` Jeff King
2008-06-28 21:53 ` Junio C Hamano
2008-06-28 14:51 ` Johannes Schindelin
2008-07-08 4:58 ` Jeff King
2008-06-27 20:29 ` David Jeske [this message]
2008-06-27 20:29 ` David Jeske
2008-06-27 20:47 ` Jakub Narebski
2008-06-27 20:51 ` David Jeske
2008-06-27 20:51 ` David Jeske
[not found] ` <-8386235276716376372@unknownmsgid>
2008-06-27 22:55 ` Robert Anderson
2008-06-27 23:14 ` Junio C Hamano
2008-06-28 0:08 ` Robert Anderson
2008-06-28 2:57 ` Dmitry Potapov
2008-06-28 3:31 ` Robert Anderson
2008-06-28 14:34 ` Stephen Sinclair
2008-06-28 16:00 ` Robert Anderson
2008-06-28 16:30 ` Robert Anderson
2008-06-28 17:12 ` Jakub Narebski
2008-06-28 18:25 ` Robert Anderson
2008-06-28 19:12 ` David Jeske
2008-06-28 19:12 ` David Jeske
2008-06-28 19:13 ` Stephen Sinclair
2008-06-28 0:22 ` David Jeske
2008-06-28 0:22 ` David Jeske
2008-06-28 1:17 Theodore Tso
2008-06-28 1:56 ` Miklos Vajna
-- strict thread matches above, loose matches on Subject: below --
2008-06-28 1:23 Theodore Tso
2008-06-28 9:30 Stephen R. van den Berg
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=willow-jeske-01l7Zen6FEDjCbjR \
--to=jeske@willowmail.com \
--cc=git@vger.kernel.org \
--cc=rwa000@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox