**** BEGIN LOGGING AT Sat May 14 02:59:58 2016 May 14 08:36:22 asl ? May 14 08:58:25 ayjay: sorry for not having looked at it yet, some stuff stole my priority, but I'll try to take a quick look at your code when I find a moment May 14 08:58:39 it's alright i'm chugging along May 14 09:01:21 .swp ? vim swapfile ? that doesn't belong in .gitignore since those are files specific to the editor you use (vim) and its config (mine uses /var/vim) May 14 09:01:30 you can put such ignore rules in .git/info/exclude though May 14 09:01:48 those are local to your working dir May 14 09:01:55 sure May 14 09:02:14 i'll actually change the config May 14 09:03:06 what are .pyc files? May 14 09:03:52 compiled py files May 14 09:04:04 i mean i basically excluded anything that wasn't relevant source May 14 09:04:23 i figured that anything that wasn't source code didn't need to be on the repo May 14 09:04:39 true, I was more wondering when they are generated since I don't see them May 14 09:04:47 well May 14 09:04:50 I do have them May 14 09:04:53 inside __pycache__ May 14 09:04:56 but that's already ignored May 14 09:05:09 yeah i just git statused, saw it, and added it to .ignore May 14 09:05:18 pycache was there too May 14 09:06:55 passing -q to dtc is something I already committed 2 days ago :) May 14 09:07:18 yeah i didn't even do that... i think i checked out ur update May 14 09:07:31 and then somehow when i pushed it to mine, and then made a pull request, May 14 09:07:36 i was look at that like "what...." May 14 09:07:44 because i haven't touched ur make file May 14 09:08:03 my git skills are pretty raw but basically i just git add, commit, push to my repo May 14 09:08:09 and i diff with ur repo and checkout if you've updated anything May 14 09:08:24 that's the problem then, since that made it your own changes May 14 09:08:34 you could have merged (default) or rebased May 14 09:08:37 *should May 14 09:08:57 how can i avoid overwriting my own changes? May 14 09:09:14 they're not overwritten May 14 09:09:45 when you pull or rebase, if git can't automatically merge changes it'll ask you for assistance May 14 09:10:04 okay so if i've made local changes and i rebase, it'll see a conflict and ask? May 14 09:10:14 because i was concerned i'd lose work May 14 09:10:25 if you committed, you won't lose work May 14 09:10:54 even if the merge/rebase goes horribly wrong, you can revert to the state your repo was in before attempting it May 14 09:11:48 thats true May 14 09:11:57 ill give it a shot May 14 09:12:02 the difference between merge and rebase btw is that rebase basically "ports" your commits to the new upstream head May 14 09:12:03 and hope i don't end up down the rabbits hole May 14 09:12:21 so instead of being commits on top of my old stuff they'd be commits on top of my new stuff May 14 09:12:33 oh that sounds like what i want May 14 09:13:16 rebase is however slightly frowned upon since it effectively rewrites history. but at the same time if you're not maintaining a branch but just preparing some patches then rebase is quite fine May 14 09:13:37 it's also often used in smaller groups of developers because it yields a cleaner revision log May 14 09:14:23 however rebasing is a bad idea if you have people "downstream", i.e. if others have forked your repo May 14 09:15:47 I suggest practicing on a separate branch btw May 14 09:17:20 yeah i really try not to experiment much May 14 09:17:42 you can experiment quite freely as long as your stuff is committed or stashed May 14 09:17:43 but if i start a different branch then i guess its not a big deal May 14 09:17:54 a branch makes things even easier indeed May 14 09:17:59 i've honestly managed to really get myself tangeld up May 14 09:18:12 hehe May 14 09:18:37 i have two chains of actions: status/add/commit/push and /diff/checkout now /diff/rebase May 14 09:19:02 checking out individual files is something you almost never want May 14 09:19:28 it seemed like a hack May 14 09:21:16 and you can fix your own history with "git rebase -i" followed by the first revision where you want to start rewriting history (it'll open up an editor with more explanation) ... e.g. git rebase -i HEAD^^ lets you fix up the last two commits May 14 09:21:51 (e.g. combine them into one commit with a new message) May 14 09:22:04 careful though, it's a powerful tool :) May 14 09:22:31 but keep in mind that you can locally play all you want... May 14 09:22:36 i'm not sure what that does yet, but i have made a ton of pushes to my own fork May 14 09:22:42 that's true too May 14 09:22:47 commits you mean? May 14 09:23:01 i mean i don't commit without pushing May 14 09:23:07 i meant to my online repo May 14 09:23:35 well if you're going to do experiments it makes more sense to *not* push of course :) May 14 09:23:41 haha yeah May 14 09:24:01 if i mess soemthing up locally can i rebase my own remote? May 14 09:25:31 well if your last known good is in github, you can either throw away your experiment and clone it freshly, or you can just forcibly set your local branch to the one of github May 14 09:26:24 the latter would be e.g. git reset --hard origin/master (while on branch master) May 14 09:27:05 ah cool, because that's the best way i think May 14 09:27:06 git also keeps some history (iirc 14 days or so by default) of how your branches have changed May 14 09:27:11 that's called reflog May 14 09:27:28 so you can even still find some branch you deleted yesterday May 14 09:29:32 ah, 30 days actually May 14 09:32:29 a recipe for cleaning up your changeset: make a new branch "git branch foo" May 14 09:32:45 then "git rebase -i c1304b0d98" .. that's the id of the first of your commits May 14 09:34:27 so i kinda still have to read about the rebase command May 14 09:34:39 i'm not really sure what it does May 14 09:34:41 rebase and rebase -i are very different May 14 09:34:50 and rebase -i pops up vim with instructions and explanation May 14 09:35:17 rebase -i lets you edit a range of commits May 14 09:36:08 you can reorder them, drop commits (e.g. the pointless "test"), combine two commits into one (e.g. if the first one had a typo and the second one fixes that) May 14 09:36:14 change commit messages May 14 09:36:49 it's actually quite self-explanatory once you start it... it gives guidance every step of the way May 14 09:37:39 oh it lets you change history May 14 09:37:46 this doesn't yet let you fix the issue of having commited my changes as your own, but that's next May 14 09:37:49 yes May 14 09:37:50 haha May 14 09:38:05 i think tho that we're early enough in the project that these things will all get washed? May 14 09:38:18 well these are just your things May 14 09:38:29 you don't have anyone downstream probably May 14 09:38:45 i'm not sure i'd want anyone downstream May 14 09:39:18 the project isn't very well defined at this point tho... May 14 09:40:02 otoh I have you downstream, so I shouldn't use rebase to change things I've already pushed, since if I did that you're going to have complicated problems to solve May 14 09:40:29 I can rebase all I want of course as long as I haven't pushed yet and noone's seen my new commits yet May 14 09:40:37 as long as I need the *published* history intact May 14 09:40:44 *keep May 14 09:42:00 but for example it happens often that I commit something, realize I made a silly mistake, fix it and then "amend" the commit May 14 09:43:20 according to this flowchart, you should not use "rebase -i" to rewrite history if have enough people downstream to form a lynch mob -> http://justinhileman.info/article/git-pretty/full/ ;) May 14 09:43:52 i'm really unfamiliar with git's algorithm May 14 09:44:04 usually it does the right thing May 14 09:44:05 it's like this amazing new world May 14 09:44:44 vim is giving me badhabits. i keep on hitting escape before i do use any shortcut keys May 14 09:44:58 and now i can't write sentences, apparently May 14 09:45:06 there's even a good chance you'll be able to rebase without manually getting rid of commits you made with changes from my repo May 14 09:45:13 i'll be on irc typing out something to you and then "ESC /j #pythong" May 14 09:45:57 alright let me take a look at it May 14 09:46:07 rebase -i May 14 09:46:21 followed by the start of the range of commits you want to change May 14 09:46:41 you can grab a commit id from the log May 14 09:48:30 interesting May 14 09:49:01 that's easiest in this case sice it's quite a few commits... if you just want to alter the last three commits you can just write HEAD^^ to indicate "the version two commits ago" May 14 09:49:47 so wait wait if you rebase -i and you quit without doing anything then nothing happens May 14 09:50:10 and should i just delete the offending lines? May 14 09:50:38 if you delete a line, that commit will be erased from history (at least in that branch) May 14 09:51:06 read the comments git will have given you :P May 14 09:52:23 i mea what does it mean to delete a commit? May 14 09:52:34 will it change physical files or it will just change the written history May 14 09:53:16 the effects of that commit are also gone.. you're rewriting the branch to pretend the commit never happened May 14 09:53:47 though again, it's not truly lost yet right away of course due to reflogs and such May 14 09:54:05 right but, what if there are changes that depend on those changes May 14 09:54:57 then it probably didn't make sense to remove the first changes but not changes dependent on them? depends also on what you mean by "depend" May 14 09:55:20 worst case you get dropped into a shell with an explanation of the conflict and need to resolve it manually May 14 09:55:21 so correcting the history could be very inconvenient May 14 09:56:11 well you should think a bit about what exactly you're doing May 14 09:56:34 but for example commits "for sanity" and "just ignoring swap files" could be merged into one commit May 14 09:57:10 that would get rid of the incorrect "for sanity" commit without creating a conflict May 14 09:57:46 you can also edit the commit that introduced the typo into adc.dtsi May 14 09:58:23 and then drop the later commit which "fixed it" (it actually just replaced one typo by a different one, lol) May 14 09:59:49 but, if you wish, an alternative would be to "replay" your commit sequence manually (but this time without the mistakes) May 14 10:00:15 okay i'm getting the sense that commits are a bigger deal than i thought May 14 10:00:24 i.e. start with a new branch with the same starting point as you did before May 14 10:01:43 make a nice clean commit... you can e.g. check out some files from your old branch (this is a rare occasion where it's actually appropriate :P ), fix anything that needs fixing, and commit May 14 10:03:01 well i think the first method you suggested work May 14 10:03:25 i did the interactive rebase, eliminated the commit "updating with zmatts" or w/e, and then rebased May 14 10:03:46 it rewound my other commits, rebased, and the reapplied my commits May 14 10:03:57 chances are the rebase would have worked even if you didn't eliminate that commit... rebase is fairly clever about detecting duplicate patches May 14 10:04:21 i.e. it would have silently dropped your repetition of my patches automatically May 14 10:04:59 ok I really need to try to get one or two hours of sleep or so May 14 10:05:09 haha well at least we talked about git May 14 10:05:09 bbl **** ENDING LOGGING AT Sun May 15 02:59:58 2016