3 ms·

Agreed. Local topic branch for experimental hacks. Rebase it when you want to integrate upstream changes.

• moe 17y ago
  I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. Hacking just happens. We try this and that, something works and gets committed, something else doesn't and gets reverted. My working copy is littered with uncommited files nearly constantly, simply because I work and play on many things in parallel and committing every time I save a file would be a noticable overhead, just as merging between topic branches all day. I'm not complaining, we get along, my working copy and I, but I agree in some situations git could be more helpful than "xxx needs update" - and that's really just one symptom of many. 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, it is mindboggingly much more intuitive to use. Git could take a lesson from that and would not even have to give up much of the purity. Yes, "everything" should still be possible - but they damn sure could make the beaten paths a bit less spikey.
  • 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.