Fork me on GitHub
#off-topic
<
2024-04-17
>
craftybones05:04:15

What is the quickest way to programmatically check if a git pull is needed? I’m currently doing a git fetch and then a rev-list to determine if a merge is needed. Is there a nicer way? The problem I have with it is that a git pull takes too long to respond even when there are no updates. I am wondering how to speed this up.

craftybones05:04:59

Imagine 100s of repos(Github Classroom)

p-himik07:04:38

Pretty sure rev-list is the way to go. I have this in my zsh theme file to show me how far the local branch and the remote have diverged:

local commits_ahead=0 commits_behind=0
read -r commits_ahead commits_behind <<<$(git rev-list --left-right --count ${current_commit_hash}...${upstream} 2> /dev/null)

👍 1
tomd08:04:17

Given that git pull is just git fetch followed by git merge under the hood, if "git pull takes too long to respond even when there are no updates" I'm not sure why doing git fetch followed by anything (`rev-list` or otherwise) would make much difference. If you want to check for remote changes without fetching, I think you'll want to look at git ls-remote instead.

1
craftybones09:04:46

😞 I guess fate has decreed that this is the case. No issues. I will either parallelise or bear the time cost

eval202010:04:42

https://myrepos.branchable.com/ might be helpful with that many repositories

1
Cora (she/her)12:04:47

maybe not exactly what you're looking for but it's an example of how to parallelize it yourself if you are so inclined https://github.com/corasaurus-hex/pull-all

tomd12:04:49

If you're just looking to check as quickly as possible without fetching, here's some bb that does what I suggested above. Wouldn't be too difficult to parallelize across multiple repos:

(apply not= (map (fn [{s :out}] (subs s 0 (min 40 (count s))))
                 [(shell/sh "git" "ls-remote" "origin" "main")
                  (shell/sh "git" "rev-parse" "main")]))

craftybones14:04:29

Thank you all. I don’t intend to parallelise just yet. But yes, I do recognise that at a very crude level I could simply parallelise with babashka, perhaps simply partition my list into chunks of n and run them all on a future, but for now, I’ll just pay the time cost

emccue15:04:28

I am like 80% on team Chronver now. Gonna wait a bit to see if I stay there, but i might start changing all my OS projects to use that. https://chronver.org/

Ben Sless16:04:20

Why is it the first thing my mind went to was worrying how this will work with interstellar travel and relativistic speeds?

john16:04:10

Yeah, is chronver gmt or local time?

emccue16:04:57

I think local time

emccue16:04:20

the important part seems to be just that "the publisher" publish an ordered set of releases

emccue16:04:36

its not really important that they line up with the actual days 1-1

emccue16:04:31

so if I, in EST, publish 2024-05-17, it doesn't matter much that it is actually ambiguous whether i hit the deploy button on 2024-06-17 in my or another person's timezone

emccue16:04:49

its just to be more human grokkable than 1 -> 2 -> 3 -> 4

john17:04:38

Spec isn't Y10K compliant

😂 2
Martynas Maciulevičius20:04:41

Spec isn't Y10K compliantThink about human lives!

john20:04:54

Dragons are going to start flying out of date selector boxes everywhere the day 9,999 ends

🐉 1
teodorlu16:04:59

Why is the Clojure community friendly?

p-himik16:04:43

Heh, it's weird that I haven't seen this question before. Made me chuckle a bit. Things I can think of: • It had a friendly, or at least a neutral, start • The relative simplicity and lack of BS in the language and the ecosystem don't make people think that suffering is the norm • On average, Clojure devs are more senior and I'd assume more open-minded • There's an active effort to keep it friendly. If someone behaves in a less-than-neutral way, attempts are made to steer that behavior in a more friendly direction

❤️ 3
👍 4
1
teodorlu16:04:20

I get curious about questions some times. And some times I just ask those questions 🤓

ghadi16:04:01

was influential

teodorlu16:04:30

Right. Rich originally posted this on the mailing list, if I remember correctly?

1
seancorfield17:04:05

And Clojure conferences have pretty much always had a Code of Conduct so that's sort of baked into the culture -- and this Slack has a CoC...

👍 2
mauricio.szabo04:04:54

We're actually not - we're all pretending. Now get out of my lawn! (obviously sarcasm :D)

😄 3
Duminda07:04:20

@U3Y18N0UC Pretence is better than honesty in this case 😄

😄 3
azimpel08:04:50

Working with Clojure is such a pleasant experience. And I wanna share it with other devs hoping to spark some interest. We're eager to give something and you do it normally in a very friendly way 🙂

❤️ 1
Daniel Gerson13:04:57

@U04V70XH6 Are you saying we're friendly because we're regulated? :face_in_clouds:

p-himik15:04:33

Just in case - a CoC is not a code of laws. It's more of a description of the overall vibe in the community that moderators try to maintain, and some specific items that are necessary for that. With that being said, a mere existence of a CoC and moderators working in its scope are not enough for a community to be friendly. Nor are they necessary in general, but I'd say are definitely a requirement for large dynamic communities.

gratitude 3
Nundrum18:04:42

I get a sense of "we have something great here, and we want to share" which lends itself to a high level of friendliness. It's not "this language is right" or "everyone uses this language because it's the best" or "the fastest ever!"

👍 2
1
seancorfield18:04:18

This language makes us happy 🙂

😊 4
💯 2
Vincent17:04:49

Thinking about starting a bank

isak17:04:41

You've come to the right language

😂 9
Stephan Renatus17:04:06

“What is the burgling of a bank to the founding of a bank?” https://en.wikiquote.org/wiki/Bertolt_Brecht

🎯 1
🛠️ 1
mauricio.szabo04:04:15

Sometimes I also think about it, but I get scared just thinking about all the things I will have to do...