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

101–110 of 119 posts

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

#101

Post by whoopsie »

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 would be brilliant and an instant subscribe from a long time tower user

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

#104

Post by lionkor »

Looks like a gimmick to me. You can achieve this easily by working on a scratch branch, and then, once ready (and with git commit -p), building the commits you want. Then, you cherry-pick them into other branches.

The rest of it is pure gimmick and would be force turned off in my team.

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

#105

Post by Already__Taken »

nhellman wrote: post #55
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…

> Then before I push, I have to temporarily rewind the branch to remove them, push, then cherry-pick them again. 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.

ok that one's a cool tip

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

#107

Post by schacon »

ratherbefuddled wrote: post #77

An aside but this is giving me ClearCase config_spec vibes. Memory is hazy - possibly due to trauma - but you could create a config_spec which would make your view (roughly: working tree) pick up different bits of the filesystem from different branches. Branches might only exist on some of the filesystem, depending on how you set up auto branching and what you checked out, and you had to know what the config_spec rul…

I feel like this is much different. We're not saying "patch these things together into a materialized view", we're saying "here is the diff between your working directory and origin/master, which branch owns which hunk" and keeping that mapping around.

We keep monitoring it until we see changes upstream (someone merged into master) and then we let you update the difference (merging or rebasing commits you made if needed)

We're not inventing massively new mindspaces.

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

#108

Post by eitland »

okl wrote: post #31
eitland wrote: post #23

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…

Don't know if that's what you're looking for but JetBrains tools have a Local History that saves all your local edits. It also notes whether unit tests where passing/failing at that point and let's you revert separate hunks.

I know. It is really useful!

The difference here is it would save it to the central repository so I know not only the steps I took but also the steps my colleagues took + K don't think local history track reason for change?

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

#109

Post by keybored »

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…

Stacked Git (stg) will let you push and pop commits. Pop when publishing, push back when you need them again.

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

#110

Post by seba_dos1 »

Nullabillity wrote: post #92
schacon wrote: post #18

Earlier quoted context omitted.

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…

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

Post reply on HN