> There's been some recent work to make > Git's merge code (also used for cherry-pick) less reliant on the index > and worktree. Yes please ! In the mean time, someone suggested another trick [0]. > Can you say more about the federation model it intends to support? My goal is to have a workflow similar as what git does, to be versatile and leave to the users the choice of the topology they want to use. Obviously, it will be most of the time a single remote where they collaborate. As a bug tracker is a different workflow than regular code, there will be some tooling to help. For instance, automatic push/pull will help make it easier to use and more "out of the way". In the data model, each commit in the linear chain link to an array of new edit operations. That means that each commit is strictly independent from the others. When you get updates for a bug and you need to merge them, you will simply rebase your new commits on top of the linear chain. This design has several properties: - the merge happen on the user repo where git-bug is installed and can validate new data - the remote used doesn't have to be aware of git-bug - when pushing an update of a ref, the remote will make sure that it's fast forward, that is, no previous edit operations has been removed. It ensure that the history is append only. So for now, collaboration is based on push/pull to whatever remote you want, as git does, with the exception of the Web UI. The goal here is to have it running locally for each user but also to make it a public interface for users that don't have write access to the repo, much like any bug tracker has. In the future, it could be possible to have more fancy features like a federated forge with ActivityPub, but that's way outside of the scope of the project for now. [0]: https://github.com/MichaelMure/git-bug/issues/15 2018-08-19 2:45 GMT+02:00 Michael Muré <batolettre@xxxxxxxxx>: > Here was my reasoning for the naming choice: > > - I need something meaningful > - I need something that encompass the idea and features of a bug > tracker because the narrower ideas and actions will be in sub commands > - other projects already used other words, in particular "issue" > - it kind of sounds and looks good > > You say that it's a namespace grab and I understand that, but in the > other hand, there is not that much freedom when choosing a name. Sorry > if I'm stepping on someone's toe :-| > > 2018-08-19 0:50 GMT+02:00 Jonathan Nieder <jrnieder@xxxxxxxxx>: >> (cc-ing Elijah Newren for the points about merging) >> Hi again, >> >> To avoid the other thread shadowing more important things: >> >> Michael Muré wrote: >> >>> Someone suggested in the Hacker News thread [0] to post it here as well. >> >> Thanks to Ævar for that. >> >> [...] >>> git-bug use as identifier the hash of the first commit in the chain >>> of commit of the bug. >> >> Clever! I like this approach to the naming problem. >> >> [...] >>> Git doesn't provide a low-level command to rebase a branch onto >>> another without touching the index. >> >> Thanks for pointing this out. There's been some recent work to make >> Git's merge code (also used for cherry-pick) less reliant on the index >> and worktree. See https://crbug.com/git/12 for some references. >> There's also been some heavy refactoring of "git rebase" code to be in >> C and be able to make use of library functions instead of being a >> shell script. >> >> That's all to say that we're in a pretty good place to consider >> introducing commands like >> >> git cherry-pick --onto=<branch> <revisions> >> >> In absence of that kind of thing, you can run commands that need to >> touch the index (but not the working tree) by setting the GIT_INDEX >> environment variable to point to a temporary index file. >> >>> I'd love to have some feedback from you. Contribution are also very >>> much welcomed. >> >> Can you say more about the federation model it intends to support? >> For example, do you imagine >> >> - having multiple copies of a git bugs repo that automatically fetch >> updates from each other >> >> - having explicit "pull request" synchronization moments when the >> owners of one copy of a bug tracker push or request a fetch of >> changes that have been happening on another >> >> - individual contributors using an offline copy of the bug tracker >> and pushing push/pull mostly to synchronize with a single >> centralized copy >> >> - something else? >> >> Thanks, >> Jonathan > > > > -- > Michael -- Michael
