IRCloggy #git 2021-07-28

Logs Search ←Prev date Next date→ Channels Documentation

Provider of IRC logs since 2005.
WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

2021-07-28

→ sickdyd joined00:00
→ igemnace joined00:00
→ hubble63 joined00:00
→ jhulten joined00:01
← Null_A left00:03
← hubble left00:04
← jhulten left00:05
← forgotmynick left00:06
→ jimklimov joined00:06
← pizdets_ left00:06
← christall left00:06
← hubble63 left00:07
← jimklimov1 left00:10
← rafspiny left00:14
→ rafspiny joined00:15
→ hbautista joined00:17
→ YuGiOhJCJ joined00:26
→ ferdna joined00:27
→ pizdets joined00:31
← adanwan left00:32
→ adanwan joined00:32
→ jhulten joined00:35
← jhulten left00:39
→ jhulten joined00:45
← AbleBacon left00:46
← jhulten left00:56
→ Gurkenglas joined00:58
← fructose left01:02
← sickdyd left01:03
→ bambanxx joined01:04
→ sickdyd joined01:08
← Raguile left01:11
→ Null_A joined01:13
← rahl- left01:17
← igemnace left01:19
← jwillikers left01:19
→ lasr[m] joined01:21
→ Raguile joined01:23
← m0viefreak left01:27
→ igemnace joined01:31
← average left01:32
← ackyshake left01:33
← Sasazuka left01:33
→ nate3 joined01:35
→ gast0n joined01:39
← hposca left01:43
→ hposca joined01:43
← hbautista left01:44
← bambanxx left01:52
← hposca left01:56
← nate3 left01:57
→ hubble joined01:58
→ bongobrown joined02:01
→ hbautista joined02:02
→ nate3 joined02:02
→ hbautista_ joined02:04
← Gustavo6046 left02:06
← Samian left02:07
← hubble left02:07
← hbautista left02:07
→ tolot_ joined02:10
→ lechner joined02:10
lechner Hi do "git clone" etc. sometimes suppress the usual output in scripting environments?02:12
→ bambanxx joined02:13
← bambanxx left02:13
→ Gustavo6046 joined02:13
← tolot left02:14
→ Samian joined02:25
← jiffe left02:29
→ finn_elija joined02:29
← FinnElija left02:29
finn_elija → FinnElija02:29
→ jiffe joined02:31
→ vicfred joined02:44
→ Sasazuka joined02:44
← nyah left02:46
← thiago left02:52
← Samian left02:59
← Sasazuka left03:09
← nate3 left03:19
← zebrag left03:22
← Null_A left03:24
→ __jmcantrell__ joined03:32
__jmcantrell__ → jmcantrell03:32
← Gurkenglas left03:38
← tang^ left03:38
→ apauli joined03:39
← PaMeDa left03:42
← jmcantrell left03:43
→ jmcantrell joined03:48
← dermato left03:52
→ saroy joined03:53
← saroy left03:54
← bket left03:54
← tejr left03:54
→ Null_A joined03:55
→ saroy joined03:57
→ bket joined03:57
→ tejr joined04:00
→ gnoo joined04:05
→ nate3 joined04:07
← nate3 left04:15
tirnanog lechner: if stderr is not directed to a tty, for example.04:16
→ haltux joined04:20
← tejr left04:22
→ tejr joined04:23
← haltux left04:24
lechner tirnanog: thanks!04:30
← gast0n left04:32
← AnAverageHuman left04:35
→ vdamewood joined04:37
→ vinleod joined04:41
→ jhulten joined04:43
← vdamewood left04:43
→ tWqaq joined04:54
← tWqaq left04:54
← lgc left04:55
→ arcatech_ joined04:56
← arcatech_ left04:57
← arcatech left04:59
→ skapata joined05:01
← skapata left05:01
→ skapata joined05:01
→ thiago joined05:02
← sudoforge left05:06
← Null_A left05:14
← thiago left05:16
← jhulten left05:22
← lpapp left05:25
→ gas51627 joined05:25
corelax_ → corelax05:32
→ adlternative joined05:35
LSD → acidsys05:49
→ guy_frm_yogaland joined05:49
vinleod → vdamewood05:56
→ palasso joined06:00
← jetchisel left06:05
← YuGiOhJCJ left06:06
← guy_frm_yogaland left06:07
→ YuGiOhJCJ joined06:09
← ferdna left06:13
← Lord_of_Life left06:18
→ Lord_of_Life joined06:19
→ cvmn joined06:27
← skapata left06:27
→ __jmcantrell__ joined06:31
← cvmn left06:31
← jmcantrell left06:34
→ randomuser joined06:38
→ FH_thecat joined06:41
← hbautista_ left06:50
→ atharvaraykar joined06:52
→ rfuentess joined06:53
→ jmcantrell joined06:57
← randomuser left06:59
← __jmcantrell__ left07:00
→ jetchisel joined07:01
→ zeenk joined07:01
→ theoceaniscool joined07:02
→ Ogronios joined07:02
→ randomuser joined07:03
→ guy_frm_yogaland joined07:05
← unluckyshrubbery left07:08
← Ogronios left07:09
→ cvmn joined07:11
← atharvaraykar left07:20
← theoceaniscool left07:20
→ atharvaraykar joined07:20
→ oxymoron93 joined07:21
cvmn how to ignore a tracked file? just putting it in .gitignore doesn't seem to work i guess.07:24
osse cvmn: there is no wa07:25
y07:25
!sparse_checkout07:26
gitinfo Sparse checkout can be used to restrict which files/folders are updated with all checkout and status operations. It cannot change the tree the checkout is rooted from. One common use case is locally keeping Git from updating some of the files tracked in your repository. See the "Sparse Checkout" section in man git-read-tree (https://gitirc.eu/git-read-tree.html).07:26
osse !assume_unchanged07:27
gitinfo 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.07:27
cvmn osse: there is no ay?07:27
→ DevAntoine joined07:27
oxymoron93 yup no wy07:27
cvmn osse: i want to make it untracked and ignored in the future. but currently it's tracked.07:28
oxymoron93 I just had to do it07:28
osse cvmn: ohhh, use git rm for that07:28
cvmn --cache too?07:28
osse sounds like you want that, yes07:28
--cached, that is07:28
cvmn then, as i git commit, git tells me to commit that i've deleted a file. my concern is: if someone git pulls, he will get his file deleted.07:29
osse ep07:29
goddammit07:29
YYYYYep07:29
My keyboard is acting up07:29
j416 cvmn: luckily he has Git, so he can easily get it back07:29
cvmn: git checkout <commit> -- <file>07:30
cvmn is it common to track .gitignore?07:30
j416 yes07:30
although, if that file is in some way important, I'm not sure I'd ignore it in the first place07:31
cvmn it's a file that keeps getting updated by git submmodules foreach ...07:31
j416 git updates the file?07:32
cvmn i have no idea what i did. this is my 1st git submodule use.07:33
.vim/pack/plugins/start/vimtex/*07:33
j416 sounds like it'd be a good idea to figure that out07:33
:D07:33
← reset left07:33
→ theoceaniscool joined07:33
cvmn every time i update the submodule, .vim/pack/plugins/start/vimtex keeps getting updated.07:33
osse is that file inside the submodule?07:34
cvmn yes07:34
[submodule ".vim/pack/plugins/start/vimtex"]07:34
osse that *is* the submodule07:35
cvmn so?07:35
← gas51627 left07:35
osse seems like you just have misunderstood submodules. When a submodule is updated, that needs to be recorded as a commit in the outer repo07:35
j416 so if you update it, it's not strane that it'll change07:35
ep07:35
strange*07:35
cvmn a bit clumsy. no?07:36
osse for your use, perhaps07:36
cvmn what should i do?07:37
osse git add .vim/pack/plugins/start/vimtex && git commit -m 'Update vimtex to the newest version'07:37
j416 the alternative would be to have no way to match the submodule to your parent project, meaning two people (recursively) fetching the same parent project might end up with different code07:38
cvmn but when i git pull on main git folder, what use do i have to see that in the git log? after all i think i'll need to git submodule foreach git pull master origin anyway to actually get them updated. no?07:38
→ epolanski joined07:38
cvmn i wonder if i should abandon submodules, and just git pull manually.07:39
j416 it's just like if you modified any other file, there's a change that you need to commit07:39
osse if someone else updates a submodule and you pull that down, git status will tell you that the submodule is out of date and you should 'git submodule update'07:39
j416 except this is an submodule07:39
osse 'git submodule update' is sometimes put in a hook so it happens automatically07:40
your foreach thing will update the submodules to the latest version available in the source repo, not the version that that the outer repo says they should be07:41
→ vysn joined07:42
osse And commits that change the recorded version of submodules appear in git log like any other commit07:43
← randomuser left07:45
← tirnanog left07:48
← mat001 left07:51
← daddy left07:52
→ daddy joined07:54
← rafspiny left07:59
← atharvaraykar left07:59
← TJ- left08:08
→ TJ- joined08:10
→ jimklimov1 joined08:11
← jimklimov left08:15
→ keypushe- joined08:19
← keypusher left08:19
→ atharvaraykar joined08:22
keypushe- → keypusher08:22
← fossdd left08:23
→ fossdd joined08:23
← Vonter left08:24
← Betal left08:26
→ Vonter joined08:27
← jetchisel left08:28
→ __jmcantrell__ joined08:29
← hnOsmium0001 left08:31
→ jetchisel joined08:31
← jmcantrell left08:33
→ natrys joined08:33
→ jmcantrell joined08:34
← __jmcantrell__ left08:37
rfuentess geez08:39
someone on my team forced a git rebase over the master branch (Disabling first the protection against that). And now I need to find the previous commit to fix its chaos08:40
and I was on holidays, so my local copies are very out-dated08:40
← jetchisel left08:41
cbreak rfuentess: do you have access to the reflog on the server?08:45
or the local repo of the perpetrator?08:45
rfuentess cbreak: yeah. I was thinking on trying to request a remote access to the perpetrator's local copy to fix it with reflog08:46
cbreak even git push output should contain this08:47
(it prints which hashes it replaces with which others)08:47
rfuentess for now, I'm exploring the remote repo where we do the merges. To see if the latest merge's HEAD it is safe to use08:47
Marmotte rfuentess: you don't need to access his local copy directly, he can push the old commits hashes to your centralized remote08:48
he can find these hashes using git reflog08:48
rfuentess I still can't understand why someone will say "this thing I want to do is safe, even if I need to remove many locks"08:50
an accidental rebase over an unprotected branch ? Sure. Not problem,. I did it many times on the past08:50
osse "git rebase over the master branch" sounds like it's not the master itself that is modified08:51
rfuentess osse: the perpetrator wanted to remove a commit that was merged too soon. So, he dropped it, and then forced a push into master (no idea why was not just reverted).08:53
Again, I'm not against that type of mistakes. I did it too on the past. I'm just annoyed that he had to remove a lock for be able to do it08:54
→ amirgon joined08:58
← saroy left08:58
→ unluckyshrubbery joined08:59
j416 rfuentess: just an idea: if the rewrite was done on purpose, simply accept the new state of that branch?09:00
← DevAntoine left09:00
← guy_frm_yogaland left09:00
→ DevAntoine joined09:02
← fossdd left09:03
→ saroy joined09:03
→ fossdd joined09:04
rfuentess j416: Yes. It is an alternative. On this case that "on purpose" means "I was too lazy to do a vile git revert and to warning everyone else about the imminent rebase"09:04
so, we got our current branches with new features on chaos due that09:05
→ __jmcantrell__ joined09:08
← jmcantrell left09:11
j416 rfuentess: easily fixable with more rebases :D09:12
rfuentess j416: hehehe yes it is :P09:14
j416 (I'm sure you know about rebase --onto, useful in this scenario)09:15
← igemnace left09:15
→ jmcantrell joined09:17
← __jmcantrell__ left09:21
rfuentess j416: probably I need to re-read it09:23
→ rahl joined09:25
← i7c left09:26
j416 rfuentess: tl;dr, if you know that in A <- B <- C <- D you don't care about A and B (which were rewritten in the rebase of master) and your branch only adds C and D, you can from your branch git rebase --onto newB B09:26
rfuentess: that'd effectively reset to newB and apply C and D on that.09:26
→ i7c joined09:27
j416 rfuentess: (where a regular rebase might instead end up with a conflict trying to apply the new master on top of the old master, i.e. A' <- B' <- A <- B <- C <- D)09:29
→ igemnace joined09:29
j416 rfuentess: er, old master on top of the new master. but the example is correct.09:30
← igemnace left09:35
rfuentess j416: basically for other contributors this may still giving them a easy time with a `git pull origin master` ?09:35
← cvmn left09:36
j416 rfuentess: pull is fetch + merge (unless configured otherwise), so they don't want that.09:37
at best you'd end up with duplicate commits09:38
cbreak git pull --rebase is much nicer09:38
→ adl_ joined09:38
← adlternative left09:38
j416 if rebase is tricky for them, you can always tell them to reset their master to upstream and restart their branch, cherry-picking their old commits.09:39
cbreak manual rebasing ;)09:39
j416 nod09:39
they'll need to do the reset _anyway_ to get a correct local master09:40
unless pull --rebase happens to sort that out for them09:40
← reprazent left09:41
→ reprazent joined09:42
j416 (if indeed you go ahead with the new master and give up rewriting it back to the old one, in case I suppose select few will have to do the reset dance still, since they may have reset to the new master :D)09:42
← DevAntoine left09:50
→ DevAntoine joined09:50
→ igemnace joined09:52
→ Gurkenglas joined09:52
← keypusher left09:55
← DevAntoine left09:55
→ cvmn joined09:57
→ pulse joined09:59
→ keypusher joined09:59
← fossdd left10:02
→ fossdd joined10:02
→ Ulli[m] joined10:07
← jmft2 left10:10
→ jmft2_ joined10:10
← fossdd left10:14
→ fossdd joined10:14
← keypusher left10:21
→ rewrit3 joined10:21
→ keypusher joined10:22
← Kamilion left10:37
→ sysh joined10:41
← Raguile left10:44
← yuckey2d left10:59
→ Kamilion joined11:02
→ m0viefreak joined11:03
← TJ- left11:05
← keypusher left11:07
→ TJ- joined11:08
→ keypusher joined11:09
← cvmn left11:12
← thetourist108 left11:13
← crysisanon[m] left11:13
→ skapata joined11:20
← skapata left11:20
→ skapata joined11:20
← fossdd left11:31
→ fossdd joined11:31
→ jwillikers joined11:38
→ shabius_ joined11:41
← dviola left11:41
→ dviola joined11:43
← jwillikers left11:43
← Murr left11:43
→ Murr joined11:43
← shabius left11:43
→ lpapp joined11:44
lpapp hi, I am confused, I have a bad and a good commit, but git says: Some good revs are not ancestors of the bad rev.11:44
git bisect cannot work properly in this case.11:44
Maybe you mistook good and bad revs?11:44
→ jwillikers joined11:44
lpapp how to reconcile this?11:46
osse are you min the middle of a bisect and you have answered good or bad a few times?11:47
lpapp just starting off.11:48
→ computeiro joined11:48
lpapp we got two builds on gitlab where one is not good, the other is. Trying to see where we introduced the regression11:48
I tracked down the commits on gitlab that those builds belong to11:48
and I would like to start bisecting the builds as there were multiple commits between those two builds.11:48
osse it seems git bisect is complaining that the good and bad commits are intermixed11:49
lpapp what does it mean intermixed in this case?11:50
osse that there cannot be one single commit where all commits before it are good and all commits after it are bad11:50
lpapp in the git log output, interestingly, it seems that the good commit is ahead in time11:50
of the bad11:50
this is odd11:50
maybe, the builds were done in a different chronological order than the commits?11:51
osse I'm in no position to know that :p11:52
← JollyRoger left11:52
→ JollyRoger joined11:54
lpapp Thanks.11:55
→ AnAverageHuman joined11:55
osse seems like you have to sort the builds by the commit they were built from, not the build date, and start from there11:59
lpapp osse: yeah, I do not know how to do that ...12:01
osse you know the precise commit each build is based on right?12:01
← skapata left12:02
lpapp yeah12:02
osse: but they are not bisectable!12:02
apparently.12:02
→ DevAntoine joined12:03
ikke lpapp: So you got a regression which was fixed later?12:03
and you want to bisect what commit introduced it?12:03
osse lpapp: they won't be if they are in the wrong order12:03
ikke Note that the terms good and bad can be confusing12:03
lpapp bug is still in their in main HEAD12:04
the whole situation is confusing...12:04
ikke The git bisect assumes that something started good, and then turned bad (so bad follows after good)12:04
but git bisect also allows you to redefined terms12:04
lpapp maybe I could go git bisect bad HEAD and git bisect good X12:04
?12:04
it will be a lot more work, but...12:04
osse that's how you're supposed to do it12:05
and preferable an X as recent as possible12:05
lpapp ok, thanks, it will be a lot more work than anticipated12:05
as I thought the QA's work to localise it to two consecutive builds could help.12:05
osse now i'm confused. what have you been doing until now?12:05
lpapp but not in this case then.12:05
ikke This is a bisect script I created the other day: https://tpaste.us/WE7B12:06
I could do git bisect run ./bisect-run.sh, and I could just let it run12:07
← YuGiOhJCJ left12:07
→ Lucgri joined12:18
← Lucgri left12:18
osse ikke: what's the point of calling git bisect terms --term-* in the script?12:19
← m0viefreak left12:19
lpapp for me, the tricky thing is that one build takes me 15-20 minutes12:19
and then manual fiddling and testing to see if it is good or bad12:19
so, I was hoping to reuse the QA research.12:19
who localised it to builds.12:19
ikke osse: visual output of what the bisect script is doing12:19
osse ikke: ah ok12:19
ikke osse: while using the terms that you defined with git bisect start12:19
→ mat001 joined12:19
osse lpapp: have QA identified some good and some bad builds?12:20
lpapp yes12:20
build numbers12:21
they do not do source code12:21
osse can you use the build numbers to find the commits?12:21
lpapp yes, but it is not the way git bisect expects it.12:21
So, yeah, not sure what is going on :D12:21
HEAD is broken, so bad12:22
and the fact that there was one commit good gives some hope12:22
← jazzy left12:22
osse find out if all the good builds are older than all the bad12:22
ikke Ehsy hr12:22
ugh12:22
osse if that's true, then you know the problem is between the last good and the first bad build. so you can bisect just that12:22
ikke What helped me visualizing it is using tig and look at the 'row' number of each commit12:23
→ lgc joined12:25
osse and by "older" I do not mean when the build was done, but the age of the commit it was built from12:26
← phundrak left12:32
← mra90 left12:34
lpapp older is newer :-P I know and appreciate that it is not ideal.12:36
→ t3nj1n joined12:36
ikke newer than?12:37
osse pen and paper helps in these kinds of situations12:39
← fossdd left12:41
→ fossdd joined12:41
← fossdd left12:48
→ fossdd joined12:49
lpapp when you are in a git bisect mode12:51
I just say git bisect bad or good without hash, yeah?12:51
since the commit is implicit :)12:51
osse to mark the current commit either good or bad, yes12:51
← computeiro left13:02
← irrgit left13:05
→ irrgit joined13:05
lpapp damn, broken build during git bisect13:07
that is a bit of a pain...13:07
osse git bisect skip13:08
ikke return exit code 125 (or git bisect skip)13:08
lpapp thanks13:09
what does skip do?13:09
does it apply some offset?13:09
osse I think it just moves to an adjacent commit13:09
→ hazmi35 joined13:14
← hazmi35 left13:15
→ jpe__ joined13:16
lpapp which one, before?13:16
osse I don't know13:17
ikke "Instead of choosing a nearby commit by yourself, you can ask Git to do it for you by issuing the command"13:17
I don't think it's definited which it will pick13:18
← sharperguy_ left13:18
lpapp thanks, someone suggested us earlier that there is a faster algorithm than git bisect (logn), is it true?13:21
← DevAntoine left13:22
→ DevAntoine joined13:23
ikke Isn't bisect log(n)?13:23
bremner yes13:23
hard to beat that in general13:23
ikke Yeah13:23
Not sure how you can do this faster than log(n)13:24
bremner you can apply heuristics, which might work better for some scenarios. I don't know of such implemented for git.13:24
ikke Never heard of anything13:25
You can use --first-parent to skip merged in branches13:25
bremner also, if you have so many commits to bisect that log(n) is more than 30, you might be doomed.13:25
ikke Depends on how fast you can test :)13:26
osse you can filter based on path too13:26
ikke Oh yeah, I forgot that13:26
→ dshikoh joined13:27
osse i tried looking through bisect-helper.c and I have no clue what happens when you skip a commit13:27
i'd expect it to just checkout the parent commit or something13:27
← Xenguy left13:27
← stats4647 left13:27
osse but the code is hard to follow13:27
→ gh34 joined13:28
← BUSY left13:28
→ stats4647 joined13:28
→ BUSY joined13:29
← stats4647 left13:33
lpapp bremner: It does not have to be more than 30 to speed up things13:34
for me, even 5->4 would be great because an attempt is 20-30 minutes.13:34
→ jetchisel joined13:37
→ r1ch joined13:38
→ arcatech joined13:39
bremner narrow the range of commits, I guess.13:39
lpapp well, even if I could, it would still be an extra 20-30 mins between 4->3 :)13:42
logn is not bad if you get instant feedback, I guess people start thinking something faster when one step is long.13:42
← Murr left13:43
→ Murr joined13:43
→ Jck_true3 joined13:44
← Jck_true left13:45
Jck_true3 → Jck_true13:45
lpapp https://cs.stackexchange.com/a/14023513:47
golden-section-search?13:47
→ darkbit joined13:48
bremner pretty theoretical / hypothical?13:49
← reprazent left13:50
→ reprazent joined13:51
lpapp it is possible :)13:52
but when you have to spend 30 mins waiting on one step, you reconsider your life :P13:52
← arcatech left13:53
ikke lpapp: do you have an automated way to verify if the bug is present or not?13:53
→ arcatech joined13:54
lpapp nope, manual testing :P13:56
:(13:56
→ randomuser joined13:57
→ nyah joined14:02
← fossdd left14:05
→ jazzy joined14:05
→ fossdd joined14:05
← fossdd left14:08
← dviola left14:10
→ dviola joined14:10
→ sudoforge joined14:14
← dshikoh left14:15
→ hubble joined14:19
← oxymoron93 left14:19
← Hrmmm left14:19
← r1ch left14:20
→ tirnanog joined14:21
← adl_ left14:23
→ fossdd joined14:25
→ thiago joined14:26
← randomuser left14:28
← reprazent left14:32
→ reprazent joined14:34
← atharvaraykar left14:42
→ cvmn joined14:44
← arcatech left14:46
← jazzy left14:48
← fossdd left14:53
→ fossdd joined14:54
→ arcatech joined14:54
→ dshikoh joined14:55
← dshikoh left14:57
→ skapata joined14:57
← skapata left14:57
→ skapata joined14:57
→ guy_frm_yogaland joined14:58
← DevAntoine left14:58
→ fef joined15:00
← sickdyd left15:08
← cvmn left15:08
→ hubble75 joined15:11
→ _sysh joined15:12
← hubble left15:13
← sysh left15:13
→ sickdyd joined15:13
→ Guest924 joined15:15
← AnAverageHuman left15:17
→ ferdna joined15:17
← sickdyd left15:18
→ AnAverageHuman joined15:22
→ banana_ joined15:23
→ sickdyd joined15:23
← madewokherd` left15:31
→ __jmcantrell__ joined15:33
← hubble75 left15:35
← jmcantrell left15:36
→ furrymcgee joined15:45
→ jmcantrell joined15:46
→ ThorMojito joined15:46
→ fnurkla joined15:48
← __jmcantrell__ left15:49
← guy_frm_yogaland left15:53
→ atharvaraykar joined15:54
← Guest924 left15:54
jpe__ → sharperguy15:57
← darkbit left15:57
← sickdyd left15:57
→ Null_A joined15:58
→ durham joined16:00
← durham__ left16:00
→ madewokherd joined16:02
← bulletsquid left16:03
← bkhl left16:03
← jiffe left16:03
← stark left16:04
← energizer left16:04
← wwalker left16:04
→ stkrdknmibalz joined16:04
← drogas left16:05
→ dskullz joined16:06
→ reset joined16:07
dskullz → dskull16:08
→ sickdyd joined16:09
← fossdd left16:10
→ fossdd joined16:11
→ AbleBacon joined16:12
→ bulletsquid joined16:13
→ energizer joined16:13
→ tkazi joined16:13
← sickdyd left16:13
← rfuentess left16:14
→ jiffe joined16:15
→ bkhl joined16:15
→ wwalker joined16:15
→ stark joined16:17
→ orbyt joined16:17
→ Betal joined16:17
→ stats4647 joined16:17
→ durham_ joined16:29
← durham left16:29
← pulse left16:34
→ tuskkk____ joined16:36
sangy silly question, because I don't know how to verify this. Does git grep grep on changed files that are either staged or unstaged for the next commit?16:37
ikke "Look for specified patterns in the tracked files in the work tree, blobs registered in the index file, or blobs in given tree objects"16:38
The default is 'tracked files in the work tree'16:38
← fef left16:40
→ fef joined16:41
← _sysh left16:44
lpapp wow16:47
git switch new-branch;git switch prev-branch16:48
I rerun the build16:48
and I get a lot of build steps with cmake16:48
is it a git thing that cmake is based on touching times and git touches files when switching branches, or something?16:48
→ nate3 joined16:48
lpapp same thing for git reset --hard HEAD~20 and git pull --rebase16:49
surely, the source and build artefacts do not change content?16:49
← fossdd left16:49
→ fossdd joined16:49
→ randomuser joined16:50
← stats4647 left16:50
imMute lpapp: I believe git sets the timestamps on the files to the commit date, so that might be whats causing cmake to rebuild16:51
→ humanface joined16:51
ikke no, git does not proactively set mtimes16:51
osse no, git just modifies the files it has to, and leaves the others alone16:52
imMute osse: it touches mtime for the files it modifies though, right?16:52
lpapp then why would I get a rebuild?16:53
osse imMute: I assume it opens the file for writing, writes and closes the bog standard way16:53
ikke maybe git has to write a file that is affecting a lot of other build arrtifacts16:53
lpapp git switch new-branch && git switch old-branch should do the same as if I had not run those two commands, surely?16:53
ikke no16:53
lpapp starting from old-branch16:53
imMute osse: I would assume that touches the mtime then...16:53
ikke git does not restore mtimes16:53
osse imMute: yep16:53
← zeenk left16:54
lpapp this is really bad16:54
it is causing me days of extra work16:54
ikke so the files have a newer timestamp than they were before16:54
osse imMute: the thing you're thinking of is probably git-archive16:54
lpapp is there a way to turn off this nonsense?16:54
ikke there is nothing to turn off16:54
imMute lpapp: touching mtimes when modifying a file is *not* something you want to turn off16:54
lpapp well, in worst case git :)16:54
ikke it requires something active to get the behavior you want16:54
There is a script that sets mtimes of files the the commit timestamp16:54
imMute lpapp: cmake *relies* on the mtime changing when the file gets changed.16:54
lpapp I hope you can see how this is really painful16:55
in a big codebase.16:55
when you try to git bisect16:55
since it will change mtimes like anything for each step16:55
causing really long builds.16:55
imMute it changes the mtimes on the files that changed. which would need rebuilding anyway...16:55
← nate3 left16:55
imMute so if it takes a long time to build, that's because there's a lot that actually needs rebuilding16:55
ikke ^16:55
lpapp I do not agree16:55
ikke why not16:55
lpapp git switch new-branch && git switch old-branch should rebuild 0 files.16:56
running this chain of commands16:56
ikke git does not promise to restore mtimes16:56
imMute that's a corner case that most people don't care about.16:56
lpapp it is quite unreasonable this to generate a 20 mins rebuild for me if I am honest :)16:56
it is not a corner case16:56
ikke lpapp: usa a build tool that looks at file contents rather than file metadata16:56
rewt why do you switch to a different branch and then back before the build?16:56
mackerman Keep checked out a work tree dedicated to this branch.16:56
lpapp you could perhaps argue that this is a cmake issue rather than git16:56
imMute why are you switching to a branch just to switch back? that's a corner case if I ever saw one.16:56
lpapp but the fact that modifying times cause huge rebuilds16:57
is really bad16:57
osse I ones worked on a codebase that had the current commit as a commandline define (ie. g++ -DCOMMIT=abcd). The problem with that is that *every compiler invocation* changed, so *every* file had to be rebuilt16:57
imMute no it's not. it's *fundamental* to how cmake works.16:57
lpapp I actually often have to switch branches to check something out16:57
some code there16:57
and then come back16:57
rewt you could use another worktree16:57
osse also not fun: g++ -DBUILDTIME=foo with second time resolytion16:57
lpapp this is by no means corner case in my workflow16:57
imMute lpapp: use multiple work trees or clones16:57
lpapp it is a standard usual case.16:57
nooooo16:57
that would be silly.16:57
imMute lpapp: why not?16:57
lpapp because this is what branches were meant for.16:58
imMute I used to have dozens of work trees for the last project I worked on16:58
lpapp to avoid multiple clones16:58
osse long builds are painful16:58
but reading16:58
lpapp I guess I could go back to the 90s16:58
osse stuff like16:58
lpapp but rather not.16:58
osse this is even16:58
worse16:58
rewt multiple worktrees do NOT need multiple clones16:58
osse lpapp: git diff --stat old-branch new-branch. how many files are changed?16:58
→ pulse joined16:58
osse and is one of them global.h that is included everywhere?16:59
lpapp osse: zero content if I switch back16:59
are you saying it is a cmake issue?16:59
osse no16:59
well, maybe16:59
rewt `git diff --stat old-branch new-branch` should have the same result regardless of which branch you're on16:59
osse maybe there are some unneeded dependencies (such as the things I described above)16:59
lpapp I am not interested in the diff between the two branches17:00
osse but I am17:00
I am trying to help17:00
rewt but that's what he asked about17:00
← roadie left17:01
← Anthaas left17:01
osse excessive rebuilding is often caused by hyperactive defines, generated headers and stuff like that17:02
but in any case, cmake relies (only) on modification times, there is no way to make git not do that, and git cannot read your mind and know that you're gonna switch back immediately after17:03
← andrzejv left17:03
lpapp that is why I said it may be a cmake issue17:03
not sure if it is reasonable for cmake to rely on modification time rather than content.17:03
without configurability.17:03
(or for any buildsystem for that matter)17:04
imMute lpapp: quite a few build systems rely on mtime. it's quite reasonable given the tradeoffs.17:04
mackerman Linus did not like this idea years ago. If the files didn't change, neither would the work tree. Also, caching compile outputs. Re: Git checkout preserve timestamp? https://markmail.org/message/b45lyln5eig6tp4x17:04
lpapp but sounds like branches are not as useful then as I thought :)17:04
if worktrees are more like the branch concept I have in mind.17:04
imMute branches are used for something else entirely.17:04
osse yes I think it can be a cmake issue as well17:04
(as in CMakeLists.txt being badly written)17:05
lpapp imMute: whose tradeoff? I do not think you can say it is the best solution for everyone.17:05
imMute if you need to look at multiple versions of the repo at a time, use multiple work trees (or constantly switch between them and deal with the consequences)17:05
lpapp: checking mtime is way cheaper than any content-based system you come up with.17:05
osse there's a buildsystem (SCons) that uses the md5 instead of timestamp. But it's slow as hell for that reason17:05
lpapp imMute: is hashing really that hard?17:05
imMute lpapp: hard? no. fast? also no.17:05
osse it will use a lot of time to figure out what to do, and that gets annoying when the answer is that there's nothing to do17:05
lpapp so hashing is slower than rebuilding?17:06
Odd17:06
imMute lpapp: hashing a file is orders of magnitude more work than checking the mtime17:06
lpapp hashing a file versus rebuilding17:06
imMute I didn't say anything about rebuilding.17:06
lpapp I am17:06
osse Fucking hell man17:06
bremner lpapp: ccache is there for you17:06
lpapp because the alternative is rebuilding.17:06
osse you're twisting our words like it's a kitchen cloth17:06
imMute and yeah, it would really suck to have to wait for cmake to hash every file just to tell you there's nothing to do17:06
lpapp: no, the alternative is mtime checking.17:06
lpapp mtime is causing huge pain for me at the moment17:07
rewt lpapp, it has to figure out IF it has to rebuild first17:07
it does that via mtime; hashing is way slower17:07
imMute lpapp: we gave you a solution.17:07
lpapp rewt: yes, but if not (my case), it will be cheaper if hashing is faster than compiling anyway.17:07
osse also, maybe it's not even the mtime17:07
imMute lpapp: so get a build system that is able to work with file hashes rather than mtime?17:08
lpapp imMute: yes!17:08
configurably17:08
it could help at times.17:08
I do not debate that mtime is useful most of the times17:08
bremner as I said, look at ccache if you are waiting on compiles17:08
lpapp but there are rare times, like mine now, when perhaps it is not...17:08
imMute you certainly sounded like it a few minutes aggo.17:08
bremner it is exactly hash based rebuilds17:09
← nickmass left17:09
osse https://scons.org/17:09
bremner assuming C or C++, otherwise, dunno.17:09
osse "Reliable detection of build changes using MD5 signatures; optional, configurable support for traditional timestamps."17:09
imMute there we go. NEXT!17:09
→ nickmass joined17:09
lpapp bremner: yes, used ccache earlier, thanks, that sounds like the right thing that I would need.17:10
→ Guest9 joined17:14
lpapp osse: 10 files changed, 167 insertions(+), 506 deletions(-)17:15
2075 cmake build setsps17:15
steps, about 20-30 mins to get it through on a modern macbook pro.17:16
ikke lpapp: https://stackoverflow.com/questions/2179722/checking-out-old-file-with-original-create-modified-timestamps17:16
There are a number of tools mentioned there17:16
lpapp thanks, this is helpful!17:17
→ stats4647 joined17:17
osse lpapp: how many build steps are there in a clean build?17:17
lpapp 500017:17
ikke lpapp: note that this probably won't help you during bisect17:17
osse then my guess is that stuff is working as intended17:18
lpapp no, for bisect, I need ccache17:18
or maybe not even that, but like an optimised header system17:18
osse you could also touch -d yesterday **/*.cpp17:18
lpapp yeah, I guess that is what the automated tools do.17:19
by the use of git commands to get the files, etc.17:19
ikke osse: don't you prevent anything from bein rebuilt, then?17:19
lpapp where yesterday == oldmtime17:19
ikke yes, that's what those tools do17:19
osse ikke: sometimes I think like i drug dealer: "Hey, I just people what they want"17:19
*like a17:20
*give people17:20
jesus17:20
ikke :D17:20
lpapp too many enters :P17:20
→ Sasazuka joined17:20
→ TomyWork joined17:20
ikke too many typos17:20
← randomuser left17:20
osse About 40 % rebuilding sounds well withing normalcy, depending on which files are changed.17:20
osse checks if normalcy is a word.17:21
lpapp yeah, I guess in a big project, git bisect speedup is only possible by a well-designed header system17:21
to avoid rebuilding everything and the kitchen sink.17:21
ikke lpapp: I think that restoring mtimes might even break the build17:22
if it does not build artifacts where the source is older then the artifact17:22
lpapp yeah, but it would be useful to jump between branches17:22
to check out things.17:22
ikke if you checkout an old commit, it would prevent those files from being rebuilt17:22
lpapp unless worktrees are the preferred workflow for that sort of thing.17:22
ikke That's one of the primary usecases17:22
for worktrees17:22
← filePeter left17:23
lpapp Is this a relatively new feature? Never heard of it.17:24
Although, I have not tried to learn new git features the last 7-10 years.17:24
ikke 1 or 2 years old or so17:24
maybe older17:24
→ randomuser joined17:24
← fling left17:24
lpapp ah, that explains why I am not accustomed with it yet, thanks!17:24
osse 201517:25
I think it had a rough beginning, though. Now it's pretty neat.17:25
ikke lol, 6 years old17:26
lpapp if you guys all use it, I guess I should learn about it17:27
because it must be useful then17:27
ikke I rarely use it, but I do not work on C/C++ codebases17:27
lpapp I thought you work on git17:28
ikke I provided a couple of patches17:28
but nothing more17:28
jast when ikke needs to make changes to git, he does it telepathically17:29
osse An alternative (if you truly just want to look around) is to make a dump of the files somewhere using e.g. git archive. I use several worktrees at work. the git-worktree command itself isn't that often I use :P17:29
lpapp what about a second clone for browsing?17:29
osse My repo at work has the fabulous name "cpp". At work I do git worktree add ../cpp-blah new-branch and away I go17:30
ikke if you clone the repo using the filepath, then the 2nd clone would be cery cheap17:30
very*17:30
jast you can do that but it makes sense to clone locally, otherwise you have to re-download everything and the DB space is taken up twice17:30
if it's something you do often, probably git-worktree is easier17:30
lpapp I see, thanks.17:31
jast personally for quick one-off browsing I use tig17:31
osse A second clone is more distinct. With worktress you can 'git fetch' in one worktree, and origin/master will be up to date in the other.17:31
ikke the only 'downside' is that you can only have one worktree per branch17:31
lpapp as I can see, it will also expire17:31
so, it will not stray around17:31
I guess that is an advatange compared to clones.17:31
ikke That only applies when you remove the directory manually17:32
git will not expire worktrees that extill exist on disk17:32
osse luckily 'git worktree list' exists17:33
lpapp oh, yes, I misread it.17:33
Is worktree also the preferred choice for build for different architectures?17:34
or is that normally done with one clone and multiple build directories?17:34
jast personally I'd try to do it with different build dirs17:34
I don't want builds cluttering up my source tree anyway17:35
osse worktrees make sense for different versions of the codebase to co-exist. presumably you want to build the same codecase for the different architectures17:36
ikke for which worktrees are not suitable17:36
furrymcgee I am using worktree into build environment17:37
← gnoo left17:39
lpapp furrymcgee: how do you mean?17:40
→ jhulten joined17:40
furrymcgee kindof chroot17:40
lpapp ?17:41
chroot?17:41
I guess worktree does not duplicate the source files?17:42
I should try, shouldn't I17:42
osse do it17:43
← Murr left17:43
furrymcgee it does not duplicate the .git dir17:43
→ Murr joined17:43
osse git worktree add ../new-dir other-branch17:43
(whether you want to ../ is up to you of course)17:43
→ rsx joined17:43
← fossdd left17:44
furrymcgee whats the use case? you have lots of changes but dont want to build them?17:44
→ hnOsmium0001 joined17:45
→ fossdd joined17:45
jast the use case generally speaking is you want to work on more than one branch at a time17:45
personally I've never needed to, branch switching has always been enough for me17:46
lpapp yeah, it should be enough unless it causes costly rebuilds.17:46
j416 I use a secondary worktree from time to time to have a notes branch checked out where I keep some notes and todo list and similar. I find it handy.17:47
furrymcgee I think a switch should be minimal and not differ too much17:47
imMute furrymcgee: it changes the mtime on the files changed which causes them to rebuild. even if you switch back to the original branch before doing the build. that's lpapp's concern.17:48
lpapp yeah17:49
← stats4647 left17:49
lpapp I have to work against the main branch and a long-lived feature branch17:49
and there is a big diversion17:49
ikke Then I would use a worktree for one of them17:50
← dminuoso left17:50
→ hubble99 joined17:50
lpapp yeah, for that, I have used two clones17:51
j416 or both. b adum.17:51
lpapp but I will reconsider that now in favor of worktrees.17:51
→ guest29348769876 joined17:51
furrymcgee commit the global config.h to both branches17:52
← guest29348769876 left17:53
→ guest29348769876 joined17:54
→ DoofusCanadensis joined17:55
← TomyWork left17:55
rsx → Guest971017:55
← Guest9710 left17:55
← guest29348769876 left17:55
→ guest29348769876 joined17:55
← guest29348769876 left17:56
→ rsx joined17:56
← randomuser left17:56
→ stats4647 joined17:59
← stats4647 left17:59
← hubble99 left18:01
← sudoforge left18:14
← fossdd left18:16
→ zebrag joined18:17
← rsx left18:18
→ fossdd joined18:23
→ m0viefreak joined18:26
→ stats4647 joined18:31
→ hbautista joined18:32
→ roadie joined18:33
← fossdd left18:33
→ fossdd joined18:34
← SuperLag left18:35
→ SuperLag joined18:35
← stats4647 left18:35
← jetchisel left18:35
← eqw left18:36
← jmcantrell left18:36
→ eqw joined18:36
→ jmcantrell joined18:38
→ sickdyd joined18:38
← fossdd left18:42
← sickdyd left18:43
→ fossdd joined18:43
← justache left18:43
→ sudoforge joined18:44
→ justache joined18:44
← fossdd left18:47
← Gustavo6046 left18:48
→ Gustavo6046 joined18:49
→ fossdd joined18:49
← saroy left18:49
→ sickdyd joined18:54
← jimklimov1 left18:55
← epolanski left18:55
← fossdd left18:56
→ fossdd joined18:57
→ gast0n joined18:59
← sickdyd left19:00
→ epolanski joined19:00
← mhi left19:00
← pulse left19:01
← fossdd left19:01
→ fossdd joined19:02
← AnAverageHuman left19:03
→ sharperguy_ joined19:04
← sharperguy left19:07
← fef left19:07
→ janemba joined19:09
janemba hi19:10
→ goldfish joined19:10
janemba I copied a git folder in my git repo but I forgot to delete the '*.git' related stuff before commit/add. Now, when I "git add -A" the files into the copied folders are not added. How can I do it ?19:12
→ stats4647 joined19:12
← Maxattax left19:15
← tuskkk____ left19:16
imMute delete the extra .git folder and try again?19:16
I guess you committed the other repo as a submodule, you'll probably have to undo that.19:16
← fossdd left19:16
ikke git rm --cached <path>19:17
→ fossdd joined19:18
janemba thx !!!19:18
rm --cached works19:18
← stats4647 left19:19
← roadie left19:19
→ AnAverageHuman joined19:19
← humanface left19:21
→ pulse joined19:21
sangy ikke: thanks! sorry it took me this long to get back to you :)19:25
← furrymcgee left19:26
→ lastgitget joined19:27
→ fling joined19:28
lastgitget Hi all - I've been asked to do some research on git commits in the last few months. I was able to get the number of commits by contributer using "git shortlog -s -n --all -e --after=04/01/2021 --merges --branches=develop" -- but I was wondering if anyone can help me write a command which nets me the last commit date per developer.19:28
← reprazent left19:28
→ jimklimov joined19:30
lastgitget So far I can only think to change the date and see which folks fall in a closer time threshold...but that's pretty cumbersome19:30
→ reprazent joined19:31
→ lightstalker joined19:32
→ __jmcantrell__ joined19:34
sangy lastgitget: you may want to use something like libgit2 for this. You can get away with some very minimal repository-walk with something like a dict with developer as key and latest commit as value19:35
probably ~10 lines total really19:35
← lpapp left19:36
← SuperLag left19:36
osse piping to awk should make this easier19:36
lastgitget thanks sangy will check it out!19:36
→ SuperLag joined19:36
sangy could also do what osse said. I'm just more comfortable with libgit2 as it's easier to maintain things around :)19:37
lastgitget osse -- not sure how to use awk in this case19:37
sangy lastgitget: np! feel free to send scripts over here if you need a second pair of eyes19:37
→ Crassus joined19:37
← jmcantrell left19:38
sangy and for osse's suggestion I would assume you could use git log with a custom format (e.g., committer email\t commit date) or so, then take it from there. My awk fu is very lacking so I can't do much more guidance :)19:40
← Null_A left19:40
← natrys left19:41
→ _banana_ joined19:41
← janemba left19:43
← banana_ left19:44
osse git log --since=whatever --date-order --pretty='%an %ad' | awk 'authors[$1] == 0 { authors[$1]++; dates[$1] = $2 } END { for (i in authors) { print author[i], dates[i] } }'19:44
something like that perhaps19:44
→ Null_A joined19:45
osse git log --since=whatever --date-order --pretty='%an%09%ad' | awk -F '\t' 'authors[$1] == 0 { authors[$1]++; dates[$1] = $2 } END { for (i in authors) { print author[i], dates[i] } }'19:45
→ roadie joined19:45
← Crassus left19:46
← fossdd left19:48
← reprazent left19:48
osse git log --since=2020-01-01 --date-order --pretty='%an%x09%ad' | awk -F '\t' 'authors[$1] == 0 { authors[$1]++; dates[$1] = $2 } END { for (i in authors) { print i, dates[i] } }'19:48
there19:48
→ fossdd joined19:48
← Guest9 left19:49
→ reprazent joined19:51
← tolot_ left19:53
→ SuperL4g joined19:55
← atharvaraykar left20:01
→ jmcantrell joined20:01
→ dibber joined20:03
osse lastgitget: http://sprunge.us/RnXmMo20:03
nedbat I have a patch file that won't apply because it has \r\n line endings, and I am on a Mac. If I edit the file to change the line endings, it applies cleanly. Is there some way to tell "git apply" to not care about this?20:04
← __jmcantrell__ left20:04
imMute nedbat: the --whitespace option seems promising.20:04
nedbat imMute: ah! thanks20:05
→ jlc joined20:08
← DoofusCanadensis left20:08
nedbat imMute: no, that doesn't make the patch apply, though --ignore-whitespace does, but it puts \r\n into my file. I want the patch's line endings to be ignored20:09
imMute could you run the patch file through dos2unix (or any number of other ways to achieve the same) first?20:10
nedbat imMute: that seems to be the only option here. the real fix is to get my team to stop making patch files with \r\n20:11
→ rahl- joined20:11
← fossdd left20:12
imMute also a good idea20:13
→ fossdd joined20:13
→ Guest59 joined20:14
← roadie left20:14
← rahl left20:14
→ Samian joined20:16
osse i thought they were supposed to be cuz HTTP, but I see git format-patch doesn't do that by default20:18
maybe i'm just stupid for thinking http and emails are the same20:18
← digdilem left20:19
imMute both of them spec \r\n for protocol line endings (like headers) but the payloads are whatever the payload format wants (in this case it should be \n)20:19
nedbat osse: in this case, it's a file attachment delivered in email20:20
osse ah20:20
imMute: doesn't that mean git-format-patch should generate files with \r\n ?20:20
nedbat osse: but it does seem like git should have an option to ignore the line endings in the patch20:20
imMute osse: for the headers part, yeah. not for the payloads20:20
← fossdd left20:20
→ srinidhi joined20:21
← Samian left20:22
→ fossdd joined20:22
nedbat is there a way to use "git diff -p" on windows and get \n instead of \r\n ?20:23
← Guest59 left20:25
← hbautista left20:27
anddam howdy, can you recommend a compact automation server? I'd like to setup some CI, possibly CD and I'd like to start with something "minimal"20:28
→ humanface joined20:28
→ stats4647 joined20:28
← sudoforge left20:31
imMute gitlab seems like a good choice.20:31
← stats4647 left20:33
← fossdd left20:34
→ fossdd joined20:35
← ThorMojito left20:37
anddam imMute: looked like a big beast20:39
imMute well do you want "minimal" or do you want a functional CI/CD ?20:39
→ Samian joined20:40
→ hubble joined20:41
→ sickdyd joined20:42
nedbat anddam: what did you mean by minimal?20:43
imMute nedbat: "doesn't have anything I don't think I need"20:44
← Null_A left20:44
← fossdd left20:44
→ Null_A joined20:45
→ fossdd joined20:45
anddam or "simple enough that even I can understand the overview"20:46
I am looking at buildbot20:46
← sickdyd left20:46
imMute buildbot was okay. I much prefer the configuration style of Azure Dev Ops or GitLab though.20:49
and I like it when issue tracking, source code tracking, and build infra is all contained in the same system. makes it easier to connect between those systems20:49
kevr → kevr[m]20:49
kevr[m] → kevr20:50
anddam nedbat, imMute: on a more serious level, I cannot exactly define my usage of "minimal", but given that buildbot wheel is ~2 MB while gitlab's docker image is ~1 GB the former is more fit to my intended meaning20:50
imMute: I see the point there20:51
imMute comparing size of python wheels to docker images is non sensical20:51
how big is the buildbot docker image?20:51
anddam let's see if I find one20:51
ah right, a master comes at ~280 MB and a worker image at ~170 MB20:52
x/80/ c/60/20:53
imMute okay that's a bit better. the gitlab image seems a little high, but it might be built on a general purpose base (like ubuntu) instead of a barely-anything base.20:53
anddam so maybe half the (docker) space taken, without the additional feature20:53
imMute but if it works, it works and you can get a gitlab instance up and running quickly. and if it's too big, you can install gitlab natively and manage the space yourself.20:54
that's the tradeoff with Docker.20:54
← Null_A left20:54
← fnurkla left20:55
→ hbautista joined20:57
← fossdd left20:58
anddam thanks for the hint20:58
→ fossdd joined20:58
nedbat anddam: are you running low on disk space?20:59
anddam nedbat: no, it was just an unnecessary reaction to disk usage21:00
nedbat anddam: i understand. 1Gb seems like a lot21:00
anddam yep, I only have 640 kB of RAM21:00
imMute O.o and it's capable of even starting Docker??21:01
anddam I know that "minimal" would strictly call for small feature set, OTOH I see the convenience in having the issue tracker and code tracking integrated21:01
← canton7 left21:02
→ canton7 joined21:04
anddam imMute: that was a joke from the (in)famous quote21:05
imMute ah. I was very young at the time, so it's not as ingrained in my head.21:05
→ Null_A joined21:08
← humanface left21:08
← mat001 left21:09
hubble ear21:09
birkoff i have accidentally amend-committed unnecessary hunks. How can I either selectively remove them or get back to the state before the last amend ?21:12
osse birkoff: git checkout -p HEAD~121:12
followed by git commit --amend21:12
imMute osse: that works for an amended commit?21:13
osse then you can (if you wish) retrieve them again with git checkout -p HEAD@{1}21:13
← madewokherd left21:14
osse imMute:I don't see why not21:15
birkoff that shows me other changes in the tree that I have not committed21:15
imMute osse: I read it as he wants to go back to the commit as it was just before it was amended. not remove the latest commit alltogether.21:15
osse ooooh21:16
birkoff: git checkout -p HEAD@{1}21:16
← orbyt left21:21
anddam wouldn't HEAD^ work as well there?21:21
oh no, HEAD^ would point to the parent, where HEAD@{1} to "what HEAD was before it was moved last time" right?21:22
btw is the latter syntax properly called "a reflog"?21:22
ikke yit refers to the reflog21:22
it's itself just a way to specify revisions21:22
man gitrevisions21:23
gitinfo the gitrevisions manpage is available at https://gitirc.eu/gitrevisions.html21:23
anddam I see, thx21:23
birkoff can I see removed commits ids / description before a git reset --hard HEAD^221:25
ikke git log -g21:25
→ mat001 joined21:25
← goldfish left21:25
osse *before* ? that's just git log HEAD^2..HEAD21:26
← gh34 left21:29
→ Raguile joined21:30
→ orbyt joined21:31
← bongobrown left21:32
→ zeenk joined21:38
→ disi joined21:40
disi i have 2 local clones (say, dirA/ and dirB/). I'm 99% sure they are the same. I want to deduplicate these into a single repo without losing anything (commits, tags, branches, etc) if there are differences. How should I do this?21:41
birkoff is there a way to restore changes that were dropped in a reset --hard ?21:41
← palasso left21:43
← hubble left21:45
← lastgitget left21:48
← jwillikers left21:49
osse yes21:49
use the reflog21:49
← vysn left21:51
← Samian left21:51
birkoff i mean uncommitted changes21:52
→ madewokherd joined21:53
→ jazzy joined21:53
imMute those are gone for good.21:54
→ vysn joined21:54
Walex disi: you can make one repository a remote for the other and then pull everthing.22:01
imMute s/pull/fetch/22:02
Walex yes sorry...22:02
disi: --tags --all (I may be forgetting something).22:02
disi: you may have to copy manually settings in .git/config if they have diverged enough.22:04
disi: maybe the reflog too, if you are interested in that.22:04
disi Walex: ok, i'll check that... probably not tho because i havent done much dev in these at all22:08
→ roadie joined22:10
← roadie left22:15
← epolanski left22:15
→ odoood joined22:24
← SuperL4g left22:27
← Null_A left22:29
→ Maxattax joined22:35
disi I have an automated `git fetch` in my crontab... For one project, though, that asks for a user/password. I don't want it to ask, I just want it to skip that remote. Is this possible (basically non-interactive fetch)?22:36
`yes | git fetch` does not seem to work22:39
→ stats4647 joined22:42
osse disi: the config supports the concept of remote groups, so you can make a group containing all the ones you want to fetch22:43
→ sickdyd joined22:45
osse maybe this is better: git config remote.badUrl.skipDefaultUpdate true in that repo22:45
← stats4647 left22:47
disi hmmm not sure that works22:48
i dont understand why `yes | get fetch` or `git fetch </dev/null` don't work22:48
osse git probably reads directly from the terminal instead of stdin22:49
← sickdyd left22:50
disi i wonder if there is a terminal when crontab runs it... if not, maybe this isn't a problem22:52
hmm `setsid git fetch` might work22:54
`git config remote.teh_remote.skipDefaultUpdate true` pretty much works (omits from `git fetch --all` but not `git fetch teh_remote`)22:55
→ Null_A joined22:58
← odoood left22:58
← ferdna left22:58
← vysn left22:59
osse man gitcredentials might also be interesting23:00
gitinfo the gitcredentials manpage is available at https://gitirc.eu/gitcredentials.html23:00
osse it's Git's version of the "remember me" checkbox on the web23:00
← Natrick left23:02
← SuperLag left23:04
→ SuperLag joined23:07
← disi left23:15
← hbautista left23:16
→ hbautista joined23:17
→ jwillikers joined23:18
← hbautista left23:18
→ hbautista joined23:19
← hbautista left23:21
← batrick left23:21
→ hbautista joined23:22
→ nate3 joined23:24
→ batrick joined23:25
← hbautista left23:27
← nate3 left23:30
← rewrit3 left23:38
← zeenk left23:44

Logs Search ←Prev date Next date→ Channels Documentation