Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitless: a version control system

gitless.com

Post reply on HN
Print view View original

371–380 of 390 posts

Re: Gitless: a version control system

#371

Post by dahart »

mikegerwitz wrote: post #370
dahart wrote: post #369

Earlier quoted context omitted.

This is a great post! I have only one minor point: > In the stash case, `git reflog` would immediately allow you to recover the lost stash. Stashes don't go in the reflog, you cannot recover them with git reflog, so you're automatically in the 'deep shit' category if you lose them. Hence the statement that stashes are dangerous. You do still have the safety net of fsck, and knowing that it's possible matters, as you…

> Stashes don't go in the reflog You can see them with `git reflog --all`.

Not after they're popped or dropped. Only while they're in the stash list.

Re: Gitless: a version control system

#372

Post by Drdrdrq »

friendzis wrote: post #320
shinymark wrote: post #296

Earlier quoted context omitted.

I find Mercurial so much easier to use than Git. Many of the concepts are similar but the hg interface feels much easier to learn and use.

At $dayjob we have a mixed bag of hg and git. I found that while git makes great distinction between local and remote (and working directory), hg is more similar to centralized VCSes. Any other remote action than "sync local with remote" requires Blak Magick Mumbojumbo™. Some "common" (as seen by original authors. Local throwaway branch is not such) tasks are sure easier than git, but stepping out of the beaten path…

I'm curious, what other remote action do you miss with hg? Push and pull (to different remote repos if needed) are sufficient for me. What am I missing?

Re: Gitless: a version control system

#373

Post by [deleted] »

arjie wrote: post #327
kazinator wrote: post #301

Earlier quoted context omitted.

The use case is that when I'm making a new repo, I want to be able to do: git rebase -i ^ git reset --patch ^ git checkout --patch ^ I can do all this if the first commit is actually the second and the first is a dummy empty one.

I meant, "what are you setting out to do?" as in "I'm trying to reorder commits" not "I'm trying to `git rebase -i commit`" (the ultimate aim, rather than the path you choose). My instinct is that you can get where you want to go fairly easily with the `git rebase -i --root` I mentioned earlier.

[deleted]

Re: Gitless: a version control system

#374

Post by projektir »

dahart wrote: post #313
projektir wrote: post #288

Earlier quoted context omitted.

> No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. I was talking about the non-rebase version. You didn't address the rest of my post: there are other cases. This will work for that particular case, but it's not a general-purpose solution. If I have branch X with config changes, and coworker wants me to switch to branch Y but I still want my config changes, wha…

Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality. What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, st…

I didn't call it a general purpose solution in that context, nor did I call it a general purpose solution for everything. I am saying that I needed a general purpose solution for a situation that occurs often in many variants. For my situation, without stash, that was creating a commit and cherry-picking it places. Stash makes that case a lot easier to manage.

I don't use stash for cases where it doesn't make sense. I use stash for cases where, for me, it makes sense. For a special set of config changes that are never pushed. They're not part of my usual work, they're config changes. In this context, your 2nd paragraph makes no sense. I don't have to arbitrarily choose one or the other "workflow", I use both, and I simply use stash for the general case of reapplying configs on random branches. There are other ways to do it but they all require more headspace and are harder to track than stash and stash pop.

I'm not saying I need to stash or that I can't do it without stash. Have you not seen my earlier post?

It has nothing to do with being comfortable with commits. I'm already comfortable with commits. I've even said, before, that I did it with commits. It's just slower to do it with commits, and it means I have to manage commits for something I'll never, ever push. Every time I make something a commit, that's extra work for me later to make sure I don't push it out. If I make commits after that commit it's extra work for me to rebase it.

I don't put things in my stash where I care about a bad merge with them or that I'm even going to bother searching for the blob, I'll just redo the changes if that ever happens, because they're minor. They're things like: "Point to my database instead of the standard dev database". I just don't want to do them by hand every single time and I don't want to track a hash that changes every time I actually do want to change my configs.

You're the one making a big deal out of something, honestly, and you do not seem to be reading my posts very carefully because you're still making a lot of incorrect assumptions.

Re: Gitless: a version control system

#376

Post by jomamaxx »

croon wrote: post #338
jomamaxx wrote: post #312

Earlier quoted context omitted.

"GUIs and "UX" are generally antithetical to making a computer do what it does best (automate things instead of creating more busywork)." Except for helping the 6 or so billion people in their daily lives, but hey, the iPhone would be 'better' if it just had 'bash'? Read your email lately from bash? Didn't think so!

False equivalence. We wouldn't have billions of users if there were no other agents than users. You can't create an iphone using an iphone.

"False equivalence. We wouldn't have billions of users if there were no other agents than users. You can't create an iphone using an iphone."

It's not a false equivalence at all.

The necessity of lower-level technology in the creation of higher-level technology does not imply that the lower-level technology is somehow 'better' or 'superior'.

You are using a UX right now to read and respond to this.

It's crazy to posit that 'UXs are inferior'. Positively wrong.

In the vast majority of cases, UX's are superior to shells. Maps, news, social media, browsing/buying things, listening to music, making music, photo editing - there are actually very few use-cases wherein the shell is advantageous. Even emacs is a UX of sorts.

Re: Gitless: a version control system

#377

Post by dahart »

projektir wrote: post #374
dahart wrote: post #313

Earlier quoted context omitted.

Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality. What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, st…

I didn't call it a general purpose solution in that context, nor did I call it a general purpose solution for everything. I am saying that I needed a general purpose solution for a situation that occurs often in many variants. For my situation, without stash, that was creating a commit and cherry-picking it places. Stash makes that case a lot easier to manage. I don't use stash for cases where it doesn't make sense.…

> You're the one making a big deal out of something, honestly, and you do not seem to be reading my posts very carefully because you're still making a lot of incorrect assumptions.

I'm sorry you feel like I wasn't listening to you. I was, and I read all your posts. You're absolutely right, I have made a big deal out of it. Despite the long discussion, I think we're in nearly full agreement, and FWIW, thank you for engaging.

I did misread your pull --rebase comment. I thought that was sorted now, but I'd be happy to address any other bad assumptions I'm making. It wasn't clear to me until just now that your config changes are small changes you never push. If you stated that before, I'm sorry.

Given your use case I agree with you, this is not an either-or proposition. And anyway, it's perfectly fine to leave all of this as my stupid opinion, and I don't want you to feel like you need to defend your use of stash. You clearly understand the issues and know how to use it.

In my mind, the only thing wrong with stash is how it's implemented, not its interface. I wish it had easier ways to recover, and I bet you did too that first time you used it.

Maybe the funniest part of this is I've been avoiding stash completely for years, but the threads for the last two days have convinced me there are some nice uses of stash that I may start adopting. A couple of them even increase safety! I do keep config changes around, and I like to name them with a tag or a branch, but I'm going to try stash and see if I prefer it.

Peace!

Re: Gitless: a version control system

#378

Post by chiefalchemist »

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

True. But the argument breaks down (for me) when you consider all the computing power we have, what we're building (i.e., lack of dog fooding), etc. and this must learn tool is the best we got.

NO ONE would use Photoshop or Ableton if they're were as messy as Git. Nuff said.

Re: Gitless: a version control system

#379

Post by eridius »

influx wrote: post #355
slowmovintarget wrote: post #350

Earlier quoted context omitted.

Git is a powerful, professional tool that requires some effort, primarily because the UI was accumulated, not designed.

It also was designed for a use case that almost no one actually does which is distributed version control. Most people use it like a svn with better branching and merging.

Everybody who's ever forked a project on GitHub is using it as distributed version control, and that's a lot of people, so I don't know why you say almost no one actually does distributed version control.

Re: Gitless: a version control system

#380

Post by eridius »

tadfisher wrote: post #240
k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

git wasn't designed to be used by humans. I can't find the quote, but Torvalds said at one point that intention of Git was to provide a content-addressable graph that more human-friendly tools could build upon for different use cases. Those 10 commands are the beginning of the iceberg when you actually start using git with teams. Where are `rebase`, `merge`, `branch`, etc? These are all commands I use daily, they are…

Git wasn't originally designed to be used by humans. There was a separate "porcelain" built on top of git, but I no longer remember what it was called. But enough people wanted to just use git proper without the porcelain that the git core commands evolved into a porcelain themselves, and the separate porcelain layer was deprecated.
Post reply on HN