10 ms·

Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the

Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?

tootie 14y ago
http://mercurial.selenic.com/ http://mercurial.selenic.com/
- varikin 14y ago
  This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius. But I still use git because I already grokked it before I learned hg.
  - syncsynchalt 14y ago
    I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).
    - the_mitsuhiko 14y ago
      > I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it). What about the index? Or the branching (bookmarks kinda work now I think), or the better remote management?
      - tootie 14y ago
        I personally hate the index. It gets in my way far more often than I actually make use of it.
        the_mitsuhiko 14y ago
        How does it ever get in the way? Just add `-a` and you can essentially ignore that there is an index on commits.
        j-kidd 14y ago
        Let's say I modified an existing file (not staged) and then git add a new file. It is a work in progress, and the two changes are not supposed to be in the same commit. Now, what can I do to see all changes I have made so far? I have done this many times with subversion (svn diff) and mercurial (hg diff). Git's index just get in the way.
      - syncsynchalt 14y ago
        You're touting these as positives for git but in the context of training a large group to use a new VCS they are a negative.
        Aga 14y ago
        I have found branching in Git to be a pleasure to teach, even to large groups. There is nothing I have to hide about them, implementation or otherwise. "This is how it works and this is what you can do thanks to that"
    - rimantas 14y ago
      Switching to git was very easy for me after hg screwed my repo. And git had much saner branching back then, not sure if anything changed in mercurial land.
    - __david__ 14y ago
      That's interesting. I learned hg first and moved to git after being frustrated with hg's limitations. Yeah, git could use an overhaul on some of it's command line interfaces (using the index on different git commands: --cached, --stage, --index), but it's so much better overall that those things become minor quibbles.
  - the_mitsuhiko 14y ago
    > The command addremove is genius That's the default of what git does even without a command.
    - stevelosh 14y ago
      No it's not. [alias] addremove = !git add . && git add -u That will do it though, so it's not too hard to add.
      - the_mitsuhiko 14y ago
        Git does it on `git commit -a`.
        stevelosh 14y ago
        No, it doesn't. -a, --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
        the_mitsuhiko 14y ago
        Ah, it's too long since I used hg. Thought it only picks up deletes.
      - austintaylor 14y ago
        git add -A
    - develop7 14y ago
      No, git doesn't track renames — git _guesses_ them
  - __david__ 14y ago
    > The command addremove is genius. Why? I find that in the middle of a big project I have lots of stupid files strewn about that I absolutely don't want checked in (TODO lists, patches I'm considering, copies of large log files I'm investigating, etc). I always add things explicitly and delete explicitly, otherwise I'd get random junk checked into my repo. How do you keep your repo clean enough to actually use automatic commands like that?
    - koenigdavidmj 14y ago
      Put that type of thing in .hgignore.
      - __david__ 14y ago
        Isn't that checked in like .gitignore? I'd rather not put stupid local stuff into a file that the rest of the team shares. And if I don't commit it then I'm stuck with a local file that always has changes, which is also begging for trouble. It also implies that I name things in some consistent way or that I add a lot of files into the ignore file. I guess other people just aren't as messy as I am?
        koenigdavidmj 14y ago
        You can keep multiple ignore files. Then .hgignore can be shared by the whole team (if you're working in C, you're going to ignore .o files, for instance, and so will everyone else). Look up the ui.ignore hgrc option to add more files (presumably one of which doesn't sync).
syncsynchalt 14y ago
Mercurial is essentially git with a clean interface and drastically fewer workflows. If it weren't for github's existence I'd recommend hg to anyone. That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.
- merijnv 14y ago
  I'm using hg even with github. The hg-git extension from the github guys works surprisingly well for me. The only downsides I've found that push/pull of very large repos tends to be a bit slow and the conversion to/from git will clobber file move histories in hg, since git doesn't track file moves.
- the_mitsuhiko 14y ago
  > That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway. Considering more people know git I would assume the training cost for hg is higher.
  - aidenn0 14y ago
    More people use git; I'm becoming increasingly convinced that few of them actually know git.
    - the_mitsuhiko 14y ago
      > More people use git; I'm becoming increasingly convinced that few of them actually know git. And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.
      - aidenn0 14y ago
        Yeah, named branches in hg are just weird.
bjeanes 14y ago
There are certainly attempts to do so. I've been meaning to try http://www.git-legit.org/ http://www.git-legit.org/

Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?

tootie 14y ago

http://mercurial.selenic.com/ http://mercurial.selenic.com/

varikin 14y ago
This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius. But I still use git because I already grokked it before I learned hg.
- syncsynchalt 14y ago
  I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).
  - the_mitsuhiko 14y ago
    > I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it). What about the index? Or the branching (bookmarks kinda work now I think), or the better remote management?
    - tootie 14y ago
      I personally hate the index. It gets in my way far more often than I actually make use of it.
      - the_mitsuhiko 14y ago
        How does it ever get in the way? Just add `-a` and you can essentially ignore that there is an index on commits.
        j-kidd 14y ago
        Let's say I modified an existing file (not staged) and then git add a new file. It is a work in progress, and the two changes are not supposed to be in the same commit. Now, what can I do to see all changes I have made so far? I have done this many times with subversion (svn diff) and mercurial (hg diff). Git's index just get in the way.
    - syncsynchalt 14y ago
      You're touting these as positives for git but in the context of training a large group to use a new VCS they are a negative.
      - Aga 14y ago
        I have found branching in Git to be a pleasure to teach, even to large groups. There is nothing I have to hide about them, implementation or otherwise. "This is how it works and this is what you can do thanks to that"
  - rimantas 14y ago
    Switching to git was very easy for me after hg screwed my repo. And git had much saner branching back then, not sure if anything changed in mercurial land.
  - __david__ 14y ago
    That's interesting. I learned hg first and moved to git after being frustrated with hg's limitations. Yeah, git could use an overhaul on some of it's command line interfaces (using the index on different git commands: --cached, --stage, --index), but it's so much better overall that those things become minor quibbles.
- the_mitsuhiko 14y ago
  > The command addremove is genius That's the default of what git does even without a command.
  - stevelosh 14y ago
    No it's not. [alias] addremove = !git add . && git add -u That will do it though, so it's not too hard to add.
    - the_mitsuhiko 14y ago
      Git does it on `git commit -a`.
      - stevelosh 14y ago
        No, it doesn't. -a, --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
        the_mitsuhiko 14y ago
        Ah, it's too long since I used hg. Thought it only picks up deletes.
    - austintaylor 14y ago
      git add -A
  - develop7 14y ago
    No, git doesn't track renames — git _guesses_ them
- __david__ 14y ago
  > The command addremove is genius. Why? I find that in the middle of a big project I have lots of stupid files strewn about that I absolutely don't want checked in (TODO lists, patches I'm considering, copies of large log files I'm investigating, etc). I always add things explicitly and delete explicitly, otherwise I'd get random junk checked into my repo. How do you keep your repo clean enough to actually use automatic commands like that?
  - koenigdavidmj 14y ago
    Put that type of thing in .hgignore.
    - __david__ 14y ago
      Isn't that checked in like .gitignore? I'd rather not put stupid local stuff into a file that the rest of the team shares. And if I don't commit it then I'm stuck with a local file that always has changes, which is also begging for trouble. It also implies that I name things in some consistent way or that I add a lot of files into the ignore file. I guess other people just aren't as messy as I am?
      - koenigdavidmj 14y ago
        You can keep multiple ignore files. Then .hgignore can be shared by the whole team (if you're working in C, you're going to ignore .o files, for instance, and so will everyone else). Look up the ui.ignore hgrc option to add more files (presumably one of which doesn't sync).

syncsynchalt 14y ago

Mercurial is essentially git with a clean interface and drastically fewer workflows. If it weren't for github's existence I'd recommend hg to anyone. That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.

merijnv 14y ago
I'm using hg even with github. The hg-git extension from the github guys works surprisingly well for me. The only downsides I've found that push/pull of very large repos tends to be a bit slow and the conversion to/from git will clobber file move histories in hg, since git doesn't track file moves.
the_mitsuhiko 14y ago
> That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway. Considering more people know git I would assume the training cost for hg is higher.
- aidenn0 14y ago
  More people use git; I'm becoming increasingly convinced that few of them actually know git.
  - the_mitsuhiko 14y ago
    > More people use git; I'm becoming increasingly convinced that few of them actually know git. And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.
    - aidenn0 14y ago
      Yeah, named branches in hg are just weird.

bjeanes 14y ago

There are certainly attempts to do so. I've been meaning to try http://www.git-legit.org/ http://www.git-legit.org/