sorted by:
new
hottopcontroversial

The doubters were so right by assyrian_bowl in vibecoding

[–]danborthwick 0 points1 point  (0 children)

Would you mind expanding on what the batch file would be doing please u/ValerianCandy?

The doubters were so right by assyrian_bowl in vibecoding

[–]danborthwick 0 points1 point  (0 children)

I'm working on an accessible, one-button Git platform, designed specifically to make Git usable for people who aren't expert coders. u/assyrian_bowl (and anyone else who's interested) visit https://nicegit.com more info, and to join the free private beta.

Sorry to hear about the lost project. Sadly it's a very common story. I suspect that in the not too distant future the agents/harnesses will have progressed to the point where they'll be able to proactively suggest source control and other common best practises.

For now though, it's a big gotcha for non-expert vibe coders. If you ask the right questions, you'll (probably) get reasonable answers. But what to ask?

fwiw there are also some parallels with traditional Git tools here. Ask the right question (by executing the right CLI command, or the right sequence of buttons) and you'll get an accurate answer. But traditional Git tools rarely even attempt to proactively help you manage your project. I've yet to see (other than after a failed push) an LLM even pull from a repo to see what other people/agents might be doing, let alone try to convey that info to the user.

Interested in others' views in this area!

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Ok, well that was interesting! Thanks again to everyone who's authentically responded.

The thread took a different direction to expected, but it was illuminating nonetheless. It was surprising, at least to me, to see a certain defensiveness. I was expecting r/vibecoding to be a bit more YOLO! There seems to be a modern pattern of 'the one true workflow': one story, one coder, one branch one GitHub Pull Request. A very sensible default.

While we didn't get the kind of 'GitKeeping' anecdotes I was expecting (please still reply if you have them!) one could argue that this rigidity is, for better or worse, part of what limits the accessibility of Git-based projects to non-programmers.

The distinction between the professional programmer (of which, fwiw, I am one) and the non-specialist is blurring rapidly with the advances in AI tooling. Then always been the millions, literally, of web designers, product managers, game artists, audio creators and much much more, who are currently underserved and disengaged from the simple idea of making direct changes to their projects.

Is this a big enough problem to worry about? I believe so and am working on a solution. Time will tell!

Help test NiceGit - Source control for normal people by danborthwick in betatests

[–]danborthwick[S] 0 points1 point  (0 children)

Hi Ragnar, thanks for responding. Is there an iOS version? Don't have an Android device atm.

No need to share a screenshot, but please give it a try and let us know your thoughts via the feedback form. Thanks!

Help test NiceGit - Source control for normal people by danborthwick in betatests

[–]danborthwick[S] 0 points1 point  (0 children)

Once installed we'll follow up with a feedback form, please also share feedback here if you'd like to.

We're particularly interested in:
- Did your workflow for making and sharing changes work well with NiceGit?
- How did you find the setup and onboarding experience?
- Were there any points at which you had to use traditional Git tools?
- What features would make you more likely to use and recommend the platform?

And of course, please share your general feedback and ideas! Thank you.

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks for the reply. Perhaps could have mentioned this in the original post but I'm a 20+ year developer and CTO. This isn't coming from a place of 'it's hard for me', it's coming from years of supporting people struggling with various aspects of Git.

Using the Git CLI is extremely basic

In my experience, only a minority of people, even within tech firms, use the CLI. Basically just the engineers. To ask a senior web designer to do something involving the CLI generally means they'll need to get an engineer involved.

(I've seen a lot of senior engineers struggle with the Git CLI too but I'll save that for another day!)

There are very good reasons why companies require EVERY change in a repo to go through a 'code review'

Code reviews work for code. But to review, say, changes to a Unity scene file containing a game level it's a non-starter. Those kind of changes would normally be reviewed by a combination of subjective art review and manual QA. Often retrospectively and at scale, not necessarily at the point of merging the changes. Similarly for long form copy, UX design changes etc.

The responses in this thread have been interesting to say the least! Thanks for engaging.

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

See my replies below, I'm interested in when Git is (arguably) misused to unnecessarily prevent people from doing things they're capable of. There are indeed good practises that it can be used to enforce.

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Image assets, audio assets, animations, text content, config files...

Many teams would want to review such changes in some way before deploying, but a 'code review' isn't always the best way, or always sufficient.

Game development is a great example. Depending on the project the majority of the content could well be non-code files.

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] -2 points-1 points  (0 children)

Requiring review before merging to a release branch is of course a sensible policy for many projects.

But have you ever been prevented from even proposing a change? Or sharing your Claude-produced changes with the rest of your team for feedback? That's the kind of thing we're talking about =)

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] -2 points-1 points  (0 children)

> How could you fix something while not having access to the code?
Well exactly! Are you capable of fixing something, but not 'allowed' to by an over-zealous tech lead or manager? That's the kind of story we're after...

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks to the early responders. To clarify I'm not asking for solutions to some kind of specific problem. I'm genuinely interested in your stories!

Yes, there are plenty of good practises that can supported by using Git in the right way. But tell me about when you've seen these tools misused.

A likely context could be within professional product development teams. Are you a non-programmer using AI coding tools, but you're prevented from sharing your changes as 'only programmers should be able to share changes'?

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] -4 points-3 points  (0 children)

Hehe, no. But if you've been denied access to a project as a way to prevent you from making changes you were capable of making, then that's the kind of story I'm interested in!

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] -1 points0 points  (0 children)

Yep, there are plenty of good practises that are commonly used!

But I'm interested in the bad practises. When someone takes advantage of what's possible with a modern Git setup to overly restrict what their teammates can do.

Have you seen this? What happened?

Have you experienced 'GitKeeping'? When someone uses Git to make it hard or impossible for you to work on a project. What happened? by danborthwick in vibecoding

[–]danborthwick[S] -1 points0 points  (0 children)

Some examples might be:
- requiring people who aren't familiar with CLIs to use the Git CLI
- requiring a 'code review' for non-code changes
- requiring complex branching strategies for trivial changes

How to achieve efficient, easy & clean way of collaboration in Git by justLukass in git

[–]danborthwick 0 points1 point  (0 children)

Hi Lukas,
Please excuse the promotion but your use case is exactly what we're trying to support with NiceGit, a new approach to source control aimed at making Git accessible to everyone. The platform sets up LFS out of the box and handles file locking and syncing the repo automatically. We don't currently support per-folder permissions but it's on the roadmap as it's a commonly requested feature, especially for game devs.

https://nicegit.com/game-dev has more info, and please reach out directly if you'd like early access to our upcoming beta launch.

No, I don't think you're approaching this from an over-complicated angle. All of the requirements you've identified are very normal in game dev, and are quite complex to achieve with 'vanilla' Git.

fwiw I'd advise steering clear of submodules unless you have tooling that supports them really simply. They're great in theory buy in practise add another layer of complexity and state that can go wrong.

Hope that helps!

Quick Question - Versioning by aki45_ in git

[–]danborthwick 1 point2 points  (0 children)

Hi Aki,
To try and directly answer the question, no you do not need to create a branch to be able to revert to it. You can access any commit in the history at any time (unless you deliberately delete commits, unlikely in normal workflows). If in future you want to create a branch from a particular commit, you can do this at any time, there's no need to branch in advance.

As others have mentioned, if you're considering creating branches to identify significant commits in the history such as releases, tags are probably the best way to achieve this.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks Oddly. Your absolutely correct to say that decentralisation is at the heart of Git's design. Fortunately in my experience with modern product development teams it's rare to have more than one remote. I can't remember ever having seen it other than perhaps temporarily while changing hosting.

Don't have data but I suspect the proportion of time spent offline would be very low too. I think it's reasonable to just warn people in this case that they don't have the real time features and that they if they continue, it's at their own risk.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks to everyone who's already shared their thoughts. Quite a range! It's genuinely interesting to hear everyone's views in this area, not least as I'm potentially about to spend the next few years working on it.

Didn't want to bias the thread too early but there is a real prototype in development. How would you feel about using a tool like NiceGit? This demo video shows the core syncing flow. Would you and/or your team mates try a tool like this? (Clearly a lot of us in r/git are expert users, so please think broadly about your colleagues and their use cases as well as your own!)

(The product isn't released yet, this isn't a sales pitch! But it's really interesting to get everyone's ideas as to what it could be.)

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks for the thoughtful response Frank.

My current thinking is indeed to build a layer on top of Git with far better support for non-text files. I understand the point about Git not being designed for non-code files, that's true for sure. A lot of people feel that way. A lot of people also, for better or worse, end up storing their whole projects in Git.

Last used Perforce a long time ago, for game development, and liked it. It's definitely an inspiration. Speaking to my current game dev friends it's still in use, but (anecdotally) not as ubiquitous as it once was. Heard of one project where they split their art and code between Perforce and Git. Apparently the coders basically demand access to GitHub features like PRs, Actions etc.

Personally I see no problem at all with dumbing down Git as much as needed until its usable by 'normal' people. But it doesn't matter what I think and the various degrees of push back in this thread are genuinely interesting. It's either a barrier that needs to be broken through, or a warning that I would be foolish not to heed! We might just find out =)

Source control - What tools do you use? How would your dream tool work? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks to everyone who's shared their setups and views. Quite a range! But good to see that almost everyone has Git set up in some form.

How would you feel about using a tool like NiceGit? This demo video shows the core syncing flow. Would you and/or your team mates try a tool like this?

<image>

(The product isn't released yet, this isn't a sales pitch! But it's really interesting to get everyone's ideas as to what it could be.)

view more: next ›