If it only lets you select one, that's strictly less powerful. What if I want some parts of it into one commit and another parts into another? The `hg absorb` works for this case.
Yeah, it's definitely less powerful that what absorb is doing. I wasn't trying to argue that it was equivalent. I just wanted to share a bash one-liner that I've had success with in case others find it helpful.
> What if I want some parts of it into one commit and another parts into another?
Looks like absorb will automatically break out every hunk into a separate fixup commit. My one-liner will create 1 fixup commit for everything that's staged. That's typically what I need, but on the occasions it's not, I use `git add -p`, as kadoban mentioned, to stage exactly what I want for each commit.
Oh, hrm, looking at this description and the one liner, I rather like.
Once you mentioned `git add -p` I realised that this is pretty much what I do already, except with a far more efficient way of selecting the relevant commit to do it to.
Then you use `git gui`, which is part of the git distribution itself, or `tig` if TUIs are your thing. I have a key binding for `git commit --squash=%(commit)` in my tig config, so I can interactively select lines or hunks to stage and then the target commit for the squash.
That still requires you to manually select hunks. The point of `hg absorb` is to automatically select hunks even if these hunks are to be squashed into different commits.
# make a fixup commit for the last time the file was modified
cff = "!f() { [ -n $@ ] && git add $@ && git commit --fixup $(git last-sha $@); }; f"
# Get latest sha for file(s)
last-sha = log -n1 --pretty=format:%h --grep 'fixup!' --invert-grep
Given a file like `git cff path/to/file.rb`, It'll find the last commit that touched that file, and make a fixup commit for it. Its great for the try-this-change-on-CI cycle: Change the Dockerfile, git cff Dockerfile, push, repeat, without it screwing up because you changed a different file while you were working on it.
It won't matter until it does, but $@ expands arguments into separate words but those expansions are themselves only word-preserved if the $@ is itself quoted. The [ will probably get away with what you want, but its use in $(git add) and $(git last-sha) almost certainly will not
$ cat > tmp.sh <<'FOO'
for a in $@; do echo "a=$a"; done
echo
for b in "$@"; do echo "b=$b"; done
echo
for c in $*; do echo "c=$c"; done
echo
for d in "$*"; do echo "d=$d"; done
echo
FOO
$ bash tmp.sh 'alpha beta' $'charlie\ndelta'
a=alpha
a=beta
a=charlie
a=delta
b=alpha beta
b=charlie
delta
c=alpha
c=beta
c=charlie
c=delta
d=alpha beta charlie
delta
Your alias seems like a completely unecessary complexity. If you want to meld new changes into your branch head you can just alias “git commit --amend”, you don’t need that mess.
Absorb will find the commits to fix up for each change in the working copy, it doesn’t just merge everything into the head.
I see, the reason it’s that long complicated alias was that I didn’t want to open up the editor to change the commit every time I updated. “git commit —amend” does that.
I read the rough how it works and it now makes sense. I might give it a try. Thanks!
That is correct, and there is a `--edit` to revert that, so my personal alias is to `git ci --amend --no-edit` such that by default it just merges the staging into the HEAD, and then tacking on `-e` will open the commit message in an editor to expand it.
This was 100% my inspiration. I used emacs+magit for years. After switching away from emacs for dev work, I still cracked it open for git interactions for another year or so. Eventually, I moved entirely to the shell with a bunch of aliases to replicate my magit workflow.
> A team I worked with in the past came to the same conclusion - turning authorization rules into WHERE clauses is a very efficient way to solve this problem, if you can figure out a clean way to do it.
For rails specifically, https://github.com/polleverywhere/moat was built with this in mind. It's heavily inspired by Pundit, but let's you write policies at the `ActiveRecord::Relation` level. So `policy_filter(Article).find_by!(id: params[:id])` would run something like `select * from articles where id = ? and id in (select id from articles where owner_id = ?);`.
Another option would be for the B to dispatch a `CustomEvent` on itself. That event will bubble up the DOM until it hits A. A would then need an event listener that would probably stop propagation and do whatever bookkeeping is necessary.
This seems like the best option, because it works just as well if the child components are loaded async (Ie: a tab component loading sub tabs on hover, and then the parent tab container needing to subscribe to that)
I never used the old trending page, but it sounds like the Changelog Nightly newsletter [1] is basically the same thing. It goes out every day at 9PM Pacific. It has 3 sections:
- most starred repositories that haven't been in the newsletter before
- most starred repositories that were created that day
Poll Everywhere (YC S08) has Q&A question support with voting. I'm a developer at Poll Everywhere and we use it during our weekly townhalls. Our company was 40% remote before the coronavirus crisis, and my experience with the Q&A poll as a remote worker has been great.
We've been following conventional commits for our front end code for the last year or so at my work. In other repositories, we've loosely followed the keep a change log conventions. I find conventional commits great when your repository will produce a package to be consumed by others. For example, conventional commits for our shared JS code helps us produce great change logs and helps us easily follow semver for the NPM packages our other applications use.
However, I don't find it that useful in the the final applications, even counter productive, since it typically will take up quite a bit of space in the commit title. Many of our front end devs completely ignore title length conventions now.
Why don’t they put the additional information in the body of the commit?
I see this in nearly every company I go to - everyone rushing to skip over adding anything useful to the permanent log by using git commit -m rather than a plain got commit.
This is the place where (mentioned elsewhere in this thread) things like issue tracker links and other context can and _should_ go if you're using something like CC.
Oh, we do. We are generally pretty great at filling in good details in the body. I didn't mention that originally because I didn't think it was noteworthy.
The main problem is very commit titles that end up looking like:
feat(SomeScope.OtherScope.Class): add support for abc and xyz option
FiveThirtyEight did a great podcast series on gerrymandering in 2017 [1]. It turns out to be a much more complicated topic than I expected. Some gerrymandering is even legally required to ensure proper representation of minority groups even if they live in somewhat distributed communities.
Which is so hilariously misguided it might be taken as a form of racism. By lumping minorities into a single candidate they create a token representative who has a very safe seat but no power in the state senate and allow all other candidates to effectively ignore that minority entirely. They don't have to worry about angering 5% of their electorate and losing the next election by a 2% margin.
If political issues actually split along the 95%/5% lines that correspond to that minority, then the 5% are effectively voiceless however you cut it. Another possibility is that most issues aren't about that minority group and you see something like republican:democrat:minority::42:43:5 split. Now the rep for that 5% has a ton of leverage to exchange, eg, votes for republican issues in exchange for republican support for minority issues.
Now let's take the other extreme. You split the minority population among 10 different seats where their population in each district is so small that their interests are ignored entirely in each one.
That's what coalition-building (an important feature of other governmental structures used outside the US) comes in. You generally have a bunch of small minority groups all over the place, but if they work together ("hey, we'll support your group's big issue if you support ours"), they can form a large enough voting bloc that their issues get traction.
If your population is relatively balanced then you need to worry about everybody because every vote might count. Sure a minority might only be 5% of the population, but if you anger them and they vote for your opponent that could absolutely change the outcome of an otherwise close race.
The original point of having districts was because states are "too large" and you want people representing an even smaller geographical area so that truly local issues are represented.
And in many places that's still the case, and is actually useful and important to get local issues surfaced properly.
For states with heavily gerrymandered districts, though, I agree: might as well just do away with districts and have the entire state vote for their entire roster of representatives.
So instead of making a choice between 2-5 candidates (major 2 plus a few independents/smaller parties), every voter has to rank up to 50 candidates (assuming ranked choice voting)? How do you expect voters to know the policy positions of that many candidates? They may as well be picking at random.
If not ranked choice voting, how would this even work?
If you're going to have a large multi-member district with proportional representation, it's not essential to use ranked-choice voting - you can get a reasonable result just by having people vote once for the ticket of candidates they prefer, then allocating the seats proportionally.
That said, ranked-choice voting in large multi-member districts is certainly possible: It is usual to require voters to rank only as many candidates as there are vacancies, though they can number more if they wish to (consequently they don't need to understand the detailed policy positions of the minor candidates that have no realistic chance of election). Voters in such systems tend to firstly order the parties based on the policy positions of those parties, then order the candidates within those parties if they have a strong opinion of the relative merits of those candidates.
I'm not sure what you're suggesting. Individual districts are going to have problems the the rest of the state or country don't know/care about. Having a representative for these districts makes sense.
For example, in my district (Brownsville in Brooklyn), we have an almost tragically poorly-ranked school system, due largely to bad funding and high crime rates in the area. I don't expect someone from Midtown Manhattan to care a whole lot about these specific problems (I know I certainly didn't when I lived in Washington Heights).
In an ideal world I guess I'd agree, everyone would care about everything at the exact appropriate weight, but that's not the world we live in. Certain problems will go ignored if we don't have fairly-granular representation for an area.
That's not a great example because really the school budget should be set at the state level and distributed evenly to every district based on student headcount.
You do make a valid point that many issues are local and that could be lost in a system where the party is focused at the state level instead of the local level. Proportional representation systems are prone to having this issue for example.
Some areas are going to require more funding than others. For example, certain areas are wealthier and as a result are less reliant on the after-school programs, while poorer areas have a higher likelihood to be single-parent, or both parents having to work, meaning that the after-school programs are vital.
That's just one example, but it's not as simple as "give a certain amount of money per kid to the schools", and saying this is reductionist.
I think America really likes them because the alternative seems like "virtual representation" (i.e. representatives represent everyone, not a local district), which was part of why they rebelled against England. The theory is you want someone to represent your local area specifically rather than all representatives trying (badly) to balance the needs of everyone.
I don't know what the difference would really be in practice, although I think the other comments in this thread about lack of proportional representation would probably apply. I think it sort of comes down to how much worse you think Tyranny of the Majority is than what we have currently (or if you want an actual proportional representation system instead).
Because otherwise every voter would need to cast a vote on every single candidate for every single seat in the legislature. It's impossible to make informed choices with so many options.
State representation usually clusters around class issues not ethnicity. And even if it didn’t, why arbitrarily focus on ethnicity? Handicapped people need representation, yet we don’t draw districts that ensures they get one. And if we did, and started splitting votes by who we think need the most representation, we might as well do away with democracy and start arbitrarily arranging representatives.
This is one reason why proportional representation is a better system. Parties can form to represent different types of interests, and their power is proportional to the number of votes they get. Instead, in the American winner-takes-all electoral system, the Supreme Court decides which groups need representation and mandates that they get gerrymandered districts.
Although I believe it was a good idea to remove them, I miss the vote score shown on comments. I had a script that would highlight the top comments. This would frequently reveal insightful comments 2 or 3 levels deep in a random thread I would have otherwise missed.
> gfx='git commit --fixup $(git log $(git merge-base main HEAD)..HEAD --oneline| fzf| cut -d" " -f1)'
It shows you the commits on the current branch and lets you select one via fzf. It then creates the fixup commit based on the commit you selected.