51–60 of 119 posts
Earlier quoted context omitted.
GitButler will literally not work when you use raw git, or other tools.
It works fine. The only thing that is a problem is “branch” and “commit”, things that use the index. But that makes sense. If you have setup two virtual branches and then from the cli run “git commit”, which branch do we commit to?
AI generated commit messages are horrible. I'm not opposed to them in principle, but currently every implementation I have seen uses the code change itself as the context to generate the message. This is just wrong. Commit messages are there to convey information that's explicitly not contained in the code itself and shouldn't just repeat or summarize the code changes (that's what the diff is for). They should contain the reason why the code change was made in the first place, approaches that were considered and did not make it into the code change, etc. Short everything that's not contained in the diff.
AI commit message generators incentivize people to write the wrong type of commit message.
Earlier quoted context omitted.
Im not following you. What do you mean by “don’t use other tooling”?
> Quick warning. You cannot use both GitButler virtual branches and normal Git branching commands at the same time, you will have to "commit" to one approach or the other. & see the description of 'the integration commit' for some detail of how they make it work: https://docs.gitbutler.com/features/virtual-branches/integra... Basically anything you do with `git` (or another GUI) will get blown away by GitButler; or i…
With that said, the tool is very cautious not to mess with any existing branches. This is the very reason it operates on a separate integration branch. Switching between the "special/integration" branch and any other branch is also not an issue.
Earlier quoted context omitted.
> Quick warning. You cannot use both GitButler virtual branches and normal Git branching commands at the same time, you will have to "commit" to one approach or the other. & see the description of 'the integration commit' for some detail of how they make it work: https://docs.gitbutler.com/features/virtual-branches/integra... Basically anything you do with `git` (or another GUI) will get blown away by GitButler; or i…
You can switch back and forth rather easily. But if you have multiple branches applied, some git commands wont make any sense.
> But if you have multiple branches applied, some git commands wont make any sense.
Sure, because of the way it's implemented. But that's just a variation on what I said really - I like the idea, see value in automating some management so that I can see & work on something that's the amalgamation of multiple branches, but I don't want to (have to) go 'all in' on some third-party tool, it needs to work like an extension of vanilla git for me, so everything else can keep working as normal.
It needs to be implemented in 2D so that git CLI can still understand, to put it in the docs' terms.
Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…
You do not necessarily need to modify and restore your branch head just to push in this case. If you have e.g. two temporary commits at the top of the branch, you can use e.g. "git push origin HEAD~2:master" to skip those commits when pushing.
Earlier quoted context omitted.
GitButler will literally not work when you use raw git, or other tools.
It works fine. The only thing that is a problem is “branch” and “commit”, things that use the index. But that makes sense. If you have setup two virtual branches and then from the cli run “git commit”, which branch do we commit to?
Earlier quoted context omitted.
> Quick warning. You cannot use both GitButler virtual branches and normal Git branching commands at the same time, you will have to "commit" to one approach or the other. & see the description of 'the integration commit' for some detail of how they make it work: https://docs.gitbutler.com/features/virtual-branches/integra... Basically anything you do with `git` (or another GUI) will get blown away by GitButler; or i…
This limitation stems from the fact that GB introduces an additional dimension of versioning on top of Git. One way of thinking of what it does with virtual branches is like "multiplexing" multiple branches onto the same working directory. On the way out they get "demuxed" into plain git trees. With that said, the tool is very cautious not to mess with any existing branches. This is the very reason it operates on a s…
Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…
Though stated differently, it's exactly the same thing: https://stackoverflow.com/questions/76717374/how-do-i-keep-a...
A somewhat related but inexact match is when you want to ignore changes to some files (e.g. I sometimes vary some test code locally and don't really want that to be exposed to others) for which I found a convenient fix on SO and compiled into an answer https://stackoverflow.com/a/70075113/3858681
Earlier quoted context omitted.
You can switch back and forth rather easily. But if you have multiple branches applied, some git commands wont make any sense.
Sorry I didn't realise you worked on GitButler when you asked. > But if you have multiple branches applied, some git commands wont make any sense. Sure, because of the way it's implemented. But that's just a variation on what I said really - I like the idea, see value in automating some management so that I can see & work on something that's the amalgamation of multiple branches, but I don't want to (have to) go 'all…
Basically all your virtual branches also live in refs/gitbutler/[name] and GB won't touch stuff in refs/heads/ because we like the idea of making sure we're not clobbering things you don't expect us to. You can just think of GitButler as a tool for managing refs/gitbutler branches.
All git tooling work totally fine, even generally if you're using something (like commit) that doesn't really make sense in the context of multiple branches.
Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…
That said even without GitButler you can improve it a bit: you can `git push HEAD^:` rather than 'temporarily rewinding the branch to remove them'. You could also consider just never committing it, stashing the changes if you really needed them out of the worktree, and if they're whole new files adding to `.gitignore`.