3 ms·

> I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. I don't either. I pretty much always work on master. If

by dlsspy 17y ago

> I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. I don't either. I pretty much always work on master. If I find myself down a deep path that should've been a topic branch, I make one then and reset my master back to origin. > I've been playing with mercurial a bit recently (yes, heresy) and can see why the git guys despise it, it's just not as pure. The main thing that stuck with me though, is that even though it's roughly comparable to git in terms of features I used hg heavily for a long time before ever touching git. I did a bit of work on an older project that used hg recently and found myself unable to figure out how to do something I often easily do in git. I don't remember the exact details, but I ended up committing and tagging after doing a "trivial" change that ended up being wrong (I noticed before pushing). Rather than pollute my public history with garbage, I just wanted to undo the mess and go back and fix the brokenness and retag. When I used hg heavily, I was very well-versed with the ins and outs of mercurial queues for doing simple fixups like this. Not having used it recently, I had to go to the manual because I couldn't remember which combination of q-commands would do a simple effective rebase. I was especially sensitive here because the last time I was a heavy hg user, I did lose changes to queues because hg doesn't have anything like the wonderful safety net of reflog to allow me to just put my tree back in a prior stat and let me try a complicated merge/rebase again.

moe 17y ago
I don't either. I pretty much always work on master. If I find myself down a deep path that should've been a topic branch, I make one then and reset my master back to origin. Well, yes, I also kludge my way through it like that. It just always leaves that old sour taste of "it should be easier than that". You know how it goes, the next pull comes along and you better remember to merge it to all your branches... I did lose changes to queues because hg doesn't have anything like the wonderful safety net of reflog This is an absolutely wonderful example, thanks for coming up with that. Yes, I know the reflog exists and you can do magic things with it. It involves commands like 'git reflog show --date=relative HEAD' and refs like 'HEAD@{1}' (I admit I had to look them up). So, do you know that stuff from the top of your head? Or how much man-page wrestling did you have to do before the safety net actually caught you? My wet dream of a git porcelaine would be different. It would include commands like "undo" and "redo" and they would do exactly what one expects and warn explicitly when their little world is not consistent anymore (e.g. an undo can't be performed because an affected file was modified). So to be clear: Undo would undo absolutely any operation (within git's ability) and same for redo. Ofcourse there are many horrible corner cases to be worked out for such an truly intuitive command-set to survive reality - but imho a porcelaine grown in such a spirit would eventually do better justice to the elegance of git than the "raw API" interface we have now. Oh and while I'm in dreamland, my dream-porcelaine would ofcourse also max out at 10-12 commands.
- dlsspy 17y ago
  > It just always leaves that old sour taste of "it should be easier than that". git branch branch-i-should-have-made git reset --hard origin/master How would you make it easier? Why is that kludgy? > So, do you know that stuff from the top of your head? Or how much man-page wrestling did you have to do before the safety net actually caught you? Uh, no. I type "git reflog" and look for the thing I want. Then I copy the hash and do whatever I was going to do with it -- the same thing I do in hg went I look at its logs and want to reference something older. You are contriving a complex use case of a rarely used safety-net command, when in reality, it's just not that hard to use. I was listening to an SE at work introducing another guy to it earlier today when the guy needed to recover from a mistake he made.
  - moe 17y ago
    How would you make it easier? Why is that kludgy? That is not the kludgy part. The kludgy part begins when you have created a few branches that way and start bringing in changes from upstream, or when the branches begin to conflict with each other. Suddenly there is housekeeping involved, merging stuff back and forward. I just don't understand why git lets me comfortably stage individual hunks (a feature that I love and use extensively) but refuses to deal with uncommitted changes as intelligently as with everything else. I don't want to commit the three spurious lines I just typed into the editor before going to the bathroom. Yet I'd like to do a quick pull from my co-worker when I come back, before continuing on those lines and without commiting my 3 lines first. This is rather contrived again, but it shows the underlying problem of git not staying out of the way as it should but instead forcing me to do something completely unrelated to my actual goal - a sure sign of a bad UI. You are contriving a complex use case of a rarely used safety-net command Well, I agree it was rather contrived. Yet I still wonder how many git users, when asked, could quickly type out the command to undo their last rebase and how many know, without looking, how to weasel out of the various follow-up errors that may appear ("Interactive rebase already started" anyone?).

by dlsspy 17y ago

moe 17y ago

I don't either. I pretty much always work on master. If I find myself down a deep path that should've been a topic branch, I make one then and reset my master back to origin. Well, yes, I also kludge my way through it like that. It just always leaves that old sour taste of "it should be easier than that". You know how it goes, the next pull comes along and you better remember to merge it to all your branches... I did lose changes to queues because hg doesn't have anything like the wonderful safety net of reflog This is an absolutely wonderful example, thanks for coming up with that. Yes, I know the reflog exists and you can do magic things with it. It involves commands like 'git reflog show --date=relative HEAD' and refs like 'HEAD@{1}' (I admit I had to look them up). So, do you know that stuff from the top of your head? Or how much man-page wrestling did you have to do before the safety net actually caught you? My wet dream of a git porcelaine would be different. It would include commands like "undo" and "redo" and they would do exactly what one expects and warn explicitly when their little world is not consistent anymore (e.g. an undo can't be performed because an affected file was modified). So to be clear: Undo would undo absolutely any operation (within git's ability) and same for redo. Ofcourse there are many horrible corner cases to be worked out for such an truly intuitive command-set to survive reality - but imho a porcelaine grown in such a spirit would eventually do better justice to the elegance of git than the "raw API" interface we have now. Oh and while I'm in dreamland, my dream-porcelaine would ofcourse also max out at 10-12 commands.

dlsspy 17y ago
> It just always leaves that old sour taste of "it should be easier than that". git branch branch-i-should-have-made git reset --hard origin/master How would you make it easier? Why is that kludgy? > So, do you know that stuff from the top of your head? Or how much man-page wrestling did you have to do before the safety net actually caught you? Uh, no. I type "git reflog" and look for the thing I want. Then I copy the hash and do whatever I was going to do with it -- the same thing I do in hg went I look at its logs and want to reference something older. You are contriving a complex use case of a rarely used safety-net command, when in reality, it's just not that hard to use. I was listening to an SE at work introducing another guy to it earlier today when the guy needed to recover from a mistake he made.
- moe 17y ago
  How would you make it easier? Why is that kludgy? That is not the kludgy part. The kludgy part begins when you have created a few branches that way and start bringing in changes from upstream, or when the branches begin to conflict with each other. Suddenly there is housekeeping involved, merging stuff back and forward. I just don't understand why git lets me comfortably stage individual hunks (a feature that I love and use extensively) but refuses to deal with uncommitted changes as intelligently as with everything else. I don't want to commit the three spurious lines I just typed into the editor before going to the bathroom. Yet I'd like to do a quick pull from my co-worker when I come back, before continuing on those lines and without commiting my 3 lines first. This is rather contrived again, but it shows the underlying problem of git not staying out of the way as it should but instead forcing me to do something completely unrelated to my actual goal - a sure sign of a bad UI. You are contriving a complex use case of a rarely used safety-net command Well, I agree it was rather contrived. Yet I still wonder how many git users, when asked, could quickly type out the command to undo their last rebase and how many know, without looking, how to weasel out of the various follow-up errors that may appear ("Interactive rebase already started" anyone?).