-
Notifications
You must be signed in to change notification settings - Fork 26
[design] .topmsg / .topdeps pollute commit history #38
Comments
Now that I think about it more, it seems to me that adding a tag to the base of the topic branch seems like the cleanest solution. This would solve #39 for free, since the tag could be lightweight or annotated. Of course there would need to be some way of tying the base tag to the topic branch, but this could easily be done by adopting a naming standard for the tag, just like |
The idea is that you would use |
@greenrd But what if I don't want to squash my topic into a single commit? That's generally a bad idea if the topic contains multiple logical changes. And it also requires an extra step, which is not ideal for the UX. |
IMO, it's a very sensible and useful suggestion.
|
@imz In reply to your points:
There's still the question of where to track a topic's dependencies though. I wonder if it shouldn't be inside the text of the annotated tag because
I've had some further thoughts on the possible locations for storing this metadata:
Currently I'm leaning towards tags. I'm still undecided whether it should be one or two tags per topic though. It could be one tag by treating any line which starts with the magic string Thoughts welcome. |
TODO: the problem with topgit internal files should be solved. The problem is like this (http://www.altlinux.org/Git/MergingBranches#.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.B5_.D1.81_gear): `tg export` exports nice patches, but it can't be called from `gear`. Gear is stupid and includes them in the patches. Possible solutions: * teach Gear to use topgit (extra dependency?); * modify TopGit not to store the meta-info (.topmsg, .topdeps) in Git trees (greenrd#38); * somehow adapt `tg export` to the needs of a Gear-based workflow (some relevant remarks and objections: greenrd#42 (comment)).
TODO: the problem with topgit internal files should be solved. The problem is like this (http://www.altlinux.org/Git/MergingBranches#.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.B5_.D1.81_gear): `tg export` exports nice patches, but it can't be called from `gear`. Gear is stupid and includes them in the patches. Possible solutions: * teach Gear to use topgit (extra dependency?); * modify TopGit not to store the meta-info (.topmsg, .topdeps) in Git trees (greenrd#38); * somehow adapt `tg export` to the needs of a Gear-based workflow (some relevant remarks and objections: greenrd#42 (comment)).
I am working on this issue this week as a Hack Week project.
I think one tag per topic keeps it clean and simple, and it seems to me advantageous to be able to simultaneously view a topic's description and its dependencies (if both exist). For example, reading the description might make you realise that the dependency list is wrong. And I can't really see any disadvantages other than having to extract the dependencies from the tag text. |
Another advantage of keeping the description and dependencies coupled together in the same chunk of metadata is that they can't accidentally get separated, e.g. when transferring between remotes, or if something goes wrong in the code. So it's clearly more robust. However there is a disadvantage to using tags, which is that normal tags occupy a single namespace ( Whilst thinking about all this, further comparisons of the status quo (which relies on A disadvantage of the status quo is that rewriting the metadata requires rebasing the whole branch, which changes all the SHA1s. This reinforces my believe that metadata should be kept separate from content! I'll update the issue description to include this. |
The idea is that changes to the metadata are tracked in the git history just like any other changes. How would you merge changes to the metadata if not? |
One immediate observation is that tracking changes to metadata is supposed to be handled by the reflog, not the normal log. But the key question here is, what are the use cases for tracking changes to the topic metadata, or being able to merge changes to the metadata? For the latter, I can imagine that if two or more developers are collaborating on a topic and are separately editing the same Please let me know if I'm missing something. Thanks! |
But it would still be a loss of functionality compared to the previous version of topgit. (Not to mention that you would need some way of converting topgit repositories to the new format.)
But it makes sure it happens.
Well that is what a merge semantically means - if you pull in someone else's changes and they have added a new dependency, that should be added to your topic branch as well. That's how TopGit's distributed nature works. We only support adding dependencies at the moment, so a merge would only add new dependencies, and therefore we don't officially support rejecting new dependencies (except by using |
On Wed, Apr 15, 2015 at 03:59:28AM -0700, Robin Green wrote:
Not really, because I'm going to keep it backwards-compatible via a new
Yes, I am hoping to add that later on. Shouldn't be hard.
Understood, but what if that dependency topic is present but different in both remotes? Then you've introduced a local dependency on the wrong thing. The only way to solve this would be to recursively merge all topics in the dependency tree, and that sounds pretty hard to handle cleanly, e.g. how would you rollback the whole tree if something went wrong during the middle of the process?
Sure - I definitely want to avoid breaking the existing support for distributed setup. That's why I'm experimenting with tags in the
Thanks for the info - I hadn't looked at
Why? We don't automatically run |
Because that is what Another possible counterargument is that if it's a fast-forward (or indeed a commit resulting from running |
Ahh, OK. But in that case, there is no risk of the user being surprised by
Here you are referring to a normal
Sounds reasonable. Thanks for all the info - this is greatly helping my understanding, even though we have gone off on quite a tangent ;-) Going back to the focus of this issue, I am pretty sure that there are many developers (myself included) who would find |
I am not sure about the technical details of this design, but the use-case you describe matches mine:
I just want to manage local patch sets. I and my team haven't yet reached the point where we would find remote collaboration on patch-sets useful. If this design helps with this use-case, I am willing to try it out. Do you have an implementation somewhere? |
@hrj Sorry for the very slow reply! My work will always be found at https://github.com/aspiers/topgit/branches but I can't remember what state I last left it in. I am hoping to return to this at some point soon though. |
.topmsg
and.topdeps
represent SCM meta-data, and so I believe it's a fundamental design mistake to include them in the commit history:git
commands and UIs.tg import
creates a topic branch per commit which is usually undesirable.)t/foo
topic branch..topmsg
or.topdeps
either creates more noise, or requires rebasing the whole topic branch..topmsg
, and one for the initial commit message.Having said that, I can hazard a guess as to why this design decision was made: in order to adhere to the third stated tenet:
This is clearly a worthy goal, but I think the current implementation is the wrong way of going about it. (However the original author's comments on this decision are encouraging.) In fact
topgit
already stores other meta-data such asrefs/top-bases/*
outside the commit history. There are alternate approaches worth considering, e.g.git-annex
uses agit-annex
branch to track its metadata.refs/
or.git/info
..git/info
.None of these will get fully and automatically transferred across remotes during using of normal
git push
/pull
/fetch
, but it wouldn't take much effort to fill in the gaps.The text was updated successfully, but these errors were encountered: