4 ms·

> "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course

by Crito 13y ago

> "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.

lmm 13y ago
I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine, the remote-tracking copies of those three on my machine, and the same again on his machine. All of which could be different. How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.
- Crito 13y ago
  Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore some of git's capabilities and treating git like SVN. Just because you can pull from your teammates, does not mean that you have to. I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through. It isn't the way that I prefer using git, but it works perfectly well.
  - lmm 13y ago
    > Set up a repo on a server somewhere and declare it to be the "central repo" That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus merges in the history).
    - Crito 13y ago
      Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow. If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.
      - lmm 13y ago
        > Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". Sure, but you hit the problem twice as often in git, because you have to do twice as many things. > If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go. In SVN that doesn't show up as a merge in the history.
        NickNameNick 13y ago
        In SVN, that shows up as a conflict which has to be merged by hand. 'git rebase' and/or 'git mergetool' are nicer.
- eropple 13y ago
  Is there a reason you aren't using disposable feature branches? I don't track my other developers' feature branches locally unless I need to view them.
  - lmm 13y ago
    You're right, thinking about it - most of the time I wouldn't have a copy of my coworker's branch (though we do sometimes pull changes from each other's feature branches - indeed that's supposed to be the big advantage of git, no?)
deleted 13y ago
[deleted]

by Crito 13y ago

lmm 13y ago

I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine, the remote-tracking copies of those three on my machine, and the same again on his machine. All of which could be different. How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.

Crito 13y ago
Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore some of git's capabilities and treating git like SVN. Just because you can pull from your teammates, does not mean that you have to. I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through. It isn't the way that I prefer using git, but it works perfectly well.
- lmm 13y ago
  > Set up a repo on a server somewhere and declare it to be the "central repo" That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus merges in the history).
  - Crito 13y ago
    Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow. If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.
    - lmm 13y ago
      > Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". Sure, but you hit the problem twice as often in git, because you have to do twice as many things. > If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go. In SVN that doesn't show up as a merge in the history.
      - NickNameNick 13y ago
        In SVN, that shows up as a conflict which has to be merged by hand. 'git rebase' and/or 'git mergetool' are nicer.
eropple 13y ago
Is there a reason you aren't using disposable feature branches? I don't track my other developers' feature branches locally unless I need to view them.
- lmm 13y ago
  You're right, thinking about it - most of the time I wouldn't have a copy of my coworker's branch (though we do sometimes pull changes from each other's feature branches - indeed that's supposed to be the big advantage of git, no?)

deleted 13y ago

[deleted]