IRCloggy #git 2023-04-05

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.

2023-04-05

ThorMojito joined00:01
hbautista joined00:06
tjaden joined00:08
another| man git-maintenance00:10
gitinfo the git-maintenance manpage is available at https://gitirc.eu/git-maintenance.html00:10
clime left00:11
jaykelly450 left00:13
gildasio joined00:22
theesm left00:26
cdown left00:26
ThorMojito left00:29
theesm joined00:29
kostkon_ joined00:31
ThorMojito joined00:32
R2robot left00:33
kostkon left00:36
shokohsc5 joined00:41
shokohsc left00:42
shokohsc5shokohsc00:42
ThorMojito left00:43
jbg left00:43
R2robot joined00:45
ThorMojito joined00:46
epicout_ left00:52
Ingvix left01:06
hbautista left01:12
jbg joined01:13
xx left01:23
ash_worksi joined01:32
ash_worksi I have a git in my .gitignore file: `src/DataFixtures/` it's the last line in .gitignore. When I run `git ls-files | grep $(tail -1 .gitignore)` I see my fixtures... why?01:33
Guest54 left01:43
ferdna left01:56
RoyalYork If I did a 'git stash' on a certain workstation, I am unable to retreive it on another workstation, correct?02:00
gvg left02:00
another| right. stash is just local02:00
RoyalYork Ok, thanks. I'll have to wait to tomorrow to get to it :)02:01
BUSY joined02:02
jacobk joined02:05
finn_elija joined02:06
FinnElija left02:06
finn_elijaFinnElija02:06
gvg joined02:06
krushia left02:11
nate1 joined02:15
zyxkad joined02:17
rurtty left02:23
zyxkad Hello, I want to ask if there are any official executable for git that can download through some URL? Github only have source file.02:23
I want use URL to download git since I'm making a installer to install a builder, and the builder need Git to download the source to build.02:23
I don't want use things such as apt, brew or apk. For it's all different on each OS. And some OS probably even don't have them.02:23
Any one can help?02:23
odoood zyxkad: use the links on https://git-scm.com/downloads02:34
cweiss0765321241 left02:36
zyxkad Thanks for reply, but this page only let me download use **package managers**. I want download it **directly from URL**02:36
cweiss0765321241 joined02:36
odoood zyxkad: so I assume you're just talking about installing on GNU/Linux distros and you're looking for a 1-size-fits-all binary, but it doesn't work that way; there's a reason why there are package managers for the different distros, and it's b/c there generally isn't just a binary you can download and use with git on any02:39
zyxkad Ah, not really good, thanks anyway.02:41
money left02:42
odoood zyxkad: if you ever consider building from source you could try to build your own statically linked git binary but that's gonna be a decent amount of effort unless you can find someone who's done it already02:45
hbautista joined02:49
Suchiman left02:54
kostkon_ left02:55
jacobk left02:55
gsi joined02:56
kostkon joined02:56
thiago left02:57
YuGiOhJCJ joined02:57
Noisytoot left02:58
gsi_ left02:59
Noisytoot joined03:00
stenno left03:03
thiago joined03:05
navi left03:06
bywaterloo left03:13
ThorMojito left03:13
magic_ninja1 left03:15
magic_ninja joined03:15
kostkon_ joined03:15
thiago left03:18
kostkon left03:20
nate1 left03:20
magic_ninja left03:21
cdown joined03:21
magic_ninja joined03:23
skapata left03:25
johnjaye joined03:27
kostkon_ left03:27
johnjaye sorry if this is a basic question. but if you have your own files you want to keep separate from a git repo how do you do that03:27
chexum left03:27
johnjaye do you have to have folder X with your stuff and then have the git repo inside that, or can you use like .gitignore to have your own folder inside the repo folder proper?03:28
chexum joined03:28
kostkon joined03:28
moldorcoder7 left03:32
skered left03:41
skered joined03:42
kostkon left03:43
kostkon joined03:43
odoood left03:49
hiroot joined03:50
GNUmoon left03:50
hiroot left03:51
GNUmoon joined03:51
kostkon_ joined03:53
kostkon left03:54
kostkon_ left04:05
kostkon joined04:07
kostkon left04:11
kostkon joined04:11
kostkon_ joined04:15
kostkon left04:20
chexum left04:20
chexum joined04:21
kostkon__ joined04:21
kostkon_ left04:22
krushia joined04:25
zyxkad left04:29
kostkon_ joined04:29
kostkon__ left04:29
kostkon_ left04:31
kostkon_ joined04:31
kostkon_ left04:33
kostkon_ joined04:34
bywaterloo joined04:34
jmike__ joined04:37
jmike_ joined04:38
ikke johnjaye: git by default will ignore other repositories inside a repository04:40
jmike__ left04:42
johnjaye oh interesting04:45
kostkon_ left04:45
johnjaye that would explain why when i cloned a repo inside this repo it ignored it when doing cleans and pulls04:45
kostkon_ joined04:45
johnjaye but i meant more things like notes or extra documents you have that shouldn't go into the main repo. isn't that what .gitignore is for, or am i misunderstanding?04:46
ikke yes, that's correct04:46
or .git/info/exclude if these only make sense for you04:46
johnjaye what's the distinction04:48
unless it's literally what you said04:48
elastic_dog left04:48
elastic_1 joined04:48
elastic_1elastic_dog04:48
ikke .gitignore is (supposed to be) tracked in the repo04:48
.git/info/exclude is local to that clone only04:49
johnjaye er. so if i put dogphoto.png in my .gitignore that will get pushed to the repo04:49
in the case of, i want a photo of my dog in the repo folder to cheer me up04:49
ok04:49
ikke the .gitignore rule would be pushed04:49
johnjaye hrm. ok. i thought those .git files were not part of the repo. but that makes sense04:50
it's a metadata file for the repo so it would be pushed too04:50
ikke also something good to know is that .gitignore rule only applies to untracked files (something some people are confused by)04:50
It's in the working tree04:50
johnjaye yeah i'm not familiar with that. tracking refers to just the source files i would think04:51
like main.cpp and main.h04:51
ikke git does not make any distinction04:51
any file in the working tree can be tracked04:51
jmike__ joined04:52
Ingvix joined04:53
johnjaye i'm looking at the git book a bit04:53
i'm confused. if something is not tracked, git doesn't care about it correct04:53
so why would it need any kind of status like ignore04:54
so if i do echo "foo" > README in the folder, git status would say you have untracked file README04:54
ikke to prevent it from accidentally being tracked04:55
and also make sure git status is clean so that it's clear that something still needs to be committed04:55
kostkon_ left04:55
johnjaye meaning if you did git add README it would give an error?04:56
jmike_ left04:56
ikke yes04:56
johnjaye ah ok this git book mentioned the info/exclude thing as well. ok04:56
gast0n left04:59
eggbean joined05:00
nattiestnate joined05:08
wagle left05:09
wagle joined05:10
hnOsmium0001 joined05:13
nate1 joined05:15
nate1 left05:20
cbreak left05:21
bgs joined05:23
cbreak joined05:24
fling_ joined05:29
fling left05:30
fling_fling05:36
Noisytoot left05:36
ThorMojito joined05:37
ThorMojito left05:38
Noisytoot joined05:39
eggbean left05:43
cdown left05:44
eggbean joined05:44
cdown joined05:45
kostkon joined05:47
cdown left05:50
igemnace joined05:50
carl-- joined05:55
otisolsen70 joined06:00
bywaterloo left06:00
Holz left06:06
Willtech joined06:07
hamburgler left06:10
kostkon_ joined06:13
kostkon left06:13
sa0 joined06:17
kostkon_ left06:18
kostkon joined06:18
jmike_ joined06:20
kostkon left06:21
kostkon_ joined06:21
jmike__ left06:24
distant joined06:25
kostkon__ joined06:25
kostkon_ left06:25
hbautista left06:26
distant left06:26
distant joined06:27
eponym joined06:28
epony left06:28
kostkon joined06:29
kostkon__ left06:30
redbool_ joined06:30
mohit left06:31
han-solo joined06:31
mohit joined06:31
eponym left06:31
redbool_ left06:33
hbautista joined06:33
kostkon_ joined06:33
redbool left06:33
redbool_ joined06:33
kostkon left06:33
k-man left06:33
kostkon_ left06:34
coot joined06:35
kostkon_ joined06:35
epony joined06:36
Betal left06:38
cdown joined06:39
kostkon_ left06:43
kostkon joined06:44
xx joined06:46
roadie joined06:47
kostkon left06:49
kostkon joined06:49
lxi joined06:50
rfuentess joined06:58
kostkon left06:58
distant left06:59
distant joined07:00
hamburgler joined07:02
mven left07:05
distant6 joined07:05
distant left07:05
distant6distant07:05
feriman joined07:09
codaraxis left07:12
k-man joined07:16
carl-- left07:18
thebombzen joined07:20
gurkenglas joined07:21
hbautista left07:22
mven joined07:23
stenno joined07:26
sebatron joined07:32
distant left07:34
FH_thecat joined07:34
sebatron left07:39
zeenk joined07:43
distant joined07:45
distant left07:48
distant joined07:49
Holz joined07:49
dionysus69 joined07:50
cloaker joined07:53
iomari891 joined07:54
epony left07:54
mobidrop joined07:58
epony joined08:00
duxsco joined08:04
hamburgler left08:04
tchan left08:09
tchan joined08:09
moldorcoder7 joined08:10
clime joined08:12
cdown left08:19
epicout joined08:24
epicout left08:24
epicout joined08:24
EvgenyK joined08:26
theoceaniscool joined08:30
epicout_ joined08:32
epicout left08:36
distant left08:38
EvgenyK_ joined08:41
EvgenyK left08:43
distant joined08:45
Suchiman joined08:46
robo left08:50
robo joined08:50
agd left08:52
agd joined08:53
EvgenyK joined08:56
EvgenyK_ left08:59
aparcar[m] left09:00
lgc joined09:01
FH_thecat left09:02
zeenk left09:02
zeenk joined09:03
EdwardIIIedwardiii09:05
Fischmiep4 joined09:06
Fischmiep left09:06
Fischmiep4Fischmiep09:06
kostkon joined09:09
kostkon left09:11
kostkon joined09:11
hnOsmium0001 left09:12
lgc left09:12
eggbean left09:12
[twisti] whats a good workflow if, while working on a feature branch, i spot a tiny bug, like a wrong if-condition or something similarly isolated, that i want to fix, but in its own bugfix branch ? i usually have a dirty work tree which means i cant just switch to main trivially. anything better than stash, checkout main, checkout -b fix/whatever, fix, commit, merge, checkout feature, rebase, stash pop ?09:13
epicout_ left09:15
selckin don't think so, i usually commit it to current branch, then in my cleanup phase before pushing, cherry-pick it to new branch and remove etc09:15
filePeter joined09:15
kostkon left09:16
kostkon joined09:16
edwardiiiEdwardIII09:16
nate1 joined09:16
selckin you can checkout -b fix main, so remove 1 step09:17
epicout joined09:17
epicout left09:17
epicout joined09:17
filePeter left09:17
justmatt left09:18
DrowningElysium joined09:19
justmatt joined09:19
nate1 left09:21
yuesbeez left09:23
kostkon left09:24
filePeter joined09:25
zen_coder joined09:27
gas51627 joined09:27
stenno i find myself often using the pattern: derive feature branch from develop -> push to remote -> do PR to develop and delete branch remotely -> locally check out develop and pull -> delete feature branch locally09:28
sometimes i keep forgetting the last step really09:29
how do you do it? are you doing the last two steps manually too or is there a better way09:29
i wonder if i should program an alias which gives me the current branch, then checks out development and deletes that branch09:30
i hoped there was a way with `git switch`, to delete the current branch, but i haven't found it yet, always gotta do `git branch -D` after checking out development09:30
sebatron joined09:31
[twisti] selckin: thanks, that sounds at least a little bit less terrible, and avoids the worktree stash, which is a pretty destructive thing if you use something like webpack-watch or similar change detecting workflows09:32
nedbat stenno: i have a git alias that means, "merge and delete the branch I just left". So I work on my branch. Once it's good, I "git switch main; git pull" (which is itself an alias), then "git brmerge-"09:34
[twisti] of course im bound to forget doing anything in the final PR cleanup, but that just kinda sorts the commit incorrectly, but doesnt mess up anything unintended09:34
stenno nedbat: thanks09:35
delay joined09:35
EvgenyK left09:40
EvgenyK joined09:41
epicout left09:43
[twisti] damn, what a mess. i accidentally committed a few things to main, didnt notice, and went on to work in a branch. the commits are also in the branch, with identical hashes. that means i can `reset HEAD~3` in main without losing the commits, right ? same hash means identical content in the branch ?09:50
bookworm sure09:51
EvgenyK left09:52
distant left09:52
EvgenyK joined09:52
trillion_exabyte left09:58
Noisytoot left09:58
nyah joined09:59
trillion_exabyte joined09:59
lightstalker left10:00
lightstalker joined10:00
Noisytoot joined10:01
skapata joined10:03
distant joined10:05
EvgenyK left10:11
cousteau joined10:12
lxi left10:13
EvgenyK joined10:13
cousteau OK, I think I found the component in git that is causing these awful graphs sometimes10:14
I thought this was part of gitk, but now I think gitk just uses git log --graph as a backend10:14
Basically: I have two branches. Branch 2 has an additional feature, and I maintain it by merging branch 1 periodically into it. So in gitk --all this looks super pretty, with like "two parallel lanes" with periodic merges between the two10:17
duxsco left10:18
cousteau BUT, if I create a new branch (or a stash) on main before merging main into feature, the whole beautiful graph gets destroyed, and uses a lot of parallel lanes instead of just two10:19
So, um, if someone who likes graphs a lot could improve the algorithm so that that doesn't happen, that'd be great...10:20
ikke cousteau: not sure if it helps, but try --topo-order10:20
clime left10:22
coot left10:22
cousteau Nope, it didn't :(10:24
Maybe one day I'll submit an example to the mailing list to clarify what my problem is10:24
vishal left10:26
cousteau Are there any options to tweak the graph generation, other than --date/author/topo-order? (this particular example looks much better in strict date order, but that's generally not a good idea I think)10:28
vishal joined10:29
oxymoron93 joined10:29
EvgenyK_ joined10:30
rosco joined10:30
Masklin left10:31
EvgenyK left10:31
cousteau Overall, I think what I want is "display merge commits as close to the bottom as possible" - I think that'd solve this issue10:31
nwoob joined10:34
EvgenyK_ left10:35
nwoob should we use feature-toggle for every feature? for ex: 15-20 feature toggles?10:35
bookworm context is lacking... you sure you wanted to ask this here?10:38
Masklin__Gurder joined10:40
duxsco joined10:41
zen_coder left10:49
inovas left10:51
f_ joined10:51
joj left10:51
joj joined10:51
feriman left10:59
duxsco left11:03
YuGiOhJCJ left11:04
johnnyrichard-nn left11:07
duxsco joined11:07
duxsco left11:08
Masklin__GurderMasklin11:14
skapata left11:18
jbg left11:20
johnnyrichard-nn joined11:20
EvgenyK_ joined11:23
johnnyrichard-nn left11:24
jbg joined11:25
vdamewood joined11:26
EvgenyK_ left11:31
navi joined11:31
Xeroine left11:33
kostkon joined11:34
cousteau left11:41
EvgenyK_ joined11:44
_sa0sin_ joined11:49
sa0 left11:52
jbg left11:54
johnnyrichard-nn joined11:55
jbg joined11:55
sebatron left11:56
EvgenyK_ left11:59
johnnyrichard-nn left12:00
thumbs left12:00
EvgenyK_ joined12:05
theesm left12:07
johnnyrichard-nn joined12:11
frank- joined12:15
johnnyrichard-nn left12:16
roadie left12:16
Cromulent joined12:18
frank-thumbs12:22
roadie joined12:23
johnnyrichard-nn joined12:24
EvgenyK_ left12:26
EvgenyK_ joined12:27
loulou left12:29
theesm joined12:29
distant left12:30
distant joined12:30
ThorMojito joined12:31
llh joined12:31
shokohsc2 joined12:36
zen_coder joined12:37
shokohsc left12:37
shokohsc2shokohsc12:37
EvgenyK_ left12:41
vdamewood left12:42
zen_coder left12:43
gast0n joined12:45
aspirin joined12:48
makara1 left12:51
makara1 joined12:52
makara left12:52
makara_ joined12:53
loulou joined12:55
loulou left12:55
loulou joined12:55
Xeroine joined13:01
nattiestnate left13:03
nattiestnate joined13:03
roadie left13:04
Rashad joined13:10
skapata joined13:11
zmt01 left13:13
nwoob left13:15
nate1 joined13:18
coot joined13:21
nate1 left13:23
alfredb joined13:23
nattiestnate left13:29
Noisytoot left13:32
Noisytoot joined13:34
f_ left13:35
f_ joined13:36
Xenguy left13:39
Xenguy joined13:39
Xenguy left13:39
delay left13:48
duxsco joined13:48
duxsco left13:48
delay joined13:56
Murr- joined13:59
Murr left14:01
Murr-Murr14:01
Noisytoot left14:10
Noisytoot joined14:12
roadie joined14:15
jbg left14:18
jbg joined14:19
jbg left14:20
dsrt^ left14:20
dsrt^ joined14:21
jaykelly450 joined14:23
gh34 joined14:29
Xenguy joined14:31
dviola joined14:33
huntm joined14:35
thiago joined14:35
CrtxReavr left14:37
Noisytoot left14:37
elastic_1 joined14:37
elastic_dogGuest417614:37
Guest4176 left14:37
elastic_1elastic_dog14:37
Noisytoot joined14:38
bywaterloo joined14:39
rama left14:44
mobidrop left14:44
cloaker left14:47
Rashad left14:53
rurtty joined14:56
gurkenglas left14:58
belsirk joined14:59
liefer396 joined15:00
coot left15:01
rfuentess left15:02
cloaker joined15:02
coot joined15:04
sudoforge joined15:05
farzat left15:07
oxymoron93 left15:10
EvgenyK_ joined15:10
zmt00 joined15:12
so-offishul joined15:14
so-offishul left15:15
EvgenyK_ left15:15
so-offish left15:17
so-offish joined15:18
odoood joined15:18
delay left15:19
dionysus69 left15:21
rfuentess__ joined15:22
sudoforge left15:22
sudoforge joined15:23
rurtty left15:24
Xardas joined15:24
Xardas why do we need to escape the * character here : $ git rm log/\*.log15:24
heistema joined15:24
gurkenglas joined15:24
cyber_heretic joined15:24
belsirk left15:25
hamburgler joined15:25
delay joined15:25
ikke Xardas: to prevent your shell from expanding it and let git do the expanding15:26
heistema I miss a feature in Git... or at least I found nothing in the documentation and / or the internet. It is about handling binary files in Git. Is this the place to find out whether such an feature exists? Or is it better to ask in git-devel? Or even somewhere else?15:27
Filing a feature request might be a bit prematurely - the feature might exist15:28
JAA Git supports binary files, just not incredibly well because the machinery is primarily for text-ish files.15:29
DrowningElysium left15:29
rama joined15:29
bn_work joined15:30
rama left15:30
rama joined15:30
Xardas ikke I've tried also not escaping it and I haven't seen any difference15:33
but what you said makes sense15:33
zumba_addict joined15:33
Xardas letting git do the work15:33
ikke It can make a difference under some circumstances15:34
for example when the files only exist in a commit but not in the working tree for example15:34
rostero joined15:35
Xardas But can I delete files in a commit without doing a checkout ?15:36
ikke No15:36
I wasn't necessarily talking about git rm15:36
heistema I might give a comprehension of my problem: Let's say you are forced to work with a software producing at least some binary files. And let's say the software is very touchy, by this I mean that every click from the user on that specific file (using the respective software) will result in a change of that specific file... No need to say the Git15:36
server will clutter up very fast, as each change gets stored on the server. Yes, there are solutions like Git LFS, but this just pushes the files onto a different repo and clutter up that server (as I've understood).15:36
So I want Git to "lock" these files and neglect changes by default... Best would be always to let me know and ask. A workaround would be to add the files manually (entering each file on the keyboard!) and copy the file back from the repo if a "wrong" change had been commited...15:36
Xardas ikke I see your point !15:36
Thank you :)15:36
JAA Xardas: `git init; mkdir log; touch log/a log/b; git add log/*; git commit -m initial; git rm log/b; git commit -m remove`15:37
After this, `git log log/*` will only report the initial commit because it expands to `git log log/a`.15:37
But `git log log/\*` will report both commits.15:37
ikke heistema: You are aways in control what you commit? What results in every tiny change being comitted?15:37
riposte left15:38
Xardas JAA : thanks !! I fully get it now :)15:39
riposte joined15:39
Xardas takes notes ../15:40
YoungFrog left15:41
pieguy128 left15:41
YoungFrog joined15:41
JAA heistema: I feel like this would best be solved outside of Git. For example, if there have only been changes to those binary files, don't commit until at least X time has passed since the last commit. Could be other triggers than just time, of course.15:41
heistema ikke Git does leave my binary files untouched and detects a change. It should download the last commited revision instead15:41
pieguy128 joined15:42
heistema ikke Unless I specifically tell Git that I changed the file...15:42
JAA That would also be an interesting but different approach..15:44
JAA Do you think that such a locking mechanism should be realized outside of git? E.g. by an extension???15:44
JAA I'm not sure I fully understand the problem here. It sounds like you have a system around that software which automatically commits changes to a Git repo?15:45
heistema JAA I do have a software making frequent, and useless changes to binary files... But I want the files to be kept in sync with the last commit unless I specifically tell Git differently15:47
JAA So you want to discard the software's writes entirely?15:47
ikke there is no flag in git to tell it to discard local changes and automatically overwrite it15:47
heistema JAA Yes, so Git should download the last revision for each of those binary files when I do a commit (if files had not been marked for add)15:48
ikke That is exactly what I mean ... Sorry for my bumpy english sometimes15:48
JAA Yeah, you would need to `git restore FILE...` explicitly for each of those files, I think. (Or `git checkout -- FILE...` on older Git versions.)15:49
You could write a little shell script to help with that, of course, so you would use `./commit 'message'` and it would do a `git commit -m message` followed by that reset for the binary files.15:50
heistema JAA That's interesting... So a flag in git might require only some lines of code... Do you think this might something to contribute to git?15:51
JAA I mean ... I could contribute.15:51
ikke heistema: I'm not sure it will be accepted15:51
JAA I'm not sure this is something that needs to be in Git, to be honest. It's a very specific requirement, and it can already be achieved with two Git commands.15:52
You could also use a post-commit hook, I think.15:52
jaykelly450 left15:52
heistema JAA One argument for such a feature is that there are many default applications developers have to use which behave in such a way. E.g. Word, Excel, Unity, Unreal, Database stuff in general, etc. etc.15:53
JAA The number of people tracking such files in Git is small though.15:54
rfuentess__ left15:56
JAA I'm no Git maintainer, so I can't and won't tell you whether or not to suggest the feature. But I'm doubtful it's something that would be considered for acceptance.15:56
heistema JAA You might have a point there. I am googling it right now, but really might be a nice idea for me to open up an open source repo and write a small git extension which one might use / or not15:57
JAA It could be up to the maintainers do decide whether they want to include it or not15:57
selckin sounds like a very special case, and should just be a script you keep local15:58
Leonarbro left15:59
JAA If I understood you correctly, I think it can be as simple as a post-commit hook containing `git restore FILE...`. If you committed the files listed there, that'll have no effect, and if you didn't, the changes get overwritten.15:59
heistema JAA You are absolutely right. That's awesome... Don't know why I didn't came up with it. And it is a very simple solution16:07
riposte left16:08
igemnace left16:08
cyber_heretic left16:10
cdown joined16:11
dimi1947 joined16:11
heistema left16:13
pieguy128 left16:14
dimi1947 left16:15
pieguy128 joined16:15
bn_work ugh, is there a way to undo a branch deletion? seems `gh pr merge 5 -r -d` failed with `error: cannot pull with rebase: You have unstaged changes. please commit or stash them.` and then still proceeded to delete the branch anyway ... sigh 🤦16:15
ikke bn_work: deleting a branch should provide the hash it had16:16
bn_work do I just need to re-pull from origin?16:16
StefanH joined16:16
StefanHheistema16:16
bookworm !reflog16:16
gitinfo The git reflog (`git log -g`) temporarily (90 days by default) snapshots your branch states at each operation that changes the branch, making it easy to undo e.g. merges and rebases. The usual warnings about !rewriting/undoing history apply. See https://sukima.github.io/GitFixUm/ for full details.16:16
bn_work ikke: this was done via gh client16:16
roadie left16:17
ikke then the reflog like bookworm mentioned or recreate it from the remote tracking branch16:17
Xardas JAA you mentioned git log log/* but I think it should be git log -- log/* I just came across it the book i'm reading now.16:17
we need to use double slashes -- to sparate options from file paths16:17
dsrt^ left16:18
farzat joined16:18
delay left16:19
bn_work ikke: if I had used `gh` to delete the branch, does it automatically push out that deletion to the remote?16:23
huntm left16:23
ikke I would not know16:24
delay joined16:24
bn_work thus invalidating option 2?16:24
delay left16:24
ikke git branch -r would confirm16:24
bn_work if so, how do I use option1? not very familiar with how to use `git log -g`?16:24
ikke You'd want to find the last time you checked out that branch16:25
which gives you the hash of hte commit16:25
bn_work ikke: hmm, I still see a `origin/foo` listed there, so I guess it's still there?16:25
odoood left16:25
ikke bn_work: git show origin/foo16:25
bn_work (assuming foo = the branch that was deleted)16:25
codaraxis joined16:25
bn_work ikke: but that would be before I made the fix in that branch?16:26
ikke bn_work: if you did not push before it was deleted, then yes16:26
JeffH joined16:26
ThorMojito left16:27
hbautista joined16:27
JeffH left16:28
bn_work well, I committed the fix locally, and then used the gh client to create a PR, so I would assume that would push it out?16:29
zumba_addict left16:30
Noisytoot left16:31
ikke yes, creating a PR involves pushing the branch16:31
JeffH joined16:31
ThorMojito joined16:31
bn_work ikke: so what would you recommend I do?16:32
ThorMojito1 joined16:32
bn_work BTW, `git show origin/foo` shows the 1 commit fix in the deleted branch16:32
bookworm reflog, checkout a branch at the upstream version16:32
ikke then that's the commit you want, not?16:32
bn_work ikke: yes16:33
ikke git checkout -b foo origin/foo16:33
JeffH left16:34
delay joined16:35
ThorMojito left16:36
riposte joined16:37
Noisytoot joined16:38
lpapp joined16:40
lpapp hi, I have uploaded my ssh public key to github, but when I am trying to push code, it is asking for username, etc, why?16:40
should it not find my local private key and realise which user has that on github?16:41
ikke lpapp: because your remote is still https16:41
elevenkb joined16:41
ikke git remote -v16:41
lpapp ?16:41
ok, thanks16:41
cdown left16:42
bn_work ikke: thanks!16:43
lpapp left16:43
hnOsmium001 joined16:46
ThorMojito1 left16:46
delay left16:47
delay joined16:48
delay left16:50
Leonarbro joined16:50
humanface joined16:51
delay joined16:51
ThorMojito joined16:51
JeffH joined16:53
JeffH left16:54
lucasta joined16:57
elevenkb left16:57
ProperNoun left16:58
Holz left16:59
delay left17:00
dimi1947 joined17:01
Holz joined17:01
dimi1947 left17:06
f_ left17:08
ProperNoun joined17:09
heistema left17:09
sudoforge left17:16
sudoforge joined17:16
cdown joined17:19
Lunatrius` joined17:19
nate1 joined17:19
Lunatrius left17:20
Lunatrius`Lunatrius17:20
sudoforge left17:22
rosco left17:24
cloaker left17:24
sudoforge joined17:24
nate1 left17:24
jrm I have the alias `clog = log --pretty=format:'%C("#"858585)%h%Creset -%C(auto)%d%Creset %<|(98,trunc)%s %C("#"858585)%cd%Creset %C("#"CC5500)%an <%ae%m%Creset %C("#"858585)(%cl)%Creset'`. The output in nice, but doing `git clog | wc -l` reports one too few for the number of commit because there is no newline at the end. How can I put a newline at the end of the output to fix this?17:25
humanface left17:37
rosco joined17:37
humanface joined17:37
JAA Xardas: The double hyphen isn't required in that specific case, but in general, yes.17:37
han-solo left17:38
jrm The answer to my question: Use tformat rather than format. :)17:46
odoood joined17:49
gareppa joined17:49
gareppa left17:49
Xardas left17:51
rosco left17:54
ahmed joined17:59
coot left18:03
jaykelly450 joined18:04
iomari891 left18:10
causasui joined18:12
gh00p joined18:18
sudoforge left18:26
Murr left18:28
jfsimon1981_b left18:31
jfsimon1981_b joined18:31
kostkon left18:36
kostkon joined18:43
rostero left18:44
ahmed left18:47
rosco joined18:55
Yruama joined18:56
Jong joined18:59
Cromulent left19:04
Murr joined19:07
zen_coder joined19:12
humanface left19:19
akash joined19:24
BrianBlaze left19:28
rosco left19:29
wootehfoot joined19:36
MajorBiscuit joined19:39
ss4 joined19:41
gurkenglas left19:42
Xeroine left19:43
wootehfoot left19:43
gurkenglas joined19:44
coot joined19:46
skapata left19:54
lucasta left19:55
duxsco joined19:56
ThorMojito left19:58
rama left19:58
rama joined19:58
theobjectivedad left19:59
epony left20:00
theobjectivedad joined20:02
alfredb left20:03
epony joined20:03
xkr47 left20:09
iomari891 joined20:10
delay joined20:10
bkircher left20:11
arescorpio joined20:12
Coop left20:14
Echoz joined20:14
GNUmoon left20:16
pieguy128 left20:17
GNUmoon joined20:17
johnjaye left20:18
cdown left20:18
ferdna joined20:19
ThorMojito1 joined20:21
mexen joined20:22
jaykelly450 left20:25
Coop joined20:26
gh00p left20:27
ss4Supersaiyan_IV20:28
iomari891 left20:29
delay left20:31
Jong left20:35
gas51627 left20:35
filePeter left20:36
feriman joined20:39
mkosmo3 joined20:43
rama left20:43
mkosmo3mkosmo20:44
swistak left20:44
bgs left20:49
Supersaiyan_IV left20:59
ThorMojito1 left21:01
JeffH joined21:01
aspirin left21:01
ThorMojito joined21:01
ThorMojito left21:02
giu- joined21:03
bn_work git 2.24.3, if I re-create a branch that had the same as a prior one that was deleted and already merged, will git allow that? or will things get messed up?21:04
same *name*21:05
delay joined21:05
rewt yes, that's allowed -- git history stores no information about any branches at all21:06
JAA Branches are just pointers to commits. When you delete a branch, there's no trace of it left really (apart from the reflog). The merge commit just happens to contain its name in the commit message, but there's nothing beyond that.21:07
skered left21:07
bn_work rewt/JAA: so how does github see that?21:07
causasui left21:07
rewt see what?21:09
JAA That sounds like a question for ##github, not #git. It might mess with the display of PR pages, not sure. But assuming the branch was deleted on GitHub, not just locally on your repo, it should be possible.21:09
ThorMojito joined21:10
clime joined21:10
ThorMojito1 joined21:11
kandinski left21:12
bn_work rewt: like would it just redetect that the branch can be merged in the previously created PR?21:13
giu- left21:13
bn_work rewt: it was merged using the `gh` client21:13
ThorMojito left21:14
skered joined21:15
giu- joined21:15
JAA > If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch.21:16
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository21:16
Hmm, not quite what you're asking, actually.21:16
giu- left21:17
giu- joined21:17
cdown joined21:17
JAA Might be easiest to just test it in a little toy repo.21:17
duxsco left21:18
JAA In any case, Git has nothing to do with that; what GitHub does with the branch info is separate.21:18
bn_work the reason I'm even considering this: there was a 4-5 char quick fix that I should have included in the original PR and instead of creating (yet) another ticket AND branch AND PR AND review request, I'm trying to still stay (somewhat) in our ("overkill" IMO*) process. *I say "overkill" as it's just a 2-person team with me and a jr. admin who doesn't even code and is still learning to, w/ no one that even knows how to review the code,21:18
lol21:18
bookworm bn_work: it would do you good to drop to the git cli, until you get a grasp of the concept, prior to the magic GitHub wrapper you don't understand21:18
Geronimo left21:18
bn_work bookworm: huh? I've been trying to stay away from the github stuff21:19
bookworm: I normally stay in the CLI21:19
bookworm you literally told us you use the gh cli tool21:19
that ain't git21:19
bn_work bookworm: ohh, I thought you were referring to the GH website as a "wrapper", lol21:20
bookworm: only to manage these PR shenanigans21:21
nate1 joined21:21
bookworm you quite literally had trouble understanding the basics of branches earlier, when you deleted your branch with the gh tool21:22
bn_work so it sounds like git won't care, that's fine21:22
bookworm and, no offense intended but that's a foundation you lack21:22
so any wrapper will make that worse21:22
giu- left21:23
bn_work bookworm: not seeing your point here, git doesn't have a concept of PRs, so I *have* to deal with gh or github.com21:23
bookworm: I know internally git doesn't have a concept of branches but you also realize that git literally has a command called "git branch" right?21:25
bookworm git has a notion of a PR, just not what you are referring to21:25
git send-email will happily set up a PR email for you and send that to a list21:25
nate1 left21:26
bookworm my point is, rather than using gh directly, maybe start of by just using git, pushing to a remote like normal and using branches as intended. Do PRs the pointy clicky way on the web21:26
once you are familiar with plain git, then you can add tools that build on top of it, not before you understand the basics21:27
JAA man git-request-pull21:27
gitinfo the git-request-pull manpage is available at https://gitirc.eu/git-request-pull.html21:27
JAA Git literally has support for pull requests. :-)21:27
bookworm that's what I meant, right21:28
JAA (I've never used it though.)21:28
JeffH I watched a git internals YouTube video which was HUGE in helping me understand git21:28
JAA I read some excellent blog posts a long while ago. It had beautiful hand-drawn graphics to explain everything. Don't remember where that was though.21:30
And naturally, there's the Git ~Bible~ Book.21:30
lxi joined21:33
cchtdgooc^ joined21:33
bn_work JAA: thanks, also found this https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#working-with-branches which it refers to but it sounds like that is just describing is a situation where a 2nd (different) branch was made after the 1st one was made and deleted or merged. In my case, the 2nd branch (with the same name) would be made after the 1st21:33
branch was already made, merged, and deleted. I wonder if github will just show the original PR as available for merge then?21:33
johnjaye joined21:34
bn_work maybe I should just avoid any issues and not create a separate new branch (of the same name) and just directly commit to the parent branch21:34
JAA Yeah, same wording on that page. And the example is different since the two branches have different names.21:35
It's about what happens if the merge target branch gets deleted, not the merge source branch.21:35
delay left21:36
gh34 left21:36
giu- joined21:36
bn_work JAA: interesting, I wasn't aware `git-request-pull` was a thing, when was that added?21:36
rama joined21:37
JAA bn_work: Copyright header says 2005, so ... a while ago.21:38
feriman left21:40
akash left21:40
bn_work ok, so if there's a native way to deal with PRs via just git CLI, I'm all for it, I was not aware this was even possible. That's the only reason I resorted to using `gh` which is half-baked anyway and doesn't support showing all inline PR comments21:41
JAA These are not the PRs you know from GitHub. Like, not at all.21:42
bn_work then they are not the same, and it's just an unfortunate name overlap21:42
JAA They're just PRs in the more general sense: request an upstream repo owner to pull certain commits from your fork.21:42
It doesn't even actually request anything. It just produces a summary suitable for an email or similar.21:43
JeffH We’re moving our repository from CVS to git. With CVS we had a process we used (implemented via scripts) to audit our build to ensure all issues/changes targeted for the build were in the build and that issues/changes targeted for future builds aren’t in the current build. A colleague of mine insists that git doesn’t require this type of auditing. Is he right? Doesn’t seem right to me.21:43
bn_work JAA: so should I just avoid creating another "branch" of the same name and just commit directly to the parent to avoid any weird github branch/PR rendering issues?21:44
goldfish joined21:45
JAA bn_work: I would probably avoid reusing branch names, but I use descriptive branch names anyway, so it hasn't come up. Not sure about 'directly committing to the parent'. Is the original PR already merged?21:48
bn_work honestly for this 2-person "team" I'm on, which no one else pulls from or uses, I can't help but feel the GH PR process that is being imposed is just... dumb / overkill, and just adding pointless paperwork, lol21:48
JAA I mean, it's good for code review, and that's useful no matter how many people you are as long as n>1.21:49
bn_work (I mean I know when it would be of value, and have worked on larger teams where it makes sense, but here it seems pointless)21:49
JAA: yes, original PR is already merged21:50
JAA: but the code review was moot, so it still needs fixing21:50
and it's a quick fix21:50
JAA I don't use PRs for projects where I'm the sole maintainer. I do use PRs for anything with at least one other maintainer. Often there is no review anyway, but sometimes there is.21:50
bn_work I'm basically the maintainer of this repo21:50
JAA: exactly21:51
JAA Right, so if the original PR is already merged, pushing to that branch is also going to look somewhat messy (same branch getting merged twice).21:51
lxi left21:51
bn_work JAA: yeah, that's what I was thinking21:51
Xenguy_ joined21:51
ThorMojito1 left21:51
JAA I'd use a separate 'fix-foo-bar' branch then. But with a different name than the now-deleted branch from the extra PR, I suppose.21:51
bn_work JAA: and the "branch" was already deleted too21:52
JAA If you have any kind of CI, PRs even make sense if you're the sole maintainer. Just a sanity check before you commit to master.21:52
Xenguy left21:54
bn_work we have no CI yet, apparently it's just not a priority here21:54
cchtdgooc^ left21:55
bn_work well, to be fair, we're a small company and I've been having to handle other non-DevOps things21:55
otisolsen70 left21:56
bn_work testing of the deployment of builds is also a bit time consuming, so it may be a while before that gets automated21:56
JAA: but who would review the PR? yourself?21:57
JAA If it's just about the CI, sure.21:58
Of course, there are alternatives. You could push to a separate branch, let CI run there, and then fast-forward master on success.21:58
bn_work JAA: I mean isn't that the point of having # of branches > 1? ie: you only merge once it's been tested and passed?21:58
like what value does adding the PR layer provide?21:58
JAA If you want to avoid the actual PR workflow.21:59
coot left21:59
bn_work yeah21:59
JAA Yeah, the PR as such doesn't make much sense unless it's a complicated change.21:59
bn_work PR workflow (as defined by GH) seems to only makes sense when you want collaboration and code reviews21:59
I feel?21:59
yes, that too21:59
JAA For complicated changes, it can be useful to see the code changes again in a different interface. Can help the brain spot bugs that you didn't notice because you were staring at `git diff` on the terminal for too many hours.22:01
Oh yeah, you could also do feature branches and then merge them without fast-forward. I sometimes do that, also for more complicated things. (Again, doesn't require a PR.)22:02
It can be convenient to be able to merge straight from the GitHub interface, where you're reviewing the CI results anyway probably.22:02
bn_work yes, for like a large feature, and where there are others on the team that can contribute helpful feedback, sure... but like I'm literally the only one that is coding in this22:03
the github interface can be slow for large diffs and sometimes it won't even show it at all if it's too large22:04
JAA Yeah, there are limits.22:04
ThorMojito joined22:04
JAA Anyway, it's a tool, there's no right or wrong way to use it, really. You'll need to establish what the most reasonable application in your case is.22:05
If you feel like it's of no use and your colleague doesn't care, sure, just make changes to master directly. That's fine, too.22:05
CI/CD can change the picture considerably, but again, tools, no right/wrong way, etc. :-)22:06
giu- left22:10
bn_work I feel like my boss is just crippling me with this whole feature branch, PR creation, review, merging, branch protection and deletion overhead w/o really understanding when it makes sense. His team is much larger (8+ people?), with multiple current (usually complex new feature) development, so it makes sense there, but for this "one-man-band" (+ new jr. admin that just joined), I mean, wtf, lol22:10
JeffH left22:12
loulou left22:16
bn_work I am going to miss this fast level of development once/if this "team" grows to that size22:17
causasui joined22:21
theoceaniscool left22:29
MajorBiscuit left22:33
clime left22:33
clime joined22:33
arescorpio left22:34
tomhg left22:36
ThorMojito left22:37
Xenguy_Xenguy22:40
pvxe left22:40
pvxe joined22:42
Geronimo joined22:43
Jong joined22:44
cbreak left22:45
cbreak joined22:50
rsrx joined22:50
mexen left22:51
loulou joined22:52
loulou left22:52
loulou joined22:52
thebombzen left22:54
rsrx left22:55
jbg joined22:55
NeatNit left23:05
robink left23:08
odoood left23:09
gurkenglas left23:09
Yruama left23:12
_sa0sin_ left23:16
delay joined23:17
NeatNit joined23:18
robink joined23:18
Coop56 joined23:21
rama left23:22
rama joined23:22
cyberpear left23:23
bn_work left23:24
Thad_the_man_2 joined23:24
Coop left23:24
magic_ninja left23:24
thad_the_man left23:25
cyberpear joined23:25
causasui left23:26
bn_work joined23:27
magic_ninja joined23:39
Jong left23:42
zeenk left23:45
delay left23:51
hnOsmium001hnOsmium000123:51
Betal joined23:52
ferdna left23:53
zen_coder left23:56
Lord_of_Life left23:56
vdamewood joined23:58
hnOsmium0001 left23:58
Lord_of_Life joined23:59

Logs Search ←Prev date Next date→ Channels Documentation