| Time |
S |
Nick |
Message |
| 08:39 |
|
|
rruma1 joined #sourcefu |
| 10:52 |
|
pdurbin |
heh. http://harmful.cat-v.org/software/_java/problem-factory.jpg via http://harmful.cat-v.org/software/java via ironcamel at https://plus.google.com/102499719144563443986/posts/Wh3v1EFzbfP |
| 14:20 |
|
pdurbin |
ironcamel: I'm glad to hear you say you like Java. I'm enjoying it too :) |
| 16:02 |
|
pdurbin |
"Alas... software developers are generally not interested in spinning narratives or crafting metaphorical microworlds. Of course, many programmers are interested in designing intuitive, self-consistent language in their tools. This would be awesome if they didn’t suck at it so very badly. In the case of git, it’s original creator, Linus Torvalds, appears to have demonstrated the classic negligence of an anti-design geek who has no time for wor |
| 16:03 |
|
pdurbin |
wordsmithing." -- https://ventrellathing.wordpress.com/2013/01/25/git-a-nightmare-of-mixed-metaphors/ |
| 16:49 |
|
semiosis |
did anyone here learn to use a VCS in school? i didn't. |
| 16:56 |
|
pdurbin |
ha! |
| 16:58 |
|
ironcamel |
learning vcs in school seems like a waste of time |
| 16:59 |
|
ironcamel |
tools like vcs are "learnable" |
| 17:01 |
|
ironcamel |
"Because the obscure language and cryptic behavior of git is impossible to remember, unless you use it every day." I agree with that. But that may be just that dvcs is complicated, it's not necessarily the fault of git. |
| 17:04 |
|
ironcamel |
the funny thing is, when I create command line tools, i model the interface after git |
| 17:04 |
|
ironcamel |
i like the program noun verb arguments ... |
| 17:04 |
|
ironcamel |
git remote add foo .... |
| 17:09 |
|
pdurbin |
yeah but git is picky about the order of flags to arguments |
| 17:24 |
|
ironcamel |
you mean you have to do git checkout -b foo, not git -b foo checkout ? |
| 17:25 |
|
pdurbin |
not specifically but yeah :) |
| 17:29 |
|
ironcamel |
in that case, it seems reasonable to enforce that order |
| 17:33 |
|
pdurbin |
git -b foo checkout is a little silly :) |
| 17:43 |
|
pdurbin |
speaking of git, I'm looking at this right now: http://stackoverflow.com/questions/449541/how-do-you-merge-selective-files-with-git-merge |
| 17:45 |
|
pdurbin |
as I've described at http://dvn.github.com/dvn-sourceforge2github/dvn-dev-on-github/quickstart/ I've branched "2656-lucene" from "develop" and I'm periodically merging in changes from "develop" by checking out 2656-lucene and running `git merge develop` |
| 17:46 |
|
pdurbin |
but now... I don't want to run `git merge develop` because if I do I'll lose the jars I need on 2656-lucene (lucene-core-3.5.0.jar and lucene-facet-3.5.0.jar) which you can see at http://danceb.in/hDzMRMyM4hGEhMzl9DNYg |
| 17:47 |
|
pdurbin |
so I ran `git merge --abort` and I'm thinking about either |
| 17:47 |
|
pdurbin |
1. not trying to keep up with "develop" for a while |
| 17:48 |
|
pdurbin |
2. trying to merge in all the changes from "develop" except changes to those lucene jars |
| 17:48 |
|
pdurbin |
option 1 is easier but I'm curious about the best way to do option 2 |
| 17:54 |
|
ironcamel |
how many commits are being merged |
| 17:54 |
|
ironcamel |
the only way i can think of to do that is cherry pick the commits you want/need |
| 17:55 |
|
pdurbin |
trying to figure out how to see that |
| 17:55 |
|
pdurbin |
how many commits |
| 17:56 |
|
ironcamel |
git log branch1 > foo; git log branch2 > bar; then vim both files and count the commits ... there are probably much better ways than that |
| 17:56 |
|
pdurbin |
heh |
| 17:56 |
|
pdurbin |
I'm looking at http://stackoverflow.com/questions/1710894/using-git-show-all-commits-that-are-in-one-branch-but-not-the-others |
| 17:57 |
|
ironcamel |
cool, the first answer mentions cherry-pick as an option |
| 17:57 |
|
pdurbin |
this seems to show it: git log develop ^2656-lucene --no-merges |
| 17:58 |
|
ironcamel |
the second option is cool too, but then your branches get out of sync, or "more" out of sync |
| 17:58 |
|
pdurbin |
hmm, well i did make the change to the jars in a single commit on the develop branch... |
| 17:59 |
|
pdurbin |
... so maybe that means i can cherry pick all but that commit somehow |
| 18:00 |
|
ironcamel |
that's pretty straightforward |
| 18:02 |
|
pdurbin |
yeah, decent write up at http://feeding.cloud.geek.nz/posts/cherry-picking-range-of-git-commits/ it seems |
| 18:03 |
|
pdurbin |
joe shaw · cherry picking a range of commits - http://www.joeshaw.org/2010/06/22/667/ |
| 18:08 |
|
ironcamel |
oh cool, i didn't know you could do that |
| 18:09 |
|
pdurbin |
cherry pick a range? yeah. as of 1.7 apparently |
| 18:10 |
|
ironcamel |
looks like i have 1.8 |
| 18:10 |
|
pdurbin |
i'd better merge this stuff in now before i go on... |
| 18:11 |
|
pdurbin |
so in http://danceb.in/hDzMRMyM4hGEhMzl9DNYg I did a `git pull` and I can see all the files that were changed, but I could have done a `git fetch` and then a... `git diff`? to see the same output, right? |
| 18:12 |
|
pdurbin |
actually, i guess what I want to see are the conflicts... |
| 18:12 |
|
pdurbin |
meh, i guess i can just do what I did... git pull .. then git merge ... and look at the conflicts |
| 18:13 |
|
pdurbin |
because basically if there are no conflics i'll just merge them in |
| 18:13 |
|
pdurbin |
i just need to be careful not to pull in the change to those lucene jars |
| 18:14 |
|
pdurbin |
(not that the lucene jar thing is a conflict... but i do need those updated jars in my branch) |
| 19:03 |
|
pdurbin |
here are the commits that have been made to "develop" that I want to merge (except 52067238) into "2656-lucene": http://danceb.in/wgwBJNeM4hGz9aO4l9DNYg |
| 19:03 |
|
pdurbin |
I went ahead and ran `git cherry-pick 4331e1e` to grab the oldest commit, the one before the change to the lucene jars I want to avoid |
| 19:05 |
|
pdurbin |
but git cherry pick makes a new commit... it's the same commit... so when comparing commits between the two branches again, it's not like the commit I cherry picked is gone from the list... |
| 19:05 |
|
pdurbin |
it's still a difference, I mean |
| 19:06 |
|
pdurbin |
I guess what I was hoping for... is that the list of differences would get smaller and smaller as I cherry pick commits from "develop" and put them on "2656-lucene" |
| 19:07 |
|
pdurbin |
sort of like marking at email as read, I guess :) |
| 19:07 |
|
pdurbin |
or crossing out an item on a todo list |
| 19:08 |
|
pdurbin |
it just seems like maybe I've started down a path of manually keeping track of specific commits, which is a pain |
| 19:47 |
|
* pdurbin |
asks the guys in #git: http://colabti.org/irclogger/irclogger_log/git?date=2013-03-14#l3600 |
| 20:30 |
|
pdurbin |
in the end I backed out of the cherry pick and went for a straight merge |
| 20:31 |
|
pdurbin |
and added the jars I need to .gitignore |
| 20:31 |
|
pdurbin |
i just need to remember to remove them from .gitignore before I merge back to develop some day |
| 21:14 |
|
pdurbin |
it's interesting to me how some of these git features like rebase and cherry-pick are talked up so much... but you should only use them in specific circumstances. good old merge is working fine for me in general |
| 23:09 |
|
semiosis |
same here |
