Time |
S |
Nick |
Message |
13:11 |
|
kyle |
hey all. |
13:11 |
|
paul_p |
hello kyle |
13:11 |
|
hdl |
hi kyle |
13:12 |
|
kyle |
I'm having some trouble with git, are there any git experts around at the moment? |
13:12 |
|
paul_p |
not sure i'm a git expert, but throw your question |
13:14 |
|
kyle |
I suppose my first question isn't a big one. I made some patches, reverted to master, and are trying to apply these patches to master. When I do, I get a list of 'patch failed' and 'patch does not apply' errors. How do I fix those? I'm using the command 'git apply mycode.patch' |
13:16 |
|
hdl |
kyle: it is because your patches are not based on the new code parts but on old ones. |
13:17 |
|
hdl |
To fix this, |
13:17 |
|
kyle |
please go on... |
13:17 |
|
hdl |
revert to your previous point |
13:17 |
|
hdl |
make a branch mywork |
13:18 |
|
hdl |
apply your patches |
13:18 |
|
hdl |
THEN rebase to origin |
13:18 |
|
kyle |
I don't know what point I was at, is it hidden in the patch file anywhere? |
13:19 |
|
hdl |
Do you know the version of the database you're at ? |
13:19 |
|
hdl |
or you were at ? |
13:20 |
|
kyle |
The patch I'm trying to apply is the Reserves System update that I posted on the 4th. |
13:27 |
|
kyle |
I'm looking at the git log and if I can revert to just after the patch 'Minor logical cleanup.' I think I will be good to go. Any idea how I would to that? |
13:27 |
|
kyle |
hi acmoore |
13:29 |
|
hdl |
where you uptodate ? |
13:29 |
|
hdl |
git reset --hard commitnumber |
13:30 |
|
kyle |
Yes, I've done that before. I'll give that a shot. |
13:30 |
|
kyle |
sucess! |
13:31 |
|
kyle |
success! that is ; ) |
13:39 |
|
kyle |
I applied the patch and git gives me a list of files that 'needs update'. I checked them out, and they all look like they were patched just fine, no modifications needed. Any suggestions on what I should do next? |
13:42 |
|
hdl |
then git branch mybranch |
13:43 |
|
hdl |
git apply your patches |
13:43 |
|
hdl |
git commit edited files |
13:43 |
|
hdl |
git rebase origin |
13:43 |
|
hdl |
should do the job |
13:59 |
|
kyle |
I think I have a handle on it now. Thanks for all the help. It would be nice if the patch files contained the number of the previous commit. |
14:49 |
|
ryan |
owen: around ? |
14:49 |
|
owen |
Yes |
14:50 |
|
ryan |
owen: have you played at all with inline table cell editing for yui ? |
14:50 |
|
ryan |
http://developer.yahoo.com/yui[…]_cellediting.html |
14:50 |
|
owen |
No I haven't. Someone was working on some AJAXy inline table editing though...for system prefs I think? |
14:51 |
|
gmcharlt |
pianohacker; also working on adding AJAX to circ pages |
14:53 |
|
ryan |
gmcharlt: were jesse's patches submitted ? |
14:54 |
|
gmcharlt |
he's still working on them |
14:57 |
|
ryan |
gmcharlt, others: http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2761 |
14:57 |
|
ryan |
any consensus on the 'correct' column length? |
14:57 |
|
ryan |
for item call number ? |
14:57 |
|
ryan |
i was thinking 64, but i see nicole suggests 255. |
14:58 |
|
gmcharlt |
255 is too long, but anything less than 100 is is too short |
14:58 |
|
ryan |
128, then |
14:58 |
|
gmcharlt |
(edge cases - you would think anything longer than 30 characters would defeat the purpose of having one in the first place, but...) |
14:58 |
|
gmcharlt |
128 is fine |
14:59 |
|
ryan |
yes, it would seem to me that > 30 characters would be a misuse of the field. |
14:59 |
|
ryan |
but may as well allow it |
15:44 |
|
kados |
that has fairly substantial implications for spine label printing |
15:45 |
|
paul_p |
a lot of ppl today here ;-). Hello kados, owen, gmcharlt, ryan |
15:47 |
|
hdl |
hi |
15:49 |
|
kados |
hi guys |
15:49 |
|
danny |
hey everyone |
16:00 |
|
danny |
I've been brainstorming about support for multiple cover art providers, basically the script will need to check to verify if the image exists if not go on to check until it finds a valid one and display it, or display owen's message that no cover art exists. Two options I have thought about are to use AJAX and go through the checks each time a cover art needs to be loaded, the other option would be to maybe have the script load once a day/week and dump into a data |
16:00 |
|
kados |
danny: I'm in favor of doing that processing client-side FWIW |
16:01 |
|
kados |
danny: doing it server-side could be pretty expensive |
16:03 |
|
danny |
ok, it will still be partially server-side though because the only way to check Baker&Taylor is to do a Perl ua->get and check to see if the image is valid |
16:04 |
|
danny |
that perl script would be called with ajax, but still a bit of backend work |
16:08 |
|
gmcharlt |
some caching would be good, though |
16:08 |
|
atz |
danny: really, ajax is the only choice since google's access methods require it |
16:08 |
|
gmcharlt |
although not all providers will allow it IIRC |
16:09 |
|
atz |
gmcharlt: yeah, i think we can defer the question of caching jacket images to a more robust proxy setup.... somebody already implemented this in the UK |
16:10 |
|
danny |
ok |
16:20 |
|
danny |
not 100% sure but I dont think you need JS to use google's method, if you can parse the JSON response in Perl it would still work, but not necessary if using ajax anyway |
01:32 |
|
chris |
gah not again |