3 ms·

I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You

I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-brained developers, it's perfectly appropriate.

mjburgess 4y ago
That requires your programming language to identify files with modules, and with your system architecture to be extended by modules alone. This is an ideal case, of course.
- enriquto 4y ago
  I don't understand your comment. The method that I describe only requires that the programming language ignores unused files. As far as I know, all modern programming languages have this feature.
  - mjburgess 4y ago
    In the way most languages and applications work, a "new feature" requires modification to several existing file.s
    - DaiPlusPlus 4y ago
      .csproj-anxiety The worst is when you move a bunch of files around in Solution Explorer and commit, maybe do a merge and push, before you realise the MSBuild/csproj files were never saved (gotta press Save All for some reason) - now you have a change you need to apply to a pre-merge commit. Good luck with that.
bigDinosaur 4y ago
This doesn't handle the reasonably common case very well where someone is working on changes which are constantly breaking the branch for everyone else. They should have their own branch and be frequently rebasing/merging so as to not disrupt others. Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed. That said, keep the branches limited and try to keep them 'linear' in the sense that you don't want to be merging between 100 different non-main branches in some byzantine nightmare. Perhaps encourage merges only to the development branch and then rebranching.
- Filligree 4y ago
  > Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed. Well, why don't you simply copy the code into a new directory and commit that? Then you can do whatever you want in the scratch directory.
  - bigDinosaur 4y ago
    To me that seems messier than a new branch. For one, how are others to know my files are test/scratch/feature branch files? I'd have to use a naming scheme, and some kind of other signal to make sure nobody imports them before they're ready or mistakes them for deployable files - and at that point I'm just replicating a branch!
    - enriquto 4y ago
      > and at that point I'm just replicating a branch! Yes. My entire point is that you can always replicate branches with actual, explicit files, and that this is a good thing to do because files are (very often) better than branches. Files plus some editor discipline are essentially equivalent to branches. Files+discipline are better than branches, according to standard unix philosophy: (1) everything is a file, (2) protocol not policy.
aqme28 4y ago
This feels like a lot of extra work to throw away the benefits you actually get out of version control. I would very much not like to work on this team.

mjburgess 4y ago

That requires your programming language to identify files with modules, and with your system architecture to be extended by modules alone. This is an ideal case, of course.

enriquto 4y ago
I don't understand your comment. The method that I describe only requires that the programming language ignores unused files. As far as I know, all modern programming languages have this feature.
- mjburgess 4y ago
  In the way most languages and applications work, a "new feature" requires modification to several existing file.s
  - DaiPlusPlus 4y ago
    .csproj-anxiety The worst is when you move a bunch of files around in Solution Explorer and commit, maybe do a merge and push, before you realise the MSBuild/csproj files were never saved (gotta press Save All for some reason) - now you have a change you need to apply to a pre-merge commit. Good luck with that.

bigDinosaur 4y ago

This doesn't handle the reasonably common case very well where someone is working on changes which are constantly breaking the branch for everyone else. They should have their own branch and be frequently rebasing/merging so as to not disrupt others. Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed. That said, keep the branches limited and try to keep them 'linear' in the sense that you don't want to be merging between 100 different non-main branches in some byzantine nightmare. Perhaps encourage merges only to the development branch and then rebranching.

Filligree 4y ago
> Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed. Well, why don't you simply copy the code into a new directory and commit that? Then you can do whatever you want in the scratch directory.
- bigDinosaur 4y ago
  To me that seems messier than a new branch. For one, how are others to know my files are test/scratch/feature branch files? I'd have to use a naming scheme, and some kind of other signal to make sure nobody imports them before they're ready or mistakes them for deployable files - and at that point I'm just replicating a branch!
  - enriquto 4y ago
    > and at that point I'm just replicating a branch! Yes. My entire point is that you can always replicate branches with actual, explicit files, and that this is a good thing to do because files are (very often) better than branches. Files plus some editor discipline are essentially equivalent to branches. Files+discipline are better than branches, according to standard unix philosophy: (1) everything is a file, (2) protocol not policy.

aqme28 4y ago

This feels like a lot of extra work to throw away the benefits you actually get out of version control. I would very much not like to work on this team.