On Sun, 21 Jun 2020 15:20:39 +0000, Johnny Billquist wrote: ... > >40. And you can abbreviate as far as they stay unambiguous. > > And it's still not anything you would want to type at all.
Yes, but. There are lots of ways to reference commits, like 'two before the current commit on this branch', but in the end, if you want to reference a random commit, you have a random address - a hash in git, a revision number in svn, and, well, nothing in cvs. ... > I am still curious about how to manage well in git the scenario where > you do have a central repository that holds the actual source of truth, > and where you want to review and approve anything that gets committed. That depends on how you want to work - in git is the usual way that you commit your work, in reasonable steps, and then hand that out for review. For git itself this means posting the diffs of each commit to the git mailing list. (Unsurprisingly there are tools for that within git.) For the workflow in our company this means pushing your commits on a personal branch, creating a pull request, and discussing the changes inside that pull request and making changes until all reviewers are happy; then that is ready for integration. In git you usually don't review changes *before* you commit them. > The gains of local repositories certainly diminish in the light of that, Not really. You wouldn't want to work with any central VCS once you're 250ms away from the server. > but it does add potential issues in keeping things in sync, getting > committed and shared. Yes, 'potential'. For a company setting, you avoid these by providing scripts for the standard workflow actions. You'll need - or at least want - these, independent of whether you work with clearcase, svn, or git, as soon as you don't all work on a single branch. > As I mentioned, we are using gerrit for this where > I work. But that is certainly not without a lot of pain. I've never seen gerrit up close, and my hearsay indicates it's a mixed bag. (We use hosted bitbucket, which so far is a pleasant experience.) PS: Reading up a bit on gerrit, it seems to use a patch-based model, with reworking the patches (i.e. amending commits). That can be daunting for beginners. > If you use something like github, then you will be using their systems > and mechanism for this, and if you are forced to switch, then this also > gets hit. Yes, but you don't lose your history or your current work; 'only' the open pull requests. With an hypothetical svnhub you'd also lose the history and have to set up a new server, totally invalidating all the dev's workspaces. With git, the transition can be much smoother, even in the case github goes bellyup instantaneously (e.g. you are kicked out as a customer). > Which was my point. It's not that you have "pure" git in the > first place. If you use some external service, you will also be > dependent on surrounding infrastructure provided, If you choose so. But it's the same with internal infrastructure. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
