>> the [branch] history after the branch is merged
> Regular commit IDs do that -- although it stores repos and full history, Gerrit doesn't really care about changeset-id's once they're merged.
In git itself, related commits in a branch can be identified using the merge commit, because that commit's parent commits correspond to the head commit and base commit of that branch. So to look at the commits in a branch after it had been merged, you can do something like:
git log merge-commit^1..merge-commit^2
This allows you to see the per commit changes as well as the overall change introduced by the branch. You mentioned that gerrit tracks that chain. Since it's not via change-set ids, then does it keep track of related commits in a branch?
So, if you implement a feature that involves multiple commits, when you push the branch up, will all the commits in the branch have the same changeset-id? If not, how is the relation between commits on a branch maintained during review and in the history after the branch is merged?
> So I always try to commit and document as I go. At that point I don't spend a lot of time getting the commit messages perfect, but I make sure they at least have all my thoughts. Before I push up the commits, I'll use "git rebase -i" and "reword" to edit the messages (typos, reformatting the text, maybe adding additional thoughts as I look at the diff).
I actually don't bother with committing anything to version control until I'm done with the feature or fix. I then will create a diff against the base branch and stage each individual part and create a commit from it. I then push up those commits to the remote.
> It drives me crazy how hostile GitHub is to reviewing individual commits.
I actually have an ingrained habit of middle-clicking on the commit sha1 and add my comments on the commit itself. It doesn't really show up with any context in the main PR view though.
Lately, I've started running git log -p --reverse origin/master.., piping the output into vim, prefixing every line with '>' and typing my comments inline like I would with an email message (trimming the parts that I'm not responding to), and then pasting the entire thing in a single comment on Github.
> Frankly Gerrit is a better-designed review tool, but it's not widely used.
I actually wish more pepole would use the email patch review process. At least there, reviewing individual commits is the default and the relation among multiple commits is preserved. I'm not sure how that's accomplished in Gerrit.
> In squash workflow, the PR is the context and the unit of change. It’s shoehorned onto git only because of GitHub.
This could be useful if a PR is essentially changing only one thing like a commit should, but since PRs usually cover a feature or a fix for a ticket, these frequently involve doing multiple things to implement the feature or fix the bug.
> the [option of enforcing the quality of commits in a PR] does not provide any practical benefits for the process (rather than theoretical “but we’ll have individual commits when 5 years later someone blames them”),
Your parenthetical clause is not theoretical. It's basically a thing I have to deal with on a daily basis when I'm fixing bugs or removing/adding features in multiple code bases that were written by people years ago who no longer work there. I can't really make use of git blame because the commit messages are non-informative, the diffs are just work in progress saves, and the linked PRs just have looks good to me comments and no description.
But for code bases where commit quality was enforced, git blame actually becomes useful and allows me to see what was done and why it was done at the time it was written.
This may be difficult due to the fact that the defendant and plaintiff are in different countries. The costs for pursuing this action may well exceed the actual loss.
In the late '90s up through 2010 or so, one's ISP would provide instructions for configuring one's mail and news clients to access their email and usenet. From there, the client would show a list of groups and you could choose which ones to subscribe to.
> nobody expected their postings to live beyond the spool expiration lifetime.
I know that a number of posters in groups I used to frequent added the X-No-Archive: yes header to their posts in the early 2000s. The Google and Deja news archive before it did honor that header apparently.
I think this may have been an attempt at humor by ruined where the post they made employs similar phrasing that dang uses when he's informing a user about a violation of the HN guidelines.
Astraweb's landing page states they have 4000 days of retention (which corresponds to March 2010 as of the time of this post). I guess certain text groups have signfiicantly longer retention times.
> No ISP I have used in recent years does. They have all been switched off, with the ISP citing low levels of use.
The event that lead to a lot of ISPs dropping their NNTP service was when Andrew Cuomo, when he was the attorney general of New York, made a deal with several ISPs to block access to child porn[1].
But if you want to find a particular post, it really depends on the retention policy of the server you use. Free ones may have a year of retention. Commercial one's have 12 years or so. The only one that I know of where one can find posts further back than that is Google groups.
I'm actually a member of several active public and private groups on Facebook where many posts have informative discussions. I rarely ever look at my newsfeed though. If I only had the newsfeed, I would have dumped Facebook long ago.
> The email ecosystem still didn't evolve into a format where we can safely transit binary data around.
The only significant characters in email are carriage return, line feed, and period. There's also a line length limit in the SMTP protocol specification. Other than that, bytes sent during the DATA phase are sent unaltered.
Base64 encoding is meant to address this, but it results in a 33% overhead in attachment size. On the usenet side, people came up with an encoding scheme called yenc that actually only escapes those characters mentioned above and only as a 2 to 3% overhead over the original file size.
> The shortcomings of IMAP and POP are reflected in all mail clients and is a large part in what has made webmail so popular.
Could you elaborate on this? I personally find using a mail client like Thunderbird to access my mail account far more responsive and seamless compared to using the webmail interface. If I don't have much bandwidth to work with, the local mail client using IMAP and SMTP will work while the webmail client will experience timeouts.
> Regular commit IDs do that -- although it stores repos and full history, Gerrit doesn't really care about changeset-id's once they're merged.
In git itself, related commits in a branch can be identified using the merge commit, because that commit's parent commits correspond to the head commit and base commit of that branch. So to look at the commits in a branch after it had been merged, you can do something like:
This allows you to see the per commit changes as well as the overall change introduced by the branch. You mentioned that gerrit tracks that chain. Since it's not via change-set ids, then does it keep track of related commits in a branch?