[HN Gopher] Git-sim: Visually simulate Git operations in your ow...
___________________________________________________________________
Git-sim: Visually simulate Git operations in your own repos
Author : todsacerdoti
Score : 286 points
Date : 2023-01-22 15:01 UTC (7 hours ago)
(HTM) web link (initialcommit.com)
(TXT) w3m dump (initialcommit.com)
| mgsloan2 wrote:
| Pretty cool!
|
| One idea I really like for avoiding VCS operation anxiety for
| beginners and experts alike is a filesystem layer that allows
| revert to any historical state. You just have your bash prompt
| output the current snapshot number, and then can use that as the
| revert target if there's a botched rebase or so. Unfortunately I
| do not know of a nicely packaged way to do this, or how to do it
| at all with OSS tools (but I bet it is feasible!).
| b5n wrote:
| If your fs already supports snapshots/versioning it might be
| convenient, but it doesn't solve the actual hard part which
| generally comes after changes have been merged upstream.
|
| If we're only concerned with local changes I'd rather introduce
| beginners to `reset`, experts will already be doing something
| similar dependent on circumstance. git reset
| --hard git tag BEFORE git reset --hard
| BEFORE git reset --hard ORIG_HEAD git
| reflog git reset --hard HEAD@{<N>}
| tempodox wrote:
| I've had VCS operation anxiety since the days of CVS. With
| Subversion it was largely a non-issue but Git made it return
| with a vengeance. This tool will presumably calm my frayed
| nerves.
| mdaniel wrote:
| > You just have your bash prompt output the current snapshot
| number, and then can use that as the revert target if there's a
| botched rebase or so.
|
| That is what the ref-log is designed to do, but in my
| experience with git the risk is not about getting historical
| content, because git is very good about that: it's the
| _current_ operation that 's the risk
|
| If I had any advice for beginners, it'd be to commit early and
| often, because git is disciplined about managing commits, but
| is a razor blade about anything in the working copy. There is
| no ref-log for "but I just typed that..." unless you told git
| to save it in something with a sha
| DenisM wrote:
| You could also use VM snapshots to undo any damage during the
| learning process.
|
| Ironic, I know.
| psychoslave wrote:
| - Dear padawan, here is your powerful elegant lightsaber. Yes, it
| can cut the vegetables you eat on a daily basis. You can even cut
| your hands easily with it. That's why I'll teach you the art of
| forecasting most probable outcomes of your next moves when you
| are using it.
|
| - Thank you Master, finally I see the light and understand the
| the fork or chopsticks dilemma is a fallacy. Millions of jedi
| knights can't be wrong after all.
| [deleted]
| prettyStandard wrote:
| This looks fantastic!
|
| I think this is what we need more of for new git users. I
| struggled for the longest with git until I came across
| learngitbranching[0]. I believe having an interactive/visual
| experience while I typed in commands is what I needed, and what
| most people need.
|
| I tell junior developers they should take a day to learn this and
| more often than not they dismiss me. Meanwhile these people will
| run into git conflicts or something and their strategy is to
| "save their work somewhere else and redownload the repo"[1]. I
| know of a "senior developer" that will do that. I basically told
| him, in my eyes, if you don't know how to use git, you are not a
| senior. Or a bad senior at a minimum. See the stack overflow
| survey. Git is used basically by all developers. How do you
| expect to be a good developer by dismissing such a ubiquitous
| tool. I think I can make an exception for people who aren't using
| git at their current company and any company before.
|
| [0]: https://learngitbranching.js.org/
|
| [1]: https://xkcd.com/1597/
| initialcommit wrote:
| Thanks for checking it out!
|
| Would be great to get any feedback you might have if you get
| the chance to install/test it out.
| prettyStandard wrote:
| Will do!
| enriquto wrote:
| > save their work somewhere else and redownload the repo
|
| Not that there's anything wrong with that, is there?
|
| As a "bad senior developer" who uses git daily, one of the
| things that I love about git is that in the end everything is
| regular files. So there's nothing wrong with just copying your
| git repository elsewhere, re-cloning it, and fixing your fuckup
| by hand. No need to feel guilty about it.
|
| Your comment sounds like criticizing somebody that does not
| know all the keyboard shortcuts that you do.
| int0x80 wrote:
| Because most problems like merging and resolving correctly,
| or rebasing or squashing if needed don't get resolved by
| cloning a new repo. If you avoid learning the tool and you
| just clone a new repo when you have a problem you won't be
| able to do any non-trivial task in git.
| prettyStandard wrote:
| Do you understand how merge conflicts happen in the first
| place? If you are to be a senior leading others, you should
| be able to explain this to juniors so they don't shoot
| themselves in the foot.
|
| Do you disagree that it's a fundamental tool to being a
| developer(today), or do you disagree that it's necessary to
| know fundamental developer tools to be a good senior
| developer?
| maccard wrote:
| Ther'es a difference between understanding how merge
| conflicts happen, and understanding how git handles basic
| operations in order ot be able to use it effectively.
|
| > If you are to be a senior leading others, you should be
| able to explain this to juniors so they don't shoot
| themselves in the foot.
|
| Firstly, not all seniors are managers. Secondly, it is not
| a good use of a senior engineer's time to be teaching
| fundamentals to a junior developer. I am a decent
| developer, a passable manager, and a poor teacher. It's
| much better for me to point my team in the direction of
| existing tools.
|
| > Do you disagree that it's a fundamental tool to being a
| developer(today), or do you disagree that it's necessary to
| know fundamental developer tools to be a good senior
| developer?
|
| Other VCS tools exist, it's possible to have gone a decade
| in the industry as an effective developer without using
| git. Many large companies use Perforce, other companies use
| internal tools. I disagree that it's necessary to
| understand the working model of fundamental tools to use
| them. We don't require truck drivers to understand the
| difference between the Otto and Diesel cycles to drive a
| truck, why is it ok to force developers to undersatnd the
| many, many, many different operations that `git checkout`
| can perform depending on the state of your repository/what
| you've asked it to do?
| spyremeown wrote:
| This is really good!
|
| I generally have a good mental model of my repo and I try to KISS
| as much as possible, but I can see the value of this in a
| teaching scenario, for example (as well as on extremely complex
| git situations).
|
| Check out the quickstart page as well, seems to have more
| content[1].
|
| [1] https://initialcommit.com/tools/git-sim
| initialcommit wrote:
| Haha wow you posted this before I could! I created Git-Sim and
| hope that folks can get some use and value out of it. Happy to
| answer any questions anyone might have, and especially looking
| for feedback so that I can improve the tool. Also if anyone is
| interested in contributing let me know and also check out the
| project Github page:
|
| https://github.com/initialcommit-com/git-sim
| user3939382 wrote:
| It doesn't matter how much I look at them, and I get the
| reasoning, but the right->left flow orientation of VCS diagrams
| will always be disorienting for me.
| initialcommit wrote:
| You can use the --reverse flag to reverse the direction of the
| graphs in Git-Sim.
|
| However the fact that time flows in the opposite direction of
| the parent/child relationships, is inevitable based on Git's
| design.
| mpolichette wrote:
| I always have to remind myself that they're dependency arrows
| and not a sequence ordering.
|
| They make it look like it flows right to left even though time
| (or at least sequence) flows left to right.
| yeputons wrote:
| Looks great!
|
| I'm really missing support for remotes. There are lots of tools
| for local-only development (like
| https://gitexercises.fracz.com/), but very few allow to
| demonstrate stuff like "Syncing a GitHub fork with the original
| repository" which involves two remotes and three copies of the
| same branch at the very least.
| initialcommit wrote:
| This is a great point. I thought about how I could simulate
| commands like "git pull" and "git push", but like you said that
| would require communicating with the remote to determine ...
| stuff ... like what objects need to be synched, and potentially
| even doing some of the actual data transfer before an accurate
| simulation would be possible.
|
| My initial goals for this tool are to purely simulate actions
| on Git repos without actually modifying them, but I might be
| flexible on that going forward, as I mention in the article
| with the --execute flag.
| capableweb wrote:
| > simulate actions on Git repos without actually modifying
| them
|
| One way around this could be to create a new temporary
| directory in /tmp, copy .git over there and symlink the rest,
| then run whatever operation in the newly copied workspace and
| compare it with the original.
|
| Then you can mutate things however you want and the original
| stays the same.
| initialcommit wrote:
| Hey cool idea! I'll definitely consider that and variations
| on it. This could work for Pull-direction operations like
| fetch/pull, but maybe not as well for push since the remote
| would still be affected in some way.
|
| Will need to think about it more...
| jfcnotagain wrote:
| You can push to a folder too. So you can just do the same
| thing. Clone the remote into a folder and push into it.
| capableweb wrote:
| Was gonna suggest the same! I use this countless of
| times. It's really cool how you can push/pull to a bunch
| of different things, including directories, ssh hosts,
| anything that can act as a directory (network mounted
| FUSE directories) and more.
|
| Personally I use it a lot for backing up git repositories
| to a USB stick where I have a backup of every single
| repository + its branches and commits in case I ever need
| to recover from them. And I can keep my GitHub remotes
| clean without 100s of branches.
| xwowsersx wrote:
| I have always wanted something like this. Will be giving this a
| try. Nice work!
| lumb63 wrote:
| This looks promising as a teaching aide. At my previous company,
| I transitioned our project from Clearcase to Git to save us
| licensing and administration fees. Many of the senior developers,
| who had never used Git, had a hard time understanding it, and I
| spent many whiteboard sessions explaining by drawing similar
| graphs. This would give those developers more autonomy, and stop
| the "let me blow it away and start over", which would drive me
| nuts. Devs spent a lot of time and frustration performing that
| operation.
|
| I believe the core issue is devs like above never take the time
| to "grok" Git. I believe part of this is due to the lack of a
| tool like above to teach easily, but also because devs want to
| ignore the "how" of their tool working to find out the exact
| commands they need to run in their current situation.
|
| One could argue users should not need to understand how their
| tool works to use it effectively and this is a leaky abstraction.
| Others could argue some commands are not intuitive (git reset can
| do many things, and git rebase swapping ours/theirs comes to
| mind). I don't claim Git is perfect, and sometimes I need to
| Google to learn more than I wanted to, to get out of an obscure
| scenario (e.g. someone put classified intelligence into a
| repository we need to transfer to a lower classification network;
| how do I rewrite the entire history while correcting this error
| that occurred 487 commits ago?). However, understanding the tree
| structure of Git, what git rebase does under the covers, what
| branches and tags are, how remotes work, how merging works, etc.
| would go a LONG way. The folk I worked with struggled to pick it
| up.
| philsnow wrote:
| > I believe the core issue is devs like above never take the
| time to "grok" Git. I believe part of this is due to the lack
| of a tool like above to teach easily, but also because devs
| want to ignore the "how" of their tool working to find out the
| exact commands they need to run in their current situation.
|
| Github is largely to "blame" for this. It mostly only exposes
| the happy path and using git kind of like any other VCS, but
| above all it ossifies the idea of git repositories being
| centralized (both because the canonical repo is always on
| github.com but also because of the forking/ownership model). A
| lot of the power (and sharp edges, and messiness) of git are in
| scenarios where everybody has a local repo and nobody's is
| really "canonical".
|
| Git is really well-suited to development of the linux kernel.
| It's not.. amazingly well-suited for the job that 95% of people
| these days press it into?
| dev_snd wrote:
| I think that the bigger problem is the misuse of Tags as the
| sole method of marking a commit for release for example.
|
| Tags could be utilised for naming commits which would make it
| much easier to reason about where in the process of your
| development you are instead of referencing commits by hash.
| Hashes are hard to remember after all.
| bornfreddy wrote:
| Except, if you rebase, your tags get "lost" (not really,
| but they still point to the same old commit unless
| explicitly changed). Log is your friend, and making sure
| that the commits make sense (they do a single well-defined
| thing) helps a lot, because you always know which commit
| does what. But yes, that means using `git commit --fixup
| <commit id> && git -i --autosquash <commit id>^1`
| frequently to fix existing (older) commits instead of
| making new trivial ones.
| airtonix wrote:
| [dead]
| viraptor wrote:
| Why not use branches for that? That's often for people to
| it.
| cdcarter wrote:
| My company is currently transitioning from a 20+ year old
| Perforce depot to a git workflow. We're certainly having issues
| like you describe, where people don't know (and don't care to
| learn) the mechanics of git. And I agree, git is the kind of
| tool where once you understand the primitives, you can quickly
| start making lateral leaps to solve problems.
|
| But I do think that there's room for a better mechanism for
| orchestrating "macros" or building other workflows on top of
| git. I know a lot of developers who'd love the ability to
| pretend they're using p4.
| IshKebab wrote:
| Were you trying to teach them with the CLI though? That's a
| terrible approach. The CLI is awful and Git is a visual thing.
|
| It's like teaching someone to drive a car using LOGO.
|
| The way to teach Git is:
|
| 1. Explain the mental model ( _correctly_ ). Basically a commit
| is a _snapshot_ with deduplication to avoid huge file sizes.
|
| 2. Show them how to use a good Git GUI. There are a lot of bad
| ones. I would recommend Git Extensions (terrible name but it's
| actually quite good). Or maybe GitX on Mac.
|
| 3. Let them learn the CLI slowly in their own time.
| lumb63 wrote:
| I never found a GUI that was more intuitive than the CLI,
| personally. I am a bad person to consult for this, since I
| live in vim and tmux (my coworkers hid my mouse for April
| Fool's Day and I went the day without it to make a point)
| while others blaze ahead in VS Code and know the bare minimum
| command line to get their job done.
|
| I'll take a look at Git Extensions, thanks for the
| recommendation! Some of our devs took to using the
| integration with VS Code, which I didn't like because I
| didn't understand how its terminology (e.g. "sync" mapped to
| underlying Git operations). Others tried the Git GUI which I
| found very confusing.
|
| I focused on the graphical operations and then tried to show
| them what commands they could run to execute those
| operations. Next time I'm in the situation, maybe I'll adopt
| a GUI-first approach.
| bornfreddy wrote:
| My issue with gui is that sometimes I need to work with git
| in terminal, over ssh, so I need to know it. Once I learned
| it, what's the point of using a gui? [0]
|
| [0] there is one operation where gui is more convenient for
| me - exploring branches in gui or GitLab ("repository ->
| graph") has no equivalent in cli that I know of
| (interestingly, GitHub doesn't have that either, but many
| gui tools do).
| counttheforks wrote:
| Terrible advice, you should absolutely start with the
| official UI, which is the CLI. Avoiding it because "it's
| hard" will just complicate everything down the line.
| renox wrote:
| Ahem, let's avoid the over-generalisation thanks!
|
| I learned git at 45yo after many years using ClearCase (even
| licensed as CC admin) and .. I really liked learning git, I do
| admit that it took me two full days of self study to start
| groking git but I wouldn't call it 'struggling'.
|
| Obviously it depends a lot of your background.. git is the 5th
| version controls I've used , while it is far from being perfect
| (submodules.. :-( ), it's my favourite.
| andyjohnson0 wrote:
| > I believe the core issue is devs like above never take the
| time to "grok" Git.
|
| The problem I have with git us that it's just too complicated.
| When I'm juggling project complexities and design complexities
| and implementation complexities, I frequently don't want to
| have to deal with git too.
|
| I understand how to stage and check in and squash, and branch
| and merge, and how to manage remotes. But last week I still
| managed to get a new repo into a state where I couldn't push
| local changes to github without doing a pull first, and I
| couldn't do a pull without (apparently) first updating the
| remote. I had a hard deadline and ended up deleting the repo
| and starting fresh. Nothing much was lost. I never had this
| trouble with tfs...
|
| Maybe I'm just not clever enough, but I've never come across a
| dev tool with as much surface complexity as git.
|
| (Not a git hater. Use it every day. Have had a personal github
| profile for a decade. Etc etc.)
| fortran77 wrote:
| I teach git professionally. I have a 3-day 12-hour course I
| give.
|
| I'm amazed how many people who have used SVN or CVS just
| assume git works like that but with different commands. And,
| of course, they get very screwed up. (GitHub contributes to
| this problem, too, with their own set of commands like
| "forks" and "pull requests" that aren't really a part of
| git.)
|
| One you understand the Merkle DAG that's at the heart of git,
| understanding the rest is simple. Yes the commands are named
| badly, but get past that and it's a great system.
| greazy wrote:
| 12 hour days? That seems way too long. How did the
| participants handle the amount of information over the time
| period?
| fortran77 wrote:
| No! It's 12 hours over 3 days.
| [deleted]
| howinteresting wrote:
| You're not alone. Git is an embarrassment to our profession.
| SavageBeast wrote:
| Finally someone comes out and says it - I totally agree. I
| don't recall ever having to have a "tutorial" on
| Subversion. Git solves a problem the average dev really
| doesn't have in the first place.
| fortran77 wrote:
| It was painfully difficult to branch in subversion. And
| remember the agony of asking someone to check in a file
| so another developer can check it out?
| capitainenemo wrote:
| Branching was just a copy? What was so hard about that?
|
| As for check-out locks. you only had to ask them to do
| that if they'd requested a lock on the file which was not
| the default. I hope people weren't doing that too often
| at your workplace.
| howinteresting wrote:
| To be fair, Subversion had plenty of serious limitations.
| Local commits are a really good thing. It's just that Git
| itself is a terrible UI around a bunch of decent ideas.
| capitainenemo wrote:
| Sure. Absolutely but there were some benefits to its
| simple model that are still attractive for a corporate
| env.
|
| https://www.bitquabit.com/post/unorthodocs-abandon-your-
| dvcs...
|
| One of my fav rants on this subject.
| rubyist5eva wrote:
| Mercurial should have won, it's superior in every way. For
| pesonal projects I use Fossil, which is fantastic.
| crispyambulance wrote:
| I've resigned myself to accepting git because I have to use
| it. But JFC, I've hated it from the first time I tried it.
|
| We now have a large selection of tools that allow you to
| visualize what's going on (I use git-kraken), as well as
| google for help on doing something that isn't in muscle
| memory.
|
| But, really, SO MUCH pain and suffering could have been
| resolved by refactoring the damn commands to something more
| coherent and consistent. Git people sometimes call this
| "porcelain"-- which I guess is an apt name because it makes
| one think of a toilet (but an improvement to a hole in the
| ground).
| fisherjeff wrote:
| This is maybe the most cogent version of my exact feelings
| on git I've ever read. In theory, I have no issues with
| git! In practice, the UX is often very very bad.
| jacquesm wrote:
| Seconded. Git, like Linux is used everywhere, you can't
| avoid them. And even though I use it externally locally I
| use subversion, whose commands make a lot more sense to me.
| But Linus has something going for him: he knows how to
| establish critical mass for his projects, and how to create
| viable ecosystems.
| airtonix wrote:
| [dead]
| capableweb wrote:
| > I believe the core issue is devs like above never take the
| time to "grok" Git
|
| I believe the same, and it's not just a problem you see with
| git, it's all over the place. Some developers seems eager to
| use something so they just skim the documentation in order to
| do the least amount of reading and understanding in order to
| implement something, but often miss some fundamental detail and
| have to jump back. Or, they fundamentally misunderstand the
| tool at all, but push forward with their own idea what the tool
| is, rather than stepping back and start learning again.
| wpietri wrote:
| You say that like it's bad, but that's just life. We're
| trying to fit a whole universe into 3 pounds of meat. If we
| stopped to truly understand anything before taking action,
| we'd never get anywhere.
|
| That's especially true in technology, where whole armies of
| people are working to complicate things as fast as possible.
| For the best of reasons, of course. But when I started out, I
| could read one short book and have a pretty good
| understanding of my computer's processor, and from there it
| wasn't much further to understanding the whole computer. Now
| I could spend days just understanding, say, processor cache
| strategies [1]. A field that is super interesting, but if I
| am to get any of my actual work done, I can't afford to dig
| into that and the many, many other similar subtopics. I'm
| going to get a casual understanding of something, do my best
| to make something useful, and only dig in further when I'm
| forced to.
|
| When I do have to dig in, it comes in two cases for me. One
| is where there is something necessary complexity that I would
| have to learn about regardless. E.g., if something is too
| slow, I need to learn about what happens under the hood to do
| proper performance tuning. Great, fine, I will learn it.
|
| But then there's the other bucket, which includes unnecessary
| complexity, bad abstractions, poorly considered UX, and the
| like. For me, git is clearly in that bucket. I intentionally
| have very simple development flows. Git can do a great deal,
| 98% of which I not only don't need, I actively don't want.
| [2] So I'm going do my best to remain ignorant of its inner
| workings, stick with my small number of commands, and very
| occasionally refer to "Oh Shit, Git!?!" [3] And I'm perfectly
| happy with that until it gets replaced with a technology that
| better matches the domain.
|
| [1] e.g.: https://chipsandcheese.com/2022/05/21/igpu-cache-
| setups-comp...
|
| [2] An example of what I don't want:
| https://www.tiktok.com/t/ZTRpPPuKf/
|
| [3] https://ohshitgit.com/
| pdimitar wrote:
| I'm very happy to fundamentally misunderstand GIT's internals
| because I want to do a finite (and small) set of operations
| with it, not HOW it operates under the covers.
|
| Conflating the two, like you do, is elitism.
|
| "If you just stopped and read to understand...", a-ha, sure,
| I'll do that for every one of the no less than 500 tools I've
| used over the course of my career and will never get anything
| done on time.
|
| There's no time. We got real work to do and no we can't
| switch to a company that gives us this time. There's a big
| world outside the Silicon Valley.
|
| GIT is a huge UX failure and seeing people pretend otherwise
| makes me question my -- or their -- sanity.
| dbalatero wrote:
| I agree with you, but I also have the thought of "well, git
| is one of the _top_ tools of the 500 I use," so I think I'm
| a bit more inclined to fill in a few more gaps as I
| encounter them. Ultimately though if you have the right
| balance of knowledge about the tool, you can always stop
| learning more about it until you learn otherwise...
| pdimitar wrote:
| Also true, and I agree. As mentioned in a sibling
| comment, with time I kind of started loathing the idea of
| learning GIT's internals so here we are. We'll see, these
| things tend to fall away with time.
| capableweb wrote:
| You won't have to put your entire life on break in order to
| understand the fundamentals of git and why it works the way
| it works. Going through https://jwiegley.github.io/git-
| from-the-bottom-up/ and really understanding the material
| will take you a couple of hours at max, but will save you a
| lot of time in the future.
|
| Wanting to understand things before using them is hardly
| elitism, not sure why you would think that.
|
| Just like you probably don't want to fix bugs without
| understand the cause, it's hard to use a tool correctly
| unless you know how the tool works.
| maccard wrote:
| Git is one (egregious) example though; Do I need to
| understand the fundamentals of every tool that I
| use/interact with every day? That's just not feasible. If
| not, where do you draw the line? To many, git is a means
| to an end, in the same way that
| $(insert_internal_tool_here) is. Nobody expects you to
| know the details of a B-tree and an R-tree to use MySql,
| so why is it ok to expect people understand the
| implementation details of git to use centralized version
| control?
| pdimitar wrote:
| I like your analogy because it outlines the flaw of GIT:
| we have to "fix bugs" in its UX so we can get our job
| done with it. :\
|
| Also yeah, I agree learning GIT is not a huge sacrifice
| but with time I built a huge internal resistance against
| it so... dunno. -\\_(tsu)_/-
|
| Maybe I'll get to it one day, in the meantime I am OK
| relearning cherry-pick and a few others every time I need
| them. I don't know, it just doesn't make sense to me.
| Guess to this day I don't see why it had to be a graph
| DB.
| counttheforks wrote:
| Do you have an alternative tool which everyone already
| uses? No? Then stop complaining and spend an afternoon
| learning it. You'll save yourself, and everyone who is
| forced to interact with you, a massive headache.
| TylerE wrote:
| Serious Stockholm syndrome on display
| pdimitar wrote:
| The only one complaining here is you. Also this is not
| Reddit, chill.
| counttheforks wrote:
| You can either learn the tools of the trade, or you can
| go online and complain about how your hammer is too hard
| to use and so you refuse to hold it right. How is that
| not complaining?
| TylerE wrote:
| You tell the guy using a brick as hammer that it isn't
| actually a good hammer, no matter how many other people
| are also using bricks as terrible hammers. Git is a
| brick.
| arcanemachiner wrote:
| Memories of the "PHP Is A Fractal of Bad Design"
| article...
| maccard wrote:
| That's not a good analogy. A better analogy is someone
| telling you that you need to understand material sciences
| to be able to use an impact driver properly.
| counttheforks wrote:
| Can you learn material sciences in an afternoon of
| minimal effort?
| bornfreddy wrote:
| Mercurial.
|
| Also, not having another option would hardly make git
| optimal (or even good).
| counttheforks wrote:
| No, it doesn't. It does make learning it practical
| considering it's what everyone uses.
|
| If you think you can do better, please do! Let me know
| when you've gotten a few projects to switch over and I'll
| gladly learn that, too. Not a lot of projects using
| mercurial these days.
| capitainenemo wrote:
| How many projects/companies do you need? There's still a
| fair number using it.
| counttheforks wrote:
| It's insane to me how many developers simply refuse to read
| documentation or spend _any_ time at all learning the new
| tools they 're supposed to use.
| charlie0 wrote:
| How to tell apart the professionals from those who just do
| the equivalent of button mashing to get something to work.
| howinteresting wrote:
| This is all Stockholm syndrome. Git has a lot of random
| accidental complexity, from reset and checkout doing too
| many things (yes I'm aware of switch and restore), to
| stacks being a pain to work with. The idea that you're
| supposed to just be in the middle of an interactive rebase
| most of the time is mind-boggling.
|
| A better thing to say is "yeah we've been saddled with this
| horrible tool, yeah we know it sucks, but it'll suck a bit
| less when you learn it. Oh and sorry if you're not a
| professional developer and have to use git, I hope we can
| do better next time."
| counttheforks wrote:
| Yes, we all know it has some rough edges and could be
| more convenient. Unless someone actually makes that
| idyllic more convenient tool and it becomes widespread,
| none of that matters. We're stuck with the hammer that
| everyone else is using. No sense refusing to learn how to
| use it just because you're stubborn, everyone else
| managed just fine.
| bornfreddy wrote:
| Well no, that's not the case. In fact many projects
| (gitless for example) clearly show that a consistent UI
| for git _is_ possible, but unless git developers decide
| to rework the tool completely, we are stuck with what we
| have. And no, using a 3rd party tool and convincing every
| team that gitless is better is simply not going to
| happen. The way out is for someone to swallow their
| pride, admit they did a half-assed job and fix it. Not
| holding my breath though.
|
| I say that as someone who uses git daily, who has learned
| git internals, who uses cli almost exclusively, who helps
| the teammates out of their git problems and who still
| hates the cli inconsistencies.
| initialcommit wrote:
| Yes much agree!
|
| A big reason I wanted to pursue this idea is exactly what you
| mentioned - a lack of ability to easily create presentation-
| quality Git structures that can apply specifically to the
| situation a user is in, NOW.
|
| A super annoying thing about troubleshooting Git issues is when
| you find a similar solution online but it's done in someone's
| random repo which could be very different that yours. Your
| whiteboard sessions are another good example down this line of
| thought.
| NeutralForest wrote:
| Git is an amazing tool with terrible UX. It's very difficult to
| know what the right thing to do is and the mental model is a
| bit weird. For example, undoing an operation is another, new
| commit.
| mooneater wrote:
| Its... cool?
|
| Alternative would be: clone the repo, do your changes, run gitk
| to be sure.
|
| Which has advantage that result looks _exactly_ the same as it
| will in production (no new diagram type b /c only using git and
| gitk), with zero risk that sim differs from reality.
| initialcommit wrote:
| Ew clone a repo to simulate a command?!
|
| Hehe jk you make a fair point, and in fact I do have a bunch of
| work left to do to make sure my simulations do match up with
| Git's behavior as closely as possible.
|
| One big benefit I was going for with Git-Sim though is to
| interrupt the developer workflow as little as possible.
|
| Changing directories, running a new clone (which could take a
| mildly annoying amount of time), and running gitk is a pretty
| big context-switch.
| xwowsersx wrote:
| I tried to get manim and its dependencies installed and ran into
| some issues: error: subprocess-exited-with-error
| x Building wheel for manimpango (pyproject.toml) did not run
| successfully. | exit code: 1 +-> [27 lines of output]
| Error in sitecustomize; set PYTHONVERBOSE for traceback:
| AssertionError: running bdist_wheel running
| build running build_py creating build
| creating build/lib.macosx-13-arm64-cpython-310 creating
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/_version.py ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/__init__.py ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/utils.py ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/cmanimpango.pxd ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/cairo.pxd ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/register_font.pxd ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/pango.pxd ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/glib.pxd ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/enums.pyx ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/register_font.pyx ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| copying manimpango/cmanimpango.pyx ->
| build/lib.macosx-13-arm64-cpython-310/manimpango
| running build_ext building 'manimpango.cmanimpango'
| extension creating
| build/temp.macosx-13-arm64-cpython-310 creating
| build/temp.macosx-13-arm64-cpython-310/manimpango clang
| -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common
| -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot
| /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
| -I/opt/homebrew/opt/openssl/include
| -I/opt/homebrew/Cellar/pango/1.50.12/include/pango-1.0
| -I/opt/homebrew/Cellar/harfbuzz/6.0.0_1/include/harfbuzz
| -I/opt/homebrew/Cellar/pango/1.50.12/include/pango-1.0
| -I/opt/homebrew/Cellar/glib/2.74.5/include
| -I/opt/homebrew/Cellar/fribidi/1.0.12/include/fribidi
| -I/opt/homebrew/Cellar/harfbuzz/6.0.0_1/include/harfbuzz
| -I/opt/homebrew/Cellar/graphite2/1.3.14/include
| -I/opt/homebrew/Cellar/cairo/1.16.0_5/include/cairo
| -I/opt/homebrew/Cellar/glib/2.74.5/include
| -I/opt/homebrew/Cellar/glib/2.74.5/include/glib-2.0
| -I/opt/homebrew/Cellar/glib/2.74.5/lib/glib-2.0/include
| -I/opt/homebrew/opt/gettext/include
| -I/opt/homebrew/Cellar/pcre2/10.42/include
| -I/opt/homebrew/Cellar/pixman/0.42.2/include/pixman-1
| -I/opt/homebrew/Cellar/fontconfig/2.14.1/include
| -I/opt/homebrew/opt/freetype/include/freetype2
| -I/opt/homebrew/Cellar/libpng/1.6.39/include/libpng16
| -I/opt/homebrew/Cellar/libxcb/1.15/include
| -I/opt/homebrew/Cellar/libxrender/0.9.11/include
| -I/opt/homebrew/Cellar/libxext/1.3.5/include
| -I/opt/homebrew/Cellar/libx11/1.8.3/include
| -I/opt/homebrew/Cellar/libxcb/1.15/include
| -I/opt/homebrew/Cellar/libxau/1.0.11/include
| -I/opt/homebrew/Cellar/libxdmcp/1.1.4/include
| -I/opt/homebrew/Cellar/xorgproto/2022.2/include -I/Library/Develo
| per/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/ffi
| -I/opt/homebrew/Cellar/pango/1.50.12/include/pango-1.0
| -I/opt/homebrew/Cellar/harfbuzz/6.0.0_1/include/harfbuzz
| -I/opt/homebrew/Cellar/pango/1.50.12/include/pango-1.0
| -I/opt/homebrew/Cellar/glib/2.74.5/include
| -I/opt/homebrew/Cellar/fribidi/1.0.12/include/fribidi
| -I/opt/homebrew/Cellar/cairo/1.16.0_5/include/cairo
| -I/opt/homebrew/Cellar/pixman/0.42.2/include/pixman-1
| -I/opt/homebrew/Cellar/libpng/1.6.39/include/libpng16
| -I/opt/homebrew/Cellar/libxcb/1.15/include
| -I/opt/homebrew/Cellar/libxrender/0.9.11/include
| -I/opt/homebrew/Cellar/libxext/1.3.5/include
| -I/opt/homebrew/Cellar/libx11/1.8.3/include
| -I/opt/homebrew/Cellar/libxcb/1.15/include
| -I/opt/homebrew/Cellar/libxau/1.0.11/include
| -I/opt/homebrew/Cellar/libxdmcp/1.1.4/include
| -I/opt/homebrew/Cellar/glib/2.74.5/include
| -I/opt/homebrew/Cellar/harfbuzz/6.0.0_1/include/harfbuzz
| -I/opt/homebrew/Cellar/graphite2/1.3.14/include
| -I/opt/homebrew/Cellar/glib/2.74.5/include/glib-2.0
| -I/opt/homebrew/Cellar/glib/2.74.5/lib/glib-2.0/include
| -I/opt/homebrew/opt/gettext/include
| -I/opt/homebrew/Cellar/pcre2/10.42/include
| -I/opt/homebrew/Cellar/fontconfig/2.14.1/include
| -I/opt/homebrew/opt/freetype/include/freetype2
| -I/opt/homebrew/Cellar/xorgproto/2022.2/include -I/Library/Develo
| per/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/ffi -I/opt/hom
| ebrew/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/i
| nclude/python3.10 -c manimpango/cmanimpango.c -o
| build/temp.macosx-13-arm64-cpython-310/manimpango/cmanimpango.o
| clang: error: no such file or directory:
| 'manimpango/cmanimpango.c' clang: error: no input files
| error: command '/usr/bin/clang' failed with exit code 1
| [end of output] note: This error originates from a
| subprocess, and is likely not a problem with pip. ERROR:
| Failed building wheel for manimpango Building wheel for srt
| (setup.py) ... done Created wheel for srt:
| filename=srt-3.5.2-py3-none-any.whl size=22467 sha256=ef7a967b7b3
| 225064d5e8eecf84934ec066e759d288fcddbe104d26954b1df35
| Stored in directory: /Users/me/Library/Caches/pip/wheels/2b/4a/52
| /216182e898297499cfe0947127f551712c4169ea2e69bcf9d7
| Successfully built click-default-group srt Failed to build
| manimpango ERROR: Could not build wheels for manimpango,
| which is required to install pyproject.toml-based projects
|
| I'm not sure what the underlying problem is here. Anyone have any
| ideas?
| xwowsersx wrote:
| I installed a later Python with pyenv and was able to get this
| to work.
| initialcommit wrote:
| Ah good! Glad to hear it. I had some issues when trying to
| install it on Mac's using the system Python. Switching to a
| homebrew-installed version of Python >3.7 worked for me in my
| testing.
|
| But glad you got it working too!
| garganzol wrote:
| This is why I'm in love with Mercurial. It has a very simple
| mental model which is not far from Git, but Mercurial's commands
| and presentation are so much more comprehensible.
| DenisM wrote:
| Do you know of a GitHub equivalent for Mercurial? Bitbucket no
| longer supports hg. :/
| ezst wrote:
| There's also Heptapod: https://heptapod.net/
|
| > Heptapod is a community driven effort to bring Mercurial
| SCM support to GitLab(tm), started by Octobus, a company
| providing professional services around Mercurial.
| stefncb wrote:
| There's sourcehut, though it's quite a paradigm shift from
| github.
| dgfitz wrote:
| Every time I see a thread like this I echo the same sentiments.
| It's not hard to grok how hg works, git adds more mental cycles
| which just take away from solving the actual problem at hand
| initialcommit wrote:
| Nice I need to find some time to actually sit down with
| Mercurial for a nice summer afternoon
| skulk wrote:
| I want to pile on here; I switched to Mercurial for some
| projects and didn't think much of it (had to look up
| equivalents of some git commands here and there). However,
| after 2 years of that, coming back to git made me feel like a
| total newbie. I recently got myself into a detached HEAD
| state and felt like I was groping in the dark with "git
| reset". I never had this issue with mercurial, even with
| weird botched evolve/content-divergent states.
| badpromptngnir wrote:
| Trying to install it right now and wow it is taking some time.
| Running 'brew install Pango scipy' is taking more than 5
| minutes(still counting). I knows its a one time process but
| still. The number of dependencies can be reduced I guess.
| initialcommit wrote:
| Hey there fellow Mac user! And thanks for testing it out - were
| you able to get it installed or is it still chugging along?
|
| Yes I feel your pain with Homebrew which can take forever just
| to check for updates on installed packages, before it even gets
| to installing anything new.
|
| I know the current installation method of having to first
| install Manim's dependencies is not ideal, but in most of my
| testing it was relatively painless.
|
| However going forward I am going to be looking for ways to make
| it a single install instead of various steps that differ across
| platforms.
| badpromptngnir wrote:
| Yes, i am testing it now.
|
| So far seems good, initially i was getting some very slow
| animation times but adding the `--low-quality` flag seems to
| work well.
|
| I am planning to do an internal session in my company on Git,
| and will be using this tool to help them visualise some of
| the concepts :)
| initialcommit wrote:
| Sweet! Yeah the slow animation is a Manim performance
| limitation, I think (hope) their community is working on
| improving that.
|
| Yes --low-quality works for testing but the fastest way
| would be to first test without the --animate flag at all,
| so you just get a final image of the command's effect.
|
| Then once you get that you can add the --animate flag to
| generate your final video to share.
|
| And awesome to hear it will be used for your company
| session! I love teaching people about Git. Feel free to
| share the tool with them so they can try it out as well!
| jerpint wrote:
| I saw the video and instantly recognized the manim style, it
| looks great!
| initialcommit wrote:
| Manim rocks.
| eurasiantiger wrote:
| The animation would be clearer if there was also an annotation of
| what was happening at each moment.
| initialcommit wrote:
| Interesting thought - do you mean like a line of text that
| displayed above that verbally described what's happening?
|
| I was considering adding some more detailed text-based output
| on the command-line detailing what was going on, but I didn't
| think about adding it directly into the image/video.
| jerpint wrote:
| I think it would be helpful in the blog post to list the
| series of changes happening to the files before the
| animations
| initialcommit wrote:
| Good suggestion, I will add that.
___________________________________________________________________
(page generated 2023-01-22 23:00 UTC)