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

21–30 of 119 posts

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

#21

Post by schacon »

catapart wrote: post #10
schacon wrote: post #5

Earlier quoted context omitted.

There are some good points, but there are things I want in my tooling that git just cant do. We need to keep some external data structures. However, we are as compatible as we can be. We keep the index in a proper state (union of all the head commits on all applied branches) and we write out refs for each branch (to refs/gitbutler so as not to clobber stuff in the normal namespace). You can still do whatever - base w…

Yeah, but if I have work in the virtual branches, how is that represented to git? Does it even exist in my local repo, or not, until it has been "handled"? And 'handled' brings up another point because I don't even know what to call this intermediate state of existence that isn't a domain of git. When I'm done with a virtual branch do I... commit to it? Collapse it into a real branch? It's new terminology, new concep…

> Does it even exist in my local repo, or not, until it has been "handled"?

Yes, we write the virtual branch states into your git repository under refs/gitbutler/[branch] so you have them represented as real git references.

There is not a lot of new terminology. You commit to your branches, push them to GitHub, open PRs, track upstream work. It's really just that you can have more than one of them applied to the same working directory at the same time.

> auto branch naming?

This is only done if you have the AI tools turned on and it's often just a placeholder. We basically want you to be able to use anonymous branches - not having to name them to start them. Think of it as a temporary description if you want, you can as easily rename them as name them in the first place. Also, I rather like them, they're often more descriptively correct than I would have done in the first place.

> doesn't trust me more than the app

This isn't our goal. Our goal is to let you delegate things you don't want to do to us in some cases and make cool things a little simpler so that more people can utilize them. But you have to _opt in_ to the AI stuff, it's not the default. Otherwise they're just called "Virtual Branch 1", etc until you rename them.

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

#22

Post by seba_dos1 »

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…

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.

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

#23

Post by eitland »

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 what happened[2]) or more valuable (because just like no one I know except me uses bisect no one will use this and it will simplify my job.)

This is (in my opinion) a great idea for a paid IntelliJ/VS Code/etc plug in but I realize I won't have time to do it.

[1]: "virtual commits" is just my marketing speak for adding extra metadata without polluting the branches we usually relate to. One possible way are branches named virtual- and IDEs that support them will hide them by default. The plug in commits automatically on the hidden branch while keeping the normal user facing branch at its current commit, and everytime one commits the normal user facing branch the metadata branch is merged as a formality.

[2]: Maybe when I hover over a function I see its refactor history? Maybe I can click on a commit to expand it and see 4 virtual commits:

- edit + successful test,

- refactor + successful test,

- edit + test fail,

- edit + successful test

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

#24

Post by robertlagrant »

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…

I think GitLab does something like this behind the scenes when you tick the Merged results[0] box. Fake commit to run CI against.

[0] https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipel...

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

#25

Post by OJFord »

'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me.

It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon as you do anything, so it could just choose arbitrarily or create some (possibly temporary) other branch name to show.

Because while I'm a proponent of rebasing, apparently the 'go-to' guy for git on the team, etc. I won't pretend it's trivial to maintain a chain of dependent branches, or not annoying. A couple more aliases than I currently have would probably help, but it'd never be as good as something like OP just clicking to 'rebase all on master', or where x-->Y-->Z(HEAD) 'switch to work on Y but keep Z', etc,=.

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

#26

Post by eitland »

robertlagrant wrote: post #24
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…

I think GitLab does something like this behind the scenes when you tick the Merged results[0] box. Fake commit to run CI against. [0] https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipel...

Thanks!

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

#28

Post by adrianmonk »

ckolkey wrote: post #11

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?

Don't worktrees require more work to actually run your code because of multiple working directories?

If you're using an IDE, you'll probably need to create a project for each working directory. Or maybe you can change the path within the IDE's project.

If you're running a local web server, it will need to be configured for each working directory, again either multiple instances or one where you keep updating the path.

For compiled languages, the builds will take longer. When you create a new worktree, you may have to do a full build. Even if you have incremental builds, as you pull in upstream changes, you'll have to do N incremental builds instead of 1 incremental build.

It's not the end of the world, but it's a bit of hassle and extra computation that isn't needed with just one working copy.

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

#30

Post by schacon »

OJFord wrote: post #25

'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…

Im not following you. What do you mean by “don’t use other tooling”?
Post reply on HN