Kind of convinced that Dropbox provides the baseline experience that source control should aspire to. "Dropbox does X, why doesn't your source control system?" should be asked over and over
-
Kind of convinced that Dropbox provides the baseline experience that source control should aspire to. "Dropbox does X, why doesn't your source control system?" should be asked over and over
-
Dropbox doesn't make you add new files, why does your source control?
Dropbox doesn't have a notion of uncommitted data, why does source control?
Dropbox isn't modal when it comes to conflicts, why is your source control?
-
@rain Dropbox is a trash can to dig through; source control is something I consciously share with other people
-
@whitequark I think that answers why source control needs to be more feature rich than Dropbox. I don't think it answers why source control has to be janky in a way that Dropbox isn't
-
@rain @whitequark for me, "I obsessively only share changes I've carefully added" is a big part of my workflow
git add -p is my jam -
@recursive @whitequark This feature does not go away when you make source control more like Dropbox
-
@rain @recursive then I think we have fundamentally incompatible views of what "like Dropbox" means
I'm sure you have a good point but I don't hope to understand what it is
-
@whitequark @recursive Basically I think that to the extent that source control diverges from Dropbox, there needs to be a good, specific answer as to why. For example, there is no good reason to not add untracked files automatically just like Dropbox does, and doing so solves real data loss issues just like Dropbox does
-
@rain @recursive my reason is that I really don't want build products in the source tree, especially given how you can't remove anything from the history
-
@whitequark @recursive Right, and that's what gitignore is for. But that shouldn't be the default. (Dropbox also supports ignore files, incidentally.)
-
@rain @whitequark @recursive I'm often too lazy to add the correct files to the ignore file till months after I'm annoyed by them still showing up in git status.
Auto add is a good way to accidentally get keys committed or other files that really shouldn't be there.
-
@encthenet @whitequark @recursive I had the same issue! But to me, that is a maladaptive behavior in light of Git not forcing me to make a decision about them.
When I switched to Jujutsu, which does force you to make decisions about those files because it auto-adds new files that aren't ignored, I fixed my workflow within minutes.
-
@encthenet @whitequark @recursive To me this is a great example of how tools influence workflows.
Imagine if Dropbox forced you to right-click and add new files. It is immediately obvious to me that it would really suck -- people would hate it because they'd lose data all the time! Why should we not hold source control to the same standards?
-
@rain @encthenet @recursive this would make me more comfortable to use Dropbox and similar file-sharing solutions
I was using my headmate's file share (that's Synology, but same idea as Dropbox) and once I, or maybe someone else in the household, put like half a terabyte of files into the wrong folder. it got backed up and noticeably increased the storage bill.
ever since I obsess over "did this go into the right folder or not?" when using that system because of the very direct costs involved
-
@whitequark @rain @encthenet @recursive very very similar experiences - my conclusion is not that content should be automatically collected and replicated on my behalf, but that permanent deletion needs to be a higher bar than it is (i also think this is true with git: `reset --hard` should yell loudly if it would delete untracked files, and probably make me ack what files i would be blowing away)
-
Noah Kennedyreplied to iximeow last edited by [email protected]
@iximeow @whitequark @rain @encthenet @recursive interesting, i use it specifically as a nuke
