Hi, > No, replies usually have no file modifications (i.e. the text of the > reply is kept in the commit-message, just as does git-dit IIUC, tho > they can add files (attachments), but these files's names should be > unique). In this case my dive into the code was to shallow.
> > Btw., it never occured to us to move some metadata into the tree the > > way BuGit does. It would surely work for some classes of issues. > > But we also want to support patch-sets and for them it would > > be problematic. > > By "patch set", do you mean that you want to have the ability for > issues to refer to some "candidate branch". Would you store the > candidate branch as a "parent" in the commit (if so, how do you > distinguish that parent from one that isn't a patch-set but some > other reference), There are multiple possibilities, all of which have pros and cons. I think the consensus at the moment is having a patch-set represented as an issue of some sort. It may either be a new issue or an existing issue (feature-request or bug-report) which is simply delared a patch-set via the metadata. On this premise, there are, essentially, two ways to include patches or "code commits" in the issue: * referring to the head through the second parent of an issue message * basing the code-branch on a commit which pulls the code-base into the message-tree As we don't want to force a specific workflow on users, we would support both. The first option has the benefit that a contributor can use regular tools to prepare a branch and simply point to that branch in an issue. However, if the branch should be rebased and/or squashed, the "old" variant is still present. This "pollutes" the repository, unless the referring message and all replies are dropped. The second option is more alike the cover-letter seen on some mailing-lists. It also lets you easily present newer variants without dead code sitting in the repo: you just add a new cover-letter, maybe as a reply to the old one and throw away the old commits once they are no longer required. However, rebasing takes more effort since you have to write a new cover-letter or copy the old one first, then rebase. Note that squashing is, however, easier in this scenario. > or would you store them under /refs/dit/<issueid>/patchsets/<id>? We were thinking about using some trailer to distinguish patches from other references E.g. the issue-type transitioned to "patch-set" -> the commit is a cover letter or it refers to the head of the code-branch. However, the idea of having the head of the code-branch as a reference in a namespace inside the issue is very appealing. It also opens a third possible workflow: having patches corresponding to an issue which are not directly connected to issue messages through the parent relationship. This could be useful for some users, e.g. when you want to make sure you don't mix code- and issue-repos. You could also do a regular rebase without having to care for any references. The drawback would be that it is decoupled from the discussion and the discussion itself vannished if the issue is "dropped" from the repo (by removing the refs). But then again, that may be what some maintainers want. Thanks for the input! > I haven't thought very much about how to deal with it in BuGit. To > the extent that I'd like to make it possible to keep the issue > repository separate from the code repository, I think I'd keep the > reference to a patch-set as a piece of text (presumably a commit-id), > probably in a file-name. This would obviously suffer from the fact > that Git doesn't get to know about this commit-id, so we have no > guarantee that this commit-id can be found in the repository (i.e. > it's like a weak-reference). Well, you could still refer to the patch-set, e.g. as a parent and just not have that commit in the repository. In this case, if someone fetches both the issue-repo and the code-repo, the pieces "magically" fit together. So some contributors could have both repos as remotes and have some sort of unified view. On the remote side, you'd probably want a hook filtering the "unwanted" commits, however. > Another interesting avenue is to see how it could handle git-appraise. Yep. We discussed ideas of integrating code-review in patch-sets during 33C3 [1], but we didn't conclude anything yet. Maybe we'll come up with something "better" than git-apprise, maybe git-apprise (or some other external tool) is the way to go. Regards, Jule [1] https://events.ccc.de/congress/2016/wiki/Main_Page _______________________________________________ dist-bugs mailing list [email protected] https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
