Just tried: <jimsys:code/dev/whimsy> % vi README.md <jimsys:code/dev/whimsy> % git commit -a [master a4f772a] test 1 file changed, 1 insertion(+), 1 deletion(-) <jimsys:code/dev/whimsy> % git push Username for 'https://git-dual.apache.org': jim Password for 'https://j...@git-dual.apache.org': Counting objects: 3, done. Delta compression using up to 24 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 285 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: To git@github:apache/whimsy.git remote: 2f85f27..a4f772a master -> master To https://git-dual.apache.org/repos/asf/whimsy.git 2f85f27..a4f772a master -> master
> On Mar 21, 2016, at 4:44 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > On Mon, Mar 21, 2016 at 4:38 PM, sebb <seb...@gmail.com> wrote: >> On 21 March 2016 at 20:32, Jim Jagielski <j...@jagunet.com> wrote: >>> I do, but I'm still unclear on dealing w/ the GH workflow. >>> >>> Can I just do it via svn, or even *our* git and not deal >>> w/ GH at all? > > You can do it entirely using *our* git and not deal with GH at all. > >> You can certainly just work on a clone of our Git; no need to use >> GitHub (once you are set up correctly). > > Nothing needs to be set up to use our git: > > https://git-dual.apache.org/repos/asf/whimsy.git > > Pushes there are automatically picked up. I've done it. > > Jim, perhaps you could try pushing a minor change to README.md and > letting us know how it works out? > > - Sam Ruby > >>>> On Mar 21, 2016, at 4:19 PM, Sam Ruby <ru...@intertwingly.net> wrote: >>>> >>>> On Mon, Mar 21, 2016 at 3:14 PM, Jim Jagielski <j...@jagunet.com> wrote: >>>>> Well, it looks like the format has been changing... so I >>>>> can see concerns. >>>>> >>>>> But really, I'm not sure why it needs to be so >>>>> "standardized" esp when it's mucking around with >>>>> stuff it has no reason to. It's adding a line, so >>>>> I don't see the reason why it has to "recreate" the >>>>> file in the 1st place. Either it finds where a new >>>>> proxy needs to go and adds it there, or find the >>>>> line that needs to be updated, and modified *that* >>>>> line, or it finds the line it needs to delete >>>>> and trashes it. >>>>> >>>>> If a tool is updating a file which is also mostly edited >>>>> by humans, it should be pretty lax about enforcing >>>>> a "format" imo. If it doesn't need to mess with >>>>> a line, it should leave it alone or output it >>>>> exactly as it was read... >>>> >>>> Originally, this was a sorted index of files in the associated >>>> proxies-received directory. >>>> >>>> I'm OK with the idea of requirements changing and/or this being a bug >>>> in the first place. >>>> >>>> None of us like the idea of single maintainer tools. In this case, >>>> what we have here is a small, standalone tool. After the dust settles >>>> (i.e., after the meeting is over), anybody want to take a crack at >>>> improving it? >>>> >>>> Note: improving it could mean rewriting in Python and moving to Steve, >>>> I don't care. What I do care about is having multiple maintainers. >>>> >>>> - Sam Ruby >>>> >>>>>> On Mar 21, 2016, at 3:02 PM, Sam Ruby <ru...@intertwingly.net> wrote: >>>>>> >>>>>> I think having a proxy web interface continues to be a good idea; but we >>>>>> need to come to a common understanding of the data format. Too late for >>>>>> this meeting, but I'm inclined to change to a JSON format for future >>>>>> meetings. >>>>>> >>>>>> Here's the relevant lines: >>>>>> >>>>>> https://github.com/apache/whimsy/blob/c5329abf90371ff2377bcb6f087abb59605bcea4/www/members/proxy.cgi#L163 >>>>>> >>>>>> Most importantly, lines that do NOT match / \S.*\(\S+\)$/ are lost. >>>>>> >>>>>> This is clearly problematic. >>>>>> >>>>>> Suggestions welcome! >>>>>> >>>>>> - Sam Ruby >>>
