111–119 of 119 posts
Edit: I now realize much (most?) of this already exist as part of the temporarily hidden Timeline feature in GitButler: https://docs.gitbutler.com/features/timeline Now we just need automatic (possibly virtual[1]]) commits that get created whenever one does a refactoring or other wide, sweeping tool assisted changes and soon my skills as dev archeologist would either become less valuable (because everyone can see wha…
I would need a concrete case. Maybe how I am working on five different “features” that all depend on each other, maybe serially. And how I can work with a pull request (forge) somewhere and get those merged and at the same time get those virtual branches updated and managed for me. Or at least that’s what I imagine that this is about. Also how existing solutions (there are many of them) fall short or have different tradeoffs.
PS: Including “git butler” in the title... would have been useful.
Intellij IDE support this through changelists. UPDATE: add link to documentation https://www.jetbrains.com/help/idea/work-on-several-features...
1. Not part of Git at all—not committed
2. Can’t be shared because, duh, not part of Git
That sounds like a fail to me. The whole point of using Git commits is that once committed, it’s just there. And things can be shared. The point of collaborative version control.
I can manage multiple changes at the same time—that’s the index, e.g. selectively apply changes to commit in Magit. I can commit and shuffle things around—that’s rebase, cherry-pick. I can push and pop commits with some third-party stack management tool that integrates with Git.
In other words: I can use Git or I can use Git + whatever rinky-dink non-database patch management (?) tool that Intellij (IDEA) has implemented. One tool is simpler than two.
This feels like we’re back in 2002 and having to use a patch management system on top of the rigid centralized VCS in order to get some local freedom. But we already have that…
But Intellij’s thing is probably more nimble for managing a lot of unrelated things at the same time. Not that I want to do that though because of increased chances of merge conflict and just the sheer brain-overhead of it all.
If you need to change to an older commit and avoid the thrashy, unreliable indexing of Intellij (IDEA): use git worktrees.
I'm very unclear why this "takes over" the git repository to work. Like even if that was absolutely necessary - and who am I to say it's not - ...surely the "actual" repository can simply live somewhere else and be manipulated? How do virtual branches differ so completely that managing them isn't just a bunch of behind the scenes checkout/commit commands being issued to another repository somewhere, even if the local…
There's a lot here that is a little confusing, because I don't think almost any of what you're saying is what we're doing. It does not take over your repository. We try pretty hard to not touch as much as possible. We do have a second place where we store metadata on everything we're doing, but it's not in your git repo. If you delete us, your repo is only very minimally added to. We can't do virtual branches by wrap…
After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees. What's the advantage of a tool like this over that?
It's a good question, I was just working on a blog post - both because worktrees are very cool and also because I think we have a nice alternative to a similar issue. With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts. Th…
With clones you have to fetch everything N times. You have to gc everything N times. You have to do `git config --local` N times if the config matters/affects all clones. If you need a local branch in two clones you need to synch. between them. The repository needs to be managed, which means that every clone needs to be managed. With a worktree there is nothing extra to manage.
And when you’re done you remove it via the subcommand and it’s gone.
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…
I think this tool would help that, because you'd stick your only-makes-sense-for-you changes on `my-eyes-only` branch; that branch would always be in your 'integration' commit, along with whatever other 1+ branch(es) you were working, and you'd just only push the latter. 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'.…
I think that this could all be done using real branches, plus an integration branch with post-commit hooks to backport each commit onto the "default" branch and recreate the octopus merge "integration" commit each time. Would that work, or am I missing something?
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…
As you describe, just maintaining a branch that regularly gets rebased onto the latest upstream using only git's inbuilt tools also works. I do that, it's a good enough solution when keeping the history of old branches by merging them into a "patch queue history" branch before rebasing so they don't get lost.
Yet, I feel a much better gui tool to support this workflow is both possible and desirable. I totally agree with the venerable schacon in that regard. So whenever I learn of a new git gui tool I get excited and hopeful.
I actually started a tool some 15 years ago, with the vague hope I could one day open source it, or at least show it around so that others can take the good ideas and run with them to implement in their tools. Unfortunately I never had enough time to move it forward beside my day job.
15 years ago I built atop mercurial queues with a Mac gui. Of course a proper tool should be built on top of a cross-platform gui and libgit2. I can't do much at the moment, but I still hope one day someone will build on my ideas or come up with better ones.
> By default, everything in the GitButler client is free to use, but we credit ourselves as the committer in your virtual branch commits. Community members and supporters of GitButler can turn this off. This is a non-starter, sorry.