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

Closed
heoa opened this Issue Jun 28, 2012 · 6 comments

Comments

Projects
None yet
2 participants
@heoa

heoa commented Jun 28, 2012

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

This comment has been minimized.

Show comment Hide comment
@jeffWelling

jeffWelling Jun 28, 2012

Owner

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..

Owner

jeffWelling commented Jun 28, 2012

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

This comment has been minimized.

Show comment Hide comment
@heoa

heoa Jun 28, 2012

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

heoa commented Jun 28, 2012

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

This comment has been minimized.

Show comment Hide comment
@jeffWelling

jeffWelling Jun 28, 2012

Owner

Like Like Like!

Owner

jeffWelling commented Jun 28, 2012

Like Like Like!

@heoa

This comment has been minimized.

Show comment Hide comment
@heoa

heoa Jul 1, 2012

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.

heoa commented Jul 1, 2012

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.

@heoa heoa closed this Jul 1, 2012

@jeffWelling

This comment has been minimized.

Show comment Hide comment
@jeffWelling

jeffWelling Jul 1, 2012

Owner

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?"

Owner

jeffWelling commented Jul 1, 2012

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

This comment has been minimized.

Show comment Hide comment
@heoa

heoa Jul 2, 2012

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)

heoa commented Jul 2, 2012

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment