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

71–80 of 119 posts

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

#71

Post by alexeiz »

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…

If you need a lot of local changes that you can't commit, then either your repository or your project (or both) are organized improperly. You must have committed files to git that should never be committed or you project doesn't allow you to adapt to the local environment without changing files committed to git.

For example, you may have hardcoded paths to tools and compilers, but in your local environment those tools have different paths. This is a problem with the project organization.

Another example, you may have something like VSCode settings file which somebody decided to commit to git, but those settings only make sense in his environment and not anybody else's environment.

Instead of searching for a workaround to these problems like virtual branches, you should push for fixing your project organization and you git repository.

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

#72

Post by schacon »

aeonik wrote: post #32
schacon wrote: post #7

Earlier quoted context omitted.

You should be able to do this pretty easily. We list your other local and remote branches in the sidebar. If you apply them, they are essentially converted into virtual branches (remote targets too, I believe)

I think I got it working today. Not sure what I was doing wrong before. Also, you I recommend that you add the capability to pull different hunks out of the commit, and separate/unsquash them, or even move them to different branches. The UI is begging me to drag parts of the commit out. I can squash commits, but it doesn't seem like I can do the opposite. Use Case: Just now I made a change to a config file, and a bui…

So, yes and no. You should be able to do `reset HEAD^` equivalent by just hitting 'undo', which is essentially what that does. You can then re-commit stuff or drag the newly uncommitted hunks to other branches.

But it's only for the last commit, so something in the middle you can only squash, you can't unfold into two commits or something. Totally doable, but not in our UI yet. (we will do that someday)

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

#73

Post by OJFord »

schacon wrote: post #61
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.

Well, one thing we can do is "merge" together multiple non-conflicting branches in your working directory without creating (or, I suppose, having to undo) merge artifacts. Like if you had three branches and you wanted to see how they will work when they're all merged, and you find an issue in one and want to fix it, GB makes this really simple. You just apply them all and then fix something and make sure it's on the…

Let me first of all be clear that I believe you have good reasons, and reiterate that I think it's great and want the features, I'm just trying to understand why it doesn't/can't work with my current rebasing workflow.

Take my example before, X-->Y-->Z(HEAD) where each of X,Y,Z here are (at least potentially) multi-commit branches, not just commits; based on top of each other.

If I need to fix something in the 'merged' (I said 'amalgamated' previously exactly to avoid that, but we can stick with scarequotes if you like ;)) result, and it belongs say with Y, then I will either:

    git fixup 

    # fixup = my alias for:
    "!f(){ target=\"$(test -n \"$1\" && git rev-parse \"$1\" || git fzsha rev-parse)\"; git commit --fixup=\"$target\" ${@:2} && EDITOR=true git rebase -i --autostash --autosquash \"$target^\"; }; f"
    
    # basically commit -m'!fixup ', and then rebase target-commit^ to apply it
or if it belongs as a standalone commit on that branch:

    git commit -m 'whatever'
    git rebase -i Y # and move it to the top so the Z stuff follows it
and then in either case:

    git branch -f Y 
    
    # if I'm doing this repeatedly,  is often HEAD~N, for however many N commits on Z.
For this feature at least, it seems like GB could be implemented as automation/abstraction of that workflow, which (clearly) is perfectly penetrable to git.

I've been working like this for more than a decade, so even if GB's better & easier it's a tough sell to partially break interoperability; to need to use GB GUI to manage the situation rather than have it as a choice.

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

#74

Post by schacon »

jupp0r wrote: post #52

Slightly offtopic, but because this was prominently featured in their demo: 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…

Well, two things. They're not on by default, you have to enable them. Both because it means we have to send your code diffs outside your machine, but mostly because lots of people don't want them.

The other is that the point is not to take away writing good commit messages. The opposite. One item on our task list is to create the _best_ commit message editor we can think of. One that Linux kernel hackers would want to use to craft a great commit. But that's for a bit later.

The AI thing, in our minds, is to eliminate "fixed some stuff" messages that have zero semantic value. If you're committing just to push, you might as well have AI give you some searchable text in less time than it would take you to write a crappy commit message.

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

#75

Post by weinzierl »

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…

Not a complete solution to the more generic problem you described, but enough for me most of the time:

1. I try to arrange things in a way that I can keep my local changes in files that are not in the repo. For example: If your software loads a file from several places and the more specific one (current dir) wins over a more generic one ($HOME or /etc) you can try to keep a local one.

All these files end up being .gitignored from a place that is not in the repo itself and not shared: Either in the global .gitignore or .git/info/exclude. If the files don't have to be in a specific place I put them in a subdir called aux, which also contains a .gitignore with just an asterisk (*) on the first line. That way it never gets added and it doesn't leave a trace in any .gitignore outside of aux.

2. Files that are checked in but need local modifications are marked with `git update-index --assume-unchanged`

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

#76

Post by o11c »

thfuran wrote: post #36
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…

It sounds like a project structure issue where local environment config that shouldn't be tracked is (or a lack of optional additional config that could be specified locally). Or maybe I'm misunderstanding the sort of change you're talking about.

Specifically, the fix is usually:

* Rename the configuration file in the repository to add an `.example` suffix (preferably, to an empty `-local` file if includes exist)

* As part of the build system, copy all `.example` files to remove the suffix, but only if they don't already exist.

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

#77

Post by ratherbefuddled »

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 rules everyone was working to were or the whole repository was effectively broken.

It was very complicated to get your head around - I guess not helped by the codebase I was working on at the time which tended to concentrate change in the same 20 files.

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

#78

Post by jupp0r »

schacon wrote: post #74
jupp0r wrote: post #52

Slightly offtopic, but because this was prominently featured in their demo: 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…

Well, two things. They're not on by default, you have to enable them. Both because it means we have to send your code diffs outside your machine, but mostly because lots of people don't want them. The other is that the point is not to take away writing good commit messages. The opposite. One item on our task list is to create the _best_ commit message editor we can think of. One that Linux kernel hackers would want t…

I totally see where you are coming from, I've just seen the fallout from more and more tools adding similar features and the net benefit has not been there, quite the opposite. It makes it easy to do the wrong thing.

That being said, with enough context (slack threads about the feature, zoom meeting transcripts, design docs, etc) I could totally see AI commit message generation being great in the future, but that's obviously a harder problem to solve than just piping the diff to OpenAI or similar.

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

#79

Post by sesm »

schacon wrote: post #70
motoboi wrote: post #29

Intellij IDE support this through changelists. UPDATE: add link to documentation https://www.jetbrains.com/help/idea/work-on-several-features...

Sort of, but it's honestly closer to normal git branches. If I'm not mistaken, you can't have multiple changelists applied simultaneously. You still have to switch between active groups of changes, no?

Changelists are more like splitting your local changes into several groups. The idea is that you usually want to commit only one group of changes while leaving others uncommitted. For every changed line the editor will show you whether it’s modified in scope of your active changelist or in scope of a non-active one. Also, you can easily ‘shelf’ and ‘unshelf’ a changelist.

I was actively using changelists for some time, but later switched to git worktrees instead. Now I usually have only 2 changelists: ‘Default’ and ‘Hacks - don’t commit!’.

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

#80

Post by motoboi »

schacon wrote: post #70
motoboi wrote: post #29

Intellij IDE support this through changelists. UPDATE: add link to documentation https://www.jetbrains.com/help/idea/work-on-several-features...

Sort of, but it's honestly closer to normal git branches. If I'm not mistaken, you can't have multiple changelists applied simultaneously. You still have to switch between active groups of changes, no?

you can have any number of changelists (or changesets) active at once.

You can actually have changes in the same file with some lines in different changesets.

When needed, you can commit changes to git (when you finish doing work) to make them visible to coworkers.

Post reply on HN