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--● feature
But his is actually just the same as
,o--● feature
o--o
`o--● upstream
and 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@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)