IRCloggy #git 2022-03-25

Provider of IRC logs since 2005.

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

	2022-03-25
bn_work	hi, git 2.32.0, attempting to push a commit and was getting an error saying there were changes pushed that I needed to pull first, so I pulled and it did a merge commit message with ` 1 file changed, 2 insertions(+), 1 deletion(-)` , but how I do I see the merge commit lines? When I do `git show ` <commit#>, it just shows the commit # and message, that's it, vs the actual lines that changed?	00:02
	← jazzy left	00:02
	← wakeup left	00:04
BtbN	you need to look at the actual commits it merged	00:04
	the merge commit will only contain changes if there were conflicts to resolve	00:05
	and you generally do not want to create merge commits when pulling. They pollute the history	00:05
	git pull --rebase is much nicer	00:05
	← ghost43 left	00:06
	→ ghost43 joined	00:06
	← sa0 left	00:09
bn_work	BtbN: how do I know what it merged? it doesn't show anything when I look at it?	00:10
	→ sa0 joined	00:10
BtbN	it merged your local branch with the one you pulled.	00:10
bn_work	so how do I see what it did?	00:11
BtbN	What do you mean?	00:11
bn_work	it says ` 1 file changed, 2 insertions(+), 1 deletion(-)`	00:11
BtbN	If there were no conflicts, it just merged the two histories with a merge commit, and put it on top of the two diverged trees	00:11
	That's the changes the commits you pulled did. Not the merge commit.	00:12
bn_work	ok, so how do I see them?	00:14
rewt	easiest is to use gitk (or a similar gui)	00:14
	← sa0 left	00:15
parsnip	wait what?	00:16
	doesn't a merge commit have a diff?	00:16
	if the two tips were different	00:16
	i just tested this	00:17
bn_work	rewt: why can't `git show` show this? I don't want to see a graph of trees?	00:17
parsnip	maybe magit is doing some magic	00:18
bn_work	or IIRC, when one does a merge, it pulls the commit and it just shows up in the history?	00:18
parsnip	git show seems to work here	00:19
	→ chenqisu1 joined	00:19
parsnip	"it"?	00:19
	shows up where?	00:20
	are you referring to your git tool?	00:20
	merge pulls a commit?	00:20
rewt	bn_work, it can, if you can interpret what it's saying, but it's much clearer in a gui	00:20
parsnip	i'm confused by your terminology	00:20
	i might recommend staying away from pull, and using fetch, until you know the difference	00:20
bn_work	parsnip: it = git	00:21
	← Strom left	00:21
bn_work	parsnip: no, git itself, I'm using git directly	00:21
parsnip	`man git-show ==> For commits it shows the log message and textual diff. It also presents the merge commit in a special format as produced by git diff-tree --cc.`	00:21
gitinfo	the git-show manpage is available at https://gitirc.eu/git-show.html	00:21
bn_work	fetch just downloads	00:22
	right, so why isn't `git show ` <merge_commit#> not showing anything?	00:22
	→ Strom joined	00:22
bn_work	it's just 1 file, 2 insertions and 1 deletion	00:23
rewt	compared to what? a merge commit has multiple parents	00:23
parsnip	how strange, that merge commits don't have a diff	00:23
	strictly speaking	00:23
	← zeenk left	00:24
rewt	technically a commit in git is a snapshot of the dirs/files; diffs are comparisons between 2 commits	00:24
bn_work	so wait, when I do a merge commit, is it leaving behind those `>>>YOURS` and `<<< THEIRS` junk and I have to manually clean it up?	00:24
	(with default merge algo)	00:24
parsnip	it sort of makes sense. if they had a diff, it could be considered redundant to the ancestor diffs	00:24
rewt	yes, those are conflict markers that you have to resolve	00:24
parsnip	bn_work: works fine here	00:24
rewt	anything that git itself cannot resolve, you have to resolve yourself	00:25
	← reprazent left	00:26
bn_work	rewt: will it tell me if there were parts it couldn't resolve?	00:26
rewt	yes, those markers are around sections it cannot resolve	00:27
bn_work	I didn't get any notification that there were conflicts that I needed to resolve?	00:27
rewt	are you sure? git's feedback is quite verbose, and most people just gloss over most of it	00:28
	→ reprazent joined	00:28
	← NeilRG left	00:28
	← perrierjouet left	00:29
bn_work	It literally brought up my editor (vim) to type in a merge commit message, then exited	00:30
rewt	then there were no conflicts and you shouldn't see those markers	00:31
	unless they were there before	00:31
	on either branch	00:31
	→ perrierjouet joined	00:31
bn_work	sorry, looks like it used `recursive` strategy	00:34
	→ llh joined	00:34
	← Arokh left	00:35
bn_work	here's the log, ie: I basically tried to push, it mentioned the error, so I tried to pull first, and it immediately brought up the editor, I accepted it's proposed message, quit https://www.irccloud.com/pastebin/4kAjb9cJ/git_push_git_pull.log	00:36
	← zmt00 left	00:36
bn_work	rewt: so how do I see what it did?	00:37
	→ zmt00 joined	00:39
	← srinidhi left	00:43
	→ kaiseisei joined	00:43
	→ wilz joined	00:43
parsnip	bn_work: i'm confused. was there a conflict? how are you getting lines with `>>>YOURS` but no merge conflict?	00:44
rewt	bn_work, do you have those markers in that file?	00:47
	→ DoofusCanadensis joined	00:49
	← Rashad left	00:50
	→ Arokh joined	00:54
	← junktext left	00:55
	← Techcable left	00:55
	← BUSY left	00:57
	→ Techcable joined	00:57
	← clime left	00:57
	← jamiejackson left	01:00
bn_work	parsnip: I don't know, that's my point, lol. It didn't claim there was any, the output I got above was all I got. But was I supposed to? or does a merge commit just merge and leave you to resolve them? (normally I thought with merges, git tells you to commit the resolved version when done)	01:02
	→ BUSY joined	01:02
	← elastic_dog left	01:03
	← jstein left	01:04
bn_work	rewt: I'm not seeing any markers like that in `Baz/whiz-3.5_blah.bash` for ex	01:04
parsnip	do you have the markers	01:04
bn_work	parsnip: ? ^^^	01:04
rewt	do you have them in any file?	01:04
parsnip	i guess you were asking above, "today am i learning, that merges will be smooth unless there's a conflict, at which point there will be markers for what i need to resolve"	01:06
	← FinnElija left	01:06
	← perrierjouet left	01:06
parsnip	so you didn't mean that you saw markers in this particular merge instance	01:06
bn_work	rawtaz: I'm not seeing it any of the files in that dir. shouldn't it be constrained to what it mentioned it? ie: `Baz/whiz-3.5_blah.bash`?	01:06
	→ FinnElija joined	01:06
bn_work	parsnip: that's not a question, but ok :)	01:07
	← ghost43 left	01:07
parsnip	bn_work: can you share the result of `git show` for the merge conflict?	01:07
bn_work	parsnip: correct, I was just giving an example of what I normally associate with merge conflicts	01:07
	again though, how do I see what it merged???	01:07
	→ elastic_dog joined	01:07
parsnip	> so wait, when I do a merge commit, is it leaving behind those `>>>YOURS` and `<<< THEIRS` junk and I have to manually clean it up?	01:08
	→ ghost43 joined	01:08
	→ mud joined	01:08
parsnip	"today am i learning, x, y, z", is a question	01:08
	← jclsn left	01:08
rewt	bn_work, what do you mean by that? it merged the 2 parent commits; what you had as master and what master was on origin	01:08
parsnip	worrying about particular grammars doesn't seem useful at the moment	01:08
	← k8yun left	01:08
	→ perrierjouet joined	01:08
parsnip	you don't want to share the output of `git show` for the merge commit?	01:09
	(i meant git show for merge commit not merge conflict)	01:09
bn_work	`$git show 48379aa` `48379aa N 2022-03-24T19:56:04-04:00 JDoe.. Merge branch 'master' of https://github.com/Foo/Bar HEAD -> master`	01:09
	← thebombzen left	01:09
	← Codaraxis__ left	01:10
rewt	are you asking to see the diff between the merge commit and one of its parents?	01:10
bn_work	parsnip: ^^^	01:10
	that's literally all it shows	01:10
	rewt: sure	01:11
rewt	`git diff <parent>..<merge>` # replace <merge> with your merge commit, and <parent> with the parent you want to diff against	01:11
parsnip	that's not what git shows me for a merge commit	01:12
	→ jclsn joined	01:12
bn_work	rewt: ok, I think that worked	01:13
	parsnip: 🤷 maybe different git config settings?	01:14
parsnip	try `git show 197ff17` for https://github.com/bradyt/git-merge-example	01:14
	it shows me parent commits for example	01:15
	parent commit hashes	01:15
	so i'm not sure why your `git show` omits that	01:15
rewt	`git show` for a non-merge commit shows the diff relative to its single parent; `git show` for a merge commit doesn't show the diff because it won't pick a parent at random... but if there were conflicts that were resolved, I think it shows the resolution diffed against both parents	01:15
bn_work	rewt: so by merging like this vs rebasing, did I lose the original commit# & message from origin:master?	01:16
rewt	no, you created a merge commit with 2 parents; your master and origin/master... with --rebase, you would've ended up with a linear history with no merge commits	01:16
parsnip	i don't think i have much configured	01:16
bn_work	parsnip: can you show me what you see? do you just get a normal diff?	01:16
	→ roadie joined	01:17
	← jclsn left	01:18
parsnip	bn_work: https://dpaste.org/MoH4	01:19
bn_work	rewt: but the other parent is remote, no? or is the other parent copied locally (albeit hidden) as remote?	01:19
parsnip	oh, diff highlighting failed, raw would be better: https://dpaste.org/MoH4/raw	01:20
	← ferdna left	01:20
rewt	bn_work, when you fetch, you copy everything that's remote to your local repo	01:20
bn_work	rewt: right	01:20
parsnip	rewt: git show doesn't display a diff? that seems to contradict my example above, and what i quoted from man	01:21
	← roadie left	01:22
parsnip	fetch would have divergence, between origin/master, and master, i guess	01:22
bn_work	parsnip: interesting, yeah, I don't get that diff with `git show ...`	01:23
parsnip	i would imagine my workflow, would be to fetch, consider the graphical log, the changes in divergence, then decide what to do	01:23
bn_work	rewt: so is the reason I don't see the original remote commit + message is because it got squashed as 1 merge?	01:23
	→ jclsn joined	01:24
bn_work	rewt: if so, would rebase allow me to pickup the original commit + message?	01:24
rewt	parsnip, what you quoted is what i said (read the whole thing you quoted, and relevant sections of the other man page too)	01:24
	← warblr left	01:24
bn_work	rewt: I hesitated to use rebase as it normally changes commit #s rewriting history, no?	01:24
parsnip	if it seemed more complicated than a clean rebase, i might rename my local master, reset local master to origin/master, then consider the best way to adopt changes from my renamed branch	01:25
rewt	bn_work, not `git pull --rebase`	01:25
	← nyah left	01:25
bn_work	The other question is, can I do anything about it now :/ (FWIW, this is just a repo used only by me on 2 machines)	01:25
parsnip	er, add new branch at current local master, and reset local master to match remote	01:25
rewt	parsnip, did you resolve conflicts in that merge?	01:26
bn_work	rewt: uh, not following... so rebase wouldn't help?	01:26
parsnip	put a new branch ref on your local divergent "tip"	01:27
	rewt: i'm going to sound rude, but i'm trying to understand your question. does it look like there's a conflict there?	01:28
	← ghost43 left	01:28
parsnip	rewt: i provided an entire repo, if you missed it	01:28
	→ humanBird joined	01:28
rewt	parsnip, no, which is why i'm confused... I don't get diffs with git show either for a merge commit, and the man page also says it doesn't show it	01:28
	← duxsco left	01:29
	→ ghost43 joined	01:29
bn_work	parsnip: now I'm afraid to push commits from my other machine if pulling them down here with lose the original commit messages :/	01:29
	→ duxco joined	01:29
bn_work	s/with/will/	01:30
parsnip	rewt: i think we should ask bn_work for a log of current situation, advise to back things up, then consider resetting things towards what occurred before the pull	01:30
	i don't want to compete to give advice >.< i'd rather just come to a consensus	01:31
	i'm giving the benefit of the doubt that you know git more than me	01:31
	i forget the bot command to ask for a log	01:31
	duxco → duxsco	01:31
rewt	!log	01:32
gitinfo	[!irclog] Public logs of #git are kept at: https://gitirc.eu/log	01:32
rewt	nope	01:32
	!terminal	01:32
parsnip	for example, it seems relevant to ask if they pushed the merge to origin yet	01:32
	← jclsn left	01:32
parsnip	in fact, i would guess they can leave master where it is currently, put a temporary branch on the old local commit, and test how the rebase would work from there, to the old origin/master	01:34
rewt	yea	01:34
bn_work	FWIW, (luckily) I can rewrite history if I really need to (I know it's usually not good practice, but 99% I'm the only one using this repo)	01:34
parsnip	assuming they thing rebase is better	01:34
rewt	i recommended gitk because it's so much clearer seeing the history visually than to figure it out on the command line (and possibly misinterpreting the output)	01:35
bn_work	parsnip / rewt: what I've been doing is basically development on two machines and doing a git pull accepting the merge commit then pushing the local commit to remote	01:35
parsnip	*think	01:36
rewt	bn_work, if it's the same branch, `git pull --rebase` is generally better ... the only history it's rewriting is your local history only of the commits since the divergence, replaying them back on top of what you fetched from the remote	01:36
bn_work	there's also only 1 branch (and one dead branch from long ago)	01:36
	it's really simple dev workflow now (ie: just me)	01:36
	(although may change soon in the future)	01:36
rewt	even for multiple people, if you want to "catch up the current branch to its latest version, keeping any changes", `git pull --rebase` is the best option	01:37
	i'm not sure what you meant here: <bn_work> rewt: so is the reason I don't see the original remote commit + message is because it got squashed as 1 merge?	01:38
	there was no squashing that you mentioned, so everything should still be there	01:38
bn_work	rewt: ok, so reset hard or so? (I forget the specific variant I need) and re-pull with `git pull --rebase`? (I've rebased interactively before but only locally and not in the context of a merge... or maybe I have long long ago, it's been a while since I've had to deal with merges- I try to avoid them, lol)	01:39
	→ jclsn joined	01:39
bn_work	reset to pre-1st merge	01:39
rewt	no, just `git pull -rebase`	01:39
	why reset?	01:39
	if you want to try that now, you have to unwind the merge commit first	01:41
	→ sa0 joined	01:43
	→ seds joined	01:44
parsnip	y'all not reading what i'm saying, i'm out	01:44
	gitk didn't come with my install	01:45
rewt	it's packaged separately on linux	01:46
bn_work	rewt: because it's already been merged?	01:46
	don't I need to rewind back to before the 1st merge?	01:46
rewt	what 1st merge?	01:47
parsnip	reset would be one way to unwind	01:47
	→ Codaraxis joined	01:47
bn_work	parsnip: you mean the suggestion to backup and create new temporary branches? sounds very complicated :/	01:47
	← jclsn left	01:47
bn_work	rewt: I've already done at least two merge commits during the pull	01:48
	← perrierjouet left	01:48
bn_work	and subsequently `git push`-ed so my other machine could see it and pull it down	01:48
rewt	pull is only a single merge.... git pull is the same as git fetch followed by a single git merge	01:48
bn_work	sorry, what I said was unclear, I've done at least 2 merge commits in separate pulls	01:49
rewt	you have multiple remotes?	01:49
parsnip	!backup	01:49
gitinfo	Worried about your data while trying stuff out in your repo? The repository in its entirety lives inside the .git directory in the root of your work tree so to backup everything `cp -a path/to/workdir path/to/backup` or equivalent will suffice as long as the repo is not modified during backup. See also http://sethrobertson.github.io/GitBestPractices/#backups	01:49
bn_work	rewt: no	01:49
	for this repo?	01:50
parsnip	bn_work: i can't imagine using git without being comfortable with creating temporary branches	01:50
	i do it all the time	01:50
bn_work	parsnip: I guess branching isn't that hard, I just hope it doesn't make subsequent merges complicated	01:50
parsnip	i suggested we get a log	01:50
	noone listens to me	01:50
bn_work	parsnip: I've been trying to keep my workflow as simple as possible	01:51
rewt	`git branch tempbranch` creates a branch at the current commit, so you can reset to wherever you want, and you can get back to this same one if something goes wrong	01:51
	→ pyeverything joined	01:51
rewt	a branch in git is just a pointer to a specific commit	01:51
bn_work	rewt: yeah, I think that's what parsnip was suggesting	01:51
rewt	yes	01:52
	→ jclsn joined	01:52
bn_work	I was just worried it would interfere with subsequent pulls since the entire repo is compared during a pull for conflicts?	01:52
parsnip	bn_work: we're not at the same computer as you, trying to give commands. it's too easy of a possibility to mess something up. suggesting to back up your repo is a safe request from my point of view	01:53
bn_work	rewt: so why wouldn't I need to do a reset?	01:53
rewt	depends on what you want to accomplish	01:53
bn_work	parsnip: is it just copying out the entire tree?	01:53
	rewt: like I said, I just want to get the original commits & their message from my other machine that was pushed, and vice versa	01:54
	right now I think they are just showing up as merge commits	01:54
rewt	bn_work, no, creating a branch is essentially creating a new "thing" that says "this is the commit i'm pointing at", doesn't copy anything, doesn't duplicate anything, and lets you easily get back to the same point	01:54
	bn_work, the ony merge commits you have are the merge commits you created with `git merge` (remembering that `git pull` is just short-hand for `git fetch && git merge`)	01:55
parsnip	iiuc, typically a merge looks at two commits, often implicit	01:55
	er	01:56
	← pyeverything left	01:56
parsnip	one branch ref, and usually one other implied commit, maybe	01:56
	← jclsn left	01:56
	→ jclsn joined	01:56
bn_work	rewt: yes, I was asking parsnip about what he defined as "backing up"	01:57
parsnip	i think we really need a log, to more easily advise	01:57
bn_work	rewt: so again, why don't I want to git reset back to before I first did my first merge commit?	01:57
parsnip	the --oneline --graph --decorate or w/e variety	01:57
	they're describing two merges, i think a log will clear it up	01:58
	bn_work: just copy the directory, like `cp foo foo.bak`	01:59
bn_work	parsnip: ah, ok, one sec	01:59
parsnip	bn_work: if something goes wrong, you have a backup. if nothing goes wrong, you delete it	01:59
	because you're asking for advice across text based chat	01:59
rewt	bn_work, best if you pastebin the output of `git log --oneline --graph` as parsnip says	02:00
parsnip	it probably won't be needed, but it's easy to make	02:00
rewt	much easier than trying to describe the repo without knowing what it looks like	02:00
parsnip	oh, maybe --decorate is default now	02:02
	→ srinidhi joined	02:04
bn_work	parsnip https://www.irccloud.com/pastebin/FTJvhfoX/git%20log%20--oneline%20--graph%20--decorate.log	02:04
rewt	that's the full output?	02:06
	← jclsn left	02:07
parsnip	the merge at 7edfe48 is the only one not from today?	02:07
	← sa0 left	02:08
parsnip	i'm trying to think what sequence of events gets to 066c03c	02:08
	→ jclsn joined	02:09
bn_work	and from machine 2 it looks like this: https://www.irccloud.com/pastebin/JQX9Uck0/git%20log%20--oneline%20--graph%20--decorate_from_machine2.log	02:09
parsnip	oh, just that diff, is all	02:09
	so that machine didn't have the changes yet, maybe	02:09
	so in a sense, a16b6eb was merged twice	02:10
	not in a literal sense, just in a, "second machine" sense	02:10
rewt	it was only merged on one, then pushed, then fetched on the other	02:11
	went into 7edfe48 in both logs	02:11
parsnip	i guess machine 1 had master at 8df9c3a, recently	02:11
rewt	yes	02:12
parsnip	okay, you could "rebase" 8df9c3a onto 65efe9e, i'm not sure that's the optimal fix	02:12
bn_work	rewt/parsnip: it looks like the first one is a superset so I think I see what you mean about not needing to reset, so I just rebase off from ab75188?	02:12
parsnip	if it were me, i would probably make this entirely linear, but that could easily be difficult to convey over chat	02:13
bn_work	are all those other branches in other branches? I don't see them when I do `git branch -a`? or at least I don't think I do?	02:13
rewt	bn_work, question is if you want to re-do the whole history, or just this last one?	02:13
parsnip	oh, that's an interesting question	02:13
	work from the initial commit, start reshaping the commits, then force push	02:14
	you could even draft the redo, with temporary branch	02:15
rewt	if you want to change it all to a linear history, you can do `git rebase -i ab75188`, and put the commits in order (top is first chronologically)	02:15
parsnip	are the commit messages stable? because soon the commit hashes won't be	02:15
rewt	yep, you can `git checkout -b newbranch`, and do the interactive rebase with that	02:15
parsnip	decide what order you want the commit messages	02:16
	oh, interesting idea	02:16
	← jclsn left	02:16
parsnip	i would have used a pair of temporary branches	02:16
	i'm not sure i've used interactive rebase over merges	02:16
	← Sulky left	02:17
parsnip	anyways, i've got to go for groceries, best of luck, regardsj	02:17
	*regards	02:17
rewt	interactive rebase is pretty powerful; you can reorder commits, change metadata (message, author, etc), edit commits, etc	02:17
	→ FFY00_ joined	02:18
	← FFY00 left	02:18
bn_work	rewt: yes, that's basically what I want to do, rebase it so it's linear and the original commit messages are shown vs these merge commits. I'm still confused why I don't see these other branches in git branch -a output	02:18
rewt	which other branches?	02:19
	you said you only have master	02:19
bn_work	parsnip: thanks parsnip	02:20
	rewt: yes, that's what I thought but that tree view (with multiple ANSI colors that didn't copy) now has me confused :/	02:20
	← Murr left	02:20
	→ thebombzen joined	02:20
	→ Murr joined	02:21
rewt	the colours are there only to make it easier to trace the lines, they serve no other purpose	02:21
	← ghost43 left	02:21
	→ ghost43_ joined	02:21
	→ jclsn joined	02:21
	→ geowiesnot joined	02:22
rewt	with more complicated histories, it helps quite a bit	02:22
	← duxsco left	02:22
bn_work	rewt: so did this create 3 branches?	02:23
rewt	no, there's only 1 branch: master	02:23
	in git a branch is just a pointer to a commit	02:24
bn_work	right, but I see 3 vertical lines now so obvious there's 3?	02:24
rewt	they're just separate "ancestry paths" (no git term for it really)	02:25
	anyways, to get the history linear, start with: `git branch oldmaster` # to create a new branch called "oldmaster" (don't worry about the name, it's only temporary)	02:25
bn_work	rewt: but not "branches" as created by `git branch ...` ?	02:25
rewt	yes, and in git, a branch is simply a pointer to a specific commit	02:26
	when you delete a branch, all traces of it disappear	02:26
bn_work	I assume I want to do this on machine(1) which is a superset of machine2 (which doesn't have everything, yet?)	02:26
rewt	when you commit, git doesn't record what branch was checked out at the time, it simply makes a new commit, sets the current one as its parent, and moves the branch pointer to the new commit	02:26
	yeah, do it on the one that has the latest	02:27
bn_work	I wonder if i'm not seeing the branches in my normal `git log` because I'm doing: `format.pretty=format:%C(auto,yellow)%h%C(auto,magenta)% G? %C(auto,blue)%>(25)%ad %C(auto,green)%<(7,trunc)%aN %C(auto,reset)%s%C(auto,red)% gD% D`	02:28
rewt	do you have any changes at all on the other machine? even not committed changes?	02:28
bn_work	"branches"	02:28
rewt	no, you only have 1 branch; "master", there are no other branches; in git, branches are not "chains of commits"	02:28
	or rather, "chains of commits" are not branches	02:29
	← ghost43_ left	02:30
	← Murr left	02:30
bn_work	on machine2 I have ~15 modified uncommitted files, ~40-50 untracked files	02:31
	→ ghost43 joined	02:31
bn_work	machine1 is basically a new machine I've started using to dev on concurrently (possibly a bad idea)	02:31
	← pizdets_ left	02:32
rewt	best if you commit everything you want to keep, and get it all on 1 machine, and do these steps on that 1 machine	02:32
	← The_Blode left	02:33
	→ hbautista joined	02:35
bn_work	right, I'm aware git tracks the entire state of the repo during a commit, re. "branches": regardless of what the underlying representation is (a pointer to just a head commit or chains of commits), isn't the diff in re. to my question moot? I was asking if there are effectively 3 "branches" now since there are 3 vertical lines? or were? (the last one seemed to merge them all together?)	02:36
	I don't know how I would "get it all on 1 machine"? besides copying it out...?	02:38
rewt	commit + push, then fetch on the other	02:39
bn_work	I'm assuming I should do this because it would overwrite those files when I pull back on machine2 after fixing it on machine1?	02:39
rewt	yes	02:39
	you'll do a reset on the other one at the end, which could lose those files/changes	02:39
bn_work	so were the 3 vertical lines master, remotes/origin/master, remotes/origin/HEAD -> origin/master ?	02:41
	could I not just stash & pop it back on machine1?	02:41
	er.. 2	02:41
rewt	you could, if you're comfortable with that	02:42
	← jclsn left	02:43
	→ roadie joined	02:44
bn_work	ok, so on machine1, I did `git branch oldmaster`. PS: `I'm still very confused with what "branches"/lines-of-ancestry/whatever-is-the-correct-term of what those 3 lines were?	02:46
rewt	there is no git term afaik for those lines... they simply indicate that the commit where 2 lines meet is a merge commit with 2 parents	02:47
bn_work	rewt: so now git checkout oldmaster and rebase -i there? or rebase on master now that oldmaster has "backed up" current HEAD?	02:47
rewt	so right where you are, `git rebase -i ab75188` will show an editor with a list of commits	02:48
	← srinidhi left	02:48
rewt	oldmaster should be at the same commit as master; we can ignore it for now	02:48
	→ jclsn joined	02:49
	→ srinidhi joined	02:51
bn_work	yeah, I've rebased interactively before. One weird thing I just noticed though from the diff I did earlier of: "`git diff <parent>..<merge>` # replace <merge> with your merge commit, and <parent> with the parent you want to diff against", one of the lines shows as a deletion vs addition?	02:51
rewt	should that line not be deleted?	02:53
	← austin987 left	02:53
	→ austin987 joined	02:54
bn_work	rewt: no, on machine2 (where that change originated from as 066c03c) it is an addition	02:54
rewt	what was the diff command you used?	02:55
	→ Murr joined	02:55
bn_work	wait, maybe I did it backwards, yes, sorry	02:57
	that's weird that only 1 of the 2 lines showed reversed	02:57
rewt	`git diff A..B` shows what changes are needed to get from A to B	02:58
bn_work	when I pop later on machine2, can I rebase it onto whatever it gets reset to?	02:58
rewt	yes	02:58
bn_work	how?	02:59
	← roadie left	02:59
rewt	let's finish this part first	02:59
bn_work	and I guess I need to git stash -u too on machine2	02:59
	ok	02:59
	← gast0n left	03:00
rewt	so you're doing the rebase -i?	03:00
bn_work	yes	03:00
	on machine1	03:00
	← jclsn left	03:01
bn_work	ok, done	03:01
	it's linear now	03:02
rewt	ok, do that same git log command again, and pastebin the output ... if you want to hide the commit messages, you can add `--formmat=%h%d` on the end	03:02
	← ghost43 left	03:03
	→ jclsn joined	03:03
	→ ghost43 joined	03:04
bn_work	rewt: https://www.irccloud.com/pastebin/0yynrBul/git%20log%20--oneline%20--graph%20--decorate_after_rebase_-i_ab75188_on_machine1.log	03:05
	→ Gustavo6046 joined	03:05
rewt	hmm... that's not what i was expecting	03:06
bn_work	... :\|	03:06
	← tatuio left	03:06
	← guest left	03:06
rewt	not showing oldmaster	03:06
	anyways... do you get any output for `git diff 48379aa..d370bc0`	03:07
	← bloody left	03:07
bn_work	no	03:07
rewt	ok, that's good	03:08
	→ stenno joined	03:08
rewt	and all the commit messages are in the order you want? (newest on top in git log)	03:08
bn_work	I assume 48379aa is now oldmaster?	03:08
	← geowiesnot left	03:08
rewt	yes, it should be	03:09
bn_work	I think so, it didn't show timestamp but as long as the original commit + messages are there (vs "merge commit foo"), I'm happy	03:09
rewt	yes, the original author info is the same as the corresponding commits	03:09
	so now you can force push it	03:10
	→ makoto2600 joined	03:10
bn_work	`git push -f`?	03:10
rewt	and then on machine2, you `git fetch`, then `git stash -u` as you said, then `git reset --hard origin/master` to reset that master to match, and the finally pop as you said	03:10
	yes	03:10
bn_work	so how I rebase when I pop?	03:11
	← makoto2600 left	03:11
rewt	it will apply the stash to what you have checked out	03:11
bn_work	ok, force pushed	03:12
rewt	like a rebase, but no commit, so technically not a rebase in git terms	03:12
	← stenno left	03:13
	→ jclsn1 joined	03:13
bn_work	uh, so what about the untracked files? PS: earlier today on machine1 I tried to stash pop (the same?) set of `git stash -u` files but it said `/foo/bar/baz already exists, no checkout` and then finally `error: could not restore untracked files from stash` (RC=1)	03:14
	FYI, machine1 was machine2 restored onto it a few months ago but it had diverged since.	03:15
	(new machine to replace slowly failing machine "2")	03:15
	← jclsn left	03:15
rewt	if the pop fails, everything is still there in the stash; everything that could be applied should be applied (iirc), and you'd only have to manually check the files it complains about	03:17
mannequin	https://paste.debian.net/1235524/	03:17
bn_work	yes, the stash is still on machine1, I'm just wondering if the same will happen with machine2, and if so, how do I get it to apply those files?	03:17
	it basically complained about everything?	03:18
rewt	it's a fresh stash from 65efe9e, so it should apply cleanly, unless you did something in 8df9c3a that would cause a conflict	03:18
	← jclsn1 left	03:20
bn_work	8df9c3a was just 1 file with 3+, 2-	03:22
	← srinidhi left	03:24
bn_work	ok, git stash -u completed	03:24
	`git status` on machine2 shows this: https://www.irccloud.com/pastebin/vEmd2Gbt/git_status.log	03:25
	→ jclsn1 joined	03:25
rewt	ok, the reset should align them	03:26
	→ saroy joined	03:27
	→ srinidhi joined	03:27
bn_work	hmm, why doesn't git log --online --graph --decorate not show origin/master, origin/HEAD?	03:30
	→ finn_elija joined	03:31
	← FinnElija left	03:31
	finn_elija → FinnElija	03:31
bn_work	I think I understand why you were also confused about oldmaster not showing up as a pointer either now	03:31
	← ghost43 left	03:31
parsnip	maybe try --all	03:31
	← jclsn1 left	03:31
bn_work	(I assume that's what you were referring to earlier by the "not what I expected" comment)	03:31
	← saroy left	03:31
	→ ghost43 joined	03:31
rewt	what if you add --all to the git log command	03:31
parsnip	(and iiuc, --decorate is redundant on newer git)	03:32
bn_work	parsnip: aha, yes!	03:32
parsnip	i just got back	03:32
rewt	wb	03:32
parsnip	nice, you got rebase -i to work	03:33
	is that mostly a matter of "skipping" the merge commits?	03:33
	← ChmEarl left	03:33
parsnip	i'll try	03:33
	wait, rebase -i selects a linear path anyways, so no merge conflicts to skip?	03:34
rewt	yeah, it excludes the merge commits by default	03:34
parsnip	i wonder what order it puts them in. author date?	03:34
rewt	that's what i'm guessing	03:34
parsnip	as empty, i guess	03:35
	a merge conflict can result in non-empty merge commit?	03:35
	→ jclsn1 joined	03:35
parsnip	anyways, i went to wrong grocery store, going out again for more	03:35
rewt	it stops on a conflict, lets you fix, git add, and then continue	03:36
	`git status` gives instructions, as usual	03:36
	→ funhouse joined	03:36
parsnip	oh, that's interesting, i'll try it now	03:36
	this is even after a conflict was resolved? a rebase -i pauses?	03:37
bn_work	wow, that apparently worked!	03:37
	`git stash pop` that is	03:37
parsnip	like, i merge, conflict, resolve, finish merge, rebase -i, and it pauses for the conflict again?	03:37
bn_work	rewt: thanks a ton!	03:37
parsnip	w00t!	03:37
bn_work	(& parsnip too)	03:37
rewt	yeah, parsnip, it pauses on each commit that has a conflict	03:38
	← tyson2 left	03:38
bn_work	ok, phew, glad I'm back to normal.	03:38
	So moral of the story, change default merge strategy to... rebase?	03:38
parsnip	or fast forward only	03:38
	iiuc	03:38
	i always fetch first, but i'm silly	03:39
rewt	`git pull --rebase` (it's not quite the same as a `git rebase`)	03:39
parsnip	i fetch, review, and decide	03:39
rewt	same here, git fetch, git status, then may git pull --rebase	03:39
parsnip	looking at --graph	03:39
rewt	maybe*	03:39
parsnip	--all	03:39
	→ Codaraxis_ joined	03:39
parsnip	i mostly use git from magit, so all my muscle memory	03:39
	← jab416171 left	03:39
parsnip	everything looks like a nail. i have very few workflows that work for lots of cases	03:40
	i constantly am looking at the graph log, use interactive rebase a lot, and create temporary branches quite a bit	03:40
	← jclsn1 left	03:41
rewt	same (except for gitk instead of graph log, but same thing in the end)	03:41
	→ leib joined	03:41
bn_work	oh EMACs, ugh, heh	03:41
rewt	hah, i wasn't gonna say it :D	03:42
bn_work	rewt / parsnip: so should I do `git config pull.rebase true` and how do you review once fetched but before pulled?	03:42
parsnip	lol	03:43
bn_work	do you just do a git diff against the HEAD of master?	03:43
	← Codaraxis left	03:43
parsnip	replace git pull with git fetch	03:43
	i use my GUI graph all to show me the diff for each node on the graph	03:44
	i can move point on commit, and the other window shows the diff	03:44
	you could do a diff	03:44
	but usually i can see the difference, like noting that my branch has changes at a completely different file or file location, and decide to rebase	03:45
	← leib left	03:45
bn_work	I guess the whole point of splitting it like that into two operations (fetch + pull) is to not be shoved into having to resolve merge conflicts?	03:45
parsnip	i can use my GUI to select two commits on the graph, and see the diff	03:45
	my CLI git-fu isn't not super hot	03:45
	→ jab416171 joined	03:45
parsnip	*is not	03:45
	yeah you can decide what to do after fetching	03:46
	→ jclsn1 joined	03:46
parsnip	if you just did git pull and got conflict, it shouldn't be hard to reset locally	03:46
rewt	pull is just fetch+merge, so doing fetch first lets you look at things before doing the merge	03:46
parsnip	assuming you wanted to reconsider as if it was a fetch	03:46
	yeah, you have like no prior information to plan, if you do git pull	03:46
	← srinidhi left	03:47
parsnip	fast foward only might be interesting	03:47
bn_work	so should I set `git config pull.rebase true` so I don't wind up in this again? I'll try to remember to just do `git fetch` from now on, but I assume I would still then need to figure out how to merge/rebase?	03:47
	→ rgrinberg joined	03:47
parsnip	then it only automates the merge in the nicest case	03:47
	pull.rebase true is okay, at least it would take you in direction of linear attempt	03:48
	but it's not fast forward only	03:48
	iiuc	03:48
	and yes, trying to prefer git fetch is fine too	03:48
bn_work	parsnip: yeah, right now it's just me but 2 machines (I'm trying to not touch the same areas to avoid conflicts), another advanced dev recently pushed a branch in a completely different area (I'm assuming I'll need to tell him to re-pull after my force push)	03:48
parsnip	oh dear	03:49
bn_work	parsnip: yeah, that's not a bad idea, I assume all mine were FFs since there were no conflicts?	03:49
parsnip	we didn't know we were advising on a repo that was already being shared	03:49
	make sure the force push is okay with team	03:49
	→ srinidhi joined	03:49
parsnip	no, a "divergent merge", i think that's separate from "fast forward only"	03:50
	you had several overlapping divergent merges	03:50
bn_work	he made his own branch	03:50
parsnip	fast forward only, is like when your commits are an ancestor of the fetched HEAD	03:50
	so merge just fast forwards	03:50
bn_work	parsnip: well, I mean, my changes could have been FF-ed?	03:51
	I did?	03:51
parsnip	okay, if you merge his branch, it will have the old divergent merges as an ancestor?	03:51
rewt	bn_work, where did you base his branch on?	03:51
	or where did he* rather	03:51
parsnip	good question ^	03:51
bn_work	parsnip: no, he branched way before	03:52
parsnip	platta2: if there is a divergence between your local branch and the remote branch, that means your local branch is not an ancestor of remote branch	03:52
	platta2: sorry, i meant bn_work	03:53
rewt	if he branched from ab75188 or a16b6eb, it's ok, otherwise he'll re-introduce divergence(s)	03:53
parsnip	if your local branch is not an ancestor of remote branch, then "git pull and merge only if fast forward" will fail	03:54
rewt	so if his history includes 8397889 or 7edfe48, that's bad	03:54
bn_work	parsnip: right, I think I see what you're saying now, basically it's only for workflow where you don't commit and only pull?	03:54
	workflows	03:54
	rewt: wait, why would him branching way before the commits all this happened, reintroduce this?	03:55
parsnip	it's for many workflows, but it will more often force you to review after "git pull", rather than trying to enter into a divergent merge or rebase or a conflict	03:55
	him not branching way before	03:56
rewt	if he branched from one of the first commits that the rebase -i didn't change, it's good; if he branched from one that got rebased, he'll re-introduce the original commit	03:56
	← eroux left	03:57
parsnip	if his branch is a descendant of your divergent merges, then work will have to be done to remove those	03:57
	in other words, you changed shared history, and that is to be avoided, and would not have to be carefully discussed with them and handled	03:57
	→ Batman__ joined	03:57
bn_work	he branched from a commit way before this diverged in ab75188 happened, so isn't he ok?	03:58
	s/in/after/	03:58
parsnip	they'll have to fetch your changes, then consider the graph, is one way to look at it	03:58
	sounds good	03:59
	→ TheCatBehemoth joined	03:59
rewt	the easiest way to solve it is for him to `git fetch`, and then `git rebase origin/master` ... that should leave his branch with only the commits he made in his branch	03:59
parsnip	hopefully the "common ancestor" is a commit before where the rebase occurred.	03:59
rewt	but yeah, if he made the branch before ab75188, he's ok	03:59
parsnip	that sounds good. here's another idea, not sure if it sounds super complicated	04:00
	:	04:00
rewt	the CA will have to be on the current linear history, so a rebase will eliminate any of the commits that were rebased here, leaving his branch with only his commits	04:01
parsnip	have them fetch your origin/master, create a temporary branch at current local master, rebase that temp branch onto origin/master, push that temp branch, now you can fetch it and make sure everything looks good	04:01
rewt	(if all the changes in a commit are already present, that commit is removed during the rebase)	04:01
parsnip	oh, you mean the rebase might work even if it had the divergent merges?	04:02
rewt	yea	04:02
parsnip	that makes sense, i hadn't thought of that	04:02
	← TheCatBehemoth left	04:03
rewt	it is possible to force an empty commit at that point, but that's not default	04:03
bn_work	CA?	04:04
	commit ancestor?	04:04
rewt	yes	04:04
	no	04:04
	common ancestor	04:04
	the last commit that's in both branches' histories	04:05
parsnip	i've used divergent merges almost never	04:06
bn_work	empty commit?	04:07
rewt	a commit with no changes	04:08
bn_work	didn't know that was possible...what is the purpose of that?	04:08
	you mean like a tag?	04:08
	→ sa0 joined	04:09
rewt	no, an actual commit, same as any other, but no diffs from the previous one	04:09
	a tag, like a branch, is just a pointer to a specific commit	04:09
bn_work	right, I was just trying to think of when a commit would be empty, but I guess it's not really a commit to begin with?	04:10
parsnip	i like my "First commit" to be empty	04:10
	i'm silly	04:10
	sometimes you can use it as a reminder	04:10
	← ghost43 left	04:10
parsnip	it is a commit	04:10
	just, sort of a trivial one	04:10
	fsvo "trivial"	04:10
	← structoha left	04:10
	→ Sulky joined	04:10
parsnip	it might be the initial commit in the category of commits /s	04:11
	it's "useless"	04:11
	→ ghost43 joined	04:11
parsnip	hence why git prevents it by default	04:11
	you have to say, "no i'm serious, i really want an empty commit"	04:11
rewt	maybe you have a CI/CD system that triggers on commit, and you want to re-trigger it, but don't want to make any changes	04:11
	→ ghost43_ joined	04:15
	→ roadie joined	04:17
parsnip	A commit is not just a worktree (diff). So it not only contains the state of the worktree, which can be "trivially" the same as its parent, but it also records who the parent is, the author and committer information, the commit message and the hash of all of that.	04:17
	← ghost43 left	04:17
parsnip	well, and parent can be empty too, for initial commits	04:18
	(you can have more than one initial commits, something not well indicated by some graphs)	04:18
	i can't remember if you can create a commit that has no author or committer. maybe not with git porcelain.	04:19
rewt	interesting... if you want to change the author of a commit, it won't let you use a blank, and if you use something that partially matches a previous author, their name+email is used	04:26
	← chenqisu1 left	04:27
	← DoofusCanadensis left	04:28
	← roadie left	04:32
	← zebrag left	04:34
	← sa0 left	04:39
	→ _xor joined	04:43
	← pulse left	04:52
	→ madewokherd` joined	04:53
	← madewokherd left	04:57
	→ pyeverything joined	05:00
	← pyeverything left	05:01
	← luke-jr left	05:04
	→ roadie joined	05:06
	← ghost43_ left	05:07
	→ ghost43 joined	05:08
	→ luke-jr joined	05:08
	← madewokherd` left	05:08
	← vysn left	05:09
	← roadie left	05:10
	→ madewokherd joined	05:12
	→ roadie joined	05:17
	← sudoforge left	05:17
	← srinidhi left	05:19
	→ srinidhi joined	05:20
	← roadie left	05:21
	← madewokherd left	05:22
	← ghost43 left	05:22
	→ ghost43 joined	05:23
	← humanBird left	05:25
	→ ferdna joined	05:27
	→ saroy joined	05:29
Hash	Hi	05:35
	I worked on something all day, then I had a bug, so I did `git stash` and it stashed it and reverted to head, and bug went away	05:35
	→ structoha joined	05:36
Hash	Now I need to do a diff of stuff in stash and stuff in head, so see what I did.	05:36
	What should I do, I read all the docs for git-stash	05:36
	https://git-scm.com/docs/git-stash	05:36
	I am in my testing branch. Should I `git stash apply` and commit this broken code, and so history is saveD?	05:37
	What is the best method in your opinions?	05:37
	→ roadie joined	05:38
	← rgrinberg left	05:39
parsnip	i'm not #git pro, but `git stash apply` sounds good to me. although i rarely use stash, i usually use magit to apply	05:42
Hash	Yeh I know you from #emacs	05:42
	I am using cli	05:42
parsnip	you could also convert it to a branch	05:42
	:-)	05:43
	→ The_Blode joined	05:43
Hash	thanks for reply, I'll check out stash apply and then commit them to a commit. You can always revert or do something else. I don't want to lose the changes. I could put them into a testing-2 branch or 'bugged' branch	05:43
	so git stash apply, get my stash back. Then git branch newbranch and the changes should go into a new branch right?	05:43
	Or if I git stash apply, then just commit to 'broken commit'	05:44
	So at least it's in history	05:44
parsnip	i guess stash just has extra features, like effectively saving index and working tree both	05:44
Hash	Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.	05:44
	... and restored (potentially on top of a different commit) with git stash apply	05:44
parsnip	i imagine theoretically, you could commit the working tree and index as separate commits	05:45
	← structoha left	05:45
Hash	Calling git stash without any arguments is equivalent to git stash push <- that's what I did. push	05:45
parsnip	er, reverse, index, then working tree, sounds intuitive to me	05:45
	yeah they sort of act as generalized patches i guess	05:45
	→ rgrinberg joined	05:45
parsnip	and, so like a stack of stashes i guess	05:46
Hash	pop: Remove a single stashed state from the stash list and apply it on top of the current working tree state, i.e., do the inverse operation of git stash push. The working directory must match the index.	05:46
	apply doesn't remove it	05:46
parsnip	i guess it's a stack because it's not a graph	05:46
Hash	pop removes it	05:46
parsnip	yeah, i usually use apply until i'm sure i'm done with it	05:47
	i guess stash is good if you really have to switch tasks quickly	05:47
Hash	git stash branch bugged_branch stash@{0} ?	05:48
	trying to get the syntax right	05:48
	https://opensource.com/article/21/4/git-stash	05:48
	A practical guide to using the git stash command	05:48
parsnip	that looks right. i wonder if there's a happy medium on documentation, somewhere between git's dry man pages, and something like a usage article	05:50
Hash	if you do git stash apply	05:50
parsnip	https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning	05:50
Hash	How do you reverse it?	05:50
	I did git stash, then git stash apply to get it back, then now I want to stash it again	05:51
	I didn't pop, so it's sitll in git stash list	05:51
	But it's been applied. How do I unapply it?	05:51
parsnip	oh, you want to add a stash@{1}?	05:51
	i mean, push to the stack?	05:51
Hash	No	05:51
	1) git stash	05:51
	2) git stash apply <- to get stash0 back	05:52
parsnip	oh, intuitively, i'm guessing you can just reset the branch ref	05:52
Hash	3) Now I want to undo #2	05:52
parsnip	reading...	05:52
	← roadie left	05:52
ikke	git stash apply applies a stash without dropping it	05:52
Hash	correct	05:52
parsnip	yeah, it sounds like you wouldn't lose anything if you "removed" the apply	05:52
	but so i want to read what apply does exactly	05:52
Hash	Now that the stash been reapplied again, if I wanted to get rid of those chagnes, what would I do?	05:52
ikke	afaik, there is no way to just unapply what you just stashed	05:52
parsnip	apply moves the branch ref?	05:53
ikke	no	05:53
Hash	Nothing happens to branch or head	05:53
ikke	it's a worktree operation	05:53
parsnip	no they applied it	05:53
Hash	just locally it creates a working tree copy adn puts changes there	05:53
ikke	git stash show -p stash@{0}	05:53
parsnip	they stashed, then applied, they want to undo the apply	05:53
Hash	^ correct	05:53
	Just for learning purposes	05:53
	I want to get my HEAD back, but keep the stash	05:54
parsnip	hmm, if you had unsaved changes in worktree, and tried to apply a stash, would it reveal conflict?	05:54
	← ferdna left	05:54
Hash	So like you stash, then apply, then what do you do if you want to get rid of the changes again?	05:54
ikke	Hash: if you did not have any other changes, the easiest would be to just reset your worktree	05:54
parsnip	reset worktree to index?	05:54
ikke	otherwise, you could try to apply the inverse of the stash	05:54
parsnip	but what if you had modified the worktree inbetween stash and apply?	05:54
Hash	Well stash is currently applied	05:55
	So how about we just create a new branch	05:55
	put the broken changes in there	05:55
	so at leat my testing branch which is bug free is clean.	05:55
parsnip	make sure working tree and index don't have unsaved items before applying	05:55
	what i would probably do ^	05:55
	← R2robot left	05:56
parsnip	how do you apply the inverse of a stash?	05:56
	hmm, `git apply -R <patch>`?	05:56
	so you need the patch from the stash	05:57
	but still	05:57
	yeah usually what i do, is i clean working tree and index, then apply the stash, then commit the index as one commit, and the working tree as as a second commit	05:57
	imo, that's a faithful representation of the stash	05:58
	and give it a clever branch name, like `faithful/stash/0`	05:58
Hash	well, right now the stash is applied. So should I just create a new branch from these changes	05:59
	or use git stash branch command?	05:59
	If I don't commit, and do git branch testing2, it should put all my uncommited changes in that branch right?	06:00
parsnip	i already know how to make a branch and make commits from an index and working tree, so that would be my first reaction	06:00
Hash	Ok so I should do that too	06:00
	Right now the stash is applied, and git status shows lot of modified files	06:01
parsnip	roughly, i'd have to review if `git branch foo` checks that branch out	06:01
Hash	So now I can do git branch testing-2	06:01
	← Gustavo6046 left	06:01
parsnip	is there only changes in index, or only changes in working tree, or both?	06:01
Hash	you switch branches with git checkout branchname	06:01
	→ Gustavo6046 joined	06:02
Hash	you crate branch with git branch newbranch	06:02
	Taht's why I use cli mostly cuz if you use gui and or magitt etc. you don't get to learn git	06:02
	once I larn it, then guis are okay to use	06:02
parsnip	right, i agree, i've gotten myself into this mess, using the GUI	06:03
	← Gustavo6046 left	06:04
parsnip	but i still know more about git than the average non computer user ;-)	06:04
	→ Gustavo6046 joined	06:04
Hash	That's true	06:05
	you're awesome :)	06:05
	So what if you have uncommited changes, and you want to put those changes into a new branch	06:06
	The data is saved on disk already but not commited	06:07
	I don't want to put these bugged code into the original branch	06:07
	I'm trying to find out if when you create a new branch, does it copy your uncommited changes to that branch? Or how does it do?	06:07
parsnip	iiuc, commits go towards movement of the checked out branch ref	06:08
	iirc, almost all git commands only move the checked out branch ref	06:08
	i had some weird mnemonic like this	06:08
ikke	uncommitted changes do not belong to any branch	06:08
	they just remain in your worktree	06:09
	← Misotauros left	06:09
Hash	git checkout -b newBranch	06:09
parsnip	like, even merge	06:09
Hash	then commit	06:09
	I got it	06:09
parsnip	when you merge two branches, the checked out one is the one that moves	06:09
Hash	https://stackoverflow.com/questions/13687334/moving-uncommitted-changes-to-a-new-branch	06:09
	← ghost43 left	06:10
	→ ghost43 joined	06:11
ikke	!float	06:11
gitinfo	If you have made a change in your working directory and have NOT YET COMMITTED, you may "float" that change over to another (`git checkout existing_branch`) or new (`git checkout -b newbranch`) branch and commit it there. If the files you changed differ between branches, the checkout will fail. In that case, `git stash` then checkout, and `git stash apply` and go through normal conflict resolution.	06:11
parsnip	it is kind of cool that you can create a new branch and check it out, with uncommitted changes, as long as it is at current commit	06:13
	← great_taste left	06:16
igemnace	well if you think about it, you're really only changing HEAD in such a case. no need to touch the work tree	06:16
	← peepsalot left	06:16
Hash	Ok	06:17
	Broken code is now in testing-2 branch	06:18
	Now I can see the diff visually and see what changed from previous commit that caused the problem.	06:18
	To only today's work is bugged. Yesterday's commit works on `testing`. testing-2 is broken code.	06:18
	So I will have to debug that tomorrow.	06:18
	If I can't figure it out, start over in testign branch from new on these new features	06:19
	I lvoe git.	06:19
	I wouldn't know what I would do without it	06:19
	How did we ever use CVS and SVN	06:19
	→ R2robot joined	06:20
	← Murr left	06:20
	→ Murr joined	06:20
parsnip	i never did	06:23
	→ stenno joined	06:25
dodo	meh, has somebody noticed that bash completion from upstream git-completion.bash completes remote names and ignores local paths? that's not something i want..	06:26
	← ghost43 left	06:29
	→ ghost43 joined	06:30
	→ feriman joined	06:32
	→ TheCatBehemoth joined	06:41
	← TheCatBehemoth left	06:46
	→ chenqisu1 joined	06:48
	→ carl-- joined	06:52
	← GNUmoon left	06:57
	→ chexum joined	06:57
	→ robink joined	07:05
	→ pizdets joined	07:05
	← ghost43 left	07:06
	→ ghost43 joined	07:07
	← rgrinberg left	07:07
	→ rgrinberg joined	07:08
	→ vysn joined	07:12
	→ zeenk joined	07:14
	← rgrinberg left	07:15
	← Akiva left	07:16
	← wonko-the-sane left	07:18
	← stenno left	07:19
	→ EvilDMP joined	07:20
	→ roadie joined	07:22
	→ wonko-the-sane joined	07:28
	← kaiseisei left	07:28
	→ kaiseisei joined	07:30
	← kaiseisei left	07:32
	→ kaiseisei joined	07:33
	→ wonko-th1-sane joined	07:33
	← wonko-the-sane left	07:34
	← kaiseisei left	07:35
	→ TheCatBehemoth joined	07:35
	→ kaiseisei joined	07:36
geirha	I write my own completions, but it may be it will complete paths if it	07:40
	if it's after a -- argument	07:41
	← howdoi left	07:41
	← hbautista left	07:42
	→ yosef[m]1 joined	07:44
	← Deknos left	07:45
	→ Deknos joined	07:45
geirha	ugh, 3.5k lines. I'm not going to bother to go through that. Seems like over-engineering	07:46
	→ stenno joined	07:47
	← kaiseisei left	07:48
	→ dionysus69 joined	07:48
geirha	anyway, you could also try starting the path with ./; it will likely switch to filename completion then	07:48
	→ kaiseisei joined	07:49
	← Gustavo6046 left	07:49
	→ Gustavo6046 joined	07:49
	→ kenanmarasli joined	07:50
	← kaiseisei left	07:55
	→ kaiseisei joined	07:56
	→ mattil joined	07:57
	← PaterTemporalis left	07:57
	← kaiseisei left	08:00
	← germ left	08:00
	→ germ joined	08:00
	→ rfuentess joined	08:02
	→ kaiseisei joined	08:03
	← kaiseisei left	08:04
	← The_Blode left	08:06
	→ kaiseisei joined	08:06
	→ NeilRG joined	08:07
NeilRG	do I need to use a personal access token with github everywhere now?	08:07
	→ The_Blode joined	08:07
geirha	using ssh keys is easier imo	08:08
	← ghost43 left	08:09
	→ ghost43 joined	08:09
	← Deknos left	08:10
	→ palasso joined	08:11
NeilRG	geirha, good idea, so I just clone using the ssh link?	08:12
parsnip	yes	08:12
	assuming you followed steps that GitHub provides to configure public key	08:13
NeilRG	parsnip, okay thanks	08:13
parsnip	GitHub has pretty good docs for various aspects of setup	08:13
NeilRG	I was using git://, but now it won't let me	08:13
	so I'm switch to ssh	08:13
	← Batman__ left	08:14
	→ Batman__ joined	08:14
	→ GNUmoon joined	08:15
geirha	git remote set-url origin [email@hidden.address]	08:16
	← wonko-th1-sane left	08:18
	→ l4s8g joined	08:19
NeilRG	geirha, thanks!	08:20
	geirha, that's useful. I ended up deleting and re-cloning	08:21
	← kaiseisei left	08:21
	→ kaiseisei joined	08:22
	← ghost43 left	08:24
	→ ghost43 joined	08:25
	→ km joined	08:29
	← km left	08:29
	→ caverton joined	08:32
	→ alip joined	08:33
	← matthewcroughan left	08:33
	→ matthewcroughan joined	08:33
	← skapata left	08:36
	→ iokill joined	08:36
	→ sa0 joined	08:36
	→ km joined	08:36
	← jimklimov left	08:37
	← carl-- left	08:43
	→ warblr joined	08:45
	← Gustavo6046 left	08:46
	→ Gustavo6046 joined	08:46
	→ otisolsen70 joined	08:46
	← NeilRG left	08:51
	→ xylz joined	08:52
	← kaiseisei left	08:53
	→ Haohmaru joined	08:53
	← km left	09:00
	→ km joined	09:01
	→ reset joined	09:02
	→ keypusher joined	09:09
	→ duxsco joined	09:09
	← sa0 left	09:10
	← ghost43 left	09:12
	→ ghost43_ joined	09:12
	← warblr left	09:13
	← keypusher left	09:14
	← austin987 left	09:18
	← ghost43_ left	09:19
	→ austin987 joined	09:19
	→ menace joined	09:19
	← menace left	09:19
	→ menace joined	09:19
	menace → Deknos	09:20
	→ ghost43 joined	09:21
	← duxsco left	09:22
	→ Anticom joined	09:24
Anticom	Hi folks. Let's say I've tagged releases 1.0.0, 1.1.0 and 2.0.0 on my main branch. Now I'd like to release a patch for 1.1.0 as 1.1.1. What are the best pratices on managing this (via branches presumably)? Are there multiple options to do this or is there just "one" good way? How would I name such a branch?	09:26
	← roadie left	09:27
	→ cart_ joined	09:28
	→ kaiseisei joined	09:28
ikke	Anticom: a project I work on typically uses stable-x.y branches	09:30
Anticom	ikke: So I would branch off of 1.0.0 with a `stable-1.0` branch and also tag my 1.1.1 release in there?	09:31
ikke	yes	09:31
Anticom	Nice, thanks!	09:31
geirha	I'd branch off 1.1.0 with stable-1.1 and then tag 1.1.1 in there	09:31
ikke	oh, right	09:32
	1.1.1 would be in the stable-1.1 branch	09:32
	If 1.0 would also need to fix, you'd cherry-pick the change to there	09:32
	← feriman left	09:35
	→ feriman joined	09:36
	→ jimklimov joined	09:37
	→ roadie joined	09:42
	← mannequin left	09:43
Anticom	Err yea of course, small hickup on my side. Of course it's gonna be stable-1.1 :) Thanks for the heads-up guys	09:44
	← roadie left	09:46
	→ roadie joined	09:46
	→ nyah joined	09:50
	← feriman left	09:50
	← srinidhi left	09:55
	→ madewokherd joined	09:55
CalimeroTeknik	can several signatures be added to a commit?	09:56
	as signoffs I mean	09:57
	→ xkuru joined	09:58
	→ azed joined	09:59
	← ghost43 left	10:02
	→ ghost43 joined	10:02
	→ tulpa_ joined	10:05
ikke	yes	10:09
	← chenqisu1 left	10:13
	← cart_ left	10:13
	← vishal left	10:15
	← AbleBacon left	10:16
	→ srinidhi joined	10:16
	→ vishal joined	10:18
	← jazzy2 left	10:18
	→ dslegends joined	10:20
	← Murr left	10:20
	→ Murr joined	10:20
	← zumba_addict left	10:22
	← l4s8g left	10:24
	← xylz left	10:25
	← ghost43 left	10:30
CalimeroTeknik	even after the commit is made, someone can say "I validate this" (possibly with PGP)?	10:30
	← haskl left	10:30
	→ tyson2 joined	10:31
	→ ghost43 joined	10:31
CalimeroTeknik	because I'm not finding any tutorial to even tell whether it exists	10:31
	→ haskl joined	10:33
CalimeroTeknik	it seems to me as though unless you are creating a commit, you can't add a signature to it	10:35
canton7	Yeah, commit signatures are added to the commit itself, and commits are immutable. You can of course create a tag which has a signature and which points to a commit	10:37
CalimeroTeknik	got it, indeed that will work then, to signal someone says "this is okay"	10:37
	man git review mentions that	10:38
gitinfo	the git manpage is available at https://gitirc.eu/git.html	10:38
canton7	Ah, you're talking about Signed-Off-By, rather than a PGP signature. Same deal: that's just a line in the commit message	10:38
CalimeroTeknik	no, I also discovered that git had this notion called signed-off-by, indeed, but I don't mean that (after all it's just a facility to add text to the message as you say)	10:38
canton7	Ah, right	10:39
CalimeroTeknik	so, the way is to create a signed tag then	10:39
ikke	Because you mentioned 'as signoffs', I assumed you beed signed-off-by	10:39
canton7	Yeah signing individual commits has questionable benefit: the normal way is by signing the release tag. That ensures that neither the commit being tagged nor any of its parents can be tampered with	10:39
ikke	meant*	10:39
CalimeroTeknik	has anyone ever raised the issue of needing several signatures on the release tag? if say, it needs the approval of 2+ maintainers	10:41
	→ keypusher joined	10:41
	→ otis^ joined	10:42
	← azed left	10:43
	← srinidhi left	10:44
	← kaiseisei left	10:46
	→ srinidhi joined	10:46
	→ xylz joined	10:48
	← hongkongliberato left	10:58
	→ toulene3 joined	11:00
	→ hongkongliberato joined	11:00
	← ghost43 left	11:00
	→ The_Blode_ joined	11:00
	→ DibbTubberOne joined	11:01
	→ ghost43 joined	11:01
	← The_Blode left	11:01
	← toulene left	11:01
	toulene3 → toulene	11:01
canton7	CalimeroTeknik, signatures are about internal approvals - they're a way for people who clone the repo to ensure that noone's tampered with it	11:01
	→ zer0bitz joined	11:02
canton7	CalimeroTeknik, if you're worried about internal approvals, that's normally done with other tooling. E.g. you might be using github/gitlab, which enforces that branches can only be merged to main after they pass code review, and that a code review needs 2 approvals from <group> before it can be merged. Equally, you may only be allowed to merge to	11:02
	the production branch with the appropriate number of approvals. That sort of thing is nicely handled outside of git itself	11:02
	← srinidhi left	11:04
	← stenno left	11:05
	← zeenk left	11:07
CalimeroTeknik	external metadata indeed. but the signable tags are quite good already	11:07
	→ sa0 joined	11:07
	→ Andy_Kw joined	11:08
	← xylz left	11:10
	→ wonko-the-sane joined	11:11
	→ stenno joined	11:14
	← wilz left	11:15
dob1	is stash indipendend from the branch ?	11:16
parsnip	i believe so	11:18
	it's sort of like a pair of related diffs	11:18
	hmm	11:18
	git represents diffs as working trees?	11:19
	→ srinidhi joined	11:19
parsnip	but consider that the stashes are a stack, not a graph like you see in git log --all --graph	11:20
	so you accrue them, like a stack, but each stash is sort of independent of the commit graph	11:20
	and branches are just pointers to commits in the commit graph	11:21
	→ thiago joined	11:22
	→ Rashad joined	11:24
parsnip	i think it's implemented in terms of the commit that your branch ref pointed to	11:24
	← GNUmoon left	11:24
	→ GNUmoon joined	11:25
dob1	parsnip, I was thinking for example if you delete the branch where you create the stash, what happen if it is a diff ? it has to be "recalculated"	11:26
ikke	dob1: commits are not diffs, they are snapshots	11:26
parsnip	but it behaves somewhat like other commits. you can try to apply it elsewhere, which might be comparable to rebasing. it may work fine, or there may be conflicts	11:26
ikke	so git _always_ calculates the diffs	11:26
	and if you delete the branch, it's just a pointed that you delete	11:26
	the history is still there, and kept alive by the stash	11:26
	a pointer*	11:26
	← hongkongliberato left	11:26
	→ cart_ joined	11:28
dob1	"the history is still there" because the stahs exists, when the stash is clear/pop/drop the history of the deleted branch will be gone?	11:28
ikke	dob1: not immediately, but eventually	11:28
parsnip	ikke: but you have to be _at_ some commit to apply the stash, and if you're no longer at the commit that branch was at, then stash apply will be like rebase	11:28
	→ lgc joined	11:28
	← ghost43 left	11:29
	→ ghost43 joined	11:29
dob1	ikke, eventaylly ? this means that if I delete a branch (that is not merged in another) I cannot be sure the data are gone?	11:31
	I didn't understand this	11:31
ikke	correct, git uses garbage collection	11:31
	because git needs to make sure the history is not referenced by other refs	11:31
	and the reflog will keep things alive for at least 90 days	11:32
	So, there is no dirrect command to directly delete commits	11:32
	→ iomari891 joined	11:32
	→ rsx joined	11:33
dob1	this is not a problem if someone for example commit as error some secret data?	11:33
	→ vimal joined	11:34
	← Rashad left	11:34
ikke	That is a potential issue. git does give tools to deal with that, but you need to make sure there is not a single reference left	11:34
	But if you pushed it to github for example, you have no control over when objects are cleaned up	11:35
	← DibbTubberOne left	11:35
dob1	it's not simple...	11:36
	← lgc left	11:36
ikke	No	11:36
	← tulpa_ left	11:37
	→ xylz joined	11:37
	← funhouse left	11:37
dob1	"git uses garbage collection" why there is not a command to force it?	11:37
ikke	git gc	11:38
	(or git maintenance run, nowadays)	11:38
	but, like I said, you need to make sure there are no references left	11:38
	you can use git reflog --expire-unreachable to get rid of reflog entries that point to unreachable history	11:39
	git reflog --expire-unreachable=now	11:39
	or git reflog --expire=now to expire all entries	11:39
dob1	I take a not of them, thanks	11:40
	*note	11:40
	← sa0 left	11:40
mackerman	All of this is just in your repo. If you collaborate with others and have pushed, you have to make them do similar cleanup on all copies of the repo.	11:41
ikke	Yes, good addition	11:42
	→ hongkongliberato joined	11:42
	← very_sneaky left	11:43
dob1	It's something that I was not aware	11:44
	I was thinking branch deleted -> gone, but it's not	11:44
	→ jaggz joined	11:45
	→ very_sneaky joined	11:45
jaggz	How do I merge these last two commits, so they have just the "Added instructions..." title?	11:45
	https://github.com/jaggzh/mumble/commits/doc-details-debian/docs/dev/build-instructions/build_linux.md	11:45
	Mumble project desires my pull request be a single commit	11:46
	(but I edited build_linux.md after the fact, through the web)	11:46
	→ Rashad joined	11:55
Anticom	jaggz: well commits pushed to a remote _should_ be considered immutable anyways, but if you really wanted to probably squash them interactively and force push	11:56
	→ bertvvvs joined	11:56
	← hongkongliberato left	11:57
	← xylz left	11:57
	← ghost43 left	11:58
	→ ghost43 joined	11:58
	→ shan joined	12:01
Anticom	s/squash/rebase	12:01
jaggz	Anticom, hmm.. I used someone's instructions with reset --soft	12:02
	git reset --soft HEAD~3	12:02
	→ PaterTemporalis joined	12:02
jaggz	then my push said I needed to pull changes	12:03
Anticom	Well that would work as well I suppose	12:03
	Yes, because git doesn't know you undid some commits in your working copy and hence assumes you'd want to pull in the changes that live on the remote	12:03
	→ ghost43_ joined	12:03
jaggz	hmm	12:04
	← ghost43 left	12:04
jaggz	Anticom, how do you make it go through without the pull?	12:05
	somehow I'm down to like 10 commits in my local git log, and 2 showing in my branch on github :/	12:05
Anticom	make what go though? You have your repo on the remote (github) and in your working copy locally on your machine. If you really want to rewrite the commits on the remote you'd have to force push	12:06
	Well then you messed something up big time it seems	12:06
	← dionysus69 left	12:06
jaggz	got it!	12:06
	one commit showing in github	12:07
	oh, and in local too.	12:07
	I had all the commits showing locally, I think, because I kept pulling in the remote changes after resetting and .. doing stuff.	12:07
	ugh.. no.. I've included tons of their changes in my one simple document change.. ugh	12:08
	Showing with 865 additions and 762 deletions.	12:08
	reset too far back maybe	12:08
	→ hongkongliberato joined	12:11
	→ csm3105 joined	12:15
Anticom	Probably	12:16
	→ synthmeat joined	12:21
	→ mannequin joined	12:21
	← cart_ left	12:28
	→ bloody joined	12:31
	→ cart_ joined	12:38
	→ perrierjouet joined	12:41
	← Rashad left	12:49
	← srinidhi left	12:49
	← xkuru left	12:50
	→ Maxattax joined	12:53
	→ xkuru joined	12:56
	← stenno left	12:56
	← cart_ left	12:57
	← Xenguy left	13:01
	→ sudoforge joined	13:01
	← XV8 left	13:02
	→ XV8 joined	13:03
	→ Rashad joined	13:04
	→ gdd joined	13:06
	→ srinidhi joined	13:07
	→ cart_ joined	13:10
	← srinidhi left	13:18
	← cart_ left	13:20
	→ cart_ joined	13:21
	→ l4s8g_ joined	13:21
	← ghost43_ left	13:21
	→ ghost43 joined	13:21
	← vysn left	13:23
	→ cdown joined	13:24
	→ stenno joined	13:25
	← csm3105 left	13:26
	→ dionysus69 joined	13:29
	← l4s8g_ left	13:30
	→ lukedashjr joined	13:30
	→ dionysus70 joined	13:30
	← luke-jr left	13:33
	lukedashjr → luke-jr	13:33
	← dionysus69 left	13:34
	dionysus70 → dionysus69	13:34
	→ sa0 joined	13:38
	← stenno left	13:39
	→ warblr joined	13:53
	← ghost43 left	13:53
	→ ghost43 joined	13:54
	→ tatuio joined	13:59
	← ghost43 left	14:00
	→ ghost43 joined	14:03
	← cdown left	14:06
	← tyson2 left	14:08
	→ caveman joined	14:09
	← otis^ left	14:10
	← sa0 left	14:10
	← mattil left	14:16
anddam	howdy, I have a list of commits A--B--C--D--E--F--G and I want to create A--G' where G' has all the squashed B .. G commits	14:19
	I figured I could do this by checking out A and then merge --squash G	14:19
	→ regedit joined	14:20
regedit	hello	14:20
	← ghost43 left	14:21
	→ ghost43 joined	14:22
regedit	is there some way to split current changes into different patches or commits or branches?	14:22
	for ex. i did a bunch of changes now in working tree but i realize 50% of them are 1 topic and 50% are another topic, i wanna go through them hunk by hunk and divide them into different commits/patches/branches or whatever makes sense	14:22
anddam	my issue is I had conflicts, whereas I expected --theirs to just "win the race" in conflics	14:22
	x/conflics/ c/conflicts/	14:22
	← roadie left	14:22
osse	if you get conflicts then the history isn't so linear you claim it is	14:23
anddam	osse: it is not	14:23
	osse: and this is a different repo	14:23
osse	anyway, you can git reset --soft A && git commit -m "Mega G'"	14:24
	regedit: use git add selectively before committing	14:24
anddam	this is a branch intended to be "public" opposed to the internal one, so I need to create a single "Mega Blob Message" commit on top of it	14:24
	osse: the reset after the conflicting merge or from a clean status in A?	14:25
	← moldorcoder7 left	14:25
regedit	osse: git add is on a file level tho? how do i git add on a line-by-line (hunk by hunk? cherry pick?) level	14:25
anddam	no, wait, reset --soft A means I should be in G	14:25
osse	regedit: git add -p	14:25
	← otisolsen70 left	14:25
regedit	ah very cool lemme look into that	14:25
	thx	14:25
	← tatuio left	14:26
regedit	how do i "safely" revert any git adds back to unstaged (but not lose any edits!...)	14:26
osse	git reset (-p)	14:26
	anddam: yes, clean state at G	14:26
regedit	ah wow it also has -p coooool	14:26
	→ The_Blode joined	14:27
anddam	osse: that moves G ref to A	14:28
	← The_Blode_ left	14:28
regedit	is there a way to git stash only what is staged or what is unstaged?	14:28
osse	anddam: It move HEAD from G to A, yes	14:29
	→ m5zs7k_ joined	14:31
	→ moldorcoder7 joined	14:31
	→ tyson2 joined	14:31
	m5zs7k_ → m5zs7k	14:31
	→ on^ joined	14:31
anddam	no, it moved the "label" G (forgive my lack of proper lingo) to point at the same ref of A	14:35
osse	ehh, sure	14:36
	I thought all those letters represented commit hashes	14:36
anddam	no, labels	14:37
osse	define label	14:37
anddam	"devel" and "master"	14:38
	refs ?	14:38
osse	sounds like branches to me	14:38
	so what is this, then: A--B--C--D--E--F--G	14:38
	are those seven branches?	14:38
	you even wrote "list of commits"	14:39
	→ stenno joined	14:39
anddam	no, that's me being bad at explaining, and understanding	14:41
osse	Let me draw up what I mean	14:41
anddam	I did mean those as commits, but used their currently attached branch names	14:41
	I just re-did the steps using G's tag and A remote (so no local branch) and it works as you said	14:42
	→ gast0n joined	14:42
anddam	I thought I could use either a commit or branch name, if they were the same _at that moment_	14:42
	← bertvvvs left	14:42
	→ pulse joined	14:44
	← hololeap left	14:45
osse	Could use either a commit or branch name where? If you mean this command: git reset --soft A then yes, you can specify the commit to reset to any way you want	14:45
	what is reset is the same in any case: the currently checked out branch	14:46
	→ hololeap joined	14:46
	→ roadie joined	14:49
	→ dvanloon4 joined	14:50
	← dvanloon left	14:51
	dvanloon4 → dvanloon	14:51
	← caveman left	14:53
	→ DoofusCanadensis joined	14:58
	← roadie left	14:58
	→ srinidhi joined	15:00
	→ cambrian_invader joined	15:04
_rgn	hi osse, still using git-blamediff every day. o>	15:06
	→ zebrag joined	15:07
	→ roadie joined	15:12
osse	_rgn: nice!	15:16
	→ YellowSuB joined	15:17
	→ Misotauros joined	15:17
	← roadie left	15:18
	→ szymon joined	15:18
	← saroy left	15:19
	← szymon left	15:19
	→ szymon joined	15:19
	→ sa0 joined	15:20
	← szymon left	15:20
	← ghost43 left	15:20
	→ ghost43 joined	15:20
	→ anaveragehuman joined	15:21
	← ghost43 left	15:24
	→ ChmEarl joined	15:24
	→ tulpa_ joined	15:24
davve	any way to show a file in a given commit? (preferably just the contents)	15:25
	→ ghost43 joined	15:25
	→ vysn joined	15:26
	→ subopt joined	15:26
	→ rgrinberg joined	15:27
osse	davve: git show commit:file	15:29
	→ madewokherd` joined	15:29
anddam	I would have gone with git cat-file -p since I did now know show commit:files would work	15:30
	→ roadie joined	15:30
anddam	but osse's hint is way more handy	15:30
	← hoochmonger left	15:31
anddam	osse: "Could use either a commit or branch name where? " <<< I mean that in my previous example I did "checkout devel" when devel was pointing at G, the "reset --soft A" moved devel from G to A. If I had done "checkout G" instead that would have been fine	15:32
	my confusion was that I could use either "devel" or "G" and that would not change anything	15:32
	← madewokherd left	15:32
	← stenno left	15:34
osse	ah	15:34
	← tyson2 left	15:35
	← moldorcoder7 left	15:35
	→ feriman joined	15:36
	→ geowiesnot joined	15:38
	→ moldorcoder7 joined	15:41
	← roadie left	15:41
	→ Oblomov joined	15:45
	→ blaklistd0 joined	15:45
	→ awmv joined	15:46
	← blaklistd left	15:46
	blaklistd0 → blaklistd	15:46
	→ wakeup joined	15:48
wakeup	I created a file in branch B. I didn't commit it. I switched to branch A. I still see the file in A. I don't want to accidently commit this file in A. So, how is there a way to make it "visible" only in B?	15:49
	→ AbleBacon joined	15:49
osse	no. either commit it (and amend that commit later) or use git stash	15:49
wakeup	git stash where?	15:50
	what does it do	15:50
	https://www.google.com/search?q=git+stash+meaning&oq=git+stash+meanin&aqs=chrome.0.0i512j69i57j0i22i30l7j0i390.2666j0j7&sourceid=chrome&ie=UTF-8	15:50
osse	exactly	15:51
	→ justsomeguy joined	15:51
wakeup	after google rejected, I think I should stop using google search engine	15:51
	as if that would change anything for them	15:51
osse	is the file currently untracked?	15:52
	as in, the file is new	15:52
wakeup	yes it's untracked	15:52
osse	in that case I would use commit instead of stash, because stash with untracked files is a bit tedious	15:53
	imho	15:53
	→ caveman joined	15:53
	→ wilz joined	15:56
wakeup	but I don't want to commit it for now	15:57
osse	I get that	15:57
	You can amend that unwanted commit when you are ready to actually commit, or undo the commit when you switch back to B	15:58
wakeup	maybe I can just put it into the gitignore	15:58
osse	that won't remove it from disk though	15:58
	← madewokherd` left	15:59
	← pulse left	16:05
	→ stenno joined	16:06
wakeup	how would you stage only new files	16:06
	git add -A stages all files, new, modified, deleted	16:06
	← justsomeguy left	16:06
wakeup	git add . stages modified and new files, no deletions	16:06
	I use this command usually to stage	16:07
	→ roadie joined	16:07
wakeup	but I should be more specific from now on	16:07
	and use the one that I really need	16:07
osse	I don't know of a direct way of staging only new files	16:09
	happens so rarely	16:09
	git add $(git ls-files --others --exclude-standard) I guess	16:09
	if your filenames are shell-friendly	16:09
	→ Sulky_ joined	16:10
	← ghost43 left	16:11
	→ ghost43 joined	16:11
	→ m0viefreak joined	16:11
	← Sulky left	16:12
	← awmv left	16:13
	← srinidhi left	16:15
	← roadie left	16:16
	→ roadie joined	16:16
	← caveman left	16:16
	← R2robot left	16:17
	← ghost43 left	16:17
	→ justsomeguy joined	16:18
	→ ghost43 joined	16:18
	← geowiesnot left	16:19
	← Murr left	16:19
	→ Murr joined	16:20
	← roadie left	16:21
	→ madewokherd joined	16:24
anddam	I had a local annotated tag foo that I force updated onto remote from another repo, so when fetching my local tag stays at the old ref	16:24
	is there a way to "refresh" all tags according to a certain remote ?	16:25
wakeup	how would you merge 2 or more commits in git? these commits have already been pushed	16:27
	I think I did this once	16:27
	→ junktext joined	16:27
anddam	wakeup: you put yourself at a certain ref and merge the other	16:27
	"checkout" to check out a ref, "merge" to perform the merge	16:27
	→ pulse joined	16:28
wakeup	https://stackoverflow.com/a/61171280/3924118	16:29
	→ fxrs joined	16:30
wakeup	git reset soft means?	16:30
	← anaveragehuman left	16:30
anddam	I don't envy you	16:30
	→ bertvvvs joined	16:30
wakeup	hah?	16:31
canton7	wakeup, !resets, https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified	16:32
gitinfo	wakeup: tl;dr of man git-reset: --soft moves HEAD, --mixed moves HEAD+index, --hard moves HEAD+index+work-tree, -- foo.txt will !unstage	16:32
wakeup	hah	16:33
	ok	16:33
	so basically we make the head detached	16:33
	→ tyson2 joined	16:36
	← mthall left	16:37
	→ mthall joined	16:37
	← rgrinberg left	16:42
	→ Jacques joined	16:43
	→ roadie joined	16:44
	← iomari891 left	16:44
	← Andy_Kw left	16:44
	→ R2robot joined	16:44
	← vysn left	16:45
	→ masber joined	16:46
regedit	how do i cancel all changes/edits that have not been added/staged - anything staged should remain staged	16:48
	→ great_taste joined	16:48
regedit	cancel i.e. revert back to when everything was last added/staged	16:48
	→ howdoi joined	16:49
	← justsomeguy left	16:49
	← stenno left	16:50
	← Rashad left	16:51
	→ Sulky__ joined	16:53
	← cart_ left	16:54
	→ Rashad joined	16:55
Anticom	regedit: afaik only staged changes are stashed. So what I would do is stash the staged changes, then revert everything that remains and re-apply the stash	16:56
	→ funhouse joined	16:56
	← roadie left	16:56
	← Sulky_ left	16:56
regedit	i think my earlier question from about 1.5hr ago was about stashing. just now i was asking just about reverting changes that werent staged (which apparently is by git checkout -- .)	16:57
	er 2.5hr ago	16:58
Anticom	Well most of us aren't paid for hanging out in here but have work to do ;)	16:58
regedit	it's ok i think you thought i was commenting about you answering late. i was actually trying to clarify potential confusion between the previous question and most recent	16:59
	← rfuentess left	16:59
Anticom	Ah i see :) Let me try to reproduce your scenario	16:59
regedit	oh thanks 🙏	17:00
	← ghost43 left	17:00
	→ ghost43 joined	17:00
Anticom	Hm	17:02
	Hm looks like there's a way simpler solution: https://stackoverflow.com/a/52713/966530	17:03
	`git checkout -- . ` seems to do the trick for me	17:03
	however i don't quite know why	17:03
	← masber left	17:04
nedbat	I can get GitHub pull requests locally with `git fetch origin pull/299/head:pr/299 && git checkout pr/299`, but then I can't pull to get more changes. I can do this: `git pull origin pull/299/head; git reset --hard FETCH_HEAD`, which works, but that last command seems really odd... What should I do instead?	17:04
Anticom	Probably does something similar to `git checkout HEAD <path_spec>`, however if I do `git checkout HEAD .`, everything is getting reverted	17:05
	And I didn't knew about `git restore` yet, so two things learned :)	17:05
	→ srinidhi joined	17:06
	→ sobkas joined	17:07
	→ masber joined	17:07
	← Jacques left	17:08
Anticom	nedbat: have you consulted https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally ?	17:08
	Anyways gotta run, good luck guys!	17:08
	← Anticom left	17:09
	← PaterTemporalis left	17:09
	← ChmEarl left	17:11
	← tyson2 left	17:11
osse	anddam: git fetch origin '+refs/tags/:refs/tags/'	17:12
	→ ChmEarl joined	17:13
osse	actually no	17:14
	confused	17:15
	but deleting the tags works	17:15
	→ Jacques joined	17:19
	→ justsomeguy joined	17:20
	← ghost43 left	17:28
	→ ghost43 joined	17:29
	→ skapata joined	17:32
	← skapata left	17:32
	→ skapata joined	17:32
	→ zumba_addict joined	17:36
	← feriman left	17:41
	→ anaveragehuman joined	17:41
	← wakeup left	17:42
	← XV8 left	17:42
	← bindu left	17:45
	→ bindu joined	17:45
	← Haohmaru left	17:46
	→ humanBird joined	17:47
	→ feriman joined	17:47
	← m0viefreak left	17:48
	← tulpa_ left	17:51
	← Jacques left	17:56
	→ XV8 joined	17:58
	← Misotauros left	17:59
	← jnnnnnnnnn_ left	17:59
	→ jnnnnnnnnn joined	17:59
	→ Akiva joined	18:04
	← ghost43 left	18:12
	→ ghost43 joined	18:13
	← TheCatBehemoth left	18:15
	→ roadie joined	18:17
	← Murr left	18:20
	→ Murr joined	18:20
	→ tyson2 joined	18:21
	→ ecraven joined	18:23
	← masber left	18:23
ecraven	hello ;) how do I show the Nth commit in a branch? I found I can use `git rev-list --all --count` to see how many commits there were until now, but say I want to see the 19420th (or rather just get its commit hash)	18:24
	→ Misotauros joined	18:24
ikke	ecraven: this is only well defined if you number backwards (from the most recent commit in a branch backwards to older commits)	18:25
	← rsx left	18:25
ikke	If that's what you want, then HEAD~N,	18:26
	← justsomeguy left	18:26
ecraven	well, I want the 19420th commit on the current branch, so go back to the start, then count 19420 along.. is there a simpler way to do this than implement this (count backwards, then subtract to get N for HEAD~N)?	18:27
	→ rgrinberg joined	18:28
ikke	No, there is not	18:28
	In theory there can be more than one Nth commit	18:29
	History is not necessarily flat	18:29
	← ghost43 left	18:29
	← jnnnnnnnnn left	18:29
	→ ghost43 joined	18:30
ikke	there can also be more then one root commit, so a single commit can have multiple positions	18:30
	→ jnnnnnnnnn joined	18:31
ecraven	yea, it seems in this repo there are no multiple-parent-commits	18:31
	→ Codaraxis__ joined	18:31
ikke	right, but git cannot assume that, so git does not have general tools to give that information or to refer to commits in that manner	18:32
	← jnnnnnnnnn left	18:32
ecraven	yea, I understand that. thanks for the tip, I'll just implement this as HEAD~(current-count - 19420)	18:32
	→ jnnnnnnnnn joined	18:32
	← bertvvvs left	18:34
	← perrierjouet left	18:35
ikke	https://tpaste.us/X0g1	18:35
	← Codaraxis_ left	18:36
ikke	https://tpaste.us/LeYm	18:37
ecraven	yea, I understand. thank you!	18:37
	← roadie left	18:38
	→ roadie joined	18:38
	← roadie left	18:43
	→ bertvvvs joined	18:43
	← rgrinberg left	18:45
	→ rgrinberg joined	18:47
	← tyson2 left	18:49
	← justOkay left	18:51
	→ justOkay joined	18:52
	← rgrinberg left	18:53
	→ The_Blode_ joined	18:54
	← The_Blode left	18:54
	→ pyeveryt_ joined	18:56
	→ john_johnk joined	18:58
dob1	I was reading this https://stackoverflow.com/a/28193740/399637 part 1. "This means the changes from f1 are not present on master (and cherry-picking possibly fails if f2 depends on them." if commits are snaptshot f2 has to include f1 too, it is just a diff then cherry pick ?	18:59
	← ghost43 left	19:00
	→ duxsco joined	19:00
ikke	dob1: cherry-pick roughly diffs a commit against its parent, and then tries to apply that on the target	19:00
	→ ghost43 joined	19:01
dob1	ikke, and when you specify more than one commit ?	19:02
ikke	It just iterates over each commit	19:03
	→ Jacques joined	19:03
	→ vicfred joined	19:03
dob1	it creates a diff for each one ?	19:03
ikke	yes	19:04
	← jimklimov left	19:04
	→ ghost43_ joined	19:06
	→ jazzy joined	19:08
	← ghost43 left	19:09
	→ roadie joined	19:09
	→ structoha joined	19:09
	← john_johnk left	19:13
	← roadie left	19:14
	→ vitali64 joined	19:15
	→ wakeup joined	19:15
	→ roadie joined	19:17
	→ vitali64_ joined	19:20
	← vitali64 left	19:22
	← structoha left	19:24
	vitali64_ → vitali64	19:24
	→ rgrinberg joined	19:25
	← roadie left	19:27
	→ junebug joined	19:28
	→ marstaik[m] joined	19:28
	← duxsco left	19:29
marstaik[m]	Hi, I've got a question regarding how to do a clean merge from an upstream while maintaining locally deleted files in a sane way	19:29
	Say Ive checked out upstream, done changes to it, and completely deleted some extra module folders that I deem I dont need	19:30
	← rgrinberg left	19:30
marstaik[m]	I then want to keep myself up to date with upstream, so I checkout upstream into another local branch	19:30
nedbat	marstaik[m]: i would recommend not deleting those folders. why not just keep them?	19:30
marstaik[m]	Extra things that aren't really needed	19:30
ikke	delete them when deploying?	19:31
marstaik[m]	I dont even have them registered in the build system	19:31
	In this particular case, Ive ported the upstream to a completely different buildsystem, so every time I merge it keeps trying to bring their build files back, there are large amounts of thirdparty libraries I don't care for either	19:31
	← vitali64 left	19:32
marstaik[m]	I guess I could solve it with a custom post-merge script that just deletes everything again but I was hoping there would be a better way	19:32
	→ vitali64 joined	19:32
	→ duxsco joined	19:33
ikke	no	19:33
marstaik[m]	I see, guess I can just make bat file or python script that nukes them all after I merge, or during merge	19:34
vaio	ohai, which self-hosted "git platform" would your recommend ? ie: gogs, gitea, something else ?	19:35
ikke	depends on your needs	19:35
	gitea and gogs are quite similar (one forked from the other)	19:35
vaio	well, it's gonna be a public infra containing some project documentation, and we need to be able to "filter" who can access it	19:36
nedbat	marstaik[m]: why delete them at all?	19:36
marstaik[m]	theres just so much of them, and the clutter	19:36
vaio	(ie: clients will need to access it, and presumably provide PR; also, it needs to be user friendly, so non technical people would be able to edit stuff from within the browser)	19:37
ikke	gitlab supports that	19:37
nedbat	marstaik[m]: clutter on your disk? are you running out of space? don't complicate your life needlessly	19:37
vaio	neat, gonna take a look, thanks ikke	19:37
marstaik[m]	mmmm Id have to think about it	19:39
	There are other files I have deleted too that I actually do need to keep deleted as well	19:40
nedbat	marstaik[m]: ok, those files: why do they have to be deleted?	19:40
	marstaik[m]: is the upstream uninterested in your changes?	19:40
marstaik[m]	In this case, yese	19:40
	* In this case, yes	19:40
	→ etuckeriv joined	19:47
	← EvilDMP left	19:49
	← vitali64 left	19:51
marstaik[m]	maybe it is just better to keep them...	19:52
	→ zeenk joined	19:52
	→ vitali64 joined	19:53
	← feriman left	20:01
	→ ghost43 joined	20:03
	← ghost43_ left	20:03
	← ghost43 left	20:05
	← ecraven left	20:05
	→ ghost43 joined	20:06
	→ feriman joined	20:06
	→ Lord_of_Life_ joined	20:09
	← Lord_of_Life left	20:11
	← on^ left	20:12
	Lord_of_Life_ → Lord_of_Life	20:12
	← vitali64 left	20:13
	→ vitali64 joined	20:14
	→ rgrinberg joined	20:20
	← feriman left	20:25
	→ perrierjouet joined	20:27
	→ ___nick___ joined	20:28
	← ___nick___ left	20:28
	← anaveragehuman left	20:29
	→ ___nick___ joined	20:30
	→ vitali64_ joined	20:30
	→ jimklimov joined	20:30
	→ feriman joined	20:30
	← vitali64 left	20:33
	← rgrinberg left	20:34
	← wakeup left	20:37
	← feriman left	20:41
	← hololeap left	20:42
	→ chemsmith joined	20:43
	→ hololeap joined	20:44
	→ phox joined	20:44
phox	soooooo. is anyone going to object to a patch where a rebase on the destination branch retains merge parents for merge commits?	20:45
ikke	phox: maybe today is your lucky day	20:45
phox	every time I commit ; checkout mainline ; merge ; pull (yes I should remember to pull first) I encounter this IMO-wrong behaviour :P	20:45
ikke	look at git rebase --rebase-merges	20:45
phox	ikke: is someone writing it?	20:45
	k, checking	20:45
ikke	someone already did	20:45
phox	heh	20:45
	I wish it was default but something :)	20:45
	ikke: although this is for auto-rebase-on-pull	20:46
	so maybe it's not tied in where I need it	20:46
	would basically be an option to pull, or a config option better yet	20:46
	→ feriman joined	20:47
	→ vysn joined	20:48
phox	> Any resolved merge conflicts or manual amendments in these merge commits will have to be resolved/re-applied manually.	20:48
	I mean I guess I'd be in the same boat with the pull as-is, I'm just not hitting merge conflicts there...	20:48
	→ EvilDMP joined	20:51
	← bertvvvs left	20:52
	← vitali64_ left	20:53
	← feriman left	20:53
	→ vitali64 joined	20:53
	→ irc_user joined	20:54
	← AnapodoPsalidaki left	20:57
	→ feriman joined	20:59
	→ m0viefreak joined	21:02
	← ___nick___ left	21:03
	← feriman left	21:07
	→ Thanatermesis joined	21:08
	← madewokherd left	21:10
	→ vitali64_ joined	21:12
	→ feriman joined	21:13
	← vitali64 left	21:13
	← vitali64_ left	21:14
	→ tyson2 joined	21:14
	← duxsco left	21:14
	← Rashad left	21:15
	← ghost43 left	21:16
	→ ghost43 joined	21:16
	← ghost43 left	21:17
	→ ghost43 joined	21:17
	← Techcable left	21:18
	→ Techcable joined	21:18
	← feriman left	21:21
	← junebug left	21:28
	← Deknos left	21:31
	← vysn left	21:31
	← Codaraxis__ left	21:33
	→ ProperNoun joined	21:35
	→ madewokherd joined	21:37
	→ feriman joined	21:46
	→ Codaraxis__ joined	21:49
	← Codaraxis__ left	21:53
	← srinidhi left	21:53
	→ Codaraxis__ joined	21:53
	← Sulky__ left	21:59
	→ Sulky__ joined	22:01
	← Codaraxis__ left	22:05
	← ghost43 left	22:07
	→ ghost43 joined	22:08
	→ peepsalot joined	22:09
	→ geowiesnot joined	22:10
	→ wakeup joined	22:22
	← feriman left	22:24
	← jimklimov left	22:25
	← ghost43 left	22:28
	→ ghost43 joined	22:28
	← Sulky__ left	22:29
	← etuckeriv left	22:37
	→ eddie joined	22:38
	eddie → etuckeriv	22:39
	← etuckeriv left	22:42
	← DoofusCanadensis left	22:44
	← geowiesnot left	22:47
	→ qwedfg joined	22:49
	← madewokherd left	22:51
	→ junebug joined	22:52
	← moldorcoder7 left	22:53
	← pulse left	22:58
	→ moldorcoder7 joined	22:58
	→ pizdets_ joined	23:03
	→ awmv joined	23:03
	← pizdets left	23:04
	← palasso left	23:07
	← ghost43 left	23:08
	→ pulse joined	23:09
	→ ghost43 joined	23:09
	→ jimklimov joined	23:15
	← Gustavo6046 left	23:16
	← zeenk left	23:20
	← xkuru left	23:20
	← kenanmarasli left	23:23
	→ stats4647 joined	23:27
	← junebug left	23:28
	← vicfred left	23:29
	→ madewokherd joined	23:33
	← wakeup left	23:39
	→ pretty_dumm_guy joined	23:44
	← awmv left	23:45

Logs Search ←Prev date Next date→

Channels Documentation