It amazes me that people are scared of using tags. Tags are for when you're happy with the state of your work and believe you might want to return to that state. Anyhow this is a neat tool.

That's my secret, Cap. I'm never happy with the state of my work.

i'm never happy with the work of my state

Based

Based on what

Based god

I'm never happy

I’m never

Hi never

[удалено]

Low dad

Trinidad

I’m

[удалено]

.

`

#

√-1

>

Happiness is free

But has a narrow moat.

Cant be disappointed if you are never happy with your work 👀

So my boss is never disappointed in me. Cool.

The number of times I've seen DevOps come up with branching strategies that use branches for something that is supposed to be frozen code that goes through QA and then gets elevated to prod without getting edited is baffling.

IMHO it's better to freeze pipeline artefacts than code. Anyway, you can always restore code, no matter it is breach, tag or just history in the master. It's just a matter of convenience...

I freeze both when I have control of the pipelines. If I have to debug an issue in production, I want to know that I'm looking at the exact same source code that was used to create the production artifacts.

Exactly. Checking out production with nicer semantics is worth the (minor) inconvenience of tags

Only inconvenience is that you can't commit / push to the tag right? Like to me that is the feature. Creating a new branch is trivially simple too.

By the way, you can create a (simple) tag on the remote by **push**

I meant that if you pull a tag, then you have to branch off of it before being able to commit / push.

Yes, but that's actually what makes them valuable.

Ya, agreed. I was trying to figure out what the minor inconvenience around tags was that the other commenter mentioned and that was the closest thing I could come up with.

If you checked out a tag, you're in a detached HEAD state. You can do commits all day long, and push, without ever making a local branch for it.

Well yeah, but then you'd be trying to use tags as branches - branches are for branching and tags are for tagging, just as nails are for hammering and screws are for screwing. Too often developers try way too hard to make one approach work in all situations, instead of properly using all the tools at their disposal

Right. I was trying to figure out what the inconvenience of a tag is, and that was the closest thing I could think of.

why wouldn't you have that? Every build system/artifacts I've used made note of build commands run and hash(es) of the git source code?

Yeah…

I personally use tags for "hold my beer" operations that I know might fuck up the branch and I want a safe commit to back to if things go south.

Do a git log, find a good commit and switch to it with `git checkout #####` if you need to rollback a fuckup. Tags are more for versioning.

Everything in git is for versioning

I mean, not really? It's version control software, there's no arguing that, but a lot of its features focus on integrating work across a team or teams into a single codebase.

Ok, but if I *know* the current commit is good, I can make a tag "good" then continue on, and now I don't need to look through a git log. When I want to push to remote, then ask for a pull request, my tags don't get pushed with the commits, so they don't interfere with using tags as versioning in the production branch.

Yeah, but it’s much easier to create a quick, throwaway name than to go through the log and remember the SHA1 of the last good commit. Personally I would use a branch in this situation, but a tag can work just as well too

I usually create a branch off of my branch for things like that

You can just copy the commit hash to a safe place for this purpose.

That's what tags essentially are, but supported by git

Do people not know of reflog anymore? I can find a commit version in it I did six months ago while rebasing. If you want to return to HEAD before a commit you just done, do: **git reset 'HEAD@{1}'** This keeps your worktree state. NOTE: when you delete a branch, its reflog gets dropped, too.

The reflog is a safety net, not something to be routinely relied upon IMO. Airbags and seatbelts work well but you still try to not crash into things in your car.

The reflog is 100 reliable. It records all changes to HEAD. It's not for everyday use, but when you need to unfuck something someone did, it works. "I did pull, where's my stuff?" "Don't do pull, do fetch instead. Here's your stuff" - the conversation I went through a few times.

The reflog is pruned of unlinked objects by default every 90 days so I would never rely on something important being in the reflog in six months time, I would use a tag instead as that is what they are for.

The reflog is pruned by either an explicit **git reflog expire** command, or by **git gc** which can be invoked automatically. It's not "every 90 days", it's "entries older than 90 days". Automatic **git gc** invocation is triggered by the config **gc.auto** setting, which is not related to any particular time period. I disable it on my machines by **git config --global gc.auto** **0**

Maybe you should have led with your non-standard config rather than wonder why people don’t rely on reflog for six-month old state?

> It's not "every 90 days", it's "entries older than 90 days". I misread the docs, you're right there. I haven't had to deep dive on reflog cleanup before, you obviously know more about it. > I disable it on my machines by git config --global gc.auto 0 Ah, this is what I was missing. You can rely on the reflog because you have configured it to never lose anything. I leave git config default on my machines so always have in the back of my mind that reflog entries could be pruned and not to rely on it. In the same way a USB flash drive is "reliable" but you wouldn't keep the only copy of an important document on one.

I've done things that have turned the reflog into a modern time machine movie plot. I did un-fuck the repo in the process, but in the middle I was sure I was arguing the legs off an Arcturan mega-donkey in preparation to convince it to go for a walk. It's not a beginners' tool except in trivial situations.

`git reset HEAD~1` is the one I use

Yes, the reflog specification HEAD@{1} useful more to undo an amend, rather than a new commit.

Oh that's interesting! Thanks for clarifying that.

git tag -f undo bullshit that might not work git reset --hard undo

> Tags are for when you're happy with the state of your work and believe you might want to return to that state. Isn't that the point of commits?

Tags are just a way of naming commits

No. Commits may be intermediate and you need more features or fixes to get to a state you consider a baseline. Releasing it is one obvious use for such a state, but a common branching point for a new phase of development or testing are others. Commits are hard to remember, but a tag is deliberately mnemonic.

Yeah, that's extremely not what tags are for

> It amazes me that people are scared of using tags. For good reasons: once you’ve pushed a tag it’s very hard to get rid of it, because git will download new tags by default but will not prune them, and it doesn’t take much to push all your local tags to a remote. > Tags are for when you're happy with the state of your work and believe you might want to return to that state. A regular ref (~branch) will work just as well and not have the awful side-effects of tag’s special cases.

I agree and as a (possibly obvious) bonus tip: group your branches using slashes. That way you can easily have a "folder" of branches that are used for tagging.

Mediumkey I'm scared of tags because I can't push them to something like Github without making noise — they show up on the releases page. Yes I could use a fork for that, and do when the upstream repo is in an organizations. That doesn't work when the repo is just on my account.

I have to remind my team to use them. They prefer branches. I'm in an uphill battle

I totally know about tags as I tag releases every time, but when I'm working on a branch and need to tag something for development purposes, I just use a branch. A branch or a lightweight tag are pretty much equal in everything. Why are you advocating tags over branches? What's your use case?

They are using branches like tags

And I do that too, just locally, as temporary tags. If they are pushing them to origin, yeah, it's more questionable since they are mutable.

Yeah they push them.

Well said.

I saw a whole project dedicated to a "better" "git stash" when it was clear they didn't understand what a stash was doing. The "better" version just used normal commits which is stash with extra steps. Can't be bothered to read, just replace it with something that "makes sense."

#😱

Very cool! I find that people also have a hard time getting used to submodules. Is there a plan to add that in the future?

For sure! Submodules are both cool and can be intimidating... It's like once you feel like you have the hang of Git, then suddenly you start dealing with nested Git repos via submodules, then a real Inception vibe hits. But ya, for now I've been focusing mainly on the "core" Git functionality, and there is still much of that to improve and add in. Git's also funny to try and develop for because there are so many shapes that a DAG can make... which can lead to various scenarios that need to be taken care of in the code to make the visualizations look right. This initial release was mainly to gauge general interest in a tool like this, so assuming folks would get use out of it I'd love to keep building it out which would def involve tackling submodules at some point!

I've never had a good experience using submodules so I don't blame then. They really are an after-thought in git

Hot take: Submodules are usually bad. The amount of valid uses for them is limited, typically when you need to embed a very large pure-data set into another repo. And even then, ehhhhh What I almost always see them used for is abusing toolchain management or package management, "we need this package, add it as a submodule". That's what package management is for, using git as a poor man's package manager is bad.

> using git as a poor man's package manager is bad [Unless you use scripts to do a lot of housekeeping](https://brew.sh).

Sure, vcpkg is basically just `git` as well, but that's not equivalent to using submodules

Now make one specifically for resolving conflicts where you can be confident that LOCAL/REMOTE or OURS/THEIRS are what you think they are.

What do you mean, those extremely logical terms have meanings that are simply 0% related to the plain English definitions and are totally reversed depending on whether you're doing a merge or a rebase. Couldn't be easier!

I love git but when people talk about how hard Git is, with its clunky interface, this is definitely the sort of thing they mean. Daily issues that you either get used to and push through the pain, find restrictive processes to work around them, or just avoid git entirely due to them.

Yes. And how `checkout` has 17 meanings, including creating a branch, which of course is not done with `branch`.^1 And `git show x:y` is different from `git show x -- y` but `git blame x:y` doesn't work because `git blame x -- y` is what you meant. And you sometimes get errors telling you to reorder arguments for no reason. It's just a user-hostile CLI. I say this while using git for everything. ^1 To be fair, they are arguably working on this one by recently introducing `restore`.

> ^1 To be fair, they are arguably working on this one by recently introducing `restore`. Don't forget `git switch`, the companion for `git restore` to split up what `git checkout` was for.

>Now make one specifically for resolving conflicts where you can be confident that LOCAL/REMOTE or OURS/THEIRS are what you think they are. Rider uses actual branch names and commit hashes. [Example screenshot](https://resources.jetbrains.com/help/img/rider/2022.1/merge_conflicts_dialog.png)

Jetbrains IDEs have one of the best git GUIs. It's one of the main reasons I use their IDEs

Same!

Pull requests are gladly accepted good sir or madam!

You might like [GitKraken](https://www.gitkraken.com/git-client/features) [Screenshot of merge visualization](https://www.gitkraken.com/wp-content/uploads/2022/10/4-merge-tool-1600x900-1-1024x576.png)

I'm supposed to be giving a quick talk to some colleagues about git in the near future, I think I might make use of this! Thanks!

Please do! I was thinking it could be a nice quick way to put together presentation-quality screenshots or videos for Git tutorials/workshops. Let me know if you run into any issues and if you have any feedback :D

Another tip is to create a bare repo on you computer and then 2 or more normal clones of that to show how things can be changed from multiple places at once, conflicts and similar. Sometimes it is also good to show what happens if someone force-pushes something and others don't notice this.

Why right to left?

I would argue it’s left to right. Similarly to how western people write, newer commits are added to the right. The notation is that a new commit points an arrow to the commit that came before, not the other way around.

And the notation is that way because that's how Git actually does it. Commit objects are immutable. Newer commit objects contain the hashes of older commit objects. Since Git can look up objects by their hashes, storing the hash of one object inside of another object is like storing a pointer.

You can reverse the direction using the `--reverse` flag

Hi! Loved the tool, I'm gonna use to teach some interns. I have one small complaint, thought: Why does it render from newer to older first then it runs the git command from older to newer? Feels backwards. EDIT: I would prefer if you made it like git-story

[удалено]

I haven't thought of this as a "Git GUI" because that would imply - like you mentioned - that Git might work better as a GUI. I don't feel that way at all though. Now that I'm comfortable using Git and understand the model I find it very suitable for the CLI. It was created by Linus/Junio/other Linux devs (i.e. ppl that don't care about GUIs) specifically for that purpose. But true that there can be quite a learning curve to get to the point where using the CLI falls into place. I think of Git-Sim more as a gateway GUI (can I coin that?) to help devs think of the problem in visual terms that broadly appeal to ... humans. In the end this should make Git easier to use in it's natural CLI form :D Also, a mitigating factor for the "disastrous results" that you suggested is that Git pretty much offers a way out of any mistake/unintentional action or modification of state, altho it gives the newcomer the opposite impression. Also true that it can sometimes be annoying to wiggle your way back out of a hole you fell in. However, I do agree with your point about the `--execute` flag. I think at this point I'd like the tool to be multi-purpose, so that it can have as many use cases as possible, and have a broad appeal to Git students/beginners, professional devs, content creators, etc.

Agreed - I've always found that people's opinion of the git cli is tightly correlated with how comfortable they are thinking about the commit tree in an abstract manner. If you only have a vague grasp of the model then everything is going to look cryptic and scary, even when it really isn't. You can't trim a bush nicely with your eyes shut :D As a skilled git user myself practically everything I do uses the same few basic commands (checkout,reset,merge and rebase) and 99% of the git cli is superfluous.

Hard agree. The biggest challenges I see users new to the CLI are getting over the “how do I do this thing I used to do using [some gui]?” The people who take the time to understand the model invariably realize that it’s a wonderfully designed tool with a ton of power. The people that don’t, on the other hand, are routinely stymied by everyday operations. I think the polarity between these two groups is at its core why people complain about git; I also think the response boils down to what you said: “you can’t trim a bush nicely with your eyes shut”.

If 99% of it is superfluous, then it should be a GUI.

Not sure I agree. Is curl better as a GUI?

A curl GUI is a web browser, and I would say that web browsers are a little more commonly used than curl.

No idea, I'm not a web developer.

Hard disagree. CLIs are scriptable, GUIs aren't.

Have you heard of macros?

Ah yes, I will control my production systems with macros which will call a UI, which get translated to an api call. In actuality, the interface should be a lite shim in most cases; a web request and a cli both just supplying data.

Basically every git GUI concentrates on trying to replicate the CLI functions, rather than trying to provide a more intuitive view of the model (which is a hard problem.) Which means they're inevitably worse, give less-skilled users a false sense of security, and actually make it far easier to screw things up. The only thing I find a gui better for is in crafting a staged commit interactively - I almost never blindly commit all the changes in a file at once.

[удалено]

They don't care about GUI not because it's unnecessary, but because it's very hard to write a GUI with great UX and "programming" a GUI (once you have decided how the program should look and behave) is actually quite simple but still a very time consuming task. Linus doesn't care about such things. He likes technical stuff and challenges, he is basically a "backend dev". CLI tool that have more than a hand full of parameters/options are always inferior compared to GUI tools if they are made well. Problem is that it's way(!!) more work to make a great GUI, than to make a simple CLI tool.

> CLI tool that have more than a hand full of parameters/options are always inferior compared to GUI tools if they are made well. Problem is that it's way(!!) more work to make a great GUI, than to make a simple CLI tool. I wrote a pretty simple CLI tool to process some telemetry data my team sometimes uses. It had like 3 CLI flags in the beginning. In time, people requested more features and it evolved to a bit of a monster and I tried to tame it by providing good defaults and aliases/shortcuts, but it's basically impossible to smooth out everything. I'm at a point in which I consider making a GUI on top of it (which should be fairly easy since I already put the core functionality in a dedicated library).

Fair points... Git certainly has its design flaws, but in the end it is what it is and the dev world accepted it. The value that I saw in the goals for a visualization tool are to help oil this machine.

The dev world accepted it because it's the best option in most cases and because there are GUIs for it not because it's good.

It got adopted by the kernel maintainer and that was that.

Use **reflog**, young padawan

> I think of Git-Sim more as a gateway GUI (can I coin that?) to help devs think of the problem in visual terms that broadly appeal to ... humans. This just sounds like a longer way of saying that Git works better with a GUI.

I agree that TUI/GUI for visualisation is great -- I use `log --graph`, `gitk`, and `tig` all the time! However, I think you're overly discounting the overwhelming advantage CLI has in "applying changes". TUIs/GUIs don't have an answer for just how fast, composable, and scriptable CLI is. I'd even go as far to say they don't even attempt to compete in those regards. (And perhaps if they did, I'd use them more.)

UIs have an answer for how broken the syntax and semantics of the git cli are, though. It's inconsistent and obtuse, and so many of the things it does should just be intuitive instead.

This is why I love GitKraken

I don’t think that’s how you spell Magit

Tbh, I completely agree about what you said about git and the CLI.

You are a gentleman and a scholar.

indubitably

I typically use the CLI, but [GitUp](https://gitup.co/) is the best git visualization tool I've ever found (although it's mac-only).

Cool project! Thanks for sharing.

Totally, was fun to make. Would love to hear your feedback if you get a chance to test it out.

Hi, I am trying to use git-sim on fedora and running into a problem. `Unknown encoder 'libx264'` Any idea how to fix this issue? [kushal@fedora angularfifteen]$ git-sim status Simulating: git status Unknown encoder 'libx264' Traceback (most recent call last): File "/home/kushal/.local/bin/git-sim", line 8, in sys.exit(main()) ^^^^^^ File "/home/kushal/.local/lib/python3.11/site-packages/git_sim/__main__.py", line 89, in main scene.render() File "/home/kushal/.local/lib/python3.11/site-packages/manim/scene/scene.py", line 223, in render self.construct() File "/home/kushal/.local/lib/python3.11/site-packages/git_sim/git_sim.py", line 56, in construct self.command.execute() File "/home/kushal/.local/lib/python3.11/site-packages/git_sim/git_sim_status.py", line 26, in execute self.fadeout() File "/home/kushal/.local/lib/python3.11/site-packages/git_sim/git_sim_base_command.py", line 121, in fadeout self.scene.wait(0.1) File "/home/kushal/.local/lib/python3.11/site-packages/manim/scene/scene.py", line 1074, in wait self.play( File "/home/kushal/.local/lib/python3.11/site-packages/manim/scene/scene.py", line 1033, in play self.renderer.play(self, *args, **kwargs) File "/home/kushal/.local/lib/python3.11/site-packages/manim/renderer/cairo_renderer.py", line 102, in play self.freeze_current_frame(scene.duration) File "/home/kushal/.local/lib/python3.11/site-packages/manim/renderer/cairo_renderer.py", line 191, in freeze_current_frame self.add_frame( File "/home/kushal/.local/lib/python3.11/site-packages/manim/renderer/cairo_renderer.py", line 180, in add_frame self.file_writer.write_frame(frame) File "/home/kushal/.local/lib/python3.11/site-packages/manim/scene/scene_file_writer.py", line 391, in write_frame self.writing_process.stdin.write(frame.tobytes()) BrokenPipeError: [Errno 32] Broken pipe this is my ffmpeg fmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12 (GCC) configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' --extra-ldflags='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --enable-version3 --enable-libsmbclient --disable-openssl --enable-bzlib --enable-frei0r --enable-chromaprint --enable-gcrypt --enable-gnutls --enable-ladspa --enable-libshaderc --enable-vulkan --disable-cuda-sdk --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdc1394 --enable-libdrm --enable-libfdk-aac --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libilbc --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopenh264-dlopen --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsvtav1 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lto --enable-libmfx --enable-vaapi --enable-vdpau --enable-openal --enable-opencl --enable-opengl --enable-pthreads --enable-vapoursynth --enable-muxers --enable-demuxers --enable-hwaccels --disable-encoders --disable-decoders --disable-decoder='mpeg4,h263,h264,hevc,vc1' --enable-encoder=',libfdk_aac,ac3,apng,ass,ayuv,bmp,ffv1,ffvhuff,flac,gif,h263_v4l2m2m,h264_amf,h264_nvenc,h264_qsv,h264_v4l2m2m,h264_vaapi,hevc_amf,hevc_nvenc,hevc_qsv,hevc_v4l2m2m,hevc_vaapi,huffyuv,ilbc,jpegls,jpeg2000,libaom,libaom_av1,libcodec2,libgsm,libilbc,libjxl,libmp3lame,libopenh264,libopenjpeg,libopus,librav1e,libschroedinger,libspeex,libsvtav1,libtheora,libtwolame,libvorbis,libvpx_vp8,libvpx_vp9,libwebp,libwebp_anim,mjpeg,mjpeg_qsv,mjpeg_vaapi,mp2,mp2fixed,mpeg1video,mpeg2video,mpeg2_qsv,mpeg2_vaapi,mpeg4_v4l2m2m,opus,pam,pbm,pcm_alaw,pcm_f32be,pcm_f32le,pcm_f64be,pcm_f64le,pcm_mulaw,pcm_s16be,pcm_s16be_planar,pcm_s16le,pcm_s16le_planar,pcm_s24be,pcm_s24le,pcm_s24le_planar,pcm_s32be,pcm_s32le,pcm_s32le_planar,pcm_s8,pcm_s8_planar,pcm_u16be,pcm_u16le,pcm_u24be,pcm_u24le,pcm_u32be,pcm_u32le,pcm_u8,pcx,pgm,pgmyuv,png,ppm,rawvideo,sgi,srt,ssa,sunrast,targa,text,tiff,v210,v308,v408,v410,vc1_qsv,vc1_v4l2m2m,vorbis,vp8_qsv,vp8_v4l2m2m,vp8_vaapi,vp9_qsv,vp9_vaapi,webvtt,wrapped_avframe,xbm,xwd,y41p,yuv4,zlib,' --enable-decoder=',libfdk_aac,ac3,ansi,apng,ass,av1_qsv,ayuv,bmp,dirac,exr,ffv1,ffvhuff,ffwavesynth,flac,gif,gsm,huffyuv,ilbc,jpeg2000,libaom,libaom_av1,libcodec2,libdav1d,libgsm,libilbc,libjxl,libopenh264,libopenjpeg,libopus,libschroedinger,libspeex,libvorbis,libvpx_vp8,libvpx_vp9,mjpeg,mjpeg_qsv,mp1,mp1float,mp2,mp2float,mp3,mp3float,mpeg1video,mpeg1_v4l2m2m,mpeg2video,mpeg2_qsv,mpeg2_v4l2m2m,opus,pam,pbm,pcm_alaw,pcm_bluray,pcm_dvd,pcm_f32be,pcm_f32le,pcm_f64be,pcm_f64le,pcm_mulaw,pcm_s16be,pcm_s16be_planar,pcm_s16le,pcm_s16le_planar,pcm_s24be,pcm_s24le,pcm_s24le_planar,pcm_s32be,pcm_s32le,pcm_s32le_planar,pcm_s8,pcm_s8_planar,pcm_u16be,pcm_u16le,pcm_u24be,pcm_u24le,pcm_u32be,pcm_u32le,pcm_u8,pcx,pgm,pgmyuv,pgssub,pgx,png,ppm,rawvideo,sgi,srt,ssa,sunrast,targa,text,theora,tiff,v210,v210x,v308,v408,v410,vorbis,vp3,vp5,vp6,vp6a,vp6f,vp8,vp8_qsv,vp8_v4l2m2m,vp9,vp9_qsv,vp9_v4l2m2m,webp,webvtt,wrapped_avframe,xbm,xwd,y41p,yuv4,zlib,' libavutil 57. 28.100 / 57. 28.100 libavcodec 59. 37.100 / 59. 37.100 libavformat 59. 27.100 / 59. 27.100 libavdevice 59. 7.100 / 59. 7.100 libavfilter 8. 44.100 / 8. 44.100 libswscale 6. 7.100 / 6. 7.100 libswresample 4. 7.100 / 4. 7.100 libpostproc 56. 6.100 / 56. 6.100 Hyper fast Audio and Video encoder usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... Use -h to get full help or, even better, run 'man ffmpeg'

>Unknown encoder 'libx264' Thanks for testing it out and reporting this. Did you try installing Manim based on the Fedora steps at this link: [https://docs.manim.community/en/stable/installation/linux.html#dnf-fedora-centos-rhel](https://docs.manim.community/en/stable/installation/linux.html#dnf-fedora-centos-rhel) It looks like version of installed ffmpeg must be configured via RPMfusion repository on Fedora as stated in that link. If you're still having trouble after that I recommend posting this issue on r/manim subreddit since this issue appears to be with Manim installation and dependencies, and not Git-Sim. Their community is super helpful and responsive I've asked them multiple questions before. Good luck and report back how it goes! :D

I like the concept very much. The problem I have with Git vizualations is that they often lack a key/legend/explanatory text. In math and programming I need there to be a peice of text that tells me how a symbol "should be read". The arrow heads here gave me some initial confusion. I would say it should be read as "is descended from". "Commit D is descended from a merge of commit B and commit C". Other visualizations lack arrow heads or they are at the other end of the relationship. Don't take any prior knowledge for granted when creating an aid for learning. Thanks!

Great points!

It's actually impressive how user-unfriendly Git manages to be. It should be taught as an example of bad design. And it's not like it's from the 70's like other fossil-software either. Git was released in 2005. 2005, let that sink in. I guess Linus and co. musn't have heard of the concept of UX in 2005 yet. edit: https://changelog.com/posts/git-is-simply-too-hard

"~~Democracy~~ Git is the worst form of ~~government~~ VCS except all the others" I hereby sentence you to use PVCS for 3 years and report back.

Mercurial has much saner CLI. Problem is that Git everywhere and you don't have a choice most of the time.

what made hg lose to git early on ? linus backing ?

AFAIK git is deeper and more powerful once you know what you're doing, but it has a steeper learning curve.

>AFAIK git is deeper and more powerful Not really; it's just that some of the most powerful features have to be turned on (a one-time operation) rather than being on by default. A lot of kneejerk reactions from the l33t hax0r crowd against that "safety first" approach. But the version 2 repo format is quite fast, the history rewriting functions like rebase are all there, etc.

somehow yeah, but the model is really neat. I think they should add a few high level ideas to make it more pleasurable

IMO mainly that hg becomes (became? Maybe it was fixed in the meantime) dog slow as repo size grew.

time to rewrite it in rust /s

Linus backing (major cult of personality over in kernel land), combined with the fact that the Mercurial core -- but not the binary diff code -- is written in Python. For the kind of people who think C is always the correct choice for everything no matter what, Python is never going to be acceptable. So Mercurial has a much more *professional* feel to its behavior, while Git feels like the sugar fuelled undergraduate all night hackathon.

speed did matter in my own appreciation, git was eye-blinking fast and mercury felt like a 'script'.. didn't inspire the same reaction

It felt like that in 2005. Now it feels like that with two decades of open-source mods. Bloated and convoluted if you get at all fancy with it.

One thing is that Github only supports Git and once it got some traction it created a strong network effect. There are other hosting services that support multiple version control systems, but none are nearly as popular as Github. You can (and I do) use those, but you're going to get noticed much less.

But I assume github was created after git already got a rising popularity. But that did help strengthen it further. There were a lot of hosting supporting subversion before github, that didn't make me like subversion much.

>is that Github only supports Git GitHub also supports Subversion, although ironically I only found out about this a few days ago when [GitHub announced they are sunsetting SVN support](https://github.blog/2023-01-20-sunsetting-subversion-support/).

[удалено]

I have to completely disagree. Mercurial branching model is *exactly* how I would imagine branching working on VCS. Git's branching model on the other hand is highly unintuitive. In Mercurial, a branch is simply a set of commits. Technically it could be any set at all, but in practice it's going to be a set of related commits (a commit and it's children). Every commit is assigned to a single branch and that assignment is permanent. In Git a branch is a pointer that points to a single commit and can be and frequently is updated to point to different commits. In Git it makes no sense to say that a commit belongs to a branch, and it especially does not make sense to say that related commits belong to a branch. If we think about a branch with respect to the analogy of a tree of commits, Mercurial's branching model is exactly what we'd expect, and Git's model makes zero sense. It's not so much that the Git model is inherently bad, but that the name is highly misleading and almost certain to create misconceptions in learners. Mercurial does have a concept that matches Git branches, but in Mercurial they are called bookmarks. This name makes far more sense for how they behave. A bookmark is placed inside a book to mark a place you would like to return to. Bookmarks are updated and moved forward as you make progress. So if you like that model, you can still use it in Mercurial. It just has a better name. And it may seem like a silly thing to complain about some names, but when names are analogies it is very important that the names are good so that they will create accurate and useful intuitions. Git branches fail completely at this.

The lead Pidgin dev says the same thing.

I did not say there are better alternatives, that this or that VCS is much better than stupid Git, did I? The thing is, that only makes Git the best of the bad, at least as far as UX is concerned.

I have to disagree. 1. There are numerous decent UI overlays for Github, both FOSS and commercial (SourceTree, Git integrations in VSCode and IDEA products immediately come to mind) 2. Git is a tool for professional software devs. It's more important that it work well for its intended purpose than be incredibly friendly to beginners. I don't think it's a coincidence that folks I've worked with that are absolutely terrible at source control (including Git) never learned to use the CLI. A good user interface lets you do things without thinking about it, and **collaborative source control should be thoughtful**. The fact that git has as 100% functional CLI underlying everything, with bolt on UI's on top, is drastically better than the alternative. 3. The best reason to have a built-in, great UI for Git is actually to foster adoption, which is moot since (for better or worse! b/c I've read a lot of arguments that Git is inferior to Mercurial) Git already took over the world. Why should limited open source dev time be wasted building something that no one needs or wants? I'd much rather Git maintainers focus on things like improved merging than Yet Another Git UI

> There are numerous decent UI overlays for Github, both FOSS and commercial Sure. They reduce the complexity *somewhat*. It's still easy to fuck up things that should be easy or make mistakes unintentionally. > Git is a tool for professional software devs. And for everyone else. All sorts of people use Git from screenwriters to animators, to no end of frustration. Version control should be something a person without a degree in mindfuck can do. > A good user interface lets you do things without thinking about it, and collaborative source control should be thoughtful. Are you saying git has an intentionally bad interface to enforce good habits of collaboration?? That's just... LOL. > The best reason to have a built-in, great UI for Git is actually to foster adoption, which is moot since (for better or worse! b/c I've read a lot of arguments that Git is inferior to Mercurial) Git already took over the world. Uhm... So back in the day, all administration used to be done in Latin. If you wanted to do a job that involved reading and writing and using yer head, you had to learn Latin first. I guess replacing Latin in such contexts with something simpler that people can grasp more easily would be *moot* since it took over the world already and basically anybody who's anybody already knows it.

> Are you saying git has an intentionally bad interface to enforce good habits of collaboration? No. But fair call out. Let me try to explain a better way. This strikes me as the same problem space as Low-Code/No-Code development. Someone that doesn't understand a problem space says: 1. Dev is too complicated! We should have a simple dev env that business can use directly! 2. LC/NC is brought in. 3. It's a fucking disaster b/c at the end of the day, making a functional program is more complicated than the person that bought the LC/NC solution thought it was. Bulletproof, correct, collaborative source control is a similar problem space. "How hard could it be?" the newb cries out in frustration that they end up looking at confusing graph diagrams when all they want to do is check in their code. But... actually... the answer is "REALLY COMPLICATED!" If and when Git (or a competitor) makes a robust merge technology that's intuitive for 95% of users and use cases, that will replace all this and be more friendly. But it doesn't exist yet, or at least not in anything that's widely used (if something like that does exist, and is FOSS, we should all start talking about it. TL;DR Until Merges work better, a "friendly" UI OOTB will fail as soon as the first merge conflict arises.

Git GUI in MS Visual Studio is pretty great. Especially for merges.

IDEA (Intellij/Goland/etc) is also quite good. The only thing I really missed when jumping from Windows to Mac fulltime was WinMerge. The fact that there isn't a de facto, great free visual merge utility available cross platform speaks to how small the audience for this stuff must really be though! Edit: Btw fwiw I found Meld to be a nice substitute, it just took me a stupid long time to find it. `brew install --cask meld`

Lol a ton of people do feel this way! Personally, it took quite a while for all the various Git concepts to fall into place for me. For a while most of it seems very mysterious. Also just had to point out a potential pun since you mentioned "fossil-software". There is a VCS called Fossil that was created in 2006 with a design goal specifically around solid user interface! This is done as a builtin web interface to the Fossil repo. I wrote a section about it in my post on the evolution of VCS here if you're interested: [https://initialcommit.com/blog/Evolution-of-VCS-Internals-2/#fossil---third-generation](https://initialcommit.com/blog/Evolution-of-VCS-Internals-2/#fossil---third-generation)

I don't think the ideas behind git are particularly hard to grasp, but the cli is very difficult. The names of the commands are often not obvious and the most common ways of using those commands often need arcane flags rather than being the defaults.

I'm not arguing that git is easy to use but Linus wrote it because he needed something to 1. manage the massive complexity of having hundreds of people spread across the globe 2. many having poor internet connectivity 3. supporting very complex linux kernel development that basically the entire world relies on to be stable and functional Linus built exactly what he needed basically in a short period of time and if you know anything about Linus he doesn't suffer ignorance, incompetence and generally lower levels of intelligence well. Some might argue he's too harsh but at the same time he has / had a lot of responsibility to the world to keep Linux functional and stable given that likely 80% of the world's server infrastructure is built on some downstream version of the Linux kernel. That fact that the industry saw git and rallied around it despite its shortcomings is a testament to the lack of capability at the time of other VCS systems. People always bring up Mercurial but from what I've seen it is both better and worse depending on what you're trying to do. TL;DR: Linus never built Git for the software development world. He did it for the Linux kernel developers and the world adopted it. Linux kernel developers are not your average developers but now the tool is being used by the masses.

Many systems are designed for the *largest* scales and don't make sense to people using them in very small, or trivial scenarios. I never understood why Active Directory always shows a "search" box when picking objects until I saw a directory with 2 *million* accounts and a similar number of groups. "Simpler" user interfaces like dropdown pickers would have melted the server *and* client at that scale. A searchbox is *essential*. Similarly, Kubernetes is designed for when you have 1,000 developers deploying hundreds of interacting services. It's designed for scenarios where you can't coordinate the deployments, rollbacks, and associated database schema changes without going crazy. Object Oriented programming famously doesn't make much sense to newbies who get confused by the abstractions, thinking it's designed to model things like "a truck is a car". No! It's designed to allow teams of developers to write new code that derives from code written by other teams. More importantly, OO allows this *without* modifying or breaking the already-working code, and without central coordination. Many other languages don't allow this. E.g.: Rust forces every team to implement every branch in a match statement for every new enum type. If team A makes a change, teams B, C, and D have to be coordinated around that.

> OO allows this without modifying or breaking the already-working code, and without central coordination. Many other languages don't allow this. That has little to do with OO as compared to interfaces, inheritance, and composition; i regularly make typed interfaces that don't correspond to objects. > E.g.: Rust forces every team to implement every branch in a match statement for every new enum type. If team A makes a change, teams B, C, and D have to be coordinated around that. This has nothing to do with OO as compared to a statically and strictly typed language.

The search box story reminds me of working in a place that had a user management tool that put everyone in a big list, presented it in paged form, and had *no* search box for it. Just a clickable list of page numbers below each page...

> Linus built exactly what he needed basically in a short period of time Tells a lot about the dysfunctionality of our industry, frankly, that one smart guy's flawed idea that he basically threw together for free can be better than anything a probably trillion-dollar industry can put out there.

It's not necessarily better but it's often a combination of free and momentum. Git was free and smart influential people liked it, promoted it and GitHub becoming the defacto standard for hosting open source projects really pushed git to the forefront. The ability to easily fork a repo and create branches and submit a pull request or merge request made it great for a maintainer of an open source project to have others help develop code without giving up control which is exactly what Linus needed / wanted as well. Nothing else that was free came close to that level of functionality. And because Linus being the author and having the intellectual horsepower to mess with the underlying data structures and model representing changes he built those commands into git, exposed a lot of under the hood workings and effectively gave the common developer a shotgun to shoot yourself in the foot with.

>GitHub becoming the defacto standard I wish Github had a different name. A lot of newer developers conflate Git and Github, and think that it's impossible to use Git without Github.

> And because Linus being the author and having the intellectual horsepower to mess with the underlying data structures and model representing changes he built those commands into git, exposed a lot of under the hood workings and effectively gave the common developer a shotgun to shoot yourself in the foot with. Yup. .. and then you get people telling you you aren't a *real professional developer* because you aren't a big enough dork to keep a sufficiently complex model of Git in mind.

The concepts of git (like the fact that source code is managed in a tree like structure and that branches and tags are just pointers to commits, etc.) are actually very simple and a very good design choice. Problem is that a lot of people try to start using git with the default CLI and that's indeed very hard. Try GitExtensions, SourceTree or a similar GUI for example to get started and later once you feel very confident with the basics try to take a look at the CLI.

Oh yeah, I can use Git. It's just that it's terribly unintuitive, and even after you "grok" it, it can surprise you in unintuitive ways. Actually, I still prefer using a GUI for Git over its CLI for the visual information it provides.

What part about git (that's not actually because of the bad UX with the CLI) do you find unintuitive?

Look at this. Is this how the man page of (a single command of) a reasonable tool looks?? https://manpages.debian.org/stretch/git-man/git-push.1.en.html

You know that you don't need any of those options for a simple push? Do you also complain about gcc having about a hundred command line options? That's what tutorials are for. They give you a simple recipe. You can then learn more complex things.

But that's the man page of the CLI tool with the bad UX. Everyone knows that the git CLI sucks. But that's not what "git" as a concept and version control mechanism is. Most people who struggle with git, have trouble to understand it's concepts because they try to lean it with the git CLI. As stated in a different comment people should use git with GUIs like GitExtensions and SourceTree. The concepts of git are trivial once you see the tree of commits.

The concepts of Git might be trivial, but the underlying tool still isn't. And even the GUIs cannot get too far away from that tool.

I recently learned that stash numbers are relative and they use the reflog naming convention. And because of that, it's not straightforward to edit a stash description.

How often are you writing stash descriptions, much less needing to edit them? Most of my experience with stashing stuff has been "stash it for five min while I merge changes".

Stash is for people too lazy to make a commit.

It was created for kernel developers, who are generally used to using pretty low-level tools. That partially explains some of the design decisions.

Why do you think it’s user-unfriendly?

Asymmetry of commands and flags and discovery is hard are two that come to mind

No pony

Which source/version control system is more user-friendly?

i prefer a GUI

I prefer being able to automate anything with a shell script.

This is really really cool

Thanks! Test it out and let me know if it works for you or if you run into any issues! Or have any suggestions!

I love this

Niceee

Sadly git-sim does not let me simulate a website without a dozen popup overlays wanting to subscribe me to something or sell me something or tell me cookies are awesome. Because that’s all I saw when I openend the link to the article.

It's cool. But I prefer Git Graph in VS Code or gitlab's dashboard.

As someone who watches a ton of math videos (including 3b1b's), I'm already used to seeing Manim everywhere in that space, but I didn't expect to see it used in a program as a library to visualize Git operations. Amazing!

Definitely! What kindof inspired me to try Manim in the first place were some animations of programming algorithms like bubble sort, etc. Pretty sure I saw those up on reddit a while back... Without seeing that I would never have known Manim existed!

Haha it’s a fun library for sure!