From: Sam Vilain <sam@vilain.net>
To: Git Mailing List <git@vger.kernel.org>
Subject: n-heads and patch dependency chains
Date: Mon, 03 Apr 2006 19:48:34 +1200 [thread overview]
Message-ID: <4430D352.4010707@vilain.net> (raw)
Hi all,
"Patch dependency chains", the best plain-English term we could find for
the scary sounding darcs term "patch calculus", are said by some to be a
very good reason to use a system like darcs, even to some its
fundamental advantage over systems such as git.
The question is, to what extent is this point true?
To get a feel for the issues involved, I tried applying an example
n-head and patch dependency logic to a "real" project that had a small
enough number of commits to make it feasible to construct everything
manually.
A side-by-side comparison of the commit history with n-head commits
(left pane) and without (right pane) is here:
http://utsl.gen.nz/git/hydra-vs-regular.png
Some important points to note:
0. gitk is re-ordering the commits to try to make the graph tidy,
so don't worry that the commits are in a different order
1. commits were considered dependent on the last commit(s) that
delivered the file(s) they modified. As in, the user specified
that extra heads be created wherever possible, including
splitting heads.
2. the "rolling" n-head was continually discarded. "n-head" is
misspelt :) as "hydra-head" in the diagrams.
3. patches that just added new files were performed by first
making a new repository, adding those files and committing.
this is why there are a lot of "starting points" on the tree
I think we can conclude from this:
- this is not impossible using the current model, and some extra
useful information can be seen in the tree that shows more real
dependency information and relationships between individual commits
- doing automatic n-head creation would probably be madness, as
far too many useless heads are created (though it is almost
guaranteed that supporting 'patch commuting' a la darcs would
make this *even worse* as it would mean that you could potentially
have even more heads)
- the current tools make this style of development difficult.
The bugs:
- git-merge-octopus isn't capable of merging commits where there is
no common commit, but none was needed as the commits' trees don't
overlap.
That is, with "git-pull -s octopus . head1 head2 head3 ..."
you get the error:
Unable to find common commit with 42f49cc...
But pulling the branches individually works fine;
Merging HEAD with 42f49cc...
Merging:
c0805...
42f49...
found 1 common ancestor(s):
1 virtual commit
That 'branch' was created by setting up a new git repo in another
path, then using 'git-fetch' to pull it into the local one.
- for some reason I had to list "-s ours" twice to git-pull when
manually making the octopus merge nodes
- `git-pull --no-commit -a' suffers from the same problem
- some tools (such as the diff window in gitk) produce *very*
strange output if you try to merge the heads and apply the next
patch in the same go.
The open questions:
- would it make a difference if this automatic patch dependency
information was stored using a different type of relationship?
- would this be more useful if the initial n-head creation was more
manual, like topic branches? And if it did work like this, would
an n-head pull feature enable the 'pu' development model to work
seamlessly?
- how useful are the other benefits of dependent commits?
The IRC log:
17:45 < mugwump> the other suggestions look quite good. I don't know
how I got roped into spending a whole day on this :)
17:46 < mugwump> oh yeah, I remember now. somebody asked for a
comparison between darcs and git
17:46 * ShadeHawk whistles innocently
So there we go, anyway. If some form of patch dependency system is to
be included in git, then I hope this message helps to explain the
practical problems and give the would-be author a good head start :)
Hot potato into the aether, anyone?
Sam.
next reply other threads:[~2006-04-03 7:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-03 7:48 Sam Vilain [this message]
2006-04-03 14:29 ` n-heads and patch dependency chains Linus Torvalds
2006-04-03 15:38 ` Sam Vilain
2006-04-03 19:37 ` Junio C Hamano
2006-04-03 23:55 ` Sam Vilain
2006-04-04 9:28 ` Andreas Ericsson
2006-04-04 9:51 ` Junio C Hamano
2006-04-04 10:44 ` Andreas Ericsson
2006-04-04 11:03 ` Jakub Narebski
2006-04-04 11:47 ` Andreas Ericsson
2006-04-20 18:08 ` Jon Loeliger
2006-04-20 18:55 ` Junio C Hamano
2006-04-21 8:50 ` Andreas Ericsson
2006-04-04 19:00 ` Junio C Hamano
2006-04-04 20:18 ` Jakub Narebski
2006-04-05 6:34 ` Sam Vilain
2006-04-05 7:11 ` Jakub Narebski
2006-04-05 7:31 ` Sam Vilain
2006-04-05 7:59 ` Jakub Narebski
2006-04-04 0:51 ` Jakub Narebski
2006-04-04 11:05 ` Catalin Marinas
-- strict thread matches above, loose matches on Subject: below --
2006-04-03 22:13 linux
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=4430D352.4010707@vilain.net \
--to=sam@vilain.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).