Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Centrally Managed Tickets-Perms -UI/repo for Manager/Producer/Leader #57

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

Comments

Projects
None yet
2 participants

heoa commented Jun 28, 2012

PLEASE MAKE THIS MILESTONE, thank you.

I don't actually care how to design ticgit but I personally like the Gitolite -way of doing things. Ofc ticgit is a bit different -story -- if we create always separate branches, we move the problem forward about management. I think much better way is to create design consistency somehow, perhaps by looking how Gitolite manages things.

  1. [DESIGN] open question [1] about branch into separate repo in the Gitolite -style
  2. [DESIGN] Consintency over different Git -projects [2] [3]
  3. ...?

Related tickets or related
[1] #56
[2] #52
[3] there are even Git -projects based on DB such as MongoDB-blog/etc -- a lot of people tinkering...

heoa commented Jun 28, 2012

Bremner in #gitolite Freenode suggested to check other options outlined here [1] for command-line -usage -- and some workflow/project -management -things such as Redmine and Trac [2]. I think someone more experienced should check this proposal.

[1] http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/
[2] http://stackoverflow.com/questions/5881578/trac-vs-redmine

heoa commented Jun 29, 2012

We discussed this in #gitolite and here the implementation details:

04:03 < heoa> (You want Ticgit works even without Gitolite. If someone wants to use it with Gitolite, it must be designed so to do so. You do not want to create any dependency that would make TicGit fragile)
04:04 < click170> heoa: This is true, but I believe integration with gitolite could be arranged so that TicGit-ng looks for clues of Gitolites existence, and if it finds these clues then it consults gitolite, and if it doesn't it presumes gitolite doesn't exist. Theoretically anyway.
04:05 < milki> id rather leave that detection to a plugin you can enable/disable
04:06 < heoa> milki: good point, very good for debugging.
04:06 < click170> Or perhaps a config file option? "gitolite directory=?" kind of line means use gitolite, if it's commented out then ignore it.
04:07 < milki> all you really need from gitolite is the parser for the conf file and the compiled perl config file >.>
04:08 < click170> Sounds easy enough to do then either way. It's the implementation of the access controls that would take the work. Many functions would need changing to be able to check if the current user has the permissions to do X.
04:09 < milki> ya, making that part hookable would make auth pretty flexible
04:11 < nevyn> click170: you probably need to be far more... frameworky about this

heoa commented Jun 30, 2012

Thanks to SethRobertson in #git and other guys helping with fetch -hacking, the simplest solution probably goes like this A) fetch all ticgit -branches, B) edit the TicGit -branches and C) push them back.

X. Example about fetching only ticgit -branch

  1. git init
  2. git remote add mh-pictures https://bitbucket.org/heoa/mh-pictures.git ;
  3. git config remote.mh-pictures.fetch +refs/heads/ticgit:refs/remotes/mh-pictures/ticgit;
  4. git fetch mh-pictures

TODO

I. do the point X for all repos specified by Gitolite-admin -repo

I.1. should the branches be renamed? (look every branch of the same name)

II. how should the editing be completed? Jekyll? Console?

III. how should the pushing be completed?

IRC dump

03:02 < cbreak> heoa: you're not supposed to clone
03:02 < cbreak> you have to init a new repository
03:02 < cbreak> then git remote add all repositories you care about
03:02 < cbreak> then change the fetch ref spec to only fetch the branches you care about
03:03 < cbreak> and then git remote update, or git fetch

Owner

jeffWelling commented Jul 1, 2012

I hate to say it but since we don't call out to the git command line, we use the git gem at the moment, so your example isn't of much help.

Also, your TODO list doesn't make any sense. There appears to be some kind of breakdown of communication here somewhere... branches shouldn't need to be renamed, I'm not sure what you're talking about there either. What editing? Jekyll is a blogging engine based on Git so again, I don't know what you're talking about.

You seem to be focusing a lot on gitolite integration, but we don't need people to tell us how to do it, we need people to do the actual coding. If you want to see gitolite integration within the next couple years I certainly welcome you're contributions to the codebase, as well as the bug reports, but code contributions would be more valuable.

heoa commented Jul 1, 2012

I also hate to say this but I think the biggest problem with Ticgit-ng is to do more, not less. A lot of error-firing "features" [1] that you can already do on commandline -- like the sorting and what are attach/sync for? Look cannot you already do them with basic Git -commands like git-fetch -hacking? I cannot see a reason to continue Ticgit-ng, what is wrong with Ticgit 2008/2009 -version?

This may be just a stupid reaction but I am now using 2008-2009 version and it seems to work well. If some GUI built on top of that, I feel features such as milestones/priority/etc are far easier to do there or what do you think.

I want to make things simpler, I cannot see a reason to make things overly complicated.

  1. dashboard to manage tickets can be created by a few git-fetch-hacking -oneliners.
  2. Ticgit is good to keep simple, only to handle tickets
  3. milestones can be handled elsewhere perhaps in README -files
  4. version -numbers can be handled spontaneously with proper gitting

Now there are already things such as gitk and some other graphical things [2], I think one should reuse them -- still investigating! Do less, not more. No-one needs clutter code!

[1] #64
[2] http://stackoverflow.com/questions/11251941/how-can-i-see-github-style-things-such-as-punchcards-and-timeline-of-git-repo

@heoa heoa closed this Jul 1, 2012

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