IRCloggy #git 2019-03-18

Provider of IRC logs since 2005.

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

	2019-03-18
	← dege left	00:00
	← Impaloo left	00:02
	← n3wborn left	00:03
	← finalbeta left	00:04
	→ jottr joined	00:06
	→ Impaloo joined	00:07
	← jottr left	00:10
	→ Beam_Inn joined	00:13
	← leeN left	00:14
	← Goplat left	00:14
	← mixaz left	00:14
	→ Beam_Inn_ joined	00:16
	→ mixaz joined	00:16
	← acidjnk left	00:17
	← Beam_Inn left	00:19
	Beam_Inn_ → Beam_Inn	00:19
	→ opilab joined	00:23
	← opilab left	00:24
	→ jottr joined	00:27
	→ dpyro joined	00:31
	← jottr left	00:31
	← wald0 left	00:32
	← Essadon left	00:36
	← mixaz left	00:36
	→ mixaz joined	00:37
	← renich left	00:41
	← CryptoDavid left	00:43
	→ learningc joined	00:45
	← Narrat left	00:47
	→ jottr joined	00:48
	← mixaz left	00:51
	→ mixaz joined	00:52
	← jottr left	00:52
	← manuelschneid3r left	01:00
	← Beam_Inn left	01:00
	← learningc left	01:00
	← de-facto left	01:01
	→ de-facto joined	01:01
	← AtumT left	01:04
	→ jottr joined	01:08
	→ Beam_Inn joined	01:11
	← jottr left	01:13
	← HenryCH left	01:18
	← Snoober left	01:25
	→ Snoober joined	01:26
	← hellauer left	01:26
	← Snoober left	01:27
	← mixaz left	01:27
	→ hellauer_ joined	01:29
	→ jottr joined	01:29
	← hellauer_ left	01:34
	→ hellauer_ joined	01:34
	← jottr left	01:34
	← hellauer_ left	01:35
	← agowa339 left	01:36
	← xaltsc left	01:40
	→ sydbarret joined	01:42
	→ jottr joined	01:50
	← jottr left	01:55
	← Beam_Inn left	01:58
	→ Goplat joined	02:00
	→ finalbeta joined	02:01
	← R2robot left	02:05
	→ jottr joined	02:11
	→ aerozoic joined	02:13
	← jottr left	02:16
aerozoic	wazup peeps, simple question... I have cloned a repo at a specific tag using git clone --branch 1.0, now the repo has a new tag "1.1". What is the proper command to update my clone to the new tag?	02:16
benharri	git checkout 1.1	02:19
aerozoic	to be clear, the source repo has a new tag.	02:20
	not my clone	02:20
	doesn't checkout change to detached mode or something?	02:22
	← lucasem left	02:26
	← freeman42y left	02:31
	→ jottr joined	02:32
rafasc	you need to fetch first.	02:34
	← sydbarret left	02:37
	← MACscr left	02:37
rafasc	aerozoic: git clone --branch <tag>; will get you in detached mode.	02:38
	← jottr left	02:38
aerozoic	rafasc, so i should be in detached mode?	02:38
rafasc	there's nothing wrong about being detached. It just means you are not in a branch.	02:39
	!detached	02:39
gitinfo	A detached HEAD (aka "no branch") occurs when your HEAD does not point at a branch. New commits will NOT be added to any branch, and can easily be !lost. This can happen if you a) check out a tag, remote tracking branch, or SHA; or b) if you are in a submodule; or you are in the middle of a c) am or d) rebase that is stuck/conflicted. See !reattach	02:39
aerozoic	yea all i want is to make sure my repo is at the new tag "1.1"	02:39
rafasc	then checkout 1.1; will do just fine.	02:39
aerozoic	i dont make changes	02:40
	ok thx	02:40
	so just like that?	02:40
	"git checkout 1.1"?	02:40
rafasc	yep	02:40
aerozoic	but git fetch first	02:40
	will git fetch download the entire git history?	02:41
rafasc	yes.	02:41
aerozoic	ok how do i only fetch the history for the new tag?	02:41
rafasc	but you already transferred everything up to 1.0, so fetch will only get the missing pieces.	02:42
aerozoic	the history for this repo goes back years and is huge	02:42
	no, i git cloned using --depth 1	02:42
rafasc	you can use git fetch --shallow-exclude=1.0	02:43
	that will not transfer any ancestors of 1.0.	02:43
aerozoic	to be more clear, i don't need the history at all, just the last commit that made the new tag.	02:44
rafasc	so you'll essentially get 1.0->present	02:44
aerozoic	1.0>present is also huge	02:44
	← justanotheruser left	02:44
aerozoic	that's the problem, lol	02:44
	← finalbeta left	02:44
aerozoic	they went years (1200 commits) from 1.0 to 1.1	02:44
	→ finalbeta joined	02:45
rafasc	git fetch --depth=1 origin tag 1.1 ?	02:45
	not sure if that would work.	02:46
	→ learningc joined	02:46
	← finalbeta left	02:46
	→ finalbeta joined	02:46
rafasc	or maybe just make another clone --depth 1.	02:48
	but I think: git fetch --depth=1 origin tag 1.1; git checkout 1.1; would work.	02:49
aerozoic	ok imma try it now	02:49
	YES!	02:50
	that's it, thanks rafasc!	02:50
	→ R2robot joined	02:51
	← ferdna left	02:51
	→ justanotheruser joined	02:52
	→ jottr joined	02:53
rafasc	yw	02:55
	← mooasaurus left	02:57
	→ mooasaurus joined	02:57
	← jottr left	02:58
	→ duderonomy joined	02:58
	← duderonomy left	03:00
	→ apoos_maximus joined	03:00
	← hofmann3900 left	03:00
	← F0rTex left	03:01
	→ duderonomy joined	03:01
	→ kadoban joined	03:02
	← duderonomy left	03:02
	→ duderonomy joined	03:02
	→ F0rTex joined	03:02
	← duderonomy left	03:02
	→ Mattiaslndstrm joined	03:02
	→ duderonomy joined	03:03
	← duderonomy left	03:03
	→ ferdna joined	03:03
	→ duderonomy joined	03:04
	← duderonomy left	03:04
	→ duderonomy joined	03:04
	← duderonomy left	03:05
	→ duderonomy joined	03:05
	← duderonomy left	03:05
	→ duderonomy joined	03:07
	← duderonomy left	03:07
	← Mattiaslndstrm left	03:07
	→ duderonomy joined	03:08
	← kjartan left	03:08
	← duderonomy left	03:08
	→ duderonomy joined	03:10
	← duderonomy left	03:12
	→ kjartan joined	03:13
	→ jottr joined	03:14
	→ duderonomy joined	03:15
	← rafasc left	03:15
	← jottr left	03:19
	← xlued left	03:19
	→ xlued joined	03:20
	← dpyro left	03:20
	→ pd09041999 joined	03:23
	← alyptik left	03:27
	← orbyt_ left	03:29
	lagothrix → Guest2486	03:30
	← Guest2486 left	03:30
	→ lagothrix joined	03:30
	→ SuperLag joined	03:30
	← SuperL4g left	03:33
	→ orbyt_ joined	03:43
	← orbyt_ left	03:47
	← learningc left	03:49
	→ learningc joined	03:49
	← Cabanossi left	03:50
	← CCDelivery left	03:52
	→ Cabanossi joined	03:53
	← Anthaas left	03:54
	→ jottr joined	03:54
	→ Anthaas joined	03:55
	← ferdna left	03:55
	← jottr left	03:59
	← pd09041999 left	04:02
	→ Brilpikk3wyn joined	04:06
	← wildlander left	04:08
	→ jottr joined	04:15
	← comptroller left	04:15
	← yyy left	04:17
	→ Lucas_Gray joined	04:20
	← jottr left	04:20
	← Lucas_Gray left	04:21
	→ pd09041999 joined	04:21
	← moei left	04:22
	→ MACscr joined	04:26
	→ alyptik joined	04:30
	→ sense8 joined	04:31
	→ jottr joined	04:36
	← jottr left	04:41
	← Cabanossi left	04:45
	← mowcat left	04:45
	← sanchexm left	04:47
	→ Elon_Satoshi joined	04:48
	← learningc left	04:48
	← sense8 left	04:50
	Elon_Satoshi → Copenhage_Bram	04:52
	→ Cabanossi joined	04:54
	→ learningc joined	04:57
	→ jottr joined	04:57
	← alyptik left	05:00
	→ pks_ joined	05:02
	← jottr left	05:02
	← pks left	05:04
	pks_ → pks	05:04
	→ Beam_Inn joined	05:04
	← aerozoic left	05:06
	→ raulp joined	05:10
	← Noldorin left	05:11
	→ jottr joined	05:18
	← GreenJello left	05:21
	← jottr left	05:23
	← Brilpikk3wyn left	05:24
	→ howdoi joined	05:47
	← learningc left	05:49
	→ learningc joined	05:50
	← shentino left	05:50
	→ jottr joined	05:54
	→ socialoutcast joined	05:55
	← Inline left	05:56
	→ ave_milia joined	05:58
	← jottr left	05:59
	← diogenese left	06:00
	→ diogenese joined	06:01
	← Bobdude left	06:02
	← learningc left	06:07
	→ learningc joined	06:08
	→ fekir joined	06:11
	← apoos_maximus left	06:12
learningc	Can the branch master be changed to another name, say for example main?	06:17
	← guardian left	06:19
	← finalbeta left	06:19
	→ finalbeta joined	06:20
	← Gabemo left	06:24
kadoban	Yes, there is nothing special about the name (except it's like the default default branch)	06:25
	→ Gabemo joined	06:27
	← inkbottle left	06:29
	→ alyptik joined	06:30
	→ jottr joined	06:31
	← hyperair left	06:32
	→ hyperair joined	06:33
	← Goplat left	06:34
	← jottr left	06:36
	← przemoc left	06:37
	← timewalker left	06:37
	→ carb0n_ joined	06:42
	→ jottr joined	06:45
	← learningc left	06:49
	→ learningc joined	06:49
	→ SkarmoutsosV joined	06:49
	→ tm007 joined	06:52
	→ T_UNIX joined	07:02
	← learningc left	07:03
	→ learningc joined	07:04
	→ Mattiaslndstrm joined	07:04
	→ Beam_Inn_ joined	07:06
	← Beam_Inn left	07:08
	Beam_Inn_ → Beam_Inn	07:08
	← SkarmoutsosV left	07:09
	← Mattiaslndstrm left	07:09
	← jottr left	07:09
	← thiago left	07:11
	→ yuriii joined	07:13
	→ rominronin joined	07:13
	← rominronin left	07:13
	→ cfjk joined	07:16
	→ rominronin joined	07:16
	→ Anthaas_ joined	07:18
	← Anthaas left	07:18
	← kjartan left	07:21
	→ fekir_ joined	07:22
	← random_yanek left	07:24
	→ random_yanek joined	07:25
	← random_yanek left	07:25
learningc	When I delete a branch, will that delete all the commits related to that branch too?	07:25
	→ kjartan joined	07:25
	← johnny56 left	07:25
learningc	Like when I cut a tree branch, all the leaves from tyhe tree are gone too	07:26
	→ chele joined	07:26
	→ random_yanek joined	07:26
	→ Makaveli7 joined	07:27
	→ andrzejv joined	07:27
	→ johnny56 joined	07:27
kadoban	Only if they're not referenced by anything else, and in practice only much later when git gets bored. Typically the commits will be safe for like 3ish months at least, due to the reflog. Though it's not a great idea to rely on that.	07:27
_ikke_	learningc: 1. git does not immediately delete commits, only whe the garbage collector is run. 2. There might be other branches still referring to the commits	07:27
learningc	I see	07:34
	So when does git get bored? Who controls that?	07:35
_ikke_	learningc: git has some conditions on when to run git gc	07:36
	it happens automatically when you run certain commands	07:36
	← duderonomy left	07:36
	→ Noti joined	07:41
	→ oxymoron93 joined	07:41
	← Olipro left	07:42
	→ jottr joined	07:44
	← learningc left	07:49
	→ clime joined	07:49
	→ learningc joined	07:49
	→ n3wborn joined	07:49
	← learningc left	07:50
	← iam730 left	07:51
	→ Mo joined	07:52
	→ apoos_maximus joined	07:53
	→ iam730 joined	07:53
	← ave_milia left	07:53
Mo	Hi, I have a script that periodically does git p4 sync on a p4 clone that was created by git p4 clone --bare //DEPOT. Now on P4 side the mail adresses have changed, but git still uses the old addresses. Where are the addresses in the log headers "Author:" come from?	07:54
_ikke_	They are stored in the commit objects	07:57
	→ kernel-sanders joined	07:57
Mo	There is https://git-scm.com/docs/git-p4#Documentation/git-p4.txt-git-p4mapUser reo remap users but afaik there is no mapping at all right now.	07:58
	So actually every change on P4 should also be applied to the git clone.	07:58
	Every mail adress change I mean.	07:58
	← fatalhalt left	08:00
	→ shentino joined	08:02
Mo	We are not submitting to P4, this is a readonly git p4 clone.	08:04
kernel-sanders	p4 user?	08:07
Mo	I asked the same some month ago here. Where can I find git p4 developers? Maybe #git-devel?	08:07
	kernel-sanders: What do you mean?	08:07
	← jakogut left	08:07
	→ Brilpikk3wyn joined	08:08
	Brilpikk3wyn → Pikk3wyn	08:09
kernel-sanders	oh it's a perforce compatibility layer, didn't know about it	08:09
	→ jakogut joined	08:10
	← flippo left	08:12
	← socialoutcast left	08:13
	→ daggs1 joined	08:13
daggs1	Greetings, is there a simple way to use git log and show all commit but the last one?	08:13
kernel-sanders	git log HEAD~	08:15
daggs1	kernel-sanders: didn't worked, I use this cmd: git log --name-only test_branch1..test_branch2 HEAD~	08:16
kernel-sanders	git log --name-only test_branch1~..test_branch2	08:17
daggs1	ahh, sec, testing	08:19
	actually git log --name-only test_branch1..test_branch2~ worked for me	08:20
kernel-sanders	cool	08:22
oxymoron93	daggs1: https://git-scm.com/docs/gitrevisions#_specifying_ranges	08:22
daggs1	oxymoron93: thanks, will look at it	08:24
	→ ViXiVTech joined	08:28
ViXiVTech	why is git so slow? 300K Avg, maxed out at 2.8Mbps for a short while... Should be WAY quicker on 300Mbit Fiber....	08:28
	→ Xeago_ joined	08:29
ViXiVTech	https://god.vixiv.net/icon-512x512.png	08:30
	← Xeago left	08:30
	Xeago_ → Xeago	08:30
	← ViXiVTech left	08:30
kernel-sanders	I guess there's more to in than connection speed, I'm averaging 4 MiB/s on a clon	08:31
	← jottr left	08:31
	→ ViXiVTech joined	08:31
ViXiVTech	100% (2899756/2899756), 622.30 MiB \| 804.00 KiB/s, done	08:32
	Less than a Mbps avg	08:33
	→ gareppa joined	08:34
ViXiVTech	on this: https://www.speedtest.net/result/8121128589.png	08:35
kernel-sanders	yeah I also have a fast connection, have a look at this: https://stackoverflow.com/q/8180525	08:36
ViXiVTech	I GUESS it could be the remote server.... or git...	08:37
	→ rosco_y joined	08:38
rosco_y	What does "git rev-parse branch@{upstream}" do?	08:38
	→ Skinok-work joined	08:39
	← daggs1 left	08:40
	→ sQVe joined	08:41
	← Pikk3wyn left	08:41
rosco_y	I thought it checked the hash sum for the branch on GitHub, but it seems more as though it's working off of my local repo	08:41
jast	ViXiVTech: usually the remote server is the bottleneck	08:41
	github for instance tends to be fairly slow	08:42
oxymoron93	well run `git fetch` rosco_y	08:42
kadoban	rosco_y: Most things are local. It's the shaid of the commit that the upstream branch was at last time you fetched, pretty much.	08:42
oxymoron93	that will update your rtb-s and you should get output which matches what you see on remote repo	08:43
jast	rosco_y: it shows the remote state from the last time you ran 'git fetch' or 'git pull' or 'git remote update'	08:43
	if you want live information, you can use 'git ls-remote origin' (for example)	08:43
	→ Pikk3wyn joined	08:46
	← carb0n_ left	08:46
	→ jottr joined	08:48
jast	kernel-sanders: if you look at the answer posted by the person who asked the question, in that case the bottleneck was the virtual NIC driver used by that person	08:49
	← apoos_maximus left	08:50
	← Noti left	08:50
kernel-sanders	jast, yes there's a long list of possible bottlenecks with things like these	08:52
jast	but I can confirm that for me, many git clones are way slower than plain HTTP downloads in the same environment	08:52
	← gareppa left	08:53
jast	the bulk of the work in git clones is on the server side, where objects have to be looked up and delta-compressed	08:53
	← jottr left	08:53
	→ gareppa joined	08:53
	← gloomy left	08:56
	← sQVe left	09:00
	← Pikk3wyn left	09:06
	← armin left	09:06
	← gareppa left	09:08
	→ jottr joined	09:09
	→ jkarder joined	09:09
	→ Ayo joined	09:10
	→ theoceaniscool joined	09:13
	← jottr left	09:13
	← rkta left	09:14
	→ rkta joined	09:15
	← rkta left	09:16
	→ duncan11 joined	09:18
	→ Tobbi_ joined	09:19
	→ sQVe joined	09:19
	← catsup left	09:19
	→ rkta joined	09:20
	→ catsup joined	09:20
	← Ayo left	09:20
	← catsup left	09:20
	→ catsup joined	09:20
	→ carb0n_ joined	09:22
	← ViXiVTech left	09:25
	→ Ayo joined	09:26
	→ baako joined	09:26
baako	hi guys, I did a file permission change to my git project and now it says I need to commit all those changes	09:27
	even if they are blank, how to avoid it and still keep the permissions?	09:27
	← cbreak left	09:28
rosco_y	kadoban, ty. I had some misconceptions about rev-parse @{upstream}	09:29
	→ jottr joined	09:30
	← rosco_y left	09:31
	← irqq left	09:31
	→ cbreak joined	09:31
	← jottr left	09:34
	→ jottr joined	09:40
	→ yyy joined	09:41
	← rominronin left	09:42
	← Anthaas_ left	09:43
	→ Anthaas joined	09:43
	← jottr left	09:45
	→ gloomy joined	09:47
	→ rominronin joined	09:48
	← bashfulshell left	09:48
Abdullah	how to add vim view and undodir in global gitignore?	09:52
	→ agowa338 joined	09:54
Abdullah	I use stow to manage my dotfiles. like my dir structure is ~/cfg = main repo dir. and vim files resides in it like ~/cfg/vim/{.vimrc,vim/)} so I stow them and they become symlinks in my homedir. I don't know how to add them in gitignore.	09:54
	→ staafl__ joined	09:54
	← staafl left	09:55
	→ YuGiOhJCJ joined	09:58
	→ jottr joined	09:58
_ikke_	Abdullah: What part is difficult?	09:58
	→ __rohit joined	10:02
Abdullah	_ikke_: I wanna keep only folders but not their contents in git	10:02
	so if I clone the repo and stow them, it should create symlink thus creating directories for vim files.	10:03
_ikke_	git does not track empty folder, so you need at least one file in there for git to create the folder	10:04
	one way is to add a .gitignore file with '*\n!.gitignore' in it and track the .gitignore file	10:04
Luyin	I committed my first commit to git.git \o/	10:05
_ikke_	Luyin: \o/	10:05
Luyin	it's typos in the man page but still :D	10:06
	→ Lucas_Gray joined	10:06
kernel-sanders	congratulations on the commit	10:06
	→ Beam_Inn_ joined	10:07
Luyin	thanks, I hope I'll be doing some more contributions in the future	10:08
	I don't know C, though, so it's not very likely that it's on git	10:08
_ikke_	Luyin: I don't know C very well as well, but I still managed to get commits in the with functional changes / improvements :-)	10:10
	← Beam_Inn left	10:10
Luyin	nice :)	10:10
	Beam_Inn_ → Beam_Inn	10:10
_ikke_	So don't let that scare you away ;)	10:10
Luyin	won't :)	10:11
Abdullah	touch ~/.vim/undodir/.heygitkeepme	10:11
	echo "!~/.vim/undodir/.heygitkeepme" >> ~/.config/git/ignore	10:12
	echo "~/.vim/undodir/*" >> ~/.config/git/ignore	10:12
	is it okay? _ikke_	10:13
_ikke_	You want to swap the order of the last 2	10:13
	← Ayo left	10:13
_ikke_	first ignore everything, then unignore a specific file	10:13
Abdullah	okay thanks.	10:14
	→ mikecmpbll joined	10:17
	→ hofmann3900 joined	10:18
	→ zonixo joined	10:18
	→ ggSo joined	10:19
	← ggSo left	10:19
	← zonixo left	10:19
	→ zonixo joined	10:19
Abdullah	its still tracking all those files	10:22
_ikke_	You need to untrack them first	10:23
	git rm --cached <files>	10:23
	← clime left	10:23
Abdullah	updating files failed while commiting	10:29
Luyin	Abdullah: you might be interested in this blog post: https://github.com/blog/2019-how-to-undo-almost-anything-with-git	10:29
Abdullah	thanks Luyin	10:29
Luyin	yw	10:31
	← Lucas_Gray left	10:32
Abdullah	error: unable to index file 'vim/.vim/bundle/python-mode'	10:32
	fatal: updating files failed	10:32
	← n3wborn left	10:33
	→ Lucas_Gray joined	10:33
	→ irqq joined	10:35
	← zonixo left	10:36
	← yyy left	10:40
tango_	hello all. let's say that I have branches A and B, I and I've merged B into A, and made no further commits. Then B gets some new commits, and I want to “update” the merge of B into A, without having to redo all the conflict resolution. what would the recommended way be?	10:40
kernel-sanders	you can merge again, conflict will only be on the new deltas	10:43
tango_	kernel-sanders: yes, but then I get two merges one after the other. by “update” I meant something like squashing the second merge onto the previous one	10:44
	i.e. getting the same effect of the redoing the merge, but pretending that the first parent was the commit before the merge on branch A	10:45
	(without twiddling the metadata directly)	10:45
	← hussam left	10:45
	→ mixaz joined	10:46
tango_	(git merge --squash does in some sense the opposite of what I want)	10:47
	→ comptroller joined	10:48
	→ zonixo joined	10:49
jast	tango_: you can't do it now without hackery, but run this so in the future you'll have an easier time: git config --global rerere.enabled true	10:52
kernel-sanders	tango_, this is what I've found: https://stackoverflow.com/a/4138485	10:53
	yeah rerere will remember conflict resolutions so you can redo that stuff without worrying	10:54
tango_	jast: I do have rerere enabled actually, but for some reason it's not working for this merge	10:54
kernel-sanders	BUT you have to be very sure about each conflict resolution because git will remember	10:54
jast	then maybe the conflicts are too different	10:54
tango_	jast: the conflicts themselves not, but the resolutions are	10:54
	kernel-sanders: I'm looking at the stackoverflow now	10:55
jast	yeah, that approach should work	10:56
	it's a little ugly but whatever :)	10:56
tango_	I'll take ugly for these kind of hacks	10:57
	8-)	10:57
	let's see if it works	10:57
	← __rohit left	10:58
tango_	woohoo	11:03
	so, do the second merge, soft-reset to before the first merge, update MERGE_HEAD, commit	11:04
	(even better, commit -c firstmerge ;-))	11:04
	kernel-sanders: thanks a lot	11:04
	(and jast)	11:04
kernel-sanders	nice glad it worked for you	11:06
	→ emsjessec joined	11:07
	→ acebrianjuan joined	11:09
acebrianjuan	Hi all	11:09
	I've got a question	11:09
	I've made a bunch of changes to my git-managed project and I would like to break down those changes in sepparate commits	11:11
	instead of making a single commit with all the changes	11:11
	to make history more granular	11:11
	→ egovirus joined	11:11
acebrianjuan	Is this possible?	11:12
	→ apoos_maximus joined	11:13
kernel-sanders	yes	11:13
	you can add the changes that you want and only commit those	11:13
acebrianjuan	kernel-sanders: yes, but what if those changes are all in the same file?	11:14
	do I still have the ability to separate them?	11:14
kernel-sanders	you can stage parts of a file with git add -p	11:14
acebrianjuan	kernel-sanders: oh, ok! I'll try that	11:14
	→ Mattiaslndstrm joined	11:14
	→ yyy joined	11:17
	← ServerSage left	11:17
	→ Noti joined	11:18
	← carb0n_ left	11:28
	→ mra90 joined	11:32
	→ al-damiri joined	11:33
	← anddam left	11:35
	→ CodeSlingerPaul joined	11:36
	← apoos_maximus left	11:36
mra90	how to push to a branch under upstream/topic/name-of-branch	11:38
	I did: "git push origin upstream/topic/name-of-the-branch" it didn't show any error but I don't see anything on github	11:39
_ikke_	git push origin upstream/topic/name-of-the-branch:refs/heads/name-of-branch	11:40
	← kjartan left	11:40
acebrianjuan	kernel-sanders: thank you `git add -p <file>` worked very well! Nice feature!	11:41
	→ Emperor_Earth joined	11:41
	← CodeSlingerPaul left	11:42
	→ rafasc joined	11:42
	← Marbug left	11:42
mra90	_ikke_: ok now I see PR option but not under that upstrem/topic/ branch	11:43
	but just upstream	11:43
	→ CodeSlingerPaul joined	11:43
mra90	and it shows wrong deltas	11:43
j416	mra90: what is the name of your local branch and what branch name do you want it to have on the remote?	11:44
	is "upstream/topic/name-of-branch" the name of your local branch?	11:44
	→ jottr_ joined	11:44
mra90	j416: yes	11:44
	→ kjartan joined	11:45
mra90	and I want to push into that origin just one commit	11:45
j416	to what	11:45
	just "name-of-branch"?	11:45
mra90	"upstream/topic/name-of-branch"	11:45
	this branch ^	11:45
j416	git push origin upstream/topic/name-of-the-branch:upstream/topic/name-of-the-branch	11:45
	or you can simply set that up: git push -u origin upstream/topic/name-of-the-branch	11:46
	then you can just do 'git push'	11:46
	next time	11:46
	← jottr left	11:47
	← acebrianjuan left	11:47
mra90	hmm it doesn't see my new commit	11:48
	← sQVe left	11:53
	← TimWolla left	11:54
	→ freeman42x joined	11:55
	→ f-a joined	11:56
	← duncan11 left	11:57
f-a	I would like to have a repo with my dotfiles. Is there a standard way of achieving that while encrypting sensitive data?	11:57
	→ TimWolla joined	11:57
nedbat	f-a: use a private repo	11:57
f-a	nedbat: a private repo would be still available to the person who owns the webspace it is uploaded to, right?	11:58
nedbat	f-a: I suppose so. use a service you trust, or don't upload the data.	11:59
	→ silenc3r joined	11:59
furrymcgee	keep it in a submodule apart from webspace	11:59
rafasc	f-a: there's a project called git-crypt, or you can set up your own smudge-clean filters.	12:00
f-a	I will check it out, thanks	12:01
rafasc	f-a: man gitattributes; there's an example somewhere in there.	12:02
gitinfo	f-a: the gitattributes manpage is available at https://gitirc.eu/gitattributes.html	12:02
	← zonixo left	12:03
	← Makaveli7 left	12:03
	→ carb0n_ joined	12:08
	← CodeSlingerPaul left	12:15
	→ CodeSlingerPaul joined	12:17
	→ duncan1 joined	12:21
	← duncan1 left	12:25
	← CodeSlingerPaul left	12:27
	← jelmer left	12:30
	→ jelmer joined	12:31
	→ duncan1 joined	12:34
	→ SkarmoutsosV joined	12:35
	→ armin joined	12:41
	← pd09041999 left	12:44
	→ toothlessg joined	12:44
	← armin left	12:44
	→ armin joined	12:45
	→ zonixo joined	12:46
	→ Metalindustrien joined	12:47
Metalindustrien	Hey, I have a bunch of git branches, but have a handful of general helper scripts that I want to be kept in sync across the branches. Should I use git submodules for that, keep them in a separate repo or how?	12:48
	← f-a left	12:49
	← leah2 left	12:49
_ikke_	A separate repo makes most sense	12:49
	→ leah2 joined	12:50
	← Lucas_Gray left	12:50
	→ Lucas_Gray joined	12:51
rafasc	and for submodules you need to have it as a separate repository anyways. :)	12:51
	→ rickumali joined	12:52
	→ Snoober joined	12:52
	← Lucas_Gray left	12:53
osse	Do the scripts change often?	12:53
	→ Lucas_Gray joined	12:53
rafasc	there's also git-subtree, which tries to solve the same problem submodules do, but use a different approach.	12:55
irrgit	Well even if they dont change that often, if its a simple change to one script, now you would have to propagate that change manually to each branch.	12:56
_ikke_	yes, so that's why it's not sensible to tie it to branch history	12:56
irrgit	Definitely keep them in a separate repo	12:56
Metalindustrien	osse yeah, I refactor them often as I aim to automate as much of the dev process as possible :)	12:56
irrgit	+1 _ikke_	12:56
	→ pd09041999 joined	12:56
_ikke_	they change at a different rate for different reasons	12:57
Metalindustrien	roger that. Separate repo. But what's the smartest way of including them in the existing git folder structure then? Just as a repo inside a repo?	12:57
_ikke_	as a symlink?	12:57
	← pd09041999 left	12:57
	→ pd09041999 joined	12:58
Metalindustrien	Ah, of course. Thanks	12:59
osse	Sounds like reasonable script to have in the repo to me	12:59
jast	guys, keep in mind that submodules can track a branch instead of a specific commit	13:02
	→ Makaveli7 joined	13:02
_ikke_	You still need to commit changes in the parent repo	13:02
	← mixaz left	13:03
	← duncan1 left	13:06
jast	oh, right. the feature is quite confusing.	13:08
_ikke_	people just need to accept the fact that submodules are meant to be stable	13:08
	The parent repo records a commit hash, there is no way around that	13:09
	→ nic-hartley joined	13:09
	→ localhorse joined	13:12
	→ howell joined	13:14
rafasc	also worth mentioning git-subtree.	13:14
	← omnireq left	13:15
_ikke_	which imho is even worse :P	13:15
rafasc	I knew you would way that. :P	13:15
_ikke_	hehe :D	13:15
rafasc	--skip-worktree is another that triggers you ;)	13:16
_ikke_	yup	13:16
	!promise	13:16
	:-/	13:16
	!skip	13:16
	d'oh	13:16
rafasc	!assume-unchanged ?	13:16
_ikke_	!assume	13:16
gitinfo	[!assume_unchanged] git update-index --assume-unchanged is sometimes suggested for keeping yourself from committing changes to a file, but it's actually a promise to Git that the file is identical to the committed version, to reduce unnecessary disk reads. Not only will Git feel free to discard the flag, it will also happily overwrite your changes whenever a checkout/merge/rebase/... updates it.	13:16
_ikke_	I must confess I have used --skip-worktree once or twice, but in the end it causes more issues then it solves	13:17
rafasc	It makes stashing 200% more cumbersome.	13:18
localhorse	I'm often in the following situation: I did a lot of changes (stream of consciousness flow), coding/compiling iteratively, everything is working fine, now I want to construct a causally logically git commit history from all my changes (which is usually not the chronological history of adding the changes): For each commit I want to make, I want to commit a subset of my changes. For determining the proper subset (that still	13:18
	compiles etc.) I want to stash a subset of my changes and then compile & run tests, if it passes, I'll create a commit and unstash, repeat until no changes left. My idea was to stage all the changes I want to commit, then stash all unstaged changes. I found a proper answer for how to stash unstaged changes here:	13:18
	https://stackoverflow.com/questions/20028507/git-stash-uncached-how-to-put-away-all-unstaged-changes/34681302#34681302 It's a hacky workaround IMO, and I often find out that my changes-subset-split choice was not correct (either it doesn't compile or tests fail) so I have to re-do the subset-split. What's the most convenient way to move a hunk (change) between both sets (from stashed to staged and vice versa)?	13:18
rafasc	Especially if you forget you set the flag.	13:18
	← baako left	13:20
localhorse	Or if you want to help me get closer to a good solution, please answer me this: How can I git stash pop some of my stashed changes?	13:20
rafasc	localhorse: I usually just make a new branch, and use checkout -p <OID>; and progressively build from that.	13:20
localhorse	Bonus question: Is there a way to move a hunk/change between stashed and staged sets in SmartGit easily?	13:21
	← furrymcgee left	13:22
localhorse	rafasc: How do you mean? Can you describe the individual steps of that workflow?	13:22
rafasc	git checkout -b rewrite-branch; git checkout -p <commit3> -- file1; git checkout -p <commit2> -- file4; git commit; rinse and repeat.	13:24
	← gloomy left	13:25
localhorse	rafasc: and when are commits 3 and 4 created in this example?	13:25
rafasc	if your original commits are isolated enough, you can even just git cherry-pick them.	13:25
localhorse	i mean 3 and 2	13:25
rafasc	localhorse: in your "stream of counsiouness" branch.	13:25
localhorse	all of those changes are not committed yet	13:26
	i want to cherry pick the uncommitted changes	13:26
rafasc	git add -p?	13:26
localhorse	rafasc: but for being able to check if it compiles and passes tests, i can't leave changes that i don't want to commit in the working tree	13:27
rafasc	but usually it's easier (and safer, if something goes wrong) to just make temporary commits.	13:27
localhorse	so i have to stash the unstaged ones or doing something equivalent	13:27
rafasc	you can stash everything and do $git checkout -p stash@{n};	13:28
jast	you can convert a stash into a branch: git stash branch <name> [<stash>]	13:28
	that makes it easy to use all the standard tools on it, e.g. git checkout -p <branch>	13:29
rafasc	or stash it selectively with stash -p.	13:29
localhorse	rafasc: and how to unstash selectively?	13:29
rafasc	localhorse: use jast suggestion. convert stash into a branch and checkout -p from there.	13:30
jast	once you've created a branch, 'unstashing' is much easier (directly doing checkout -p on a stash is a bit wonky IMO)	13:30
rafasc	jast: never noticed stash branch :O	13:30
jast	it's been around for a long time, actually	13:30
	→ SerialSmile joined	13:30
rafasc	I keep using: git checkout -p stash@{n}; directly.	13:30
localhorse	jast: rafasc: is there no way to unstash individual changes/hunks?	13:30
rafasc	localhorse: no	13:31
localhorse	(without turning stash into a branch)	13:31
	ok	13:31
	← carb0n_ left	13:31
localhorse	`git checkout -p stash@{n}` will pull it from stash but it will stay stashed, right?	13:31
rafasc	you can try using: git checkout -p stash@{n}; but that won't remove it from the stash.	13:31
localhorse	ok	13:31
	but it would be the same issue with a temp branch, right?	13:32
jast	yes, but it will be much less smart about applying changes correctly	13:32
localhorse	jast: why?	13:32
jast	'git stash branch' automatically drops the stash if the branch gets created cleanly and without conflicts	13:32
rafasc	because stash can stash multiple states. index, uncommited, untracked, etc..	13:32
jast	stashes store 2-3 sets of changes, as rafasc said	13:32
localhorse	jast: but i mean, if i do `git checkout -p <branch>` on the stash branch, it will also not remove it from that branch	13:33
rafasc	when you use stash@{n}, I think you're using the 'index' if I remember correctly.	13:33
jast	to do that, a stash is internally a reference to a special commit with multiple parents; each parent is one of these changesets	13:33
	→ hussam joined	13:33
rafasc	so depending, you would need to do things like stash@{1}^2; <- this is obscure..	13:33
localhorse	what does the number in {} represent vs after ^ ?	13:34
	{1} is the top of the stash stack?	13:34
rafasc	parent number. No, top is 0.	13:35
jast	okay, I looked it up - the base stash commit contains the working tree changes; the first parent is the original base; the second parent contains the index changes; the third parent contains untracked files	13:35
	so if all you care about is the working tree changes, I guess directly doing 'checkout -p' on the stash will probably work decently	13:36
localhorse	maybe i'm approaching this problem the wrong way. is there a mainstream solution for splitting a set of uncommitted changes into a set of causal commits? (i can't believe there is no easy solution, as this must be quite a common issue)	13:36
jast	repeatedly use 'git commit -p'	13:36
	or 'git add -p' and 'git commit'	13:36
localhorse	but for compiling & running tests i can't leave changes that i don't want to commit in the working dir	13:36
	i only want to commit if it compiles & passes tests	13:37
jast	well, commit a set of changes. stash. compile/test. pop stash. rinse, repeat.	13:37
	the commit is local only so you can always undo/change it if the compile/test fails.	13:37
localhorse	yes but that requires me to add the full set of changes manually for every try	13:37
jast	uh... no?	13:37
localhorse	i am looking for an easy way to move changes between the stashed and staged sets	13:37
	→ guardian joined	13:38
localhorse	jast: the `commit a set of changes` part doesn't require me to add each change individually for every try?	13:38
jast	no	13:39
localhorse	so how can i undo the commit while keeping those changes staged?	13:39
jast	if you run tests and determine that the commit is not done yet, just add more changes and commit --amend	13:39
localhorse	yes but what if i want to remove some changes?	13:39
jast	or 'git reset --soft HEAD~' to undo the commit but keep working tree and index intact	13:39
	then you 'git reset -p HEAD~' those changes, commit --amend	13:40
	← swalladge left	13:40
jast	or use the reset --soft opion if you prefer	13:40
	→ CEnnis91 joined	13:41
localhorse	jast: and the ~ stands for the commit before HEAD?	13:42
jast	yes	13:42
localhorse	and HEAD^ ?	13:42
jast	all the syntax explained here: man gitrevisions	13:42
gitinfo	the gitrevisions manpage is available at https://gitirc.eu/gitrevisions.html	13:42
localhorse	thanks	13:43
jast	HEAD^ and HEAD~ are the same thing	13:43
localhorse	ah ok	13:43
jast	but HEAD^2 and HEAD~2 are not :)	13:43
localhorse	:/	13:43
jast	^2 = second parent (only exists in merge commits), ~2 = go back two commits, following first parents	13:43
rafasc	~is depth search, ^ is breath search.	13:43
jast	when you need a number, ~ has more use cases in most situations	13:44
localhorse	so you can combine them in a chain like HEAD^n~m^k~i ?	13:44
rafasc	yes	13:44
localhorse	to navigate the parent tree	13:44
	ok	13:44
jast	you could, but that's usually not worth the hassle	13:44
localhorse	makes sense, thanks :)	13:44
	and the index is the commit chain?	13:45
rafasc	no	13:45
jast	nah, the index is what you have staged	13:45
localhorse	ah ok	13:45
jast	it's also called staging area	13:45
rafasc	the index is what is turned into a commit when you commit.	13:45
osse	I call it Gareth	13:45
jast	basically creating a commit copies the index	13:45
localhorse	and `~` is shorthand for `~1`, same with `^`?	13:46
jast	yep	13:46
localhorse	ok	13:46
rafasc	you can even use silly things like: HEAD~~~~~~~~~~~~	13:46
	→ jungsubk joined	13:47
	→ bluezone joined	13:47
rafasc	git rev-parse will convert it into a hash. If you want to play with it.	13:48
localhorse	so `git reset --soft -p HEAD~` will undo the last commit, but move its committed changes to staged, and move the specified change from staged to unstaged/modified?	13:48
rafasc	--soft will do nothing but move the branch pointer back one commit.	13:49
	That implies that you keep the index and worktree, from it.	13:50
localhorse	and without --soft?	13:50
benharri	--mixed is the default	13:50
rafasc	you cannot use --soft with -p.	13:50
	what I said was for just --soft.	13:51
oxymoron93	^	13:51
jast	git reset -p <commit> just lets you selectively apply changes from another version to the index	13:52
	and git reset --soft changes the branch pointer without doing anything else	13:53
localhorse	jast: another version in another branch?	13:53
jast	so since, after committing, your index remains unchanged, changing the branch pointer back to HEAD~ will undo the commit but keep the index as it was when you committed	13:53
	_any_ version	13:53
	but usually you'll be wanting a version that is quite similar so you don't have to work through thousands of lines of diff	13:54
localhorse	but i thought committing doesn't leave the index unchanged, it clears the index	13:54
jast	that's a common misconception	13:54
localhorse	ah	13:54
jast	think of the index as a snapshot that will become a commit	13:54
localhorse	ah, index is just a diff, right?	13:54
jast	all of your unchanged files are in the index, too, they're just identical to the checked out version	13:54
	and if you diff the two, they don't show up	13:54
localhorse	so it's a diff of an empty set of changes	13:54
	ok	13:55
jast	the index contains all of the file data	13:55
rafasc	localhorse: it's the other way around. the index is the entire snapshot of your project.	13:55
jast	and in a diff you don't see most of that because the data is the same as in your working tree	13:55
rafasc	git status is the thing only showing diffs.	13:55
jast	yeah, same for 'git status' and friends	13:55
localhorse	ok. and when doing this workflow (doing a trial commit and reset --soft) a lot, it will create a lot of commits that won't become part of the pushed chain, but still take up disk space?	13:55
	or will they be auto pruned?	13:56
jast	but if you use the internal 'git ls-files' you'll see a list of all staged+unchanged files, taken straight from the index	13:56
osse	localhorse: they will be pruned eventually	13:56
localhorse	automatically?	13:56
	← jokajak left	13:56
osse	yep	13:56
jast	staging versions of files that you don't end up committing, and undoing commits, creates objects that are unreferenced and so, technically waste space	13:56
localhorse	osse: at what time?	13:56
	at push?	13:57
osse	localhorse: git automatically runs git gc after some operations that are expected to produce lots of objects, such as fetch and rebase	13:57
jast	git has heuristics to periodically run a cleanup during certain operations (e.g. fetch/pull)	13:57
localhorse	ah ok	13:57
jast	or you can manually 'git gc'	13:57
	even then there are a few safeguards to avoid losing objects you might still need, so in practice most of the time your objects will be kept for at least 14 days and usually 90 days or longer	13:57
avar	osse: s/lots of objects/objects/ though :)	13:57
osse	localhorse: specifically it runs git gc --auto	13:57
rafasc	usually the heuristics are good enough for 99.9% of the cases. Actual statics I made up right now.	13:58
	← jungsubk left	13:58
	← Makaveli7 left	13:58
osse	avar: I was just quoting the docs. But the docs say "many"	13:58
jast	let's say "potentially many"	13:58
localhorse	jast: rafasc: thanks for being so patient with me :) so i guess the most convenient workflow would be to do trial commits, then git stash, compile & run tests, if it fails, git reset --soft HEAD~, git stash pop, unstage some changes & stage others, git commit --amend, git stash, compile & run tests again.. right?	13:59
	→ dpyro joined	13:59
jast	sure, that's one way to do it	14:00
avar	urgh, more docs that are mostly lies :(	14:00
	→ jungsubk joined	14:00
osse	?	14:00
jast	but you can also do something a little fancier	14:00
	← pd09041999 left	14:00
	→ jokajak joined	14:00
rafasc	localhorse: the most covenient will depend on preference. But right now, you have more information than you started to choose what's convenient for you. :)	14:01
localhorse	and with `git add -p` i can stage AND unstage individual changes?	14:01
jast	git has this super-powerful feature called 'interactive rebase' that allows you to restructure commits after the fact, and it makes it particularly easy to reorder or combine commits	14:01
	'git add -p' stages, 'git reset -p' unstages	14:01
localhorse	jast: yes but i want to ensure that at every commit in time, the codebase compiles & passes tests	14:01
	← dpyro left	14:02
jast	well	14:02
localhorse	with interactive rebase it would be easy to screw that up	14:02
jast	it starts mattering a lot at the time you actually share those commits	14:02
localhorse	true but i'm a perfectionist ;)	14:02
jast	I do a lot of commit editing before ultimately making sure they are all clean, and pushing them	14:02
avar	osse: I mean in reality it's just run after various top-level porcelain commands, nothing to do with "many" or "loose"	14:02
rafasc	rebase can actually help with that. With -x, you can run a test in a sequence of commits.	14:02
	← nic-hartley left	14:02
localhorse	jast: and you use interactive rebase for that?	14:02
jast	well, you can make your own choices, of course. perfectionism, of course, tends to require more work. :}	14:03
localhorse	but it only allows reordering and combining on the granularity of commits, not changes, right?	14:03
jast	yeah, I usually make a bunch changes, the commit them in chunks	14:03
localhorse	for that it would be cherry pick, right?	14:03
jast	then I start testing and if I notice any breakage, I make extra commits that fix up the previous issues	14:03
osse	avar: yes, that's true. But the "some" in "some top-level commands" is the clue. It's run after fetch, for example, but not add.	14:03
jast	finally I reorder and squash the commits as needed	14:03
localhorse	jast: yes, that's what i've been doing until now..	14:03
rafasc	localhorse: you can use 'edit' to edit changes or and even add new commits on the fly.	14:03
avar	osse: yeah, there's the assumption that "add" will be followed up with "commit"	14:04
jast	if you want it to, rebase will rewrite each commit, stop, let you look at it and potentially change it before it goes on to the next one	14:04
	interactive rebase, that is	14:04
	that's less useful if you think you might need to move a change from a later commit to an earlier one, but quite useful for most other scenarios	14:05
	→ baako joined	14:05
localhorse	jast: btw, how do you avoid the situation where you rebase, there is a conflict, you fix it, git rebase --continue and then you realize you missed something in the conflict resolution step, so the codebase doesn't compile. do you redo the whole rebase?	14:05
	→ nic-hartley joined	14:06
localhorse	or can you jump to that step again?	14:06
jast	you can, but it takes a little bit of manual work	14:06
osse	avar: ok, it's not run after commit --amend either	14:06
	avar: but whatever	14:06
localhorse	jast: what would be the most "pro" way to do it? :)	14:06
baako	hi guy says i have over 2k files to commit but thats not true. When I look in some of the files I see "file contents are unchanged"	14:06
jast	basically you have to remove the failed commit, re-launch the sequence editor and re-insert the previous rebase command	14:06
osse	I was just quoting the docs. I'm not interested in argument which one of us knows exactly what went on inside the authors' heads at the time	14:06
jast	("re-launch the sequence editor" means: git rebase --edit-todo)	14:07
	baako: that sounds like mode changes	14:07
localhorse	jast: and then it will run the rebase and the only conflict it shows will the the one that you removed?	14:07
avar	osse: it is run on commit --amend	14:07
localhorse	so you won't have to do the other conflicts again	14:07
baako	jast: i did change the directory permission	14:08
localhorse	?	14:08
osse	avar: you're right. I give up. you win	14:08
baako	but dont know why git will care as I have not change the files name or file contents	14:08
osse	Feel free to submit a patch to fix the docs	14:08
avar	I'm writing those now :)	14:08
	Just saying that now they're mostly inaccurate	14:09
jast	localhorse: sorry, gotta go take care of some other things now	14:09
localhorse	ok :)	14:09
baako	what do I do please	14:09
osse	avar: I guess commit --amend is expected to produce (or leave behind) loose objects too?	14:09
	I mean they could have made it run on git diff...	14:09
jast	baako: git tracks which of its files are executable, so if you changed that, that would explain it. if you never want to track any permission changes in your repo, run 'git config core.filemode false'	14:10
	→ sQVe joined	14:11
jast	(this works on a per-repo basis. on platforms that don't really have 'executable' flags, e.g. windows, you may want to turn it off globally: git config --global core.filemode false)	14:11
	I gotta go now, good luck	14:11
avar	osse: I added it back to git-commit in a recent release, the point is not to have a porcelain workflow which will end up accumulating crap forever	14:12
	osse: ...which I discovered with some automated stuff that was doing "git commit" without a "fetch"	14:12
localhorse	Regarding stashing unstaged changes, I found a better solution than https://stackoverflow.com/questions/20028507/git-stash-uncached-how-to-put-away-all-unstaged-changes/34681302#34681302 namely `git stash -k -u` https://makandracards.com/makandra/853-git-stash-unstaged-changes The post is 8 years old though, is it still correct?	14:13
rafasc	!tias	14:13
gitinfo	Try it and see™. You learn much more by experimentation than by asking without having even tried. If in doubt, make backups before you experiment (see !backup). http://gitolite.com/tias.html may help with git-specific TIAS.	14:13
localhorse	found this, apparently someone uses that as their workflow for running tests only on staged files: https://stackoverflow.com/questions/41304610/run-tests-only-for-staged-files-git-stash-k-u-and-git-stash-pop-will-rais	14:16
	rafasc: but `git stash` is equivalent to `git stash push`, right?	14:18
rafasc	Calling git stash without any arguments is equivalent to git stash push.	14:19
	man git stash;	14:19
gitinfo	the git-stash manpage is available at https://gitirc.eu/git-stash.html	14:19
localhorse	thanks	14:19
	→ cdown_ joined	14:21
	← Lucas_Gray left	14:22
	→ CryptoDavid joined	14:22
	← tsdh left	14:22
localhorse	rafasc: btw, is the git stash bug mentioned in the answer fixed by now?	14:22
	→ Lucas_Gray joined	14:23
	← cdown left	14:24
	cdown_ → cdown	14:24
rafasc	that's not a bug. So no.	14:24
	!eek	14:24
gitinfo	[!eekaconflict] Merge conflicts are a natural part of collaboration. When facing one, don't panic. Read "How to resolve conflicts" in man git-merge and http://git-scm.com/book/ch3-2.html#Basic-Merge-Conflicts then carefully go through the conflicts. Picking one side verbatim is not always the right choice! A nice video explaining merge conflicts: https://www.youtube.com/watch?v=zz7NuSCH6II	14:24
	→ Anticom joined	14:25
Anticom	hey guys. When working with pull requests on github, git always wants to merge the branch again locally when i do a git pull on the branch that has been merged into after i perform the merge using github website after successful review	14:26
	Why is that happening and how can i solve that issue?	14:26
	Might it be due to some local git config on my system or is this "expected" behaviour?	14:26
BtbN	That depends entirely on how upstream merges your commits.	14:28
localhorse	rafasc: will `git stash pop --index` unstash changes that were part of a partially staged and partially stashed file (with `git stash -k -u`) correctly now?	14:28
BtbN	If they alter the commit message, or do a merge commit, history will be different	14:28
	That's why you work on branches and keep master clean	14:29
Anticom	BtbN: i'm merging the PRs using "create merge commit" on github	14:29
localhorse	the OP said > "After running tests and then git stash pop, it raises conflicts on file B because it is partial staged. I'm sure that I did not change file B when stashing and testing. I wonder how to auto-merge with git stash pop without any conflict just like before I stashed them."	14:29
BtbN	There's your reason then.	14:29
localhorse	so --index fixes this?	14:29
Anticom	which would do the same as doing "git checkout develop; git merge feature/abc --no-ff"	14:29
BtbN	yes	14:30
	→ pd09041999 joined	14:30
Anticom	but when i then do "git checkout develop; git pull" on my machine, git opens up my vim where it wants to merge again right away	14:30
	and i don't understand why that is	14:30
BtbN	the merge commit goes on top of the HEAD of develop. While your feature-branch is also on top of that very same HEAD.	14:31
	So you did merge the feature yourself locally?	14:31
	← pd09041999 left	14:31
BtbN	And then pulled?	14:31
Anticom	BtbN: no	14:31
rafasc	localhorse: nothing fixes it. You're bound to have conflicts when applying things that change neighbouring lines.	14:31
osse	Anticom: git log @{u}..	14:31
	← Fusl left	14:31
osse	that's the commits that need the merging	14:31
localhorse	rafasc: not neighboring lines, separate hunks!	14:31
	→ nurdie joined	14:31
	→ pd09041999 joined	14:31
localhorse	separate changes that `git add -p` classified as separate	14:32
Anticom	osse: but how would i avoid that from happening?	14:32
	→ gloomy joined	14:32
localhorse	when staging	14:32
BtbN	I still don't understand what you are even doing.	14:32
osse	Anticom: either rebase instead of pull, or put those commits somewhere else	14:32
localhorse	rafasc: so git stash pop --index should be able to merge them back without conflicts, right?	14:32
	← Noti left	14:32
Anticom	after all the branch has been merged on remote already so i should just be able to pull that merge commit, shouldn't i?	14:32
rafasc	localhorse: when you add -p twice, git updates the index. At that point, it has no information how the index came to be.	14:32
BtbN	If your develop is clean, and all work on the feature happened in a branch, yes.	14:32
	→ Fusl joined	14:32
osse	Anticom: yes, but you have local commits	14:32
	→ thiago joined	14:33
Anticom	osse: but what commits do i have that are not on the remote?	14:33
BtbN	How should we know?	14:33
Anticom	let's say i've got a develop and my feature branch. my local HEAD is sitting on top of the last commit on that feature branch and so does the remote HEAD, right?	14:33
localhorse	rafasc: so how can i merge the partially stashed & partially staged file back together as unstashed&unstaged/'modified'?	14:33
rafasc	localhorse: did you read the manpage of stash?	14:33
osse	Anticom: the ones listed by the command I mentioned	14:34
BtbN	git will only do a merge commit if it can't fast-forward, which means there have to be commits on develop that are not on the remote.	14:34
localhorse	yes	14:34
rafasc	it says right there: Applying the state can fail with conflicts;	14:34
	→ duncan1 joined	14:34
localhorse	rafasc: so how to solve those?	14:34
Anticom	osse: one sec, i'll set up a testing gh repo	14:34
	← Fusl left	14:34
rafasc	the same way you solve any conflicts.	14:34
localhorse	rafasc: ok but there would only be conflicts if the lines of changes overlap, right?	14:35
	i mean the "contexts"	14:35
	→ Fusl joined	14:35
localhorse	(not numeric line numbers)	14:35
	→ dege joined	14:35
	→ inkbottle joined	14:35
	← Fusl left	14:35
	→ Fusl joined	14:36
	→ t0th_- joined	14:37
t0th_-	hi, how i can remove a file from git history?	14:37
osse	t0th_-: !sensitive	14:37
gitinfo	t0th_-: [!filter_sensitive] You can use filter-branch to remove sensitive data from a repository's history. https://help.github.com/articles/remove-sensitive-data/	14:37
rafasc	it's not that simple. If you partially stash a change, and apply them in a different order, for example. You're susceptible to conflicts... it will all depend in the state of the index/working tree at the time of apply.	14:37
localhorse	rafasc: i won't partially stash a change, but i partially stash the set of changes in a file. but each change in a file will be either stashed or changed!	14:38
	← WarauSalesman left	14:39
localhorse	so then there won't be conflicts when unstashing and unstaging?	14:39
	(the same file)	14:39
Anticom	osse: So this is the scenario: https://github.com/Anticom/prtest/pull/1	14:39
	i checked out develop, did the initial commit, pushed it. Then i checked out feature/add-contents-to-hello, did a commit and pushed that as well	14:40
	this is my log: https://gist.github.com/Anticom/63a68382a3d4f4a5e947f7627b6afe4e	14:40
	← pd09041999 left	14:41
Anticom	what are the correct steps to take now to avoid a local merge and get back to develop with the feature branch merged?	14:41
osse	Anticom: if you merge that PR via the web interface and then run git pull locally that scenario won't happen	14:42
	→ Makaveli7 joined	14:42
Anticom	so i have to pull on feature/add-contents-to-hello not on develop?	14:42
	because that's what i usually do. "git checkout develop; git pull"	14:43
osse	Now I'm confused	14:43
	→ Inline joined	14:43
osse	Your original question was related to merging a PR on the web right?	14:43
Anticom	no it was all about avoiding git wanting me to merge the changes although they have been merged via the web ui already	14:43
osse	yes	14:44
	If you merge that PR online, and then git pull in develop that won't happen	14:45
Anticom	let's see^^	14:45
osse	if you now make a new commit on develop then it will	14:45
t0th_-	thanks	14:45
Anticom	osse: https://asciinema.org/a/zRY4QtbZv1hgEYuLqZE55mP7g	14:46
	exactly what i described :S	14:47
osse	Anticom: what does 'git config pull.ff' say ?	14:48
Anticom	might this be due to some local git config? (for example merge.ff = false)	14:48
osse	yes, exactly	14:48
rafasc	localhorse: idk, like I mentioned earlier, I prefer making commits and rewriting branches with rebase interactive. It's much more reliable than figuring out the intricacies of stash. You'll want to rewrite the branch anyways... so why not just do it in one go?	14:49
	→ Ayo joined	14:49
	→ DaGoaty joined	14:49
Anticom	hm ah so after the fetch git wants to ff merge to incorporate the remote changes, right osse ?	14:49
	→ hellauer joined	14:49
osse	Anticom: that tells git to create a merge commit even when there's not need	14:49
	*no need	14:49
localhorse	rafasc: because i have to split the set of changes into commits, not just reorder & stash commits	14:50
osse	Anticom: yes by default that's what git will do	14:50
	← rominronin left	14:50
Anticom	was hoping git was smart enough in that case. I set this option for convenience when merging stuff locally so i don't forget to add the --no-ff and ruin the history	14:50
	→ rominronin joined	14:50
osse	Anticom: I mean you can do git pull --ff-only	14:50
rafasc	localhorse: branches in git are dirty cheap. There's no reason to avoid doing local commits. With the advantage it is much easier to recover if you mess up. (reflog has your back). There's no index-log (yet).	14:51
	localhorse: you can add -p to split changes into commits.	14:51
Anticom	osse: and that would override the merge.ff=false for pulls?	14:51
rafasc	but I think me and jast already mentioned that.	14:51
localhorse	rafasc: yes but splitting the changes into commits is what i need to do.	14:51
osse	Anticom: yes	14:51
localhorse	rebase can't move changes between commits, right?	14:52
	so i can't use that	14:52
rafasc	IT CAN.	14:52
osse	interactive rebase can	14:52
rafasc	I also mentioned that.	14:52
localhorse	ok	14:52
	ah right	14:52
Anticom	osse: any disatvantages to be aware of when setting pull.ff=only permanently?	14:52
localhorse	btw, how can i do `git ls-files --modified` but ALSO get untracked files listed?	14:53
osse	Anticom: not that I can think of at the moment	14:53
localhorse	and staged files	14:53
rafasc	localhorse: you can stop at any moment during the interactive rebase with 'edit'.	14:53
	→ pd09041999 joined	14:53
Anticom	osse: great, thanks for the solution then :>	14:53
osse	localhorse: --modified --untracked	14:53
	I mean --others	14:53
rafasc	or the new 'break' command.	14:53
localhorse	osse: that also lists ignored files	14:53
	→ apoos_maximus joined	14:54
	← nic-hartley left	14:54
osse	--exclude-standard	14:54
rafasc	localhorse: you need to brush up your manpage reading skills...	14:54
localhorse	osse: thanks but that doesn't show staged files	14:54
Anticom	osse: $ git config --global pull.ff=only --> error: invalid key: pull.ff=only	14:54
	← wadadli left	14:54
osse	Anticom: use a space, not equals	14:54
Anticom	ah, cheers	14:54
	← rominronin left	14:55
	→ AbleBacon joined	14:55
	← hellauer left	14:55
osse	localhorse: that's a different beast... ls-files --stage	14:55
	i would guess that can't be combined with the others	14:56
rafasc	osse: actually, --cached	14:56
osse	git diff --staged --name-only	14:56
	rafasc: but he said staged	14:56
	not all tracked :P	14:56
	→ czart_ joined	14:57
rafasc	👍	14:57
	→ wadadli joined	14:57
rafasc	but --stage is still the wrong answer. :P	14:57
	but you already fixed that.	14:57
osse	in that case there is no right answer	14:57
	→ rominronin joined	14:57
	← rominronin left	14:57
	→ rominronin joined	14:58
osse	there's no way to make ls-files to all at once	14:58
localhorse	i want to be able to zip all modified AND untracked files into a zip, like this: https://stackoverflow.com/questions/4126300/git-how-to-get-all-the-files-changed-and-new-files-in-a-folder-or-zip/4126342#4126342	14:58
	but with untracked and staged files, how?	14:58
	→ ghoti joined	14:58
	← YuGiOhJCJ left	14:59
osse	{ git diff --staged --name-only -z; git ls-files --exclude-standard --others -z; } \| tar --null --files-from=- -C -cf files.tar	14:59
rafasc	localhorse: can I ask why?	15:00
Anticom	tried it again, works a treat! thanks again :)	15:00
localhorse	rafasc: as a backup if i mess up	15:00
rafasc	because this feels like is trying to solve the problem git was designed to solve.	15:01
	make a branch; commit everything. No need for messing around with zip files.	15:02
Anticom	localhorse: i usually just do "cd ..; cp -r <orig> <orig>.backup; cd <orig>; # do potentially messy stuff"	15:03
osse	I wrote that command line directly on IRC	15:03
	So be careful	15:03
	Untested, untrusted, unloved	15:03
localhorse	Anticom: but i want to exclude the git ignored files because that would be 100gb+	15:03
Anticom	fair enough	15:04
localhorse	rafasc: but if i commit it to a tmp branch, i lose the state of what's modified/staged/untracked etc.	15:04
Anticom	maybe there's an inverse of git check-ignore ?	15:05
	← t0th_- left	15:05
Anticom	to list all not ignored files and simply put them into an archive	15:05
	git check-ignore -n i guess?	15:05
	→ Envil joined	15:06
rafasc	localhorse: you only lose the untracked state, which can be solved by committing the untracked files separately.	15:08
	localhorse: you know what? forget what I've said.	15:08
	→ johnstonf joined	15:09
	→ Beam_Inn_ joined	15:09
	← Khisanth left	15:09
localhorse	huh, why did `git stash -k -u` try to rm an ignored dir?	15:10
rafasc	because you told it to with -u.	15:11
	← Beam_Inn left	15:11
	Beam_Inn_ → Beam_Inn	15:11
localhorse	but it was ignored!	15:11
rafasc	-k is --keep-index. It has no effect on untracked files.	15:11
localhorse	rafasc: how can i only refer to untracked non-ignored files?	15:11
_ikke_	And note that at this moment in git ignoring files / directories means they are expendable	15:12
rafasc	^^^ x100	15:12
localhorse	_ikke_: but they aren't	15:12
	i just don't want them in the repo	15:13
_ikke_	(there is a discussion going on in the git mailing list to introduce the concept of precious files)	15:13
localhorse	and why did `git stash -k -u` ALSO seem to have stashed my staged files?	15:13
	at least according to `git stash show`	15:13
	→ swalladge joined	15:13
	→ GreenJello joined	15:14
rafasc	because that's what git stash does. Staged changes files are in the index. --keep-index only controls if you get to keep the index after the stash. But the index is always stashed away.	15:15
_ikke_	On a related note, does oneone else always get conflicts when restoring a stash created with -k?	15:16
	I never seem to get that to apply cleanly	15:16
	s/oneone/anyone	15:16
osse	I for one was surprised when I first learned --include-untracked also took ignored files	15:17
rafasc	_ikke_: hmm.. is that always literal?	15:17
	→ tang^ joined	15:18
_ikke_	rafasc?	15:18
rafasc	because I can create a stash with -k, and it pops with no conflicts.	15:19
johnstonf	If I have ssh key, do I use same key for all pc's and macs I have? Or need new for each?	15:19
_ikke_	johnstonf: That's more security related than anything else	15:19
	← andrzejv left	15:19
johnstonf	New to irc, should I talk somewhere else?	15:20
	← silenc3r left	15:21
localhorse	rafasc: i made a mistake. I already committed before unstashing unstaged files, so if i unstash now (`git stash pop --index`), it won't work?	15:21
_ikke_	You could try #ssh, but they are probably give a similar response. It's something you need to decide yourself	15:21
	→ hellauer joined	15:21
johnstonf	Its a choice?	15:22
_ikke_	yes	15:22
rafasc	localhorse: it will either work or ask you to resolve the conflicts. !tias.	15:23
gitinfo	localhorse: Try it and see™. You learn much more by experimentation than by asking without having even tried. If in doubt, make backups before you experiment (see !backup). http://gitolite.com/tias.html may help with git-specific TIAS.	15:23
localhorse	rafasc: NOOO, unstash didn't work, all my changes are lost :(	15:23
	→ Khisanth joined	15:23
_ikke_	Using the same key means you have to add your key only once on every destination, but a compromised key you have to replace it on every host you use it on	15:23
	→ gracecr joined	15:23
localhorse	rafasc: https://www.irccloud.com/pastebin/q4QkYFnP/	15:24
	how can i unstash then?	15:24
rafasc	localhorse: a failed apply doesn't drop the stash.	15:24
	← Novae left	15:25
localhorse	i'm using this script (2nd half): https://stackoverflow.com/questions/41304610/run-tests-only-for-staged-files-git-stash-k-u-and-git-stash-pop-will-rais	15:25
	→ Novae joined	15:25
localhorse	when stashing, it also said `warning: failed to remove test_postgres_data/: Directory not empty`	15:25
	test_postgres_data is in .gitignore	15:25
	i didn't even want to stash it	15:26
	so how can i unstash now?	15:26
johnstonf	I'm not worried about compromised key	15:26
localhorse	ah `git stash pop --index` worked	15:27
	← theoceaniscool left	15:27
_ikke_	johnstonf: then I would use the same key	15:27
johnstonf	But I hear ya	15:27
localhorse	so i guess `git clean -df` threw that error?	15:27
	← chele left	15:28
localhorse	how can i do `git clean -df` but not cleaning ignored files/dirs?	15:28
rafasc	localhorse: it's in the manpage of git clean.	15:28
johnstonf	If I put separate key on each, do I use one private key, or multiple -one per each) on my git-server (on my nas)?	15:28
osse	that's what git clean -df does	15:28
localhorse	rafasc: and how can i do `git stash -k -u` but not stashing ignored files/dirs?	15:28
	← gloomy left	15:30
	← agowa338 left	15:31
johnstonf	#worldnews	15:33
rafasc	johnstonf: take this /j	15:35
	→ gloomy joined	15:36
	← hellauer left	15:37
	→ fattredd joined	15:38
	→ hellauer joined	15:39
	← Snoober left	15:39
	→ hiram_abiff joined	15:39
johnstonf	rafasc: tx	15:39
	← al-damiri left	15:40
	← dege left	15:40
	→ duderonomy joined	15:40
	← swalladge left	15:41
fattredd	Hey all. I've got a git filter that takes 1000x longer to run than the perl script it's calling. More info here: http://ix.io/1DS1	15:41
	Why is it taking so much longer? Can I reduce that?	15:42
_ikke_	fattredd: possibly because it's doing a lot of redundant work	15:43
	and a lot of disk IO	15:43
	git filter-branch is not optimized for speed	15:43
	← Mattiaslndstrm left	15:43
rafasc	fletom86: have you tried putting that oneliner in their own script? Maybe it's something gone wrong with the escapes?	15:43
fattredd	Nah it's not a filter-branch. It's a clean/smudge filter	15:43
rafasc	_ikke_: ^	15:44
_ikke_	ah	15:44
rafasc	tagged wrong person, oops.	15:44
	fattredd: you .gitattributes may be matching multiple files?	15:45
_ikke_	rafasc: now i'm offended :P	15:45
rafasc	no, your tag was correct. fletom_86 was the one I tagged by mistake. (_ not tagging him again)	15:46
	← adder left	15:48
	→ SuperL4g joined	15:48
	← sQVe left	15:48
	← SuperLag left	15:49
	← fekir_ left	15:50
	← pd09041999 left	15:50
fattredd	I tried putting it in a seperate file (less escapes) and it's hanging now. Maybe I need to check on those escapes...	15:50
	→ jottr joined	15:52
	← kjartan left	15:52
	← jottr_ left	15:55
	← gloomy left	15:55
	→ kjartan joined	15:57
	→ Noldorin joined	15:58
	← zonixo left	15:58
	→ Es0teric joined	15:58
	→ mowcat joined	16:00
	→ gloomy joined	16:01
	→ boombatower joined	16:01
	← thiago left	16:05
fattredd	Good lord I hate escapes	16:06
	clean = perl -pe \"s/\\\\'[^\\\\']*\\\\'/\\\\'dummyText\\\\'/g\"	16:07
	That is the working answer	16:07
	→ [twisti] joined	16:07
	← xcm left	16:07
	→ xcm joined	16:07
[twisti]	for files, git has --assume-unchanged. is there something similar for submodules ? i have a submodule, that i locally updated, which i want to stay updated, but do not want to commit	16:07
jast	assume-unchanged is not designed for that use case and is not reliable for it	16:08
	in both cases, the reliable way is "don't stage any changes to those files/submodules"	16:08
rafasc	I think we can make the bot trigger automatically on the term --assume-unchanged. :/	16:09
jast	for files, sparse checkout / skip-worktree is an option... not sure if that works for submodules	16:09
	→ skeebo joined	16:09
jast	rafasc: I actually recommended assume-unchanged to someone the other day	16:09
	for its original purpose :)	16:09
rafasc	i'll have to check the logs! Unbelievable.	16:10
[twisti]	jast: wont i run into problems when i do things like rebasing with unstaged changes ?	16:10
jast	in terms of submodules, I don't think rebase even updates them... but don't take my word for it, I've just never actually checked	16:10
	→ pd09041999 joined	16:11
	→ Regon joined	16:12
	→ subopt joined	16:13
	← Beam_Inn left	16:13
	→ Mattiaslndstrm joined	16:13
	→ Beam_Inn joined	16:14
	← tm007 left	16:14
	← duncan1 left	16:14
subopt	Why do i need to fetch the latest changes of the remote for a subtree before i do `subtree pull` ?	16:15
	← Skinok-work left	16:15
avar	osse, jast : re earlier, fixed the gc docs a bit, now they should be mostly correct: https://public-inbox.org/git/20190318161502.7979-1-avarab@gmail.com/	16:16
	← oxymoron93 left	16:16
rafasc	subopt: I don't think you need to do that..	16:16
	← skeebo left	16:17
subopt	rafasc : that's what i thought, but i see people doing it in all the subtree tutorials i've looked at so far. Would there be any advantage to doing so?	16:18
	→ causasui joined	16:19
	← jakogut left	16:19
	← jungsubk left	16:20
rafasc	I think the difference is that with pull you will only fetch the branch in question, while fetch will sync all your remote-tracking branches.	16:21
	SuperL4g → SuperLag	16:21
rafasc	don't quote me on that though.	16:21
subopt	rafasc : thanks. I'll look into that.	16:21
	← hellauer left	16:22
	← foul_owl left	16:22
	→ impermanence joined	16:24
	→ foul_owl joined	16:26
	→ JoyBoy joined	16:32
	← Ayo left	16:34
	→ rsrx joined	16:40
	→ thiago joined	16:41
	→ swalladge joined	16:45
gracecr	"I think the difference is that with pull you will only fetch the branch in question, while fetch will sync all your remote-tracking branches." - rafasc	16:46
kadoban	xD	16:46
gracecr	sorry	16:46
	← Lucas_Gray left	16:47
rafasc	gracecr: I told them to no not quote me, I am pefectly fine with your quotes <3	16:47
	← mra90 left	16:47
gracecr	<3	16:47
	← pd09041999 left	16:50
	← JoyBoy left	16:56
	→ orbyt_ joined	17:00
	→ gareppa joined	17:01
	← swalladge left	17:01
	→ pd09041999 joined	17:03
	← Tobbi_ left	17:06
	← yyy left	17:07
	→ fatalhalt joined	17:08
	→ AtumT joined	17:09
	→ bviktor joined	17:11
bviktor	is there a way to specify the username as a variable in the .gitmodules remote address? e.g. url = ssh://$username@gerrit.foobar.com:29418/foo/bar.git	17:13
	→ swalladge joined	17:14
	← fattredd left	17:20
	← Anticom left	17:20
	← swalladge left	17:22
	← hahuang65 left	17:22
	← subopt left	17:23
	→ hahuang65 joined	17:24
	→ moei joined	17:27
	→ hahuang65_ joined	17:28
	← hahuang65_ left	17:30
	← hahuang65 left	17:31
	← rominronin left	17:33
	← mikecmpbll left	17:33
	→ rominronin joined	17:34
	→ hahuang65 joined	17:34
	→ HZun joined	17:37
	→ hahuang65_ joined	17:37
	← rominronin left	17:38
	→ quackgyver joined	17:38
canton7	bviktor, not aware of any, but note that you can use relative paths in .gitmodules, which means you can inherit the user+host of the parent repo	17:38
	→ Dirak joined	17:40
bviktor	you can, unless your submodules are on several hosts :)	17:40
	← gareppa left	17:40
Dirak	Is it possible to have `git checkout -b` act as `git checkout` if the branch already exists?	17:41
bviktor	i just don't understand why gerrit would enforce a _variable_ in their remotes	17:41
	← hahuang65 left	17:41
bviktor	i settled with git config url insteadOf	17:41
	← Es0teric left	17:41
bviktor	and then in jenkins jobs we prepend jenkins@ to the submodule url and all is well - theoretically	17:42
	→ Brilpikk3wyn joined	17:43
	← Brilpikk3wyn left	17:43
	→ rominronin joined	17:43
	→ hahuang65 joined	17:43
	← hahuang65 left	17:44
bviktor	git config --global url."ssh://jenkins@gerrit.foobar.com:29418/".insteadOf "ssh://gerrit.foobar.com:29418/"	17:44
	→ rominron_ joined	17:45
	← rominronin left	17:45
	→ SuperL4g joined	17:45
	← rominron_ left	17:45
	← gloomy left	17:45
	→ swalladge joined	17:45
	→ hahuang65 joined	17:46
	← hahuang65_ left	17:46
	→ gloomy joined	17:46
	← SuperLag left	17:47
	SuperL4g → SuperLag	17:47
	→ rominronin joined	17:48
	← hiram_abiff left	17:48
	← swalladge left	17:50
	→ borkr joined	17:52
	→ durham joined	17:52
	← rominronin left	17:56
	← durham left	17:57
	→ yyy joined	17:57
	→ rominronin joined	17:58
	→ Sasazuka joined	17:58
	→ renich joined	17:58
	→ sbeyer joined	17:58
	← shiva__ left	17:59
	→ in1t3r joined	17:59
	← orbyt_ left	18:03
	← DaGoaty left	18:05
	→ orbyt_ joined	18:06
	→ Lauven joined	18:10
	← rominronin left	18:11
	→ rominronin joined	18:12
	← irqq left	18:12
	← jstimm left	18:14
	→ __rohit joined	18:18
	→ greggerz joined	18:19
	← rsrx left	18:20
	→ funkytwig joined	18:21
	→ subopt joined	18:21
funkytwig	Hi, think I buggered up my remote trying to change https to ssh, thing I did a git 1, not 2 thing	18:23
	git remote set-url origin [email@hidden.address]	18:23
	← kreyren left	18:23
_ikke_	so what is wrong with that?	18:23
	→ swalladge joined	18:23
funkytwig	I get 'fatal: 'git@github.com/ben-tvpp/malmesburyonline.git' does not appear to be a git repository	18:24
	→ awalvie joined	18:24
_ikke_	The first / needs to be a :	18:24
funkytwig	it was ' Fetch URL: https://github.com/ben-tvpp/malmesburyonline.git'	18:24
	cool, ta	18:24
	← R2robot left	18:26
	→ R2robot joined	18:27
	← subopt left	18:27
	← xcm left	18:27
	→ xcm joined	18:28
	← sauvin left	18:29
	← fyuuri left	18:31
	← Lauven left	18:31
	→ rominron_ joined	18:31
	← gloomy left	18:33
	→ awalvie__ joined	18:34
	← rominronin left	18:35
	← awalvie__ left	18:44
	→ opalepatrick joined	18:44
	← awalvie left	18:44
	← rominron_ left	18:46
	→ omnireq joined	18:48
	→ m0viefreak joined	18:49
	→ rominronin joined	18:49
	← inkbottle left	18:52
	→ qxd joined	18:54
	← Beam_Inn left	18:55
	← baako left	19:00
	← rominronin left	19:02
	← SerialSmile left	19:04
	→ rominronin joined	19:04
	← kezimo left	19:05
	→ mixaz joined	19:06
	← orbyt_ left	19:06
	← rominronin left	19:09
	← fekir left	19:11
	→ fekir joined	19:11
	← raffo left	19:14
	← czart_ left	19:20
	→ gareppa joined	19:20
	→ kezimo joined	19:22
	← jelmer left	19:23
	← Dirak left	19:23
	→ irqq joined	19:24
	← irqq left	19:26
	→ irqq joined	19:27
	← pd09041999 left	19:27
	→ gloomy joined	19:29
	← Envil left	19:29
	→ jelmer joined	19:30
	← kapil____ left	19:31
	→ mona_x joined	19:31
	← gloomy left	19:33
	→ minimal_life joined	19:36
	→ hinbody joined	19:38
	→ wyre joined	19:40
	← gordonfish left	19:43
	← shabius left	19:44
	→ shabius_ joined	19:44
	→ gordonfish joined	19:45
	← bviktor left	19:45
	← nasamuffin_ left	19:47
	← GreenJello left	19:47
	→ GreenJello joined	19:47
	→ nasamuffin_ joined	19:49
	← minimal_life left	19:50
	← mona_x left	19:51
	← T_UNIX left	19:52
	→ rominronin joined	19:52
	→ nowhereman joined	19:52
	← mattcen left	19:52
	← emsjessec left	19:54
	→ mattcen joined	19:56
	← rominronin left	19:56
	→ Dirak joined	19:59
	→ Phylock joined	20:02
	→ gloomy joined	20:05
	← CryptoDavid left	20:05
	← Dirak left	20:06
	→ orbyt_ joined	20:10
	→ kerframil joined	20:10
	← gareppa left	20:10
	← gloomy left	20:11
	← SkarmoutsosV left	20:13
	← swalladge left	20:13
	← mattcen left	20:14
	← nowhereman left	20:14
	← orbyt_ left	20:14
	→ Dirak joined	20:15
	→ plexigras joined	20:16
	→ rominronin joined	20:18
	→ mattcen joined	20:19
	← opalepatrick left	20:20
	← Mattiaslndstrm left	20:21
	→ Lucas_Gray joined	20:21
	→ jakogut joined	20:26
	← rominronin left	20:28
	← __rohit left	20:30
	← gracecr left	20:33
	← plexigras left	20:35
	→ swalladge joined	20:38
	→ oojacoboo joined	20:38
	→ plexigras joined	20:38
	← Regon left	20:44
	← toothlessg left	20:44
	→ nowhereman joined	20:48
	→ Olipro joined	20:49
	→ kreyren joined	20:49
	→ CrtxReavr joined	20:55
	→ inkbottle joined	20:55
CrtxReavr	If I just do a local git commit, where do the files go?	20:55
_ikke_	in the .git directory	20:56
	but not directly recognizable	20:56
CrtxReavr	Any identifiable subdir of that?	20:56
_ikke_	objects	20:56
	→ n3wborn joined	20:56
	→ r00t66 joined	20:58
CrtxReavr	file(1) reports these files as "zlib compressed data" but zcat(1) doesn't work on them.	20:58
	← renich left	20:59
	→ orbyt_ joined	20:59
thiago	zcat is not zlib data, it's gzip file format	21:01
	what are you trying to do?	21:04
	← nowhereman left	21:04
	← fekir left	21:06
	← Lucas_Gray left	21:06
	← r00t66 left	21:08
	← apoos_maximus left	21:09
	← Noldorin left	21:09
CrtxReavr	printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" \|cat - ./cf/e393e25528fb9f1b6ab7847e0a700f14076bfc \| gzip -dc	21:11
	That works.	21:11
	You have to prepend the zlib "magic number"	21:11
	← rickumali left	21:11
CrtxReavr	I just wanted to see the locally stored files in the repo.	21:12
	Anyways, thanks.	21:12
	← CrtxReavr left	21:12
	→ jstimm joined	21:17
thiago	it's: <type> <space> <size in ASCII> <NUL> then the contents	21:20
	the sme contents you can get with git cat-file <type> <hash>	21:20
	→ lucasb joined	21:20
rafasc	they're gone :(	21:24
	← shabius_ left	21:24
	← howell left	21:26
thiago	git_rehash() { (printf "%s %d\\0" `git cat-file -t $1` `git cat-file -s $1`; git cat-file `git cat-file -t $1` $1) \| sha1sum; }	21:27
	← boombatower left	21:29
	→ shabius joined	21:30
	→ boombatower joined	21:31
rafasc	using git is cheating. Otherwise wou would just use hash-object. :P	21:32
	← borkr left	21:32
	← iNs left	21:32
	→ iNs joined	21:33
rafasc	I know it still helps to understand the format.	21:33
	← swalladge left	21:34
	→ wootehfoot joined	21:38
	← localhorse left	21:40
	→ raffo joined	21:41
	← plexigras left	21:48
	→ swalladge joined	21:49
	← dcpc007 left	21:52
	← raffo left	21:53
	supernov1h → supernovah	21:57
	← greggerz left	21:57
	→ dege joined	21:59
	→ dcpc007 joined	21:59
	← nurdie left	22:00
	→ raffo joined	22:01
	← orbyt_ left	22:06
	← Makaveli7 left	22:13
	← mattcen left	22:13
	← qsx left	22:14
	← qxd left	22:15
	→ mattcen joined	22:17
	→ qsx joined	22:17
	→ hellauer joined	22:18
	← slacker_nl left	22:19
	→ bashfulshell joined	22:22
	→ orbyt_ joined	22:24
	→ socialoutcast joined	22:25
	← raffo left	22:26
	← socialoutcast left	22:27
	→ socialoutcast joined	22:28
	→ nic-hartley joined	22:30
	← staafl_ left	22:33
	→ staafl_ joined	22:33
	← hellauer left	22:42
	← AbleBacon left	22:43
	→ hellauer joined	22:43
	← likewhoa left	22:44
Sasazuka	seems like checking out branches (at least on mac) is case insensitive but if I do PR it is case sensitive - is there anyway to force git to be case sensitive?	22:44
	→ likewhoa joined	22:44
Sasazuka	PR on github that is	22:44
	core.ignoreCase is set to true for some reason	22:46
meejah	Sasazuka: I'm not on a mac, but I suspect that's because OS X's filesystem is case-insensitive (and git uses files to represent branch and tag names)	22:46
Sasazuka	meejah: ah I thought mac fs would be case sensitive	22:46
meejah	I believe it's "case tolerant": it will keep the case you give it, but also load files if you spec the wrong case? (also, my mac knowledge is kind of old now)	22:47
	← orbyt_ left	22:48
Sasazuka	I guess -- HFS saves the case of a file that is created or renamed but is case-insensitive in operation.	22:48
meejah	right, that's my understanding	22:51
	← kneeki\|a left	22:52
	← Phylock left	22:53
	← likewhoa left	22:59
	← socialoutcast left	22:59
	← thiago left	23:00
	← ChrisLane left	23:00
	→ Mattiaslndstrm joined	23:00
	→ orbyt_ joined	23:01
	← dege left	23:03
	← n3wborn left	23:03
	→ renich joined	23:04
	→ likewhoa joined	23:04
	→ thiago joined	23:04
	← mixaz left	23:05
	← likewhoa left	23:06
	→ likewhoa joined	23:06
	← egovirus left	23:06
	→ ChrisLane joined	23:07
	← orbyt_ left	23:15
	← tang^ left	23:18
	← sbeyer left	23:19
	→ orbyt_ joined	23:21
	← hellauer left	23:21
	← justanotheruser left	23:24
	→ justanotheruser joined	23:24
	← justanotheruser left	23:26
	← ChrisLane left	23:26
Hello71	that's called "case insensitive".	23:26
	→ justanotheruser joined	23:26
Hello71	if you're talking about shit like DOS short names that's "fixed case"	23:27
	but I don't think git even runs on DOS	23:27
jim	good chance you could port it to dos, I don't see a reason why there'd be sticking points on the port	23:28
	if it doesn't just compile without incident	23:29
rafasc	I am not so sure abou that.	23:30
jim	but I see your point, which is probably "who needs dos anyway"	23:30
rafasc	it already required some effort to build it for windows.	23:32
jim	what's the difference between "git init" and "git init ."?	23:32
meejah	nothing, AFAIK	23:32
rafasc	jim: none	23:32
jim	ok, so would it go to something like "it documents what I did"?	23:32
	→ __rohit joined	23:33
	→ ChrisLane joined	23:34
jim	ok, what's the difference between "git init ." and "git init foo"?	23:34
__rohit	jim: git init . => make current dir a git repo while git init foo => mkdir foo and make foo a git repo	23:36
meejah	one init's "current dir" and one inits a subdir?	23:36
	→ Beam_Inn joined	23:36
jim	git init foo, is it the equiv of mkdir foo ; cd foo ; git init .?	23:37
meejah	yes	23:37
__rohit	and cd ..	23:37
	if you want to look it that way	23:38
jim	oh ok	23:38
	← wootehfoot left	23:38
jim	thanks for the conversation	23:39
__rohit	:)	23:39
rafasc	git -C foo git init .	23:40
	just to complicate things even more :D	23:40
__rohit	rafasc: won't that result in dir not found?	23:41
rafasc	there's an extra git there.	23:41
__rohit	I mean is foo doesn't exist?	23:41
	s/is/if/	23:41
rafasc	__rohit: yes.	23:41
	git -C x; just does cd x; before running the command.	23:41
__rohit	;)	23:42
	rafasc: I was looking into the code for `git diff` thing we talked about earlier ... I could trace all the way down to `xdiffi.c` where `xdl_diff` is called ... but how to proceed beyond? can you help me?	23:43
	because ws_fix_copy use different params	23:43
	should I make a func then and there?	23:44
rafasc	I don't remember talking about that. You may be confusing me with someone else.	23:44
__rohit	how to handle it exactly?	23:44
	oh ... the "it would be nice if git diff --check actually generated whitespace free patch" one	23:45
	error free*	23:45
rafasc	oh, that I never looked into to it.	23:46
	__rohit sighs	23:47
__rohit	if you have time, can you guide me a little here?	23:47
rafasc	what I've said was that diff --check could generate a patch that if applied in would fix the whitespace errors.	23:47
__rohit	yes yes	23:47
rafasc	I have no idea if that's an easy task.	23:47
__rohit	I think somewhere here we should insert code? what say? https://github.com/git/git/blob/master/xdiff/xdiffi.c#L1027	23:49
	← orbyt_ left	23:49
	← oojacoboo left	23:51
	→ cfoch joined	23:51
	← jelmer left	23:52
	→ oojacoboo joined	23:52
	→ jelmer joined	23:53
	→ treehug88 joined	23:54
rafasc	__rohit: https://github.com/git/git/blob/master/diff.c#L3207 ?	23:55
__rohit	hmm	23:56
rafasc	I think it consumes the diff line by line and outputs fprintf(data->o->file, "%s%s:%d: %s.\n"	23:58
	when it finds errors.	23:58
__rohit	I appears so	23:59
	s/I/It/	23:59
rafasc	So I guess that instead of that, it could output a - line, followed by a + with the whitespaced fixed.	23:59
	but it is more complicated than that.. You need to build headers, etc...	23:59

Logs Search ←Prev date Next date→

Channels Documentation