Make ticgit -branch into separate repo in Gitolite-style-managed-centrally

[heoa]

I cannot understand why ticgit uses a separate branch for tickets. In Gitolite (permission -management), it creates a separate repository. Why not to create a separate repository under Gitolite with ticgit so it is easy to manage all tickets in the Gitolite -management in the same place -- current ideology of creating always new branches feel shortsighted.

PROPOSAL 0: do not create separate branches for ticgit, replace it with Gitolite -style central repo so manager can manage tickets more easily in one place

---> creating consistency with Gitolite -style management -- and why on earth do we need an extra branch for tickets?

[jeffWelling]

The alternative options in regards to TicGit-ng using a branch have been discussed before with the pros and cons of each laid out, let me see if I can find out where...

But if memory serves, the perceived benefits of the branch model (I didn't make the original decision to write it that way, I picked it up after the fact) seemed to best fit, though I do remember that the conclusion of said discussion was based on an agreement that ideally TicGit-ng would be able to support multiple back-ends (branch-based, file-based, repository-based, et cetera) based on a config file, but that has yet to be implemented.

I'll see if I can find that discussion though..

[heoa]

Please, join #gitolite in Freenode to discuss this issue further -- you can find the gitolite -creator. I think we should listen him a bit about his goals for gitolite -- is it easy to create some sort of central management for Tickets, Perms, etc?

Look this ticket [1] about consistency between different projects. You may find this useful, the structure of version-control [2], notice the related -threads!

[1] #56
[2] http://stackoverflow.com/questions/11218069/version-control-for-tickets

[jeffWelling]

Like Like Like!

[heoa]

I think this is stupid idea. Keep tickets close to the repo in branch. Gitolite -creator seemed to agree with that. The challenge is now some git-fetch -hacks to manage the tickets in many ticgit -branches.

[jeffWelling]

Hold the phone, I'm curious now, what do you mean by "The challenge is now some git-fetch -hacks to manage the tickets in many ticgit branches?"

[heoa]

Please, put your screen to #git in Freenode. We had yesterday quite intensive and long discussion about this issue, here an example about fetchspec (or was it called refspec?) -hacking [1]. If you do it wrong like using some odd depth -par or "$ git clone REPO ticgit", you get a lot of unnecessary history that can mean lag. So the way to manage large amount of repos (with ticgit -branches) with different sizes is to hack the refspec.

I don't know yet how to proceed from this on. Robert suggested gitslave but he misunderstood the puzzle. Someone suggested to create a dummy repo and then fetch the tickets from each branch -- but this point particularly how to push them back (look this is apparently some shallow fetch/cloning -thing lacking history) is confusing to me -- because we lack the full history and have customized branches, pushing them back may need some precaution and editing things.

Do not hesitate to research deeper. We need no clutter ruby -code to solve this problem but people to discuss this deeply, probably best place #git in Freenode. I will probably look deeper to this after hacking some 2008/2009 versions, looks simple enough for me and getting rid of "features" that I cannot understand.

[1] #57 (comment)