atom feed21 messages in nz.co.katipo.lists.kohaRe: [Koha] LibLime Enterprise Koha Q&A
FromSent OnAttachments
Joshua FerraroSep 15, 2009 2:15 pm 
Kyle HallSep 15, 2009 2:35 pm 
Chris CormackSep 15, 2009 2:52 pm 
Chris NighswongerSep 15, 2009 3:08 pm 
Joann RansomSep 15, 2009 3:14 pm 
Piotr WejmanSep 15, 2009 3:26 pm 
Brendan GallagherSep 15, 2009 9:07 pm 
paul POULAINSep 16, 2009 1:15 am 
Liz ReaSep 16, 2009 11:01 am 
Daniel GrobaniSep 16, 2009 2:19 pm 
Reed WadeSep 16, 2009 3:00 pm 
Chris NighswongerSep 16, 2009 3:25 pm 
Owen LeonardSep 16, 2009 6:51 pm 
paul POULAINSep 17, 2009 12:44 am 
paul POULAINSep 17, 2009 1:11 am 
Thomas DuklethSep 18, 2009 9:36 am 
Thomas DuklethSep 18, 2009 9:43 am 
Thomas DuklethSep 18, 2009 10:44 am 
MJ RaySep 22, 2009 2:56 am 
paul POULAINSep 22, 2009 6:22 am 
Joe AtzbergerSep 22, 2009 8:05 am 
Subject:Re: [Koha] LibLime Enterprise Koha Q&A
From:paul POULAIN (paul@biblibre.com)
Date:Sep 22, 2009 6:22:54 am
List:nz.co.katipo.lists.koha

MJ Ray a écrit :

"Thomas Dukleth" <koha@agogme.com> wrote:

On Thu, September 17, 2009 07:44, paul POULAIN wrote:

Daniel Grobani a écrit :

"We will not be making our git repo public as it contains customer-sensitive data."

Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !

I can believe that people do many poorly conceived things when they are in a hurry. I also know that Git is a very robust tool which can be used to manage much more than source code data.

Yes, this is a main reason for the difficulty of republishing private forks. Not only do you have to make sure that the git HEAD doesn't contain confidential data that was added in error, but also that the visible history doesn't show it.

A suggestion: git rebase -i => reorder your patches to put the offending patch on top git reset --hard => remove it from your git tree rm offendingfile.csv => remove the file definetly

HTH

(did I already say I love git ?)