| 1 |
It's an implementation detail. It's not unimportant, but this can be |
| 2 |
decided once the project is accepted. That being said some last |
| 3 |
thoughts. |
| 4 |
|
| 5 |
On Thu, Mar 26, 2009 at 19:39, Caleb Cushing <xenoterracide@×××××.com> wrote: |
| 6 |
> I think you're abusing branches a bit, plus I don't want to look |
| 7 |
> through hundreds of branches (unless I made them)... and even then I'm |
| 8 |
> assuming only 1 or 2 non remote branches on a machine. |
| 9 |
|
| 10 |
If you use git directly that is a problem. However cfs will contain |
| 11 |
functionality to only show branches related to a given package or set. |
| 12 |
|
| 13 |
> of course maybe |
| 14 |
> I don't understand the layouts of files in those branches. I'm kind of |
| 15 |
> assuming that each branch will just have the source of it's files and |
| 16 |
> not the full config directory layout... |
| 17 |
|
| 18 |
No it will contain the complete layout. And the root isn't /etc. It's |
| 19 |
/ because not all config files live in /etc. |
| 20 |
|
| 21 |
Again, it's like git-submodules just that the different modules do not |
| 22 |
have to live in a dedicated subdirectory. The first thing that has to |
| 23 |
be implemented is "git-mixedmodules". (Well it does not have to be the |
| 24 |
first thing, but I think that's where I would start.) |
| 25 |
|
| 26 |
> to be honest I think your |
| 27 |
> layout adds a bit too much branch complexity for the normal user or |
| 28 |
> admin. |
| 29 |
|
| 30 |
That will all be neatly hidden with cfg and with git grep is your friend. |
| 31 |
|
| 32 |
Any thoughts on other aspects of my proposal? (Thanks for the input so far.) |
| 33 |
|
| 34 |
-- Jonas |
Archives