Dear list,
We are trying to approach a functionality I call "branch dependencies". Essentially, the idea is rooted in distro development, but probably applies to normal development too.
For instance, you might have a feature branch off upstream. Once upstream advances, you should merge upstream into your feature branch (or rebase your feature branch) to ensure that you are working on the right assumptions.
Another case might be a feature you want to write, which depends on two (or more) feature branches of other people, e.g. say you need a new configuration option introduced in feature branch "conf-option", and you also base your work on the "speedup" branch, because otherwise the software is too slow for your new feature. If one or both feature branches advance, you should merge, as before.
It would be useful if Git could help you keep track of what needs to be merged, especially as the number of feature branches and dependencies increases. TopGit was Petr's answer to this challenge, and it works fine, albeit it's a bit too complex and we find it scaring new contributors, rather than making their lives easier.
Therefore I am investigating ways in which to simplify/improve TopGit. In doing so, I discovered that you guys made a lot of progress in Git since the last time I had time to really dive into your tool.
If you would permit me, then please let me ask if you can think of Git functionality that could be useful in achieving what we're trying to do.
For instance, there is git-branch --set-upstream, which could be useful, but it only seems to support one "dependency" (which is usually the remote ref being tracked by a branch).
One challenge seems to be that a branching point has no information about which of the children continues as mainline — this information is only available in a project's workflow policy. For instance:
o--o--o--● upstream
\
o--● featureBut his is actually just the same as
,o--● feature
o--o
`o--● upstreamand Git has no way to find out whether it is now "feature" that needs a merge of "upstream" or vice versa.
It is thus necessary somehow to store the (project-specific) dependency information, to be able to (automatically) determine that "feature" needs an update in the above.
TopGit does this using a file in the worktree, but many of us find this suboptimal.
I have had the following alternative ideas:
1. a separate DAG, like Git notes. The problem is that this
requires additional refspecs to be set up for merges and
fetches; 2. like (1.), but a ref in refs/heads/* (like pristine-tar). This
could be considered ugly as it exposes too much implementation
detail; 3. information stored in the Git commit messages. Again, too much
implementation detail exposed and ugly; 4. additional Git commit headers — this is not supported at the
moment (cf. commit generation discussion); 5. orphan parent nodes to certain commits, in which these data can
be stored, e.g. o--o--o--●
/
o To fetch these data, one would walk up the DAG until one finds
a multi-parent commit with a parent having a specific format
(somewhat brittle…) To me, this is the least offensive, but it does expose
implementation details in the commit history.How else could I store the dependency information, keeping in mind that I might have more than one dependency?
And the original question remains: given such dependency information, which Git tools could I harness for the purpose, trying to reduce the amount of additional code needed?
Thanks,
--
martin | http://madduck.net/ | http://two.sentenc.es/
it is better to have loft and lost
than to never have loft at all.
-- groucho marx
spamtraps: madduck.bogus@madduck.net