IRCloggy #git 2021-11-04

Provider of IRC logs since 2005.

WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

	2021-11-04
	← pyeveryt_ left	00:01
	← durham left	00:03
	→ durham joined	00:04
	→ engest joined	00:05
	→ travaldo joined	00:06
	→ zebrag joined	00:07
	← durham left	00:08
	→ Xenguy joined	00:12
	→ brianward joined	00:19
	← Lord_of_Life left	00:22
	→ Lord_of_Life joined	00:22
	→ DoofusCanadensis joined	00:25
	→ causasui joined	00:29
	→ Celelibi joined	00:32
	← causasui left	00:35
	→ bodiccea_ joined	00:39
	← palasso left	00:46
Linkandzelda	rawtaz: not sure if you remember our discussion from the othr day, but I found the single repo to be quite a problem. the wiki content being branched off causes serious inconsistent issues across different feature branches, and while its supposed to be the only source of truth it ends up having no source of truth in that situation. so looks like its multiple repos for me :)	00:49
	← orbyt left	00:49
	← haritz left	00:49
	→ durham joined	00:50
lantech19446	Linkandzelda: I only have 2 branches one for testing changes and one for production and I find it difficult to keep them in sync even using pull requests and merging them somehow one of them is always behind	00:54
rawtaz	Linkandzelda: ok, i cant really get the picture because i dont know your contents etc. not sure why git branches would be a problem at all, but perhaps youre meaning something else when you say "branched off"	00:55
	← durham left	00:55
rawtaz	lantech19446: why is that? one should be your main branch, the other where e.g. dev and testing happens (ideally you'd have testing and dev as separate branches). or you run dev on main.	00:56
	regardless, do stuff on one and when it's done move the other one up to date with it. as long as one of the two branches only moves in one direction it should be fine	00:56
Linkandzelda	rawtaz: i mean, say in current master I wrote something about the project direction in the wiki. then created a branch for feature X. then wrote in the wiki in master and in feature X. maybe its my bad management but, this created already an inconsistency in documentation. since the project is supposed to evolve, i have to make sure the master has the most up tp date wiki contents. am i mismanaging	00:56
	it?	00:56
lantech19446	rawtaz: I do but somehow even though I pull into my test branch before i do anything it always winds up behind somehow.	00:57
	→ odoood__ joined	00:57
	← odoood__ left	00:57
rawtaz	Linkandzelda: if you do what you said, then youll have changes in both master and featureX branches, right? if those two changes do not conflict with each other, you can merge featureX into master. if they do conflict you can still merge featureX into master but must resolve the conflict as part of the merge, thats normal.	00:58
	Linkandzelda: so use master as the branch that you push finished things into - i.e. master only moves in one direction, forward	00:58
lantech19446	honestly i'm sure it's a me issue and not a git issue, i think git is fantastic and I just deal with it and follow what the errors tell me to do to correct it.	00:58
	← arcatech_ left	00:59
rawtaz	lantech19446: not entirely sure how you mean by the feature branch being behind :D what i do is have my feature branches and before i merge them into master i just rebase them onto lastest master. and i do the same whenever i want the feature branch to have whatever happened in master since last time i kept the feature brach up to date with master. i think that might be waht youre talking about, changes in master making the feature out of date?	01:00
Linkandzelda	lantech19446: good practice i'd say is to have master be the last good verified working version. then you dont need production branch, unless you want to make double sure that production = whats in production. but thats just as easy as saying master is whats in production right now. if that makes sense? not sure, maybe it doesnt work for you	01:00
lantech19446	that's what i'm doing now a testing branch and master is prod	01:00
rawtaz	lantech19446: sooner or later it will start clicking into place, keep having at it and dont be afraid to mess around. you always have the `git reflog` to see your recent commits (that you screwed up lol)	01:00
	← sebastorama left	01:01
	→ haritz joined	01:01
	← haritz left	01:01
	→ haritz joined	01:01
	→ gregraubie joined	01:02
	← CaCode_ left	01:02
	← The_Jag left	01:02
	→ pmcnabb9 joined	01:03
Linkandzelda	rawtaz: the problem isnt about merging them back, its more like not seeing the content of the wiki in full at one moment. sure, it can be merged back, but only when feature X is done and verified. if all i added in the wiki is stuff about feature X then thats ok but often times they are cross-references to other features or parts of the project. its not possible to merge only certain commits back to	01:03
	master, or is it?	01:03
	→ causasui joined	01:05
rawtaz	Linkandzelda: if you have feature branch X and since you created it and did some changes in X there was also changes made in branch master, then all you need to do to see all that is in master is to rebase the branch X onto master (or you can merge master into X, personally i find that much uglier though, i rebase instead). then X will have whatever is in master as well as your changes in X.	01:05
	the only thing then that you wont see is other branches (unless you also merge those into X, but then it starts becoming messy)	01:05
	← gregraubie left	01:05
rawtaz	that said i still dont really get why you need to do so much branching just for a wiki. what's wrong with someone editing a page and that creating a commit directly on master?	01:06
	← ninjin left	01:06
	→ ninjin joined	01:06
	← jonosterman left	01:07
Linkandzelda	rawtaz: thats what im thinking, to have a constant work tree for master and use that to work with the wiki directly on master and only branch-specific stuff in feature branches to keep it clearer. though the wiki is just a part of the project. the project itself will be what creates the branches and the features	01:07
rawtaz	regarding that "seeing it all" thing, i think master is the only thing you need to consider being "all", because other feature nbranches that others are working on should not be considered finalized. so all you need to get into "seeing it all" is your feature branch and master.	01:08
	sure. sounds good. should work fine with feature branches, thats what everyone does daily	01:08
	← pmcnabb9 left	01:08
	→ jonosterman joined	01:08
rawtaz	you just need to get into rebasing them on master when you want the stuff in master to be in the feature branch too, it's that simple	01:08
Linkandzelda	yes thats what i was gonna say. i dont want to see half baked documentation on feature Z in master when thats not even merged into master	01:08
rawtaz	(or merge, if you prefer that extra cruft in your history - totally pointless in normal settings IMO, can be relevant in certain bigger projects)	01:09
	exactly	01:09
Linkandzelda	rawtaz: ok, i think im not up to speed on the true uses of rebasing. i know it and have done it but i dont do it often enough to say "yea, that will solve the issue"	01:11
	← causasui left	01:12
rawtaz	better fiddle with it a bit then, it's really not complicated at all	01:12
	especially if you do interactive rebase, that is the `git rebase -i` command	01:12
	oh wait, never mind that. forget the interactive when it's about rebasing onto master.	01:13
	i mixed things up there	01:13
	but i can tell you that there's very nice explanations with ascii art in `git help rebase`, they really show what to type if you want to e.g. rebase feature X on master, so just look there	01:13
	← nehsou^ left	01:14
	→ matthewcroughan_ joined	01:15
mackerman	Regarding not being able to see everything, note that the tree does have everything at the point it branches, plus the commits unique to this branch.	01:15
	So you can read "old" files without switching.	01:15
	← imp left	01:15
	← matthewcroughan left	01:15
rawtaz	yeah. its just that they also want to see new commits that popped up on master	01:16
	but it's very true that they'll see what was on master at the time they created the feature branch, along with the changes they made to the feature branch	01:16
	← engest left	01:16
	→ Xenguy_ joined	01:17
	← alzgh left	01:17
	→ engest joined	01:17
	→ rgrinberg joined	01:18
	→ AABUWF joined	01:19
	← Xenguy left	01:20
	← pulse left	01:21
Linkandzelda	yes true indeed, reading old stuff won't be an issue. looks like i'll be doing a lot of rebasing to bring things in line on related feature branches. will check out the help too to gain a better understanding of rebasing	01:22
	← mfiano left	01:24
	→ nrl^ joined	01:24
	→ ttree joined	01:25
rawtaz	also git stash and git stash pop are nice to know about	01:26
	→ pulse joined	01:27
	← epolanski left	01:27
rawtaz	bedtime, nite	01:27
	rawtaz &	01:27
Linkandzelda	cheers	01:29
	→ imp joined	01:34
	← Raguile left	01:42
	Xenguy_ → Xenguy	01:43
	→ causasui joined	01:44
	← tmz left	01:44
	← causasui left	01:48
	← dermoth left	01:53
	→ BSaboia joined	01:59
	← ChmEarl left	02:09
	→ dermoth joined	02:10
	← engest left	02:14
	← perrierjouet left	02:17
	→ causasui joined	02:19
	← causasui left	02:24
	← AsenMx left	02:26
	→ hololeap_ joined	02:32
	← BSaboia left	02:32
	← hololeap left	02:33
	→ durham joined	02:43
	← durham left	02:45
	→ durham joined	02:45
	← brianward left	02:46
	← causa_sui left	02:46
	← imp left	02:50
	← durham left	02:50
	← Yruama left	02:56
	→ causasui joined	02:58
	→ Raguile joined	02:59
	→ arcatech joined	02:59
	→ tmz joined	02:59
	← travaldo left	03:02
	← causasui left	03:02
	← arcatech left	03:03
	← cdown left	03:12
	← Strom left	03:13
	→ Strom joined	03:15
	→ engest joined	03:19
	→ gast0n joined	03:29
	← igemnace left	03:29
	→ arcatech joined	03:31
	→ causasui joined	03:32
	← causasui left	03:40
	← FinnElija left	03:42
	→ finn_elija joined	03:42
	finn_elija → FinnElija	03:42
	→ igemnace joined	03:42
	← DoofusCanadensis left	03:47
	→ saroy joined	03:55
	← Xenguy left	03:59
	← rkta left	04:03
	→ rkta joined	04:03
	← Portugol9 left	04:06
	→ Portugol9 joined	04:08
	→ nightstrike joined	04:18
	← arcatech left	04:18
	← skapata left	04:18
	→ tirnanog joined	04:21
	→ arcatech joined	04:23
	← arcatech left	04:33
	→ pyevery__ joined	04:34
foo	Is there a way to pull all branches from a specific remote repo?	04:35
	I have two repos, a dev repo and production repo. And when I pull from product (default upstream) I can't seem to easily be able to pull all branches from dev repo?	04:35
	→ arcatech joined	04:37
	← arcatech left	04:43
	jazzy2 → jazzy	04:49
	→ causasui joined	04:49
	← gast0n left	04:51
	← causasui left	04:54
	→ Guest50 joined	05:00
	→ cads joined	05:00
Guest50	test	05:01
	← pulse left	05:04
	← vishal left	05:05
	← nattiestnate left	05:09
	→ vishal joined	05:09
	→ nattiestnate joined	05:10
	← engest left	05:10
	← rgrinberg left	05:11
	← pyevery__ left	05:19
	← Xaldafax left	05:20
	→ pyeveryt_ joined	05:20
	← nattiestnate left	05:22
	← remyabel left	05:24
	← pyeveryt_ left	05:28
	→ remyabel joined	05:31
	← betelgeuse left	05:36
	→ betelgeuse joined	05:37
	→ mei joined	05:39
	← emf_ left	05:39
	← Guest50 left	05:45
	← mei left	05:45
	← kevr left	05:47
	→ The_Blode joined	05:48
	→ kevr joined	05:49
	← shailangsa left	05:53
	← GNUmoon left	05:57
	→ alzgh joined	05:57
foo	There isn't a way to push to two remote repos when I do git push is there?	05:59
ikke	no, there is not	06:00
	→ pyevery__ joined	06:04
remyabel	git remote \| xargs -L1 git push --all	06:05
	← mannequin left	06:11
	← Raguile left	06:13
	← zebrag left	06:17
	→ shailangsa joined	06:18
	← pyevery__ left	06:19
	← jetchisel left	06:27
	→ jetchisel joined	06:28
	← ttree left	06:30
	→ causasui joined	06:30
	→ ttree joined	06:31
	← hbautista_ left	06:33
	→ pretty_dumm_guy joined	06:33
	→ CaCode_ joined	06:34
	← causasui left	06:35
	→ pyeveryt_ joined	06:47
	→ mfiano joined	06:54
	→ kenanmarasli joined	06:58
	→ CaCode joined	06:59
	← pyeveryt_ left	06:59
	← jimklimov left	07:00
	← mfiano left	07:01
	← CaCode_ left	07:02
	← unluckyshrubbery left	07:04
	→ steam joined	07:05
	→ vdamewood joined	07:06
	← Dragnslcr left	07:08
	→ Dragnslcr joined	07:08
	→ jimklimov joined	07:11
	← bloody left	07:11
	← igemnace left	07:11
	← saroy left	07:17
	← wolfdale left	07:20
	← CaCode left	07:22
	→ CaCode joined	07:22
	→ igemnace joined	07:24
	→ otisolsen70 joined	07:25
	← ninjin left	07:31
	← steam left	07:33
	→ steam joined	07:34
bookworm	hm? You can just add a push url in addition to the existing upstream no ikke ? git remote set-url --add --push [...]	07:34
	so why, "no there's not"?	07:35
	→ ninjin joined	07:36
	← thiago left	07:36
	→ GNUmoon joined	07:42
	← jonosterman left	07:43
	→ lgc joined	07:43
	→ jonosterman joined	07:44
	→ causasui joined	07:48
	← steam left	07:52
	→ palasso joined	07:52
	← causasui left	07:53
	→ steam joined	07:53
	← rahl left	07:57
	← CaCode left	07:57
	→ rahl joined	07:58
	→ BenjiProd joined	07:59
	→ rfuentess joined	08:00
	→ jazzy3 joined	08:02
	← jazzy left	08:02
	jazzy3 → jazzy	08:03
	← crabbedhaloablut left	08:05
	pah_ → pa	08:06
	← pa left	08:06
	→ pa joined	08:06
	→ crabbedhaloablut joined	08:06
	← cmbengue left	08:12
	← mat001_ left	08:13
	→ wolfdale joined	08:17
	→ theoceaniscool joined	08:20
	→ vladoski joined	08:21
	→ nad joined	08:25
	← jazzy left	08:25
Samian	Is this a bad commit message? Replace #include "autograd/custom_function.h" which breaks build.	08:25
	I replaced it with #include <torch/csrc/autograd/custom_function.h>	08:26
	maybe I should have wrote "Fix bad include bad."	08:26
	anyone's thoughts?	08:26
[twisti]	i would have written "Replace incorrect #include "... and left it at that	08:29
	'fix bad' is generally not very helpful, and 'breaks build' is not relevant information - if the include was wrong, it doesnt really matter where that wrongness was noticed	08:29
	unless the wrong include worked on dev pcs but not in ci or something like that	08:30
rfuentess	Samian: you could go with something like the first suggestion from [twisti] and then in a new paragraph explain why it was breaking the build	08:31
	it is up to you. And "learning" to write good commits messages takes time and practice (And it will be suggestive)	08:31
Samian	the "breaks build" part is to notify the user that it's not a preferential change, or a preemptive change, but rather a necessary change because the last commit does not build	08:32
	if that's not clear, then I didn't accomplish communicating what I hoped to	08:33
	← nad left	08:33
Samian	[twisti] is ny point persuasive at all? or you're not buying any of it?	08:34
[twisti]	no, i suppose thats fair	08:35
	→ Nod0n[m] joined	08:39
Nod0n[m]	Hi, I do have a git repo which shows error: file write error: Input/output error fatal: unable to write loose object file	08:40
	What can I do? It has multiple branches and it has a remote pointing to gitlab.	08:41
[twisti]	Nod0n[m]: hdd full ? permission problem ?	08:42
Nod0n[m]	Oh it was something wired with vscode. I noticed now, I was in some fuse what ever and started it again and now everything works.	08:44
	→ dcpc007 joined	08:44
Nod0n[m]	(I was using the terminal inside of vs code)	08:44
	← sudoforge left	08:48
	→ saroy joined	08:56
	← reset left	08:57
	← ttree left	08:57
	→ Xavier7 joined	08:58
	← cads left	09:03
	→ Ilyu joined	09:05
	← Betal left	09:07
	← Xavier7 left	09:09
	→ unluckyshrubbery joined	09:10
	→ dimi1947 joined	09:11
	→ Xavier7 joined	09:13
	→ ath28 joined	09:14
	← The_Blode left	09:15
	→ dimi__ joined	09:16
	← dimi1947 left	09:17
	→ perrierjouet joined	09:17
	→ The_Blode joined	09:18
	← ath28 left	09:19
	← jonosterman left	09:22
	→ jonosterman joined	09:22
Timvde	Does anyone know a tool that implements both a side by side diff and --color-moved? (and preferably also --color-moved-ws=ignore-all-space)	09:23
	→ Gaboradon joined	09:26
	→ mannequin joined	09:26
	→ daoudr joined	09:33
	← Arsen left	09:35
	→ Arsen joined	09:35
ikke	I'm not sure if it does the latter, but did you look at delta?	09:36
	← dimi__ left	09:40
Timvde	I have heard about it, but I don't use it... Let me check!	09:40
	→ dimi1947 joined	09:40
	← webmariner left	09:40
	← Xavier7 left	09:40
	→ Xavier7 joined	09:41
	← Xavier7 left	09:42
	→ Xavier7 joined	09:43
Timvde	ikke: Ah, nice! Setting delta --side-by-side as core.pager worked :D	09:46
	It plays well with the built-in git flags	09:47
	← Arsen left	09:50
	→ Arsen joined	09:50
	→ causasui joined	09:50
	← Arsen left	09:51
	→ Arsen joined	09:51
	→ ath28 joined	09:55
	← causasui left	09:55
	→ dimi__ joined	09:56
	← Arsen left	09:56
	← dimi1947 left	09:58
	→ dimi1947 joined	09:58
	← ath28 left	09:59
Timvde	Is there a way to pass arguments to the pager? (so I don't have to add --side-by-side to core.pager, but can add it on an as-needed basis to my git diff/show)?	10:00
	s/\?$//	10:00
	← dimi__ left	10:01
	← saroy left	10:02
	← The_Blode left	10:02
	→ The_Blode joined	10:03
	→ mexen joined	10:03
	← dimi1947 left	10:03
	← Xavier7 left	10:03
	← perrierjouet left	10:04
	→ Xavier7 joined	10:04
	→ Arsen joined	10:04
	→ perrierjouet joined	10:06
	→ RiFo joined	10:07
	→ zer0bitz joined	10:08
	→ The_Jag joined	10:14
	→ AsenMx joined	10:19
	→ vlado_ joined	10:23
	→ TJ- joined	10:23
	→ dimi1947 joined	10:24
	→ rsx joined	10:25
	← vladoski left	10:26
	→ ath28 joined	10:27
	→ computeiro joined	10:27
	← dimi1947 left	10:30
	→ dimi__ joined	10:31
	← Xavier7 left	10:33
	← vdamewood left	10:33
	→ Xavier7 joined	10:34
	→ dimi1947 joined	10:34
	← ath28 left	10:35
	← Xavier7 left	10:36
	→ Xavier7 joined	10:36
	← dimi__ left	10:36
	← The_Blode left	10:38
	→ The_Blode joined	10:40
	→ oo_miguel joined	10:42
oo_miguel	Hi, how can I check "git config" values that are not set explicitly in my .gitconfig. (e.g. [difftool "nvimdiff"])	10:45
	← Xavier7 left	10:59
	→ juliopcrj joined	11:00
	→ Xavier7 joined	11:00
	← Xavier7 left	11:01
	← TJ- left	11:02
	→ Xavier7 joined	11:02
	→ cdown joined	11:02
	→ lavos joined	11:02
	→ molten joined	11:04
	hololeap_ → hololeap	11:05
	→ TJ- joined	11:05
	→ Swahili joined	11:05
	← jetchisel left	11:06
	← molt left	11:07
	→ molt joined	11:07
	→ jetchisel joined	11:07
Swahili	Q: Worktree, I'd like to use it today. To make changes/track/commit changes,cd to the worktree <path>, correct? or is there a `git worktree` command to switch between, let's say branchA and branchB (where branchB is a `worktree add`). Thanks!	11:07
	← lavos left	11:08
osse	Timvde: only thing I can think of is an alias	11:09
	← molten left	11:09
Timvde	osse: I came to the same conclusion, thanks for confirming :)	11:09
osse	Swahili: git worktree is used to creating/removing them and such. To work in them you can just cd like normal	11:09
Swahili	osse: thank you! was just wondering ;_) thanks!	11:10
	← hololeap left	11:10
Swahili	osse: of course that if added in the parent workdir, we need to be careful not to include and commit it, or is it ignored automatically (of course not right)?	11:11
osse	Swahili: I would guess it is, but I'm not sure.	11:11
Swahili	osse: all good ;)	11:11
osse	Swahili: I prefer to have the worktrees next to eachother.	11:11
	← perrierjouet left	11:11
	→ perrierjouet joined	11:12
Swahili	osse: I'll see how I get along with it. Let's say the project is /pathnameA you'd add it to ../pathnameA-refactor-foobar?	11:12
osse	yes, exactly	11:12
Swahili	osse: fair ;)	11:12
	osse: yeh I'll do that too, sounds better	11:13
	→ aminvakil joined	11:14
	← AbleBacon left	11:15
	← vlado_ left	11:26
	→ vladoski joined	11:26
Samian	Is it safe to delete branches once they've been merged?	11:29
rawtaz	yep	11:29
Samian	thanks!	11:30
rawtaz	if theres no need to continue working on that branch, that is	11:30
	→ multi_io joined	11:30
rawtaz	if you delete it and want to "continue" working on it youll have to create a new one	11:30
	← thebombzen left	11:31
	← Hash left	11:32
multi_io	if I set "myremote/foo" to be the remote tracking branch of local branch "foo-local", why does a simple "git push foo-local" still not do the right thing? (which would be basically git push myremote foo-local:foo)	11:32
	→ thebombzen joined	11:33
multi_io	instead, I still get "fatal: The upstream branch of your current branch does not match the name of your current branch." and need to issue "git push myremote foo-local:foo" manually	11:33
BtbN	Does it work if you just git push?	11:34
	← jjakob left	11:35
	→ jjakob joined	11:36
multi_io	BtbN: nope, same error	11:36
rawtaz	multi_io: what does your config snippet for that remote tracking look like, and/or how did you set it as the remote tracking one?	11:38
	anyway if you just run git push -u yourremotename localbranchname:remotebranchname then it should work after that i think?	11:41
	there's also a config setting named push.default that might be worth looking into to know about it	11:41
	rawtaz &	11:42
ikke	s	11:43
	← AsenMx left	11:46
	← juliopcrj left	11:47
	← Ilyu left	11:56
	→ vysn joined	11:56
	← Xavier7 left	12:04
	→ Xavier7 joined	12:05
	→ rewrit3 joined	12:06
	→ otisolsen70_ joined	12:08
	→ otisolsen70__ joined	12:10
	← otisolsen70 left	12:12
	← Xavier7 left	12:12
	→ Xavier7 joined	12:13
	← otisolsen70_ left	12:13
	→ constxo joined	12:22
	→ no_gravity joined	12:24
no_gravity	I often wish a fast forward merge from branch "feature x" would mark each commit that is merged as comming from "feature x".	12:24
	So when you look at your commit history and think "in which context did this change take place" you could see it in a line like "context: feature x".	12:25
rawtaz	no_gravity: a regular merge would do that, not? (creating a merge commit with that info in it)	12:26
no_gravity	rawtaz: Yes, but that is much more cumbersome.	12:26
rawtaz	ok :)	12:27
selckin	JIRA-3: blabla	12:27
no_gravity	rawtaz: A commit is like a waypoint to me. Having a waypoint to say "the last 3 waypoints were done in the context of feature x" does not match my mental model at all.	12:27
rawtaz	no_gravity: hm interesting. what would match it? can you make a simple drawing of a history that would?	12:28
	→ constxd joined	12:28
no_gravity	rawtaz: In my model, "git log" would get a switch "--context" and then each commit would be displayed along with an extra line "context: feature x"	12:29
rawtaz	so basically you are saying that you dont want a separate/explicit commit to mark the ancestry, but instead just a note with an existing commit?	12:30
no_gravity	rawtaz: If you do "git merge featureX", then context would be set to "featureX" for all commits it merges. Or you can override it with "git merge --context=featureX".	12:30
	rawtaz: "a note with an existing commit"?	12:30
rawtaz	i see.	12:31
	← constxo left	12:31
no_gravity	rawtaz: In my model it would be another field, just like "date" or "author".	12:31
	← Xavier7 left	12:31
rawtaz	yeah	12:32
	→ Xavier7 joined	12:32
rawtaz	a more flexible version of that would be if it wasnt specifically another field named "context", but that git had a feature where on commits you can assign one or more key-value metadata entries. then you could still assign context=foo but you could also use it for other things.	12:33
	and that makes me wonder if git already has that :o	12:33
selckin	no_gravity: https://stackoverflow.com/questions/47475712/git-how-to-list-specific-trailers-footers-in-git-log-format	12:34
	!man git-interpret-trailers	12:34
gitinfo	The git man pages are available online at https://gitirc.eu/git.html. Or were you looking for the "man git-foo" syntax (without the !)?	12:34
	the git-interpret-trailers manpage is available at https://gitirc.eu/git-interpret-trailers.html	12:34
	← Xavier7 left	12:35
	→ Xavier7 joined	12:36
rawtaz	thats great. but it doesnt really match no_gravity's use case or what they want. with trailers they have to be added to each commit. no_gravity wants to be able to somehow record a key-value when doing a merge/fast-forward	12:37
no_gravity	selckin: ?	12:37
rawtaz	on each affected commit, that is	12:37
selckin	no_gravity: "13:25:25 no_gravity │ So when you look at your commit history and think "in which context did this change take place" you could see it in a line like "context: feature x"."	12:37
no_gravity	Yes	12:37
selckin	it does that	12:37
	add the metadata in your commit message	12:37
rawtaz	selckin: yes but then you have to add the trailer to every commit you make on that branch first, right?	12:37
	when you make those commits.	12:37
no_gravity	selckin: The commit message is manually written at commit time. My model adds the field at merge time.	12:37
rawtaz	or rewrite the commits before you fast-forward, to THEN add the trailer.	12:38
selckin	sure, or script it during the merge, can't invent features that don't exist	12:38
rawtaz	no, but one can suggest one, right?	12:38
selckin	sure, but i can suggest a way to do it now aswel right?	12:38
	anyway won't happen again sorry	12:38
rawtaz	yeah but its not the same thing - unless they want to or are fine with rewriting the commits of course :L)	12:39
	:)*	12:39
	meh	12:39
	→ mat001 joined	12:41
	→ GoGi joined	12:41
no_gravity	Changing the commit messages would lead straight into workflow complexity hell.	12:42
	→ vlado_ joined	12:43
no_gravity	As it changes the hash and trashes the assumption that a commit is under control of the commit author, not the one who merges.	12:43
	If an existing git feature could be abused to do it, maybe git-notes. I never used git-notes though.	12:44
rawtaz	yeah	12:44
	← Murr left	12:44
	→ Murr joined	12:45
rawtaz	(to not changing it - it's not worth it in this case)	12:45
	honestly i dont see why using merge commits is so bad. one has to adapt to tools as well at times	12:45
no_gravity	But its not only about "getting it to work somehow". But also about easy team flow. If everybody knows and expects a certain function, that is the best case.	12:45
rawtaz	yep	12:45
	← vladoski left	12:45
no_gravity	rawtaz: Haha, I am very hesitant to adapt to tools unless I consider them perfect.	12:45
rawtaz	FWIW ive been using merge commits in varoius projects and even though i dont prefer them it doesnt make much difference in the end	12:45
	yeah, the problem with that is that you never find anything thats perfect ;)	12:46
	so you waste a lot of time	12:46
	its better to find the one or two that are almost perfect and then pick the one that feels best :3	12:46
	← Xavier7 left	12:46
no_gravity	Yes, that is why my toolkit mainly consists of vim and git.	12:46
rawtaz	hah	12:47
osse	adding the field would change the hash as well	12:47
rawtaz	its you and the rest of the world :D	12:47
	→ Xavier7 joined	12:47
	→ AsenMx joined	12:47
no_gravity	rawtaz: So far I am leading :)	12:48
rawtaz	lol	12:48
	you need `stow` too though	12:48
	then its all complete	12:48
no_gravity	rawtaz: What's stow?	12:49
rawtaz	gnu stow, an awesome tool for managing e.g. your .dotfiles or whatever else you need	12:49
no_gravity	What does it do?	12:49
rawtaz	its hard to sum up in one sentence, i suggest you ddg "stow dotfiles" to find a short blog post that illustrates it	12:49
no_gravity	If it is hard to describe it in a sentence, I don't need it.	12:50
	→ gh34 joined	12:50
no_gravity	My world is simple. I use vim to edit text files and git to keep a history of them.	12:51
rawtaz	if you are not open to learning about suggestions, whatever.	12:51
no_gravity	I am open. But via communication, not via links.	12:52
osse	is it hard to describe? I thought you just did it. "managing e.g. your dotfiles"	12:52
	← mannequin left	12:52
no_gravity	Why do I need to "manage" "my dotfiles"? What are "dotfiles"? Files that start with a dot?	12:53
rawtaz	no_gravity: regardless your lack of interest shows that you want things served on a silver platter. why should i spend more time explaining stow to you when there are GREAT blog posts that are super easy to find and that clearly illustrates why its so good in a much shorter time than i could possibly even try to explain it to you? it doesnt make sense.	12:53
	that said, if you dont feel a neeed, then fine. its up to you of course, i was just trying to be helpful :)	12:53
no_gravity	rawtaz: Not only do I want things served on a silver platter, I also serve things on silver platters. That is my mode of communication.	12:54
	← _xor left	12:55
rawtaz	good for you!	12:55
	i guess there's a pattern to not wanting to adapt :-)	12:56
osse	depends on the link of course, but often a link is a silver platter	12:56
	→ komputilo joined	12:57
no_gravity	Chatting has the benefit that it is much more contextual and two-way.	12:59
	← FinnElija left	12:59
	→ _xor joined	13:00
	→ FinnElija joined	13:01
	→ ThorMojito joined	13:01
	← no_gravity left	13:03
	← Xavier7 left	13:06
	→ constxo joined	13:06
	← constxd left	13:09
	→ rgrinberg joined	13:12
	← tirnanog left	13:18
	→ pmcnabb joined	13:27
	→ saroy joined	13:32
	← vimal left	13:34
	← AsenMx left	13:34
	→ AsenMx joined	13:36
	→ engest joined	13:36
	→ mat001_ joined	13:37
	← mat001 left	13:40
	→ FieryMewtwo joined	13:52
	→ Guest33 joined	13:52
	← Guest33 left	13:53
	→ causasui joined	13:53
	← rgrinberg left	13:53
	→ rgrinberg joined	13:54
	→ Thanatermesis joined	13:55
	→ phylaz joined	13:55
	→ juliopcrj joined	13:58
	← causasui left	13:58
	← alzgh left	13:59
	→ causasui joined	13:59
	→ alzgh joined	14:00
	→ vimal joined	14:05
	← vlado_ left	14:06
	→ vladoski joined	14:06
	← wyre left	14:11
	→ wyre joined	14:11
	← wyre left	14:11
	← Albright left	14:13
	→ Albright joined	14:14
nuala	so but stow uses symlinks extensively, nu? (seems to have some other use cases too)	14:16
	→ gregraubie joined	14:16
	→ wender joined	14:19
	← rgrinberg left	14:19
	→ ath28 joined	14:20
	→ dimi__ joined	14:21
	← computeiro left	14:22
	← dimi1947 left	14:22
	← ath28 left	14:25
	← alzgh left	14:26
	→ alzgh joined	14:26
	← dimi__ left	14:27
	→ pyevery__ joined	14:28
	→ Achylles joined	14:29
	→ sebastorama joined	14:31
	← nrl^ left	14:31
	→ Siecje joined	14:32
Siecje	I'm doing a merge but I'm getting changes in one that are not in the other, but they are actually in both.	14:33
	→ thiago joined	14:34
	← pyevery__ left	14:34
	→ pulse joined	14:36
	← alzgh left	14:37
osse	Siecje: can you elaborate?	14:38
	→ przemoc joined	14:39
	← sebastorama left	14:41
	→ wyre joined	14:41
	→ phylaz1 joined	14:42
	→ harpia joined	14:42
	← phylaz left	14:42
	phylaz1 → phylaz	14:42
	→ madewokherd` joined	14:42
	← madewokherd left	14:46
	→ rgrinberg joined	14:46
	→ causa_sui joined	14:52
	← Achylles left	14:53
	← Siecje left	14:53
osse	Guess not	14:53
	← dermoth left	14:55
	→ furrymcgee joined	14:55
	→ bloody joined	14:56
	→ ChmEarl joined	14:58
	→ meator joined	14:58
	→ sudoforge joined	15:00
	→ caef^ joined	15:00
	→ arcatech joined	15:00
hexology	if i'm trying to explain rebase to a newbie, is it fair to say that `rebase <old-base> <end> --onto <new-base>` is the "full" form of the command, and that `rebase <old-base> <new-base>` implicitly is `rebase <old-base> <new-base> --onto <old-base>` ?	15:01
	that is, the "default value" for `--onto` is the same `<old-base>` where the rebase is starting from	15:01
	rather, `rebase <old-base> <end>` implicitly is `rebase <old-base> <end> --onto <old-base>`	15:02
	← meator left	15:04
osse	It's not the stupidest thing I've heard in my entire life.	15:04
	I even think it's true.	15:05
	But in the form without --onto, the base you specify is the new base, not the old	15:05
	→ pyeveryt_ joined	15:06
	← arcatech left	15:06
	← ELFrederich left	15:07
	→ dermoth joined	15:07
osse	I'd rather say that git rebase <new-base> <end> figures out what commits to rebase between <new-base> and <end>. with --onto that list of commits doesn't change, but the commits end up somewhere else	15:09
	ie. git rebase <new-base> <end> --onto <different-base>	15:09
	→ mat001 joined	15:09
osse	pro-tip: pen and paper, or whiteboard. muuuch easier to explain in then	15:10
	← pyeveryt_ left	15:11
	← mat001_ left	15:12
	← dermoth left	15:15
	→ sebastorama joined	15:15
furrymcgee	the git switch is confusing me too, most of the time I rebase the current branch like this: git rebase HEAD~10	15:16
	→ mat001_ joined	15:17
	← sebastorama left	15:18
	← mat001 left	15:20
furrymcgee	with git stash you barely need more than one branch	15:20
	→ Xaldafax joined	15:22
	← komputilo left	15:22
	→ sebastorama joined	15:23
	→ vlado_ joined	15:24
	← vladoski left	15:26
	← rgrinberg left	15:26
	← haskl left	15:28
	→ dermoth joined	15:28
	← Gaboradon left	15:32
	← phylaz left	15:32
	→ phylaz joined	15:32
	← jjakob left	15:34
	← irrgit left	15:35
	→ jjakob joined	15:37
	← thebombzen left	15:37
	→ thebombzen joined	15:37
	→ rgrinberg joined	15:37
	← molt left	15:39
	→ skapata joined	15:39
	← skapata left	15:39
	→ skapata joined	15:39
	→ durham joined	15:39
	→ hbautista_ joined	15:40
	← sebastorama left	15:40
	→ arcatech joined	15:41
	→ molt joined	15:42
	← durham left	15:43
	→ durham joined	15:43
	← harpia left	15:45
	→ haskl joined	15:50
	← kenanmarasli left	15:51
	→ irrgit joined	15:54
	← arcatech left	15:57
	→ goldfish joined	15:58
	← vlado_ left	15:58
	→ vladoski joined	15:58
	→ mfiano joined	16:00
	→ iffraff joined	16:01
	← iffraff left	16:02
	→ ELFrederich joined	16:02
	← Xaldafax left	16:02
	← otisolsen70__ left	16:04
	← skapata left	16:06
	→ humky joined	16:08
	← stkrdknmibalz left	16:09
	→ Xaldafax joined	16:12
	← dermoth left	16:12
	→ Yruama joined	16:14
	→ arcatech joined	16:16
	← bkircher left	16:17
	→ orbyt joined	16:18
	→ dextercd joined	16:20
	→ dermoth joined	16:25
	← thebombzen left	16:27
	→ mbalmer_ joined	16:27
	← RiFo left	16:28
	→ thebombzen joined	16:28
	← ThorMojito left	16:28
	← mbalmer left	16:31
	← Murr left	16:31
	→ Murr joined	16:32
canton7	I'd explain it differently, heh. With --onto, you specify the start of the range of commits to rebase. Without --onto, git works it out from what you're rebasing onto where	16:33
	← Murr left	16:33
	← FieryMewtwo left	16:34
	→ Murr joined	16:35
	→ harpia joined	16:35
	bin → sbin	16:37
	→ irc_user joined	16:39
	→ ___nick___ joined	16:41
	← ___nick___ left	16:41
	→ ___nick___ joined	16:43
	← ___nick___ left	16:43
	← oo_miguel left	16:44
	→ ___nick___ joined	16:45
	→ mat001 joined	16:45
	← mexen left	16:48
	← mat001_ left	16:48
	← vladoski left	16:53
constxo	kings	16:54
	question:	16:54
	← shailangsa left	16:54
constxo	let's say you make some changes and the diff is really noisy because of changed line-endings/indentation etc.	16:55
	→ kenanmarasli joined	16:55
constxo	is there a handy way to split into two commits where one is purely whitespace changes and the other has as few whitespace changes as possible?	16:55
	← durham left	16:58
	→ durham joined	16:58
	← hbautista_ left	16:59
	→ emf joined	17:02
	→ vikonen joined	17:02
furrymcgee	there are tools for whitespace formatting	17:03
osse	you can do some tricks grabbing the ws-insensitive patch, apply that in reverse, commit that, then commit the original	17:03
	← rgrinberg left	17:07
osse	hmm maybe not	17:08
	→ anton joined	17:11
	→ zebrag joined	17:13
	← pulse left	17:15
	← Samian left	17:18
	→ ThorMojito joined	17:19
	← dcpc007 left	17:19
	→ shailangsa joined	17:19
	→ FieryMewtwo joined	17:19
	→ pulse joined	17:20
	← alkino left	17:21
	→ skapata joined	17:21
	← skapata left	17:21
	→ skapata joined	17:21
	→ komputilo joined	17:23
	← phylaz left	17:24
	→ reset joined	17:27
	→ pyeveryt_ joined	17:34
	← pyeveryt_ left	17:39
	→ rgrinberg joined	17:45
	→ pyevery__ joined	17:46
	← pulse left	17:46
constxo	osse: ended up doing just that	17:49
	git diff -U0 -w --no-color \| git apply --cached --ignore-whitespace --unidiff-zero -	17:49
	beautiful	17:49
	← momomo_ left	17:49
	→ dansan joined	17:50
	← rfuentess left	17:51
	→ momomo joined	17:52
osse	nice	17:54
	← momomo left	17:55
	← rsx left	17:55
	← goldfish left	17:57
	→ nasamuffin joined	18:00
	← saroy left	18:00
	→ webmariner joined	18:00
	→ momomo joined	18:01
	→ junktext joined	18:01
	→ goldfish joined	18:02
	← goldfish left	18:02
	→ phylaz joined	18:02
	→ cmbengue joined	18:03
	→ vicfred joined	18:04
	→ Samian joined	18:04
	← webmariner left	18:05
	→ webmariner joined	18:07
	→ DoofusCanadensis joined	18:09
	→ goldfish joined	18:19
	← pyevery__ left	18:19
	→ pyever___ joined	18:19
	← remyabel left	18:20
	← igemnace left	18:23
	← mschorm left	18:24
	← komputilo left	18:25
	→ stoned joined	18:29
	← webmariner left	18:32
	← vicfred left	18:34
	← arcatech left	18:34
	→ arcatech joined	18:35
	← AsenMx left	18:42
	← Murr left	18:44
	→ Murr joined	18:44
	← arcatech left	18:46
	← wgrant left	18:51
	← rgrinberg left	18:51
	→ rgrinberg joined	18:52
	→ arcatech joined	18:53
	← arcatech left	18:56
	→ jazzy joined	18:58
irc_user	If I think of something small that should have been in the last commit, I usually just do `git commit -m "f"` and then `git rebase -i	19:00
	@~, and then change it to fixup. Is there a way to do this without rebasing?	19:00
	→ komputilo joined	19:00
irc_user	interactive rebasing*	19:00
	→ Raguile joined	19:01
	→ wgrant joined	19:03
	← rgrinberg left	19:10
	← goldfish left	19:11
	← furrymcgee left	19:13
	← wgrant left	19:15
	→ bkircher joined	19:17
	→ llh joined	19:21
	← GNUmoon left	19:23
	→ GNUmoon joined	19:24
mackerman	irc_user: git commit --amend	19:30
	← reillybrogan left	19:30
osse	irc_user: --amend is the right answer, but you might want to use commit --fixup/squash and then rebase -i --autosquash (--autosquash can be enabled by default)	19:31
	→ hbautista_ joined	19:31
osse	for the cases where it's not the last commit, but e.g. the fifth to last or whatever	19:31
	→ reillybrogan joined	19:32
irc_user	Oh, amend works great, thanks so much mackerman :)	19:33
	osse: What is the main difference between something like `git commit -m "f" && git rebase -i @~~~~~` and fixup+autosquash?	19:34
	← lgc left	19:35
osse	irc_user: With the latter the todo list is automatically changed	19:36
irc_user	It looks like all fixup does is name the commit the same name as the specified one with `fixup!` added to it, and then autosquash automatically uses the `fixup` option instead of `pick`?	19:36
osse	That's basically it	19:37
	And reorders appropriately	19:37
irc_user	I see. I feel like that would make sense if I could use `@~~`, but the fact that I have to copy the commit hash makes it so much slower :/	19:38
	→ AsenMx joined	19:38
irc_user	I guess I could make an alias...	19:38
	← vysn left	19:39
osse	irc_user: You can use @~~~~	19:40
	I prefer @~4 but you do you	19:41
irc_user	Oh I meant with the commit, when you specify `--fixup` you have to specify a commit hash.	19:41
osse	No you don't	19:41
irc_user	lemme try again -.-	19:41
	I was wrong.... thank you...	19:43
osse	I have a small script that wraps rebase. It basically does GIT_EDITOR=true git rebase -i. It's pretty effective :)	19:43
imMute	osse: how is that different than leaving off the -i ?	19:45
irc_user	Oh woah that's awesome, I'll use that too. Thank you for your help :)	19:46
osse	imMute: Without -i the magic keywords don't work	19:46
	Then it's just a plain rebase	19:46
	→ jazzy3 joined	19:48
	→ cvmn joined	19:50
	← jazzy left	19:51
	← bodiccea_ left	20:01
	← BenjiProd left	20:04
	→ bodiccea joined	20:04
	→ wgrant joined	20:04
	← thblt left	20:05
	← wgrant left	20:16
	→ ZacSharp joined	20:20
	← engest left	20:21
	→ engest joined	20:22
	jazzy3 → jazzy	20:22
	← caef^ left	20:24
	→ wgrant joined	20:28
	← constxo left	20:33
	→ pulse joined	20:37
	← gh34 left	20:45
	← cvmn left	20:46
	← juliopcrj left	20:50
	→ m0viefreak joined	20:51
	→ sniperwolf joined	20:54
	← engest left	21:01
	→ engest joined	21:02
Linkandzelda	if I create a repo which is designed to serve as a project template, and then I create a bunch of projects with it, then update the repo template. is it as simple as merging from the template remote origin to bring the updated template files into the projects (barring any conflicts where tempate files were totally overwritten etc)? i'm thinking more in terms of build systems/testing systems	21:03
	pre-configurations or other tools/utilities	21:03
	← GNUmoon left	21:03
	← ___nick___ left	21:04
rawtaz	Linkandzelda: you mean that you create your template repo, then clone that into different project repos, and then want to merge new template changes from the template repo? yeah that should work	21:05
	→ dsrt^ joined	21:05
rawtaz	it's pretty much like any fork of a regular software project	21:05
ZacSharp	if it's really just a common history kept in a separate repo you can do that, if you are talking about github templates I'm not sure because you don't get the history	21:05
	also resolving conflicts by always taking the version from the new repo might cause errors	21:06
	← pyever___ left	21:06
	→ masber joined	21:07
	→ pyevery__ joined	21:07
	← kenanmarasli left	21:08
Linkandzelda	rawtaz: yea pretty much that	21:08
	← pyevery__ left	21:08
	→ pyevery__ joined	21:09
rawtaz	yeah. go for it. just make sure you experiment a bit so you feel comfy that it works, before you go production	21:09
	→ Ilyu joined	21:14
	← orbyt left	21:15
	← ZacSharp left	21:20
	→ ZacSharp joined	21:21
	← ano left	21:23
	← bket left	21:24
	→ ano joined	21:25
	→ junktext_ joined	21:25
	← ano left	21:27
	→ bket joined	21:27
	← junktext left	21:27
	→ charking joined	21:27
	→ ano joined	21:27
charking	Hello. I have to use HTTPS to push commits to a repo. How can you specify the username to use? The remote URL is https://my_username@host/foo/bar, but that doesn't seem to work.	21:28
	It prompts me for username everytime anyway	21:28
	← masber left	21:29
	← ThorMojito left	21:30
charking	Never mind. Adding .git to the repository URL fixed it.	21:30
	I guess maybe it does a redirect and so the username I specified got lost.	21:30
	→ cvmn joined	21:30
	→ jstein joined	21:30
imMute	charking: seems plausible	21:32
	← charking left	21:38
cvmn	how do smart people manage their projects? something like timelines and such?	21:38
rawtaz	relaxing enough during the first 95% for them to endure the panic during the last 6% of the project before presenting it at 7am the following morning	21:39
	← jonosterman left	21:39
	→ LuKaRo joined	21:39
	← bket left	21:39
rawtaz	cvmn: on a serious note the question is too vague. i mean, smoe projects use scrum or other methodologies. some just make a simple timeline on their own, splitting up work more or less. some just do it without much of a timeline	21:40
	it relaly depends on the project and setting	21:40
	→ jonosterman joined	21:40
cvmn	i'm the single man in charge of managing the projects. i have to coordinate everything.	21:42
	should i just use vim and edit project.txt?	21:42
	i wonder if there is a better approach so tht i can sync with android?	21:43
rawtaz	why not. you can use a gantt chart or some other means. perhaps a kanban board.	21:43
	ther's a webapp (you can run it stand-alone if you want) thats named personal kanban board, its really nice	21:43
	theres tons of services for this stuff online if you want to use something like that	21:44
	the tools are plenty, what it boils down to is knowing how much micromanaging you want to do :)	21:44
cvmn	how about just google tasks?	21:45
rawtaz	yeah wh ynot	21:45
	personally i wouldnt put stuff with google, but if thats how you roll why not	21:45
cvmn	are you ungooged?	21:46
rawtaz	i think it makes sense to start small and keep it simple. you will learn with time what you think that you need to change or so with your planning	21:46
	of interest might be that you dont build yourself into some system htat its messy to move away from into something else when you need to	21:46
	perhaps even a simple spreadsheet with a gantt chart in it might be a good start	21:46
	→ bket joined	21:46
rawtaz	then again i GUESS you can somehow export the google tasks in some okay format?	21:47
cvmn	i am afraid to took at my good tasks.	21:48
	goog*	21:48
	← engest left	21:48
	→ engest joined	21:49
	← pyevery__ left	21:49
	→ GNUmoon joined	21:51
	← cvmn left	22:02
	← harpia left	22:10
	→ vysn joined	22:11
	→ pyeveryt_ joined	22:14
	→ ThorMojito joined	22:14
	← ZacSharp left	22:16
	← jinsun left	22:17
	→ jinsun joined	22:18
	→ rgrinberg joined	22:23
	← dermoth left	22:25
	← rgrinberg left	22:27
	→ rgrinberg joined	22:28
	→ dermoth joined	22:38
	→ arcatech joined	22:45
	← DoofusCanadensis left	22:46
	→ Xenguy joined	22:46
	← dermoth left	22:46
	← arcatech left	22:47
	← twb left	22:48
	→ arcatech joined	22:51
	← tmz left	22:52
	← arcatech left	22:55
	→ igemnace joined	22:57
	→ arcatech joined	22:58
	→ dermoth joined	22:58
	→ tmz joined	22:58
	← anddam left	23:06
	→ ZacSharp joined	23:06
	→ bobdobbs joined	23:11
	→ pizdets joined	23:19
	← arcatech left	23:23
	→ arcatech joined	23:26
	← The_Jag left	23:28
	← ZacSharp left	23:31
	← Thanatermesis left	23:32
	← pyeveryt_ left	23:35
	→ nvmd joined	23:37
	← sniperwolf left	23:42
	← arcatech left	23:43
	→ YuGiOhJCJ joined	23:43
	→ AbleBacon joined	23:43
	→ ferdna joined	23:44
	→ arcatech joined	23:45
	← causasui left	23:47
	→ Erisa7 joined	23:49
	← emf left	23:50
	← Erisa left	23:51
	Erisa7 → Erisa	23:51
	→ causasui joined	23:53
	← engest left	23:54
	→ engest joined	23:55
	→ richbridger joined	23:55
	→ tusko joined	23:56
	← bobdobbs left	23:56
tusko	Help me plz	23:57
	I added some big file, tried to commit, git didn't like it (because size). I ran git rm file and rm file so it is gone.	23:57
	But I still can't commit because it say the file too big like	23:57
	← causasui left	23:57
	← m0viefreak left	23:58
rawtaz	tusko: what does `git status` show?	23:58
	you can pastebin the output, e.g. at kopy.io	23:58
	→ causasui joined	23:58
tusko	git status says I'm 2 commits ahead	23:58
	← Raguile left	23:58

Logs Search ←Prev date Next date→

Channels Documentation