4 ms·

> I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrat

by u801e 5y ago

> I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrating thing. Think, having your graphics designer able to make commits, or having someone who only wants to update docs. The question really should be why do we want to use git for version control when people really want an backup system where they can essentially update files by uploading a new version of the file.

happymellon 5y ago
Especially when they use tools that make files that contain all the history through "non-destructive changes" anyway. But I think the reason is because the mess of folders they then create in DropBox and they can never find their files. What would be great is if someone could make a TimeMachine for non-developers that uses git, because that is what they are doing in their heads anywy.
- u801e 5y ago
  Most editors and word processors, along with other applications have undo and redo features that allow them to do that. If that could be tied with a timestamp, then it would be easy to see what version of the file they're working with. The only other feature they may find useful is a way to add a note to the file they saved indicating what changed (which would be the equivalent to a commit message). Integrating those file(s) as a submodule or subtree in a git repository would work on the development side, but people who generate those files would have no need to interface with git, and people who use git would not need to use the editor for those files to get the history they need.
b3morales 5y ago
Frontend developers really like their designers to have versions, because it handles the eternal: Designer: Hey, I filed a bug for this, it doesn't look like the design. <screenshot of design they changed yesterday> Developer: Um, we released that like two weeks ago; it's correct according to the design I had at the time. Designer: Yeah, but this is the design <link to continuously updated document in web editor with no history> Maybe you can just fix it really quick today? Doesn't have to be git, but some way to match up releases to the design document that was current at that time is quite useful.
- u801e 5y ago
  A timestamp would be sufficient in that case. If you think of most editors and word processors, they have undo and redo features that allow users to go back and forth in terms of the history of their edits. Those features normally don't support branches and if you make a change in the middle of a redo, you lose access the rest of the other redo steps. So you could tell the designer that you have the version they sent you on Friday August 13, 2021 at 3:12 PM EDT. Did they make any changes after that, or did they mean to send you a version they made prior to that?

by u801e 5y ago

happymellon 5y ago

Especially when they use tools that make files that contain all the history through "non-destructive changes" anyway. But I think the reason is because the mess of folders they then create in DropBox and they can never find their files. What would be great is if someone could make a TimeMachine for non-developers that uses git, because that is what they are doing in their heads anywy.

u801e 5y ago
Most editors and word processors, along with other applications have undo and redo features that allow them to do that. If that could be tied with a timestamp, then it would be easy to see what version of the file they're working with. The only other feature they may find useful is a way to add a note to the file they saved indicating what changed (which would be the equivalent to a commit message). Integrating those file(s) as a submodule or subtree in a git repository would work on the development side, but people who generate those files would have no need to interface with git, and people who use git would not need to use the editor for those files to get the history they need.

b3morales 5y ago

Frontend developers really like their designers to have versions, because it handles the eternal: Designer: Hey, I filed a bug for this, it doesn't look like the design. <screenshot of design they changed yesterday> Developer: Um, we released that like two weeks ago; it's correct according to the design I had at the time. Designer: Yeah, but this is the design <link to continuously updated document in web editor with no history> Maybe you can just fix it really quick today? Doesn't have to be git, but some way to match up releases to the design document that was current at that time is quite useful.

u801e 5y ago
A timestamp would be sufficient in that case. If you think of most editors and word processors, they have undo and redo features that allow users to go back and forth in terms of the history of their edits. Those features normally don't support branches and if you make a change in the middle of a redo, you lose access the rest of the other redo steps. So you could tell the designer that you have the version they sent you on Friday August 13, 2021 at 3:12 PM EDT. Did they make any changes after that, or did they mean to send you a version they made prior to that?