4 ms·

I'm a single developer who has recently switched from subversion to git and I'm having a few problems adjusting. My setup is that I work on my code from various

by Oatmeat 18y ago

I'm a single developer who has recently switched from subversion to git and I'm having a few problems adjusting. My setup is that I work on my code from various places (home, laptop, school) and I want to a consistent view of my code from each place. That is, if I create a git branch at home and write some code in it, I want to see that branch right away when I start working from school. Right now, I have a main server set up where I push my changes to after finishing work for the day. But now suppose I create some new tags and branches. I need to do git push --all git push --tags Then when I start working from a different location next time, I do git pull git checkout --track -b <new-branch> origin/<new-branch> Where I have to do the last command for each new branch that I want to see in my working copy. Things are even worse when I want to delete a branch (after having merged it into the mainline). I do git branch -d <branch-name> git push origin :<branch-name> And this will remove the branch from the local repository and my main repo, but at each of the other repositories I still need to delete the remote tracking branch. Does anybody know a way to simplify this workflow with git?

aggieben 18y ago
From home, start with condensing to one command: git push --all --tags From location1, if you just want to be able to make your working copy look like origin/<branchname>, you don't have to create a new branch. You can checkout on a tracking branch. You just can't do all your normal work there (i.e., when you want to commit, you'd need to checkout a branch to commit on). If you want to create local branches that track all the remote branches, the command you're currently using (minus the --track option) is what you need. As for deleting a branch, the simplest way is to not push branches that you're not going to keep. I understand what your context is, so you'll likely be stuck with maintaining branches in your central repository. There's not a dramatic simplification I can see in your workflow, but here's where Git's strong-suit really kicks in: it's very, very scriptable. It would be nearly trivial to write simple bash scripts to do most of this in one command (you might even be able to get there with aliases).
- Oatmeat 18y ago
  Thanks for the reply. Regarding the push command, it currently does not allow both the --all and --tags options to be used together (very strange). Regarding not pushing temporary branches, this seems contrary to one of the reasons I started using git: it makes branches cheap and easy to throw away when you are done with them. I can understand the way git works regarding each developer using only the branches they are interested in, but I can't seem scale this philosophy down to a single developer. I want all my working copies to be the same. I want new branches to propagate. I want branch deletions to propagate. I've thought about scripting some of this, but for some pieces I am not sure how to proceed. Consider branch deletion. The problem here is that I can delete the branch from the main repository, but that doesn't force deletion for each of the clients. Instead, I would need to write a custom "git pull" style command that I run in a working directory before I start my work. Should this command delete all remote branches so that actual deletions are propagated, and then "git pull" restores the remote branches which still exist? [edit: I've discovered that "git remote prune" will delete remote tracking branches that are no longer in the repo] Don't other git users have this issue? Presumably there are others who work from more than one location and want a consistent view from each, yet I can't seem to google for any help on these issues.
  - aggieben 18y ago
    Yeah, I realized post-facto that --all and --tags doesn't work. Alternatively, you can list your tags with things to push, like git push origin master my-tag ... That might also work with --all. If it does, you could get away with: git push --all origin my-tag As for the rest...I'm not sure what your best way forward is. One way might be simply to don't delete branches. They'll clutter the list of branches, but so what? Just ignore them if you don't use them. The 'git remote prune' way is probably best. Run that, and then check for local branches that aren't tracking a remote. That's scriptable. I don't think there's a simple and elegant answer here, because what you're doing basically turns Git into subversion. That's pretty much unavoidable when one is doing what you're doing. You could be more "distributed" if you only worked on specific features or modules (or whatever) at specific locations. Then you could just merge when necessary instead of always having to keep your branches in sync :-)
TFrancis 18y ago
I have a similar work flow to yours and I experience many of the same problems you do with DVCS. I'm currently thinking about just using rsync to keep my development environments the same. I haven't made this move yet but, I can't think why I couldn't.

by Oatmeat 18y ago

aggieben 18y ago

From home, start with condensing to one command: git push --all --tags From location1, if you just want to be able to make your working copy look like origin/<branchname>, you don't have to create a new branch. You can checkout on a tracking branch. You just can't do all your normal work there (i.e., when you want to commit, you'd need to checkout a branch to commit on). If you want to create local branches that track all the remote branches, the command you're currently using (minus the --track option) is what you need. As for deleting a branch, the simplest way is to not push branches that you're not going to keep. I understand what your context is, so you'll likely be stuck with maintaining branches in your central repository. There's not a dramatic simplification I can see in your workflow, but here's where Git's strong-suit really kicks in: it's very, very scriptable. It would be nearly trivial to write simple bash scripts to do most of this in one command (you might even be able to get there with aliases).

Oatmeat 18y ago
Thanks for the reply. Regarding the push command, it currently does not allow both the --all and --tags options to be used together (very strange). Regarding not pushing temporary branches, this seems contrary to one of the reasons I started using git: it makes branches cheap and easy to throw away when you are done with them. I can understand the way git works regarding each developer using only the branches they are interested in, but I can't seem scale this philosophy down to a single developer. I want all my working copies to be the same. I want new branches to propagate. I want branch deletions to propagate. I've thought about scripting some of this, but for some pieces I am not sure how to proceed. Consider branch deletion. The problem here is that I can delete the branch from the main repository, but that doesn't force deletion for each of the clients. Instead, I would need to write a custom "git pull" style command that I run in a working directory before I start my work. Should this command delete all remote branches so that actual deletions are propagated, and then "git pull" restores the remote branches which still exist? [edit: I've discovered that "git remote prune" will delete remote tracking branches that are no longer in the repo] Don't other git users have this issue? Presumably there are others who work from more than one location and want a consistent view from each, yet I can't seem to google for any help on these issues.
- aggieben 18y ago
  Yeah, I realized post-facto that --all and --tags doesn't work. Alternatively, you can list your tags with things to push, like git push origin master my-tag ... That might also work with --all. If it does, you could get away with: git push --all origin my-tag As for the rest...I'm not sure what your best way forward is. One way might be simply to don't delete branches. They'll clutter the list of branches, but so what? Just ignore them if you don't use them. The 'git remote prune' way is probably best. Run that, and then check for local branches that aren't tracking a remote. That's scriptable. I don't think there's a simple and elegant answer here, because what you're doing basically turns Git into subversion. That's pretty much unavoidable when one is doing what you're doing. You could be more "distributed" if you only worked on specific features or modules (or whatever) at specific locations. Then you could just merge when necessary instead of always having to keep your branches in sync :-)

TFrancis 18y ago

I have a similar work flow to yours and I experience many of the same problems you do with DVCS. I'm currently thinking about just using rsync to keep my development environments the same. I haven't made this move yet but, I can't think why I couldn't.