Hi Michael,
# Resolving/avoiding conflicts: > If I understand correctly, in git-dit you allow a non linear history > of edit. A maintainer then can (has ?) to decide how to resolve the > conflict, that is, how to order the operations. It's not really a matter of ordering operations but rather select which of the options provided is the "upstream" one (or present his/her own). Note that this view really only matters for metadata, e.g. the assignee or the issue's status. > I think it's a question of taste here. I personally very much prefer a > tool with low friction, that does it's job without requiring any > specific attention. I think the automatic merge where you get the last > word, combined with the fact that the merge happen on a pull and not a > push, should works reasonably well. Ideally, the maintainer would not decide manually each time he/she is presented with a choice. Rather, a software would perform the selection based on a policy which could be selected or specified by the maintainer. Of course, this makes only any sense for repositories which either accept pushes from users or are fed by from other sources (e.g. other repos or a ML). We actually have a small demo for a server-side update-hook in our repo [1]. The latter will probably come if we finally set up an e-mail bridge or a propper web UI. > A bug tracker is a communication tool, not a code versioning system > where you need to control everything exactly. With communication > tools, you can tolerate a small degree of "errors" as long as it's > easily detected and corrected. Also as I said in my previous email, > there is ways to improve on that if the need arise. Still, if I understand correctly, you need to put in extra work into git-bug to prevent loss of data when pushing to a repository from multiple sources. Which is bad for a communication tool. # Remotes > In git-dit, you have a list of remotes with descending priority. Is > that to have a fallback if the default remote fail ? I'm not sure > which approach would be best (unique default remote, fallback, > multiple remote) so I will wait to get feedback from users to decide. The idea is to support multiple remote repositories. In most cases, the list will only have a single entry (e.g. "origin"). However, there are legitimate use-cases for having multiple remotes. Hence, we decided to support such use-cases. For example, projects may have an issue-repository for each component. E.g. each sub-maintainer could keep a separate repository. Or you could have a separate (private) issue-repo for issues with security implications. Or an archive where old (resolved) issues go to keep the main repo small. Given multiple remotes presenting issues to you, remotes could present diverging views of one and the same issue (other "head" reference): one remote may present you an issue as "closed" while another may present it to you as "assigned". In such a situation, we have to decide which reference to use for aggregating metadata. Hence, we use a list with decreasing priority. Btw: the local head always has precedence over remotes. # "Issue states" > This is definitively a subject where git-bug need to improve to > support other bug-trackers. I don't have a clear plan here yet though. > > Thank you for explaining how it works in git-dit. Well, technically it's not yet implemented in git-dit. The specification and library lives in another repo. > It's an approach worth looking at. Do you have a link for where this > is worked on ? Yep, here: [2] Incidentially, have you seen the "git enumerations" proposal I posted on the git ML [3]? I was not sure whether you are subscribed to that list and I apparently forgot to put you into the CC. Regards, Julian [1] https://github.com/neithernut/git-dit/blob/master/examples/hooks [2] https://github.com/neithernut/issue-states [3] https://marc.info/?l=git&m=153479555608283 _______________________________________________ dist-bugs mailing list [email protected] https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
