3 ms·

> because the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. This doesn't make any sense, at all,

> because the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. This doesn't make any sense, at all, in any way or form to me. Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. > and when you switch branches we'll believe that you want to throw away what you were just working on. Switching branches checks if something would be thrown away, and will not proceed if that is the case.

lowbloodsugar 6y ago
>Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. I am so sorry. That sounds awful. Life doesn't have to be that way.
tsimionescu 6y ago
Aren't the IDE and build system files IN the repo? Normally if I clone a repo from scratch, all I have to do to build is `cd new-location/ && make`, and similarly to import in the IDE (though of course that will take some extra time, because I'll be forced to do a clean build, probably also re-downloading all dependencies).
- zwieback 6y ago
  Yes, they are in the repo but we usually have one developer own those and manage the check-ins. That avoids minor differences in those files, which sometimes depend on details of the workstation setup. There's probably a better way to handle this
- formerly_proven 6y ago
  I mean sure but it turns this: - Checkout different branch - Continue working Into this: - Checkout branch into new location - (Close project in IDE) - Browse to branch location, open IDE - Move all terminal $PWDs to the new location, as needed - Make a coffee while the IDE re-indexes everything - (Compiled languages: Hit make, enjoy another coffee while the build runs) - (npm and similarly structured projects: Hit install, enjoy another coffee while all dependencies are being fetched/checked/installed) And I just don't see how that's desirable. With git I can create, merge and switch between branches in seconds, and don't really have any problems (I've almost never felt the need to have two branches checked out at the same time). But with tree-per-branch I only see problems, and all branch-related operations become slow and annoying. One use case I could imagine where this is useful if you are simultaneously maintaining several mainline branches. But even within those "work areas" I'd rather be able to quickly switch branches.
  - tsimionescu 6y ago
    If you're switching branches, you anyway need to reindex and download new dependencies. You may not need to for very close branches, but in the general case that is not guaranteed.

lowbloodsugar 6y ago

>Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. I am so sorry. That sounds awful. Life doesn't have to be that way.

tsimionescu 6y ago

Aren't the IDE and build system files IN the repo? Normally if I clone a repo from scratch, all I have to do to build is `cd new-location/ && make`, and similarly to import in the IDE (though of course that will take some extra time, because I'll be forced to do a clean build, probably also re-downloading all dependencies).

zwieback 6y ago
Yes, they are in the repo but we usually have one developer own those and manage the check-ins. That avoids minor differences in those files, which sometimes depend on details of the workstation setup. There's probably a better way to handle this
formerly_proven 6y ago
I mean sure but it turns this: - Checkout different branch - Continue working Into this: - Checkout branch into new location - (Close project in IDE) - Browse to branch location, open IDE - Move all terminal $PWDs to the new location, as needed - Make a coffee while the IDE re-indexes everything - (Compiled languages: Hit make, enjoy another coffee while the build runs) - (npm and similarly structured projects: Hit install, enjoy another coffee while all dependencies are being fetched/checked/installed) And I just don't see how that's desirable. With git I can create, merge and switch between branches in seconds, and don't really have any problems (I've almost never felt the need to have two branches checked out at the same time). But with tree-per-branch I only see problems, and all branch-related operations become slow and annoying. One use case I could imagine where this is useful if you are simultaneously maintaining several mainline branches. But even within those "work areas" I'd rather be able to quickly switch branches.
- tsimionescu 6y ago
  If you're switching branches, you anyway need to reindex and download new dependencies. You may not need to for very close branches, but in the general case that is not guaranteed.