Junio C Hamano wrote: >> 2. revising published commits / re-basing >> >> This is what "stg" et al do. The tools allow you to commit, >> rewind, revise, recommit, fast forward, etc. >> >> > >stg wants to have a link to the fork-point commit. I do not >know if it is absolutely necessary (you might be able to figure >it out using merge-base, I dunno). > > "stg pull" and "stg pick" could conceivably link individual patches in a patchset to their precedent in a previous series. This would make looking at the evolution of individual patches over time more feasible. >> In this case, the "prior" link would point to the last revision of >> a patch. Tools would probably >> >> > >Probably what...??? > > ...probably support this as an explicit operation - ie "publish", so that winding whilst developing is not tracked. >> 3. sub-projects >> >> In this case, the commit on the "main" commit line would have a >> "prior" link to the commit on the sub-project. The sub-project >> would effectively be its own head with copied commits objects on >> the main head. >> >> > >You say you can have only one "prior" per commit, which makes >this unsuitable to bind multiple subprojects into a larger >project (the earlier "bind" proposal allows zero or more). > > It would still support that. Each commit to the sub-project involves a change to the tree of the "main" commit line (a copy of the commit into a sub-directory of it). The advantage is that the "tree" in the main commit is the combined tree, you don't need to treat the case specially to just get the contents out. This is kind of like how SVK works by default - you have one local repository, inside which you track remote repositories. Each commit on the upstream repository is copied individually into your own repository. So your local repository numbers easily reach into tens of thousands (small numbers in git land, I know) while the upstream revisions are just in the thousands. >There may be some narrower concrete use case for which you can >devise coherent semantics, and teach tools and humans how to >interpret such inter-commit relationship that are _not_ >parent-child ancestry. For example, if you have one special >link to point at a "cherry-picked" commit, rebasing _could_ take >advantage of it. When your side branch tip is at D, and commit >D has "this was cherry-picked from commit E" note, and if you >are rebasing your work on top of F: > > A---B---C---D > / > o---o---E---F > >the tool can notice that F can reach E and carry forward only A, >B, and C on top of F, omitting D. So having such a link might >be useful. But if that is what you are going to do, I do not >think you would want to conflate that with other inter-commit >relationships, such as "previous hydra cap". > > Right, I see the problem, a strong argument for a more generic solution as you presented. Sam. - : 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