Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Git client for simultaneous branches on top of your existing workflow

gitbutler.com

Post reply on HN
Print view View original

91–100 of 119 posts

Re: A Git client for simultaneous branches on top of your existing workflow

#91

Post by Nullabillity »

videlov wrote: post #17
Nullabillity wrote: post #16

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 decisio…

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

> 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.

Re: A Git client for simultaneous branches on top of your existing workflow

#92

Post by Nullabillity »

schacon wrote: post #18
Nullabillity wrote: post #16

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 decisio…

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…

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.

Re: A Git client for simultaneous branches on top of your existing workflow

#93

Post by swozey »

bvrmn wrote: post #84

As usual couldn't recommend stacked git [1] enough. If you prefer CLI it greatly reduces cognitive load about branches/rebases especially if your work with review server allowing to see changes between force pushes (gitlab, gerrit). [1]: https://stacked-git.github.io/

The idea with this seems to be - I'm working on a branch and can't easily switch right now to put out a patch, or MY current branch HAS the patch and I want to push that out before the entire branch is ready so I make the stg commits and pushes and that patch is released.

In their example [1] at the very end they commit --all of their patches into the main patch and I guess merge that into main.

I'm kind of confused on the commit --all part. If you're putting out single patches like stg committing your current file, what benefit do you get by making multiple patches, not pushing them to main immediately, but holding them as a patch series until you're done to then merge all together? Is it mostly for the developer to keep track of X change = Y patch while you're fixing multiple things?

Like, I'm in a branch right now that unfortunately I've got 3 patches doing different unrelated things. But the changes are in a lot of the same files, so to use this patching I would have to pull out the other 2 patches in the same file, stg commit the one patch, then add patch 2, stg commit patch 2, etc that eventually just commit --all into the same file but are now identifiable by X change = Y patch?

Definitely a lot easier if had I had started out using this and stg committed patch 1 before writing patch 2 and 3.

Am I right about all of this or missing anything, or completely off? I wrote it in another comment but I deal with a lot of massive infrastructure changes where one push is deploying basically entire datacenters of load balancers and clusters, etc. a LOT of files are modified at once, so I'm in repos for a WHILE until I do my push and it makes it very hard for me to switch branches if I need to hop around real quick, I'm super apprehensive about stashing and changing branches in the middle of big PRs but I really couldn't explain why. I always worry I'm going to lose something or forget about the branch, etc.

I could definitely patch on things like, "This patch adds the loadbalancers and routing, this patch adds the cluster, this patch adds the security."

[1] https://stacked-git.github.io/guides/usage-example/

Re: A Git client for simultaneous branches on top of your existing workflow

#94

Post by thesh4d0w »

It's really confusing to have a windows logo underneath the download link, but then no download for windows.

I guess that windows icon is supposed to be grayed out, but all 3 icons are shades of gray so it's not obvious at all until you mouse over it and see "coming soon".

Re: A Git client for simultaneous branches on top of your existing workflow

#96

Post by Night_Thastus »

radarsat1 wrote: post #34

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…

Stash?

That's what I do, in any case. If I have a few various small configurations I want to carry around, I stash them when I need to swap branches and then pop them off.

That way it's never in the history and there's none of that nonsense to deal with.

Re: A Git client for simultaneous branches on top of your existing workflow

#97

Post by reyqn »

schacon wrote: post #69
reyqn wrote: post #63

Earlier quoted context omitted.

Maybe I don't understand how gitbutler works, but the main reason I use worktrees is actually to keep my IDE and incremental builds getting confused when I switch branches, on branches that have lots of differences. It works really well, and I can fix stuff on old versions of our app in a jiffy. I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.

Since we write out our virtual branch artifacts into refs/gitbutler/X, you could actually pretty easily setup worktrees from each of them to do this type of work on. Perhaps setup a post-commit hook to update any active worktrees automatically too. Might be an interesting way to effectively work on several worktrees from a single working directory.

That's interesting. I'll try this out when windows support ships and keep an eye on it in the meantime.

Re: A Git client for simultaneous branches on top of your existing workflow

#98

Post by bvrmn »

swozey wrote: post #93
bvrmn wrote: post #84

As usual couldn't recommend stacked git [1] enough. If you prefer CLI it greatly reduces cognitive load about branches/rebases especially if your work with review server allowing to see changes between force pushes (gitlab, gerrit). [1]: https://stacked-git.github.io/

The idea with this seems to be - I'm working on a branch and can't easily switch right now to put out a patch, or MY current branch HAS the patch and I want to push that out before the entire branch is ready so I make the stg commits and pushes and that patch is released. In their example [1] at the very end they commit --all of their patches into the main patch and I guess merge that into main. I'm kind of confused…

You are right about conflicting changes. They are hard to manage as order independent changes with any tool. In stgit context I often split big change into multiple ordered patches and yes I know what piece (incremental edit) should be added to what patch. Classic example: doing refactoring around main task. Refactoring goes into one patch, main changes into another. It allows greatly simplify review process.

But common case for me is to have multiple independent patches for different features/bug fixes. For example one current project has 12 patches, another one has 5 patches. Two or three are dedicated to current work. Rest are drafts with ideas.

> I'm kind of confused on the commit --all part.

Me too. Almost always task is represented by a single patch. And I push changes on patch basis. One patch -> one review.

Re: A Git client for simultaneous branches on top of your existing workflow

#99

Post by jcrben »

videlov wrote: post #67
OJFord wrote: post #57

Earlier quoted context omitted.

Maybe the problem is that the docs aren't selling me anything that I don't currently achieve by (manually) rebasing? So I'm left thinking I'd rather stick with my current workflow (or maybe motivated to alias it up a bit more) than adopt this limitation.

I think you are right that our documentation does not sufficiently communicate what the application does especially in various corner cases. For my own sake, allow me to articulate the core value proposition once more. GitButler's virtual branches permit two novel use cases: - A developer can lazily assign diffs/changes to belong to separate logical branches while maintaining their content within the same working dir…

This convinced me that it's maybe worth trying. Given the number of tools out there and how easy git feels for me right now (pretty easy), that's a highish bar
Post reply on HN