| Time |
Nick |
Message |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:15 |
|
Dyrcona joined #evergreen |
| 09:47 |
pinesol |
News from commits: LP#2132541: (follow-up) clarify description of the ChiliFresh "generic placeholder... <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fca8a8fde8324d986f28bc70dd384c4ea92fb2e3> |
| 09:47 |
pinesol |
News from commits: LP#2132541: (follow-up) move the Amazon base_url to be next to the rest <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7efa2bb81dd3e595457bc652f3a1d9bed069cf5e> |
| 09:47 |
pinesol |
News from commits: LP#2132541: Followup opensrf.xml.example improvement <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bf929a937ba44f0b1e8475f5c44890782183fb58> |
| 09:47 |
pinesol |
News from commits: LP#2132541: added content handler for ChiliFresh cover images <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=21302baebaa8715c45d069a4f21a22f7ac484009> |
| 10:29 |
|
beardicus joined #evergreen |
| 10:39 |
|
beardicus joined #evergreen |
| 11:00 |
|
Christineb joined #evergreen |
| 11:25 |
Dyrcona |
Since it is quiet today, I'm updating CWMARS customization to late main and resolving conflicts with recent changes. When I look at some of the diffs on my current custom branch, I don't remember why we made some of these changes, but guess I'll keep most of them for now. |
| 11:26 |
Dyrcona |
I think if I kept all of the hundreds or thousands of individual commits instead of squashing them from time to time, it would be more clear. It always feels like a trade off with number of commits, etc. |
| 11:27 |
Dyrcona |
Ah, but this line in the squashed commit message explains what I'm looking at right now: Expand awards by default. |
| 11:28 |
Dyrcona |
I thought that's what the change did, but it's not always clear. commit_messages++ |
| 11:33 |
Dyrcona |
Ok. That's the easy stuff. Now for Ecard diffs. |
| 11:36 |
Dyrcona |
Oh, that's gonna be tricky..... We should probably have an internal discussion about how different we wanna be. |
| 11:40 |
Dyrcona |
I suppose I can commit the files with the conflict markers for now and come back to them later. I don't actually run this branch and only use it when I'm making a new series. I should try a 3.16 custom branch. I don't have one, yet. |
| 11:42 |
Dyrcona |
This is too messy. That's why I put it off for a day when I have time to really look at things, but the thing is this may affect workflows, and we need some communication with the vendor because they may have a custom configuration for us, etc. |
| 11:42 |
Dyrcona |
It will have to wait, but in the meantime I can start a conversation. |
| 12:16 |
csharp_ |
Dyrcona: we have the same dilemma re: ecard |
| 12:16 |
csharp_ |
and reconciling our custom commits and "us-only" backports is painful because we rebase/cherry-pick rather than merge (yeah, yeah, I know) |
| 12:19 |
Dyrcona |
I rebase/cherry-pick, too. |
| 12:20 |
Dyrcona |
I have other projects where I merge. |
| 12:22 |
jonadab |
My instincts when I started using git, without much prior version-control experience, were to merge a LOT. I've had experienced programmers who were used to CVS, tell me that I have *way* too many merge commits in certain of my repositories (not related to Evergreen). |
| 12:23 |
jonadab |
Apparently using a feature branch for every bugfix and then merging it once it's done, is not the done thing? |
| 12:24 |
Dyrcona |
jonadab: Depends on the project and past workflows. People who started with git/mercurial or another DVCS tend to prefer merge. Those who came from CVS or emailed patches prefer cherry-pick/merge. |
| 12:24 |
jonadab |
So it's good to hear someone has the opposite issue. |
| 12:24 |
Dyrcona |
cherry-pick/merge is called the "Patch workflow" in the git documents. |
| 12:25 |
Dyrcona |
I would prefer merges for main and tag branches, but I'm in the minority and old habits die hard. |
| 12:26 |
jonadab |
I do use cherry-pick sometimes, when I specifically don't want all of the commits another repository has, e.g., when pulling individual features from a fork/variant codebase. |
| 12:26 |
Dyrcona |
I like rebasing/squashing feature and custom branches. I could probably merge my custom branch with master and it would produce fewer conflicts, but I'd end up with something closer to the older code. I may want to rethink the eCard customization. |
| 12:26 |
csharp_ |
the only reason I care about merge vs patch is I can't easily answer the question "does branch X have this commit?" |
| 12:27 |
Dyrcona |
csharp_++ That's the main argument for merge in my opinion. |
| 12:27 |
jonadab |
That makes sense to me. |
| 12:27 |
Dyrcona |
jonadab: Yeah, cherry-pick makes it easy to get individual commits and that's its main purpose as far as I can tell. |
| 12:28 |
csharp_ |
when I'm testing something, I like seeing the pile of commits on top, and that seems to be the main point in favor of patch workflow |
| 12:28 |
csharp_ |
but there are ways to sort git log too |
| 12:28 |
Dyrcona |
When I get really desperate, I'll sometimes generate patches from git and apply them in another branch with `git am` |
| 12:29 |
* Dyrcona |
confesses to editing patches occasionally to remove stuff I don't want. |
| 12:30 |
Dyrcona |
All of that being said, I'm not sure there's a workflow that easily reconciles code drift like we're looking at with eCard. |
| 12:32 |
csharp_ |
Dyrcona: probably not |
| 12:32 |
jonadab |
When the code is _too_ far diverged, manual cherry-pick becomes essentially the only option. I've seen that e.g. when pulling in a commit from a Slash'EM variant into NetHack Fourk (a variant of a variant of a variant of 3.4; Slash was forked from before 3.0 IIRC). |
| 12:32 |
csharp_ |
I need to explore git log more - topo-order is interesting: git log --graph --oneline --all --decorate --topo-order |
| 12:33 |
Dyrcona |
Well, even then, when rebase/cherry-pick says you deleted files because they don't exist in your fork..... |
| 12:33 |
jonadab |
Hence the "manual". |
| 12:33 |
csharp_ |
"am" = "apply mailbox" - that's not confusing |
| 12:34 |
jonadab |
And yeah, I had entire directory trees that were just not organized the same way. |
| 12:34 |
Dyrcona |
I like my brief alias for a quick look. I run `git brief [branch|commit]` and it does git log --abbrev-commit --pretty=oneline |
| 12:35 |
Dyrcona |
Yeah. We ran into that somewhere in the 2.x to 3.x transition, a whole subdirectory moved up in the hierarchy. |
| 12:36 |
Dyrcona |
apply mailbox goes back to how Linus used to review patches sent in email. He'd save the mails to a mbox file and then apply it. |
| 12:36 |
csharp_ |
Dyrcona: huh |
| 12:36 |
jonadab |
I figured something like that. |
| 12:36 |
jonadab |
I've never liked mbox format, but that's not git's fault. |
| 12:36 |
* csharp_ |
sends profanity-laced screed to Linus for that |
| 12:37 |
Dyrcona |
It's handy sometimes if you have a bunch of git diff output you want to apply. |
| 12:37 |
Dyrcona |
Well, mbox isn't Linus's fault. I think it existed before Linux did. It's more of a convention than a standard. It's simple, but has some really rough edges. |
| 12:38 |
jonadab |
Oh, mbox *certainly* existed before Linux did. Or Minix for that matter. |
| 12:38 |
csharp_ |
oh I was just making fun of his tendency to cuss out people |
| 12:38 |
jonadab |
And yes, three quarters of its problems are because it was never carefully designed. |
| 12:38 |
csharp_ |
mbox is fine :-) |
| 12:38 |
jonadab |
It just sort of... evolved. |
| 12:38 |
csharp_ |
I use mutt as a client |
| 12:38 |
Dyrcona |
I remember back when I hacked on KMail in the KDE 2.0 days, we had issues with people wanting to share mbox files with Pine or other MUAs. I made a path to make the KMail FROM line more like the others. |
| 12:38 |
csharp_ |
jonadab: as so many things do |
| 12:39 |
Dyrcona |
People are actually expecting the FROM line to have a valid email and date.... Go figure.... :) |
| 12:40 |
Dyrcona |
FROM could be empty for all your MUA should care. :) |
| 12:41 |
Dyrcona |
I still have some old files that "FROM aaa aaa" in them. |
| 12:41 |
jonadab |
I mean, if your MUA *generates* empty From lines, I hate you. But if it just doesn't care what the From line is an incoming message, I can live with that. |
| 12:42 |
Dyrcona |
Anwyay... That's not Evergreen, unless we follow Zawinsky's Law and add email reading to Evergreen. |
| 12:42 |
jonadab |
Heh. |
| 12:42 |
jonadab |
I'm kinda surprised that hasn't happened yet, tbh. |
| 12:43 |
csharp_ |
the original wishlist for Evergreen features from PINES libraries included all kinds of things |
| 12:44 |
Dyrcona |
Can it do my laundry and take out my trash? |
| 12:44 |
csharp_ |
many of which are now available from other software nowadays |
| 12:44 |
csharp_ |
yeah, basically |
| 12:44 |
csharp_ |
honestly, most of the continuing requests from EG's early days when I started were trying to make the software do management |
| 12:44 |
Dyrcona |
It's great to have ideas. |
| 12:50 |
csharp_ |
PINES feature requests c. 2004: https://docs.google.com/spreadsheets/d/1cfH7lOWUeaL82RWjwGtodoFGjlMEgPqe/edit?usp=sharing&ouid=106847884017378119798&rtpof=true&sd=true |
| 12:52 |
Dyrcona |
"Accurate hold list." We still haven't gotten that and never will given all the knobs. |
| 12:52 |
csharp_ |
yeah - it's kind of amazing comparing this to current wishlist and current features |
| 12:53 |
csharp_ |
many of them even now are better served by third-party software or software unrelated to EG |
| 12:54 |
csharp_ |
lol at "no frames" |
| 12:56 |
Dyrcona |
I liked frames for all of 5 minutes in the '90s. |
| 13:02 |
csharp_ |
I don't know if the "# of requests" and "Accounted for" were me or someone else, but that was obviously unfinished :-) |
| 13:03 |
csharp_ |
I was definitely the one who transcribed the actual flipcharts |
| 13:03 |
csharp_ |
the originals still exist in my boss's office somewhere |
| 13:17 |
Dyrcona |
So, I wonder how difficult it would be to make a custom branch minus our eCard stuff... I suppose I could approach it a couple of ways. |
| 13:20 |
Dyrcona |
Easiest thing might be to take my current custom branch and remove the eCard stuff in a new branch, then either rebase that or cherry-pick it onto a copy of main. |
| 13:20 |
Dyrcona |
That way, I can at least reconcile the other conflicts. |
| 13:21 |
* Dyrcona |
does that. |
| 13:22 |
Dyrcona |
Hrm. rebase -i and remove files.... |
| 13:22 |
Dyrcona |
I was thinking of just checking it out and git rm but that's not thorough enough. |
| 13:23 |
Dyrcona |
Does cherry-pick have an -i options like add and rebase? |
| 13:23 |
Dyrcona |
Apparently not. |
| 13:25 |
Dyrcona |
There are a lot of customizations that I could drop in the interest of space. The files have been rm'd but the commit are still there. |
| 13:26 |
* Dyrcona |
creates a new branch to rewrite history, but I think I'll keep the old branch around, though the history is there in other branches as well. |
| 13:30 |
Dyrcona |
Ooh. git filter-branch looks like fun and very dangerous. |
| 13:35 |
Dyrcona |
Hm. Instead of dropping a pile of things that are later deleted. I could just fixup all those commits and they'll magically disappear in the end.... |
| 13:37 |
Dyrcona |
Hm. I should think about this and plan it out rather than just jumping in. There are so many ways to get what I want. |
| 13:37 |
Dyrcona |
I could reorder commits and use fixup to make things disappear. I could drop commits. |
| 13:38 |
Dyrcona |
I should probably make two or three passes: 1 to remove ecard and another to remove our obsolete custom domain stuff. |
| 13:38 |
Dyrcona |
Right ecard first. |
| 13:46 |
Dyrcona |
oh. git add -i changed at some point recently. `git add -e {file}` now does what git add -i used to do. |
| 13:55 |
* Dyrcona |
hates to leave in the middle of a large, interactive rebase, but tha's life. |
| 13:55 |
Dyrcona |
catch you all later. |
| 14:54 |
|
Dyrcona joined #evergreen |
| 14:56 |
Dyrcona |
Well, I managed to botch it the first time and couldn't abort the rebase: fatal: could not move back to a21ab16fb91f7f0109e2a56c4c481cfbad210284. |
| 14:56 |
csharp_ |
oof |
| 14:56 |
csharp_ |
I've never seen that before |
| 14:56 |
Dyrcona |
I basically just committed what I had, rebased and resolved conflicts until it was done, switched branches, deleted the botched one, and started over. |
| 14:58 |
Dyrcona |
I'll explain how I got there: I did the `git rebase -i [commit before my first customization commit]`. |
| 14:58 |
Dyrcona |
I edited the instructions to edit the first commit and drop a bunch of other related to the eCard stuff. |
| 14:59 |
Dyrcona |
While editing the first commit, I did `git checkout HEAD^` so I could remove and edit files before committing. (If you ever want to split a commit you do this for that also.) |
| 15:00 |
Dyrcona |
While messing with stuff I did a `git checkout HEAD -- [somefile]`, but I didn't want to do that I discovered a few minutes later, and I sort of panicked under time pressure, so I didn't think of checking it out from the custom branch. |
| 15:00 |
Dyrcona |
I tried to abort the rebase and got that message. |
| 15:01 |
Dyrcona |
Anyway, it's all fixed now. I have a customization branch based on main with the community eCard/eRenew code minus the links in the OPAC templates. |
| 15:01 |
csharp_ |
Dyrcona++ |
| 15:02 |
Dyrcona |
Not sure how useful this branch will be, but it was an interesting exercise. There were conflicts that I wouldn't have expected when things were added or removed. |
| 15:04 |
Dyrcona |
Like in the fm_IDL.xml. I would have thought that since I deliberately put our custom report sources at the bottom that git could have figured out the new entries, but no. I had to resolve that by keeping everything. |
| 15:07 |
Dyrcona |
"Don't panic." True words of wisdom. |
| 15:09 |
Dyrcona |
And, that's what I get for "rushing" a large rebase near the end of the day/work week. We're closing....8 minutes ago, and I'm off the rest of the week. |
| 15:09 |
Dyrcona |
Happy Thanksgiving to those who celebrate it, and happy rest of the week/weekend to everyone! |
| 17:03 |
|
mmorgan left #evergreen |
