[Nullabillity]

This seems like an incredibly poor idea to me. You now have the problems of rebase (your commits no longer represent a consistent repo snapshot), but even worse (your commits _never_ represented a consistent repo snapshot!).

Is there a way to identify commits made by GitButler? Can I configure my host to reject them automatically?

And the "generate a commit message for me" button really nails the kind of poor decisions that lead here.

[videlov]

I think there may be a misunderstanding here. While the tool does something unorthodox locally, the output that it generates is plan Git trees that do represent a consistent snapshot. It is the process of arriving at those snapshots (locally) that we feel we can make more ergonomic. Disclaimer: I am a Co-founder

[Nullabillity]

> While the tool does something unorthodox locally, the output that it generates is plan Git trees that do represent a consistent snapshot.

Yes, they're snapshots of something, but they're not snapshots of states that you were ever in when developing or testing.

If you develop PRs A and B together then you have no idea if there's a hidden dependency between them, because you only ever tested (A+B). This is risky but manageable if they are actually related changes. Things get worse with the suggested workflow of "work on A, find bug, create B and submit bugfix, then go back to A".

And worse, you don't even have a clue which point in A matches up to which point in B. The history that you do generate ends up being effectively worthless.

Saying that you generate snapshots is like saying that RAM is just a linear array. Sure, you can read it, but the meaning is completely lost without context.

[schacon]

GitButler creates normal Git commits and trees with libgit2. It's not dissimilar to using a tool that implements it's own interactive adding or something. The point is that Git is the database and Git hosts (such as GitHub) matter in our workflows, but actually creating the trees that represent the trees you want to share can happen in any way. We are changing how to conceptualize and execute how to get the trees you want, but the output is Git objects.

[Nullabillity]

Sure, you can do stupid crap with the git CLI.

But scaling up the magnitude of that crap, turning into it into a headline feature, and making it easier to forget that you're doing it in the first place doesn't address why it's a bad idea or help the situation at all.

Or to relate it to another feature: yes, git supports rebasing. That doesn't mean that it should be a regular part of your workflow, or that it would be a good idea to build a new UI on top that focuses on it.

[seba_dos1]

You seem to have a poor understanding of what git does and how to use it to work effectively. It's a versatile tool that accommodates various workflows, even ones that are radically different from yours.

It's fine, everyone started from scratch at some point and it takes time to get there, but meanwhile you probably should be more open to a possibility that when someone does things differently than you, it may not necessarily be "stupid crap".

[seba_dos1]

Commits always represent a consistent repo snapshot (it's what they actually are technically), and they don't have to represent a snapshot of your worktree at all even when using plain standard client with `git add`, so not sure what's your point there.