9 ms·

Git Town – A high-level command line interface for Git

159 points by tnorthcutt 9y ago

jsiepkes 9y ago
Seems like a more lightweight version of the 'arc' cli tool of Phabricator (which I really like BTW)?
sigi45 9y ago
Hell of work around a few git commands. Screencast, website, promo. I prefer aliases i configure myself to understand them, most of my colleges don't even bother with that detail of git commands at all and use an ui.
- superlopuh 9y ago
  I think that's sort of the point, instead of having aliases, this is a low-effort way to have even people who prefer to use GUI clients (like me) to have an easy-to-use/install unified command line workflow. I'm very tempted.
partycoder 9y ago
Over the years, there have been many "friendly interfaces to git", in both UI or command line form. They all suffer from the same issue: in the face of conflicts they just failsafe to good old git. I think these tools are good if you want to do something more productively but in the end you will still need to know about git.
- qguv 9y ago
  I'm not sure this is trying to prevent anyone from needing to learn the actual git commands. (Note that the abstraction intentionally leaks by showing the commands that are run.) It appears to be more of a tool for experienced users on centralized teams to save some time typing.
georgecalm 9y ago
Another great alternative that I use every day is https://hub.github.com https://hub.github.com, especially if you work with GitHub.
- kevingoslar 9y ago
  Hub is awesome, and orthogonal to what Git Town does. You can use both together, though.
btym 9y ago
For example, correctly merging a finished feature branch requires up to 15 individual Git commands! Am I missing something? Does `git merge` imply fourteen other commands?
- stinos 9y ago
  Maybe they include things like stashing/popping current uncomitted changes, switching to target branch, pulling source and target branches first, rebasing feature branch onto latest target branch, resolving conflicts, ... ? All of these are things I has to do at one point or another to 'just' merge some feature branch from somebody else into master while I was working on another branch myself. So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands.
  - falcolas 9y ago
    > So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands. My concern would be: what happens when the automation encounters and edge case; what kind of unholy mess would you end up with? And to be fair, with GitHub and GitLab, doing local feature branch merges has become a very rare event for me in the last 5 years.
    - kevingoslar 9y ago
      Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started. That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.
      - Jare 9y ago
        Edge cases handled properly may be the killer feature of this project, at least for me. With git, as long as I'm in familiar territory it's fine, but when somethings goes off rails my head's working set explodes with options.
rojoca 9y ago
https://github.com/Originate/git-town/blob/master/documentation/commands/sync.md https://github.com/Originate/git-town/blob/master/documentat... I think it would be good if the docs had the git commands that are run for a git-town command.
- kevingoslar 9y ago
  Good suggestion, will add them! Git Town uses Cucumber as living documentation: https://github.com/Originate/git-town/blob/master/features/git-town-sync/current_branch/feature_branch/no_conflict/with_tracking_branch.feature https://github.com/Originate/git-town/blob/master/features/g...
jph 9y ago
Git Town looks thorough to me. It includes well-written source code in Go, plenty of edge-case error checking, good messages, and excellent feature tests. Kudos! If you're interested in branch aliases, here are some that may be helpful that I use at GitAlias.com. topic-start = "!f(){ branch=$1; git checkout master; git fetch; git rebase; git checkout -b "$branch" master; };f" topic-pull = "!f(){ branch=$(git branch-name); git checkout master; git pull; git checkout "$branch"; git rebase master; };f" topic-push = "!f(){ branch=$(git branch-name); git push --set-upstream origin "$branch"; };f" topic-finish = "!f(){ branch=$(git branch-name); git checkout master; git branch --delete "$branch"; git push origin ":$branch"; };f" branch-name = rev-parse --abbrev-ref HEAD
- tokenizerrr 9y ago
  Why not just `git fetch; git rebase origin/master`?
  - jph 9y ago
    Personal preference. I prefer to get the local master up to date first. A more-sophisticated alias would/could verify that the local master is buildable, testable, etc. before doing the rebase. What I like most about using aliases for topic branches (a.k.a. feature branches) is that any team can define its preferred workflow and encapsulate it.
    - evilstiefel 9y ago
      This might also be "dangerous" if git is set to the matching scheme instead of simple, since you don't just pull origin master. I guess anybody simply copying these from here should just be aware and be careful of what they just paste :D.
- jwilk 9y ago
  You should backslash-escape your inner double-quotes.
  - 9y ago
junk3r 9y ago
If bash aliases didn't exist, this would be useful.
gt_ 9y ago
I am new to programming (less than 1 year) and the insignificance of this project is obvious to me. This looks very well done, but my understanding is that a user friendly wrapper for such a ubiquitous programming tech with already widespread GUIs and pluins is comparable to reinventing a wheel. It's a little frustrating how many projects like this appear to get so much attention and end up on HN, because it makes for a disorienting maze of distractions for newer programmers. I love all the productivity, excitement, possibility but it's still peculiar and debatably problematic. My best guess is this was a personal project that solved some person(s) problems, and for some reason related to networking or self-promotion, it got the decoration of a full release treatment. What else could cause this? I know there are zillions of these every day but this seems like one we all can see through. Can anyone share some insight here? Should I be contributing to the heap of projects like these to further my own career?
- nothrabannosir 9y ago
  What you're seeing and describing is endemic to the entire field of programming. You will encounter it at every level. Frameworks keep being invented left and right which address solved problems, or solve non-existing ones. Meaningless busywork. This will never stop: it is human. Don't fight it: embrace it. Navigating this wasteland is part of your job. A keen eye for separating wheat from chaff is a valuable asset. Learning to code is only step 1 in learning to program. Learning how to choose your tools, and what to ignore, is just as important.
  - gt_ 9y ago
    This does help me a lot to get this response. I personally actually love downloading and testing small tools and sometimes worry my search for better tools or the promise of better tools is a distraction. But, maybe this willingness to continue the search is just highly correlated with my fascination and interest in becoming a programmer.
- Normal_gaussian 9y ago
  > the insignificance of this project is obvious to me > comparable to reinventing a wheel > many projects like this appear to get so much attention and end up on HN > Can anyone share some insight here? First the HN audience, its core is hackers and startups. These people have certain problems in common, and they are always on the lookout for ways to eliminate them. The hackers build things and the startup people do a lot of management and they are often one and the same. Secondly good version control is hard to use across a project without swamping new arrivals or accidentally breaking something. Git isn't good enough, but it is what we have. So like good hackers we take the first, see the second and try and produce something better. This is how we end up with lots of similar looking projects. Because they are solving real problems being faced by HN users they get upvoted until the comments discover some fatal flaw (leaky? prevents key conflict resolution?). This author reckons hes solved it, so he gives it the full treatment because it is worth a lot to have __actually__ solved it. If I could resolve git woes by handing a newbie a ten minute video I would be ecstatic. Remember, it is important to reinvent the wheel [1] though don't waste time on these projects unless you can see a way through. [1] https://pbs.twimg.com/media/CMyiLuKUwAA6l-V.jpg https://pbs.twimg.com/media/CMyiLuKUwAA6l-V.jpg
746F7475 9y ago
So this is for people who don't know how to use aliases (bash or git)?
- ungzd 9y ago
  They had to write thousand lines of code in Go instead of these aliases. Startup aura!
- kevingoslar 9y ago
  Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.
  - 746F7475 9y ago
    I still don't see the killer feature here. It just throws around ton of commands, most of which are completely unnecessary.
paulddraper 9y ago
Slick stuff. But can you use this in practice and not know what git is doing? Aka is this really not a leaky abstraction? I ask sincerely; having known git for years I can't objectively answer this.
- qguv 9y ago
  As an experienced git user, I'd use this on projects with a central repo, if only because it saves some typing.
- kevingoslar 9y ago
  It shows the Git commands it runs, as well as their output. So, you know exactly what Git is doing.
jaimex2 9y ago
Shouldn't this whole thing just be a pull request into git itself?
- roblabla 9y ago
  No. Git tries to be agnostic to your workflow. Also, some of the commands are tailored for github, which is not the only git host. See gitlab, gogs, gerrit, etc...
romanr 9y ago
Looks very similar to Git Flow
rwieruch 9y ago
I like to keep Git puristic. I have only a few aliases, because I want to operate on every machine the same way. Git can be intimidating for newcomers. In the last two years, I noticed the pattern that I only use a few essential Git commands in order to resolve a handful of scenarios. I have written them up: https://www.robinwieruch.de/git-essential-commands/ https://www.robinwieruch.de/git-essential-commands/ Maybe it helps some people to get started.
- charlierudolph 9y ago
  I believe knowing the low level commands is very important. I don't think anyone should use Git Town without learning everything covered in your article. Git Town prints every* Git command it runs and what branch it is run on. That was my first contribution to the project as I wanted to know exactly what the tool was doing. * Git Town runs other git commands to inspect the state of things (for example: what is the current branch, are there any uncommitted changes). These are not printed but each one that changes the state (for example: checking out another branch, fetching updates, merging branches) are printed
  - rwieruch 9y ago
    I will give it a shot! Thanks for the clarifications :)
throwme_1980 9y ago
Don't bother, learning GIT is a transferable skill, this will be thrown out as soon as you join a proper development team . Gimmicky at best
- SmellyGeekBoy 9y ago
  I don't see much utility in this but I certainly don't restrict the toolset my developers use and would be perfectly fine with them using this on any of our machines, especially if it made their lives easier.
- charlierudolph 9y ago
  This tool is not meant to replace Git. Each command runs a series of git commands (all of which are printed out) which may be different based on the state of your repository. I would advise against using Git Town without understanding Git.
afshinmeh 9y ago
Seems interesting but I don't personally like using these kind of projects. Having a wrapper around another technology or tools to make things easier to use, encapsulates many more important concepts that you have to know as a good developer. I don't think giant tech companies use these kind of tools as well.
- oblio 9y ago
  Giant tech companies basically use their own version control systems. Facebook uses something forked from Mercurial, I think, Google has a Perforce derived one, etc. They basically take the approach presented here to 11.
- charlierudolph 9y ago
  Git Town is meant to be a wrapper around Git but an extension. The commands it adds are suitable for particular workflows where you would otherwise be running the same series of git commands. It prints out all the Git commands it runs and the output of them. I think Git Town is best used only after someone learns Git (and has possibly run through the workflows by hand).
franzwong 9y ago
When I saw the name, I thought it was a simcity game with git :P
git-pull 9y ago
Those who think a wrapper is going to help their development is in for something when things break and they don't know how to operate things the way they're meant to. git is an especially poor choice for wrappers. You're hiding the concepts of staged and unstaged information, branches, tags, remotes, submodules. Regardless of VCS, you're setting yourself up for failure when you buy into a third-party tool's workflow rather than knowing what the hell you're doing. Pick up git as you go along. Rather than a tool doing who knows what behind the scene. If you really goof things when you're starting, don't be afraid to git reset --hard <ref> / git commit --amend + force push, as long as you know where you're at in history.
- kevingoslar 9y ago
  Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing. The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive. Good developers engineer repetition away. Great developers share what they build. Hence Git Town.
  - nolemurs 9y ago
    > Good developers engineer repetition away. Great developers share what they build. Hence Git Town. Sure, but a handful of of bash and/or git aliases handles that just fine while also being better suited to a user's particular workflow and easier to learn.
    - allover 9y ago
      If you're trying to achieve a workflow like 'Git Flow' [1], having everyone in your team attempt it manually with their own home-brew aliases is going to go very badly. [1] http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/
  - 9y ago
mdekkers 9y ago
Git is a great foundation for source code management. No. Fucking marketing doublespeak. Git is great for source-code management. Don't start your pitch by trying to redefine and reposition Git. You lost me right there.
dahart 9y ago
> squash-merge the password-reset branch into the master branch (this makes it look like a single, clean commit, without the convoluted merge history and the many intermediate commits on your branch) Is this what most people do? And is this something you can turn off with Git Town? I don't like to to squash-merge, I spend time making sure my commits are as much logical and self-contained units as they can be in my branches, and I want to preserve the ability to revert and/or bisect them later.
- MBlume 9y ago
  It's a trade-off. Many devs don't know how to do that, don't care to do that, will never learn to do that, and for them squash merge is a good option.
  - dahart 9y ago
    For sure. I'm not suggesting anyone else shouldn't; on the contrary just asking if Git Town goes both ways, and whether squash merge is more common in practice? I would have assumed that a regular (not squashed) merge is more common, and easier to do, because it's the default behavior of "git merge". It takes extra git commands and/or extra non-default arguments to git merge to get a squash merge. My GitHub also doesn't default to squash merge, IIRC... Don't you have to choose squash merge or be told to use it, if you don't otherwise know or care?
- gumby 9y ago
  I am the opposite, I like shush-merge although I understand and empathize with your view. My usage is to commit very frequently, like whenever I make a non-trivial fix or small refactor, or when something that touches several files compiles cleanly, or passes a unit test. This is several commits per day. It's practically every file save (if you remember filesystems with explicit version support). So my commit history is very noisy. When I push back to a shared repo, I want the commit history to document what the change is; various false or partial paths are not enlightening (if I planned to follow strategy 'X', found it did work, and backed out and used algorithm 'Y' then that should go in the source as a comment, not in the metadata. If my check ins were once a day I might not want to lose them. So I'm philosophically aligned with you, but my commits are so high frequency that the merge functions as a low-pass filter.
mempko 9y ago
The command-line interface is what I loved about darcs. Too bad it never got the mind share because of early performance problems.

159 points by tnorthcutt 9y ago

Seems like a more lightweight version of the 'arc' cli tool of Phabricator (which I really like BTW)?

Hell of work around a few git commands. Screencast, website, promo. I prefer aliases i configure myself to understand them, most of my colleges don't even bother with that detail of git commands at all and use an ui.

superlopuh 9y ago
I think that's sort of the point, instead of having aliases, this is a low-effort way to have even people who prefer to use GUI clients (like me) to have an easy-to-use/install unified command line workflow. I'm very tempted.

partycoder 9y ago

Over the years, there have been many "friendly interfaces to git", in both UI or command line form. They all suffer from the same issue: in the face of conflicts they just failsafe to good old git. I think these tools are good if you want to do something more productively but in the end you will still need to know about git.

qguv 9y ago
I'm not sure this is trying to prevent anyone from needing to learn the actual git commands. (Note that the abstraction intentionally leaks by showing the commands that are run.) It appears to be more of a tool for experienced users on centralized teams to save some time typing.

georgecalm 9y ago

Another great alternative that I use every day is https://hub.github.com https://hub.github.com, especially if you work with GitHub.

kevingoslar 9y ago
Hub is awesome, and orthogonal to what Git Town does. You can use both together, though.

btym 9y ago

For example, correctly merging a finished feature branch requires up to 15 individual Git commands! Am I missing something? Does `git merge` imply fourteen other commands?

stinos 9y ago
Maybe they include things like stashing/popping current uncomitted changes, switching to target branch, pulling source and target branches first, rebasing feature branch onto latest target branch, resolving conflicts, ... ? All of these are things I has to do at one point or another to 'just' merge some feature branch from somebody else into master while I was working on another branch myself. So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands.
- falcolas 9y ago
  > So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands. My concern would be: what happens when the automation encounters and edge case; what kind of unholy mess would you end up with? And to be fair, with GitHub and GitLab, doing local feature branch merges has become a very rare event for me in the last 5 years.
  - kevingoslar 9y ago
    Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started. That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.
    - Jare 9y ago
      Edge cases handled properly may be the killer feature of this project, at least for me. With git, as long as I'm in familiar territory it's fine, but when somethings goes off rails my head's working set explodes with options.

rojoca 9y ago

https://github.com/Originate/git-town/blob/master/documentation/commands/sync.md https://github.com/Originate/git-town/blob/master/documentat... I think it would be good if the docs had the git commands that are run for a git-town command.

kevingoslar 9y ago
Good suggestion, will add them! Git Town uses Cucumber as living documentation: https://github.com/Originate/git-town/blob/master/features/git-town-sync/current_branch/feature_branch/no_conflict/with_tracking_branch.feature https://github.com/Originate/git-town/blob/master/features/g...

jph 9y ago

Git Town looks thorough to me. It includes well-written source code in Go, plenty of edge-case error checking, good messages, and excellent feature tests. Kudos! If you're interested in branch aliases, here are some that may be helpful that I use at GitAlias.com. topic-start = "!f(){ branch=$1; git checkout master; git fetch; git rebase; git checkout -b "$branch" master; };f" topic-pull = "!f(){ branch=$(git branch-name); git checkout master; git pull; git checkout "$branch"; git rebase master; };f" topic-push = "!f(){ branch=$(git branch-name); git push --set-upstream origin "$branch"; };f" topic-finish = "!f(){ branch=$(git branch-name); git checkout master; git branch --delete "$branch"; git push origin ":$branch"; };f" branch-name = rev-parse --abbrev-ref HEAD

tokenizerrr 9y ago
Why not just `git fetch; git rebase origin/master`?
- jph 9y ago
  Personal preference. I prefer to get the local master up to date first. A more-sophisticated alias would/could verify that the local master is buildable, testable, etc. before doing the rebase. What I like most about using aliases for topic branches (a.k.a. feature branches) is that any team can define its preferred workflow and encapsulate it.
  - evilstiefel 9y ago
    This might also be "dangerous" if git is set to the matching scheme instead of simple, since you don't just pull origin master. I guess anybody simply copying these from here should just be aware and be careful of what they just paste :D.
jwilk 9y ago
You should backslash-escape your inner double-quotes.
- 9y ago

junk3r 9y ago

If bash aliases didn't exist, this would be useful.

gt_ 9y ago

I am new to programming (less than 1 year) and the insignificance of this project is obvious to me. This looks very well done, but my understanding is that a user friendly wrapper for such a ubiquitous programming tech with already widespread GUIs and pluins is comparable to reinventing a wheel. It's a little frustrating how many projects like this appear to get so much attention and end up on HN, because it makes for a disorienting maze of distractions for newer programmers. I love all the productivity, excitement, possibility but it's still peculiar and debatably problematic. My best guess is this was a personal project that solved some person(s) problems, and for some reason related to networking or self-promotion, it got the decoration of a full release treatment. What else could cause this? I know there are zillions of these every day but this seems like one we all can see through. Can anyone share some insight here? Should I be contributing to the heap of projects like these to further my own career?

nothrabannosir 9y ago
What you're seeing and describing is endemic to the entire field of programming. You will encounter it at every level. Frameworks keep being invented left and right which address solved problems, or solve non-existing ones. Meaningless busywork. This will never stop: it is human. Don't fight it: embrace it. Navigating this wasteland is part of your job. A keen eye for separating wheat from chaff is a valuable asset. Learning to code is only step 1 in learning to program. Learning how to choose your tools, and what to ignore, is just as important.
- gt_ 9y ago
  This does help me a lot to get this response. I personally actually love downloading and testing small tools and sometimes worry my search for better tools or the promise of better tools is a distraction. But, maybe this willingness to continue the search is just highly correlated with my fascination and interest in becoming a programmer.
Normal_gaussian 9y ago
> the insignificance of this project is obvious to me > comparable to reinventing a wheel > many projects like this appear to get so much attention and end up on HN > Can anyone share some insight here? First the HN audience, its core is hackers and startups. These people have certain problems in common, and they are always on the lookout for ways to eliminate them. The hackers build things and the startup people do a lot of management and they are often one and the same. Secondly good version control is hard to use across a project without swamping new arrivals or accidentally breaking something. Git isn't good enough, but it is what we have. So like good hackers we take the first, see the second and try and produce something better. This is how we end up with lots of similar looking projects. Because they are solving real problems being faced by HN users they get upvoted until the comments discover some fatal flaw (leaky? prevents key conflict resolution?). This author reckons hes solved it, so he gives it the full treatment because it is worth a lot to have __actually__ solved it. If I could resolve git woes by handing a newbie a ten minute video I would be ecstatic. Remember, it is important to reinvent the wheel [1] though don't waste time on these projects unless you can see a way through. [1] https://pbs.twimg.com/media/CMyiLuKUwAA6l-V.jpg https://pbs.twimg.com/media/CMyiLuKUwAA6l-V.jpg

746F7475 9y ago

So this is for people who don't know how to use aliases (bash or git)?

ungzd 9y ago
They had to write thousand lines of code in Go instead of these aliases. Startup aura!
kevingoslar 9y ago
Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.
- 746F7475 9y ago
  I still don't see the killer feature here. It just throws around ton of commands, most of which are completely unnecessary.

paulddraper 9y ago

Slick stuff. But can you use this in practice and not know what git is doing? Aka is this really not a leaky abstraction? I ask sincerely; having known git for years I can't objectively answer this.

qguv 9y ago
As an experienced git user, I'd use this on projects with a central repo, if only because it saves some typing.
kevingoslar 9y ago
It shows the Git commands it runs, as well as their output. So, you know exactly what Git is doing.

jaimex2 9y ago

Shouldn't this whole thing just be a pull request into git itself?

roblabla 9y ago
No. Git tries to be agnostic to your workflow. Also, some of the commands are tailored for github, which is not the only git host. See gitlab, gogs, gerrit, etc...

romanr 9y ago

Looks very similar to Git Flow

rwieruch 9y ago

I like to keep Git puristic. I have only a few aliases, because I want to operate on every machine the same way. Git can be intimidating for newcomers. In the last two years, I noticed the pattern that I only use a few essential Git commands in order to resolve a handful of scenarios. I have written them up: https://www.robinwieruch.de/git-essential-commands/ https://www.robinwieruch.de/git-essential-commands/ Maybe it helps some people to get started.

charlierudolph 9y ago
I believe knowing the low level commands is very important. I don't think anyone should use Git Town without learning everything covered in your article. Git Town prints every* Git command it runs and what branch it is run on. That was my first contribution to the project as I wanted to know exactly what the tool was doing. * Git Town runs other git commands to inspect the state of things (for example: what is the current branch, are there any uncommitted changes). These are not printed but each one that changes the state (for example: checking out another branch, fetching updates, merging branches) are printed
- rwieruch 9y ago
  I will give it a shot! Thanks for the clarifications :)

throwme_1980 9y ago

Don't bother, learning GIT is a transferable skill, this will be thrown out as soon as you join a proper development team . Gimmicky at best

SmellyGeekBoy 9y ago
I don't see much utility in this but I certainly don't restrict the toolset my developers use and would be perfectly fine with them using this on any of our machines, especially if it made their lives easier.
charlierudolph 9y ago
This tool is not meant to replace Git. Each command runs a series of git commands (all of which are printed out) which may be different based on the state of your repository. I would advise against using Git Town without understanding Git.

afshinmeh 9y ago

Seems interesting but I don't personally like using these kind of projects. Having a wrapper around another technology or tools to make things easier to use, encapsulates many more important concepts that you have to know as a good developer. I don't think giant tech companies use these kind of tools as well.

oblio 9y ago
Giant tech companies basically use their own version control systems. Facebook uses something forked from Mercurial, I think, Google has a Perforce derived one, etc. They basically take the approach presented here to 11.
charlierudolph 9y ago
Git Town is meant to be a wrapper around Git but an extension. The commands it adds are suitable for particular workflows where you would otherwise be running the same series of git commands. It prints out all the Git commands it runs and the output of them. I think Git Town is best used only after someone learns Git (and has possibly run through the workflows by hand).

franzwong 9y ago

When I saw the name, I thought it was a simcity game with git :P

git-pull 9y ago

Those who think a wrapper is going to help their development is in for something when things break and they don't know how to operate things the way they're meant to. git is an especially poor choice for wrappers. You're hiding the concepts of staged and unstaged information, branches, tags, remotes, submodules. Regardless of VCS, you're setting yourself up for failure when you buy into a third-party tool's workflow rather than knowing what the hell you're doing. Pick up git as you go along. Rather than a tool doing who knows what behind the scene. If you really goof things when you're starting, don't be afraid to git reset --hard <ref> / git commit --amend + force push, as long as you know where you're at in history.

kevingoslar 9y ago
Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing. The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive. Good developers engineer repetition away. Great developers share what they build. Hence Git Town.
- nolemurs 9y ago
  > Good developers engineer repetition away. Great developers share what they build. Hence Git Town. Sure, but a handful of of bash and/or git aliases handles that just fine while also being better suited to a user's particular workflow and easier to learn.
  - allover 9y ago
    If you're trying to achieve a workflow like 'Git Flow' [1], having everyone in your team attempt it manually with their own home-brew aliases is going to go very badly. [1] http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/
- 9y ago

mdekkers 9y ago

Git is a great foundation for source code management. No. Fucking marketing doublespeak. Git is great for source-code management. Don't start your pitch by trying to redefine and reposition Git. You lost me right there.

dahart 9y ago

> squash-merge the password-reset branch into the master branch (this makes it look like a single, clean commit, without the convoluted merge history and the many intermediate commits on your branch) Is this what most people do? And is this something you can turn off with Git Town? I don't like to to squash-merge, I spend time making sure my commits are as much logical and self-contained units as they can be in my branches, and I want to preserve the ability to revert and/or bisect them later.

MBlume 9y ago
It's a trade-off. Many devs don't know how to do that, don't care to do that, will never learn to do that, and for them squash merge is a good option.
- dahart 9y ago
  For sure. I'm not suggesting anyone else shouldn't; on the contrary just asking if Git Town goes both ways, and whether squash merge is more common in practice? I would have assumed that a regular (not squashed) merge is more common, and easier to do, because it's the default behavior of "git merge". It takes extra git commands and/or extra non-default arguments to git merge to get a squash merge. My GitHub also doesn't default to squash merge, IIRC... Don't you have to choose squash merge or be told to use it, if you don't otherwise know or care?
gumby 9y ago
I am the opposite, I like shush-merge although I understand and empathize with your view. My usage is to commit very frequently, like whenever I make a non-trivial fix or small refactor, or when something that touches several files compiles cleanly, or passes a unit test. This is several commits per day. It's practically every file save (if you remember filesystems with explicit version support). So my commit history is very noisy. When I push back to a shared repo, I want the commit history to document what the change is; various false or partial paths are not enlightening (if I planned to follow strategy 'X', found it did work, and backed out and used algorithm 'Y' then that should go in the source as a comment, not in the metadata. If my check ins were once a day I might not want to lose them. So I'm philosophically aligned with you, but my commits are so high frequency that the merge functions as a low-pass filter.

mempko 9y ago

The command-line interface is what I loved about darcs. Too bad it never got the mind share because of early performance problems.