Find out what you, or someone on your team, did on the last working day(github.com)
github.com
Find out what you, or someone on your team, did on the last working day
https://github.com/kamranahmedse/git-standup
45 comments
I sort of feel the same way. If it's meant to work within the node ecosystem, go for it, but if not, just ship an executable.
Of course, the reason this is happening is that there's a bunch of people now writing command line tools in JavaScript because that's what they use and know. Just like in the past (and now) there were a bunch of people doing it in Perl, Ruby, etc.
It's definitely not very UNIX-y in its ethos, but I can understand why it happens.
Of course, the reason this is happening is that there's a bunch of people now writing command line tools in JavaScript because that's what they use and know. Just like in the past (and now) there were a bunch of people doing it in Perl, Ruby, etc.
It's definitely not very UNIX-y in its ethos, but I can understand why it happens.
On that topic this tool has a built in directory searching, but why bother doing that when there already exists a generic git tool to execute any git command in multiple git repositories? You could run 'git map standup' and see it for all of the repos
> By default the script searches only in the current directory or one level deep. If you want to increase that, use the -m switch. $ git standup -m 3
> By default the script searches only in the current directory or one level deep. If you want to increase that, use the -m switch. $ git standup -m 3
`git map` isn't a built-in git command.
Making command line tools in node is pretty awful in my experience.
Node is meant to be used async, which makes simple dev tools like looping over a bunch of .zips and extracting them a total pain. Pretty much every library or method of doing something in node.js is going to lead back to promises, and the second that happens your entire app becomes promises. Its massive overkill for most small dev tools.
Node is meant to be used async, which makes simple dev tools like looping over a bunch of .zips and extracting them a total pain. Pretty much every library or method of doing something in node.js is going to lead back to promises, and the second that happens your entire app becomes promises. Its massive overkill for most small dev tools.
I'd argue async/await is almost no overhead, code flow becomes synchronous again.
The code linked to is written in bash and doesn't require nodejs.
Yes, but it's packaged and distributed via npm: https://www.npmjs.com/package/git-standup. (And note the package.json in the repo.)
Agreed, but I'm not bothered if the tools' sole purpose is to run - on the same hardware - software whose own minimal requirements make installation the CLI runtime env a trivial addition.
I have never written anything in Node so can't comment directly on whether it's a good language for CLI tools, but:
> Command line tools are minimal and should be usable on bare-bones systems
I disagree. I run a very graphical desktop, but nonetheless have a strong preference towards CLI tools when they are for relatively simple tasks.
I think this tool makes sense as a CLI tool rather than as a non-CLI tool. Given that, the question comes down to "given that this will be a CLI tool, what language should the author have used?". In almost all cases, unless portability is a string concern, this comes down to personal preference.
> Command line tools are minimal and should be usable on bare-bones systems
I disagree. I run a very graphical desktop, but nonetheless have a strong preference towards CLI tools when they are for relatively simple tasks.
I think this tool makes sense as a CLI tool rather than as a non-CLI tool. Given that, the question comes down to "given that this will be a CLI tool, what language should the author have used?". In almost all cases, unless portability is a string concern, this comes down to personal preference.
I know you can expect the source code, but this trend of pasting things into the terminal with sudo is crazy:
> curl -L https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh
> curl -L https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh
Especially in light of the recent article and discussion "Tactics, Techniques, and Procedures of the Yahoo Hack" https://news.ycombinator.com/item?id=13921524
JSP shell committed into Git, self-approved, and queued for deployment
JSP shell committed into Git, self-approved, and queued for deployment
(I meant inspect, not expect)
My much less polished bash script:
$ tt 2017-03-21
repo1 author date
commit desc
commit desc
repo2 author date
commit desc
function tt {
local day=$1;
local d=$PWD;
local buf="";
echo $day;
cd $GR;
for i in *; do
local p=$GR/$i;
if [ -d "$p/.git" ]; then
cd "$p"; whatup $day
fi
done
cd $d;
}
function whatup {
local day="$1"
if [ "$day" = "" ]; then
day=`date +'%Y-%m-%d'`
fi
local author="$2"
if [ "$author" = "" ]; then
author="amichal"
fi
local dir=`basename $PWD`;
local msg=`git log --all --author $author --oneline --since="$day 00:00:00" --until="$day 23:59:59.999"`
if [[ ! -z "${msg// }" ]]; then
echo "$dir $author $day"
echo "$msg"
echo "----------"
fi
}I love those exciting stand-ups where you tell everyone what you did yesterday
Yes, it reminds me of primary school. I love being treated like a small child.
Especially in a remote company, do you have a better idea how to spread knowledge?
Standup listing what you did kind of sucks. But also literally knowing 0 about what anyone else in the team is working on also sucks. Unless you literally just want to be handed a pile of Jira tickets by a PM and told to fix them? But that seems not a very healthy environment.
Something like this post where you dump a git log of what each person pushed could get maybe the boring part of standup automated... and then you would only need to report the non code part.. which maybe seems better?
Standup listing what you did kind of sucks. But also literally knowing 0 about what anyone else in the team is working on also sucks. Unless you literally just want to be handed a pile of Jira tickets by a PM and told to fix them? But that seems not a very healthy environment.
Something like this post where you dump a git log of what each person pushed could get maybe the boring part of standup automated... and then you would only need to report the non code part.. which maybe seems better?
Putting aside that most teams in the world aren't remote, do you seriously need to do that daily?
Something more fundamentally wrong is going on if people can't assign work more than a day in advance without stepping on each other's toes.
Daily standups are simply a form of micro-managing, the scrum guys have done a colossal amount of harm to our industry.
Something more fundamentally wrong is going on if people can't assign work more than a day in advance without stepping on each other's toes.
Daily standups are simply a form of micro-managing, the scrum guys have done a colossal amount of harm to our industry.
> Putting aside that most teams in the world aren't remote, do you seriously need to do that daily?
Have you worked both remote and in person? In person you generally see people every day. Remote you do mot.
> Something more fundamentally wrong is going on if people can't assign work more than a day in advance without stepping on each other's toes.
Not always about assigning work. What if you are working on some task, and to fix a bug you need to refactor something. How do you spread that knowledge? Code review by entire team? Slack blast? Stand-up announcement? Somehow you should want to manage that..
> Daily standups are simply a form of micro-managing, the scrum guys have done a colossal amount of harm to our industry.
Scrum is a tool. It can be used well, and it can be used poorly. There are times when over-communication (what scrum tends towards) is very good. There are times when it is bad. I think remote it can be better to slightly over vs slightly under-communicate.
Have you worked both remote and in person? In person you generally see people every day. Remote you do mot.
> Something more fundamentally wrong is going on if people can't assign work more than a day in advance without stepping on each other's toes.
Not always about assigning work. What if you are working on some task, and to fix a bug you need to refactor something. How do you spread that knowledge? Code review by entire team? Slack blast? Stand-up announcement? Somehow you should want to manage that..
> Daily standups are simply a form of micro-managing, the scrum guys have done a colossal amount of harm to our industry.
Scrum is a tool. It can be used well, and it can be used poorly. There are times when over-communication (what scrum tends towards) is very good. There are times when it is bad. I think remote it can be better to slightly over vs slightly under-communicate.
Nothing that can be learned from tools belongs in a standup—or any meeting—unless it's especially notable. Spend a morning automating the reporting of it to email or IRC or Slack or whatever (god, email, please) and forget about it.
[deleted]
What happens if someone's name is "all"
Security policies don't sound right.
Leaving first employer: Sit in a windowless room with a newspaper and several other people also with feet on desks also reading newspapers, riding out 90 days of resignation notice looking forward to next job. Fully paid, needing to turn-up 4 hours per day mainly centered around lunch, which included a break and had social time with soon-to-be former-colleagues. Cannot in any way be associated with future employer during these 90 days: meetings, personal interaction, emails, visits, anything.
Edit: For those that think this doesn't sound right, think of your access to market-sensitive information, and a loyalty exists with the soon-to-be former employer. Mitigation of ourselves and the organisation.
I, and others in the windowless room were completely OK with this set-up of arrangements, as were our future employers who knew this on signing us. Not a non-complete clause in any way, simple prudence.
Leaving first employer: Sit in a windowless room with a newspaper and several other people also with feet on desks also reading newspapers, riding out 90 days of resignation notice looking forward to next job. Fully paid, needing to turn-up 4 hours per day mainly centered around lunch, which included a break and had social time with soon-to-be former-colleagues. Cannot in any way be associated with future employer during these 90 days: meetings, personal interaction, emails, visits, anything.
Edit: For those that think this doesn't sound right, think of your access to market-sensitive information, and a loyalty exists with the soon-to-be former employer. Mitigation of ourselves and the organisation.
I, and others in the windowless room were completely OK with this set-up of arrangements, as were our future employers who knew this on signing us. Not a non-complete clause in any way, simple prudence.
Plain old `git log` can handle most of this, if you care less for a nice interface.
git log --author="[email protected]" --since=1.days
You can of course tweak the way that git log outputs too, to make it more readable.
Something like:
git log --pretty=format:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset --abbrev-commit
can make it quite pretty.
git log --author="[email protected]" --since=1.days
You can of course tweak the way that git log outputs too, to make it more readable.
Something like:
git log --pretty=format:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset --abbrev-commit
can make it quite pretty.
Similarly I came up with some aliases long ago in my git config:
day = log --all --abbrev-commit --date-order --date=relative --since='one day ago' --stat
day-more = log --all --abbrev-commit --date-order --date=relative --since='one day ago' -p -w
weekend = log --all --abbrev-commit --date-order --date=relative --since='three days ago' --stat
weekend-more = log --all --abbrev-commit --date-order --date=relative --since='three days ago' -p -wWhile I don't disagree, I still value tools like what the author posted. git log is a pretty powerful thing, and can do a lot of things; sometimes, it can do so much as to make it harder to see what you should do with it, and it's nice to see people's wrappers — even thin ones — that handle concrete use cases like this.
His examples seem …prolific. I mildly hope his tool outputs something like "No commits for this author; must be out shaving the yaks" on the days when someone has nothing to commit. Perhaps he is working on a nicer code base than I.
His examples seem …prolific. I mildly hope his tool outputs something like "No commits for this author; must be out shaving the yaks" on the days when someone has nothing to commit. Perhaps he is working on a nicer code base than I.
This tool wraps git log and offers multiple repository logging.
`$ curl -L https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh
`
nice. this shit again
nice. this shit again
I see this comment a lot regarding piping an untrusted script to a shell with sudo permissions. Do you feel much safer downloading something as a package (maybe installer executable) and then running it with sudo? What's to prevent the same kind of dangers as the scripted version? At least with the scripted version I can quickly glance at it and figure out all that it does, rather than try to unpackage an installer exe.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
This outlines a POC for detecting whether your script is being downloaded or piped into Bash. Beware.
This outlines a POC for detecting whether your script is being downloaded or piped into Bash. Beware.
Good point, but the domain `raw.githubusercontent.com` is a dumb CDN that a possible attacker cannot control.
Can you say the same about raw.gjthubusercontent.com ?
Also, the attacker can push an update if they can successfully guess the window between you reviewing a file and you installing a file. Not nearly as reliable as that POC, but hardly impossible.
Best to avoid building bad habits. Perhaps worthwhile to build good ones - even when it's "safe" to skip.
Also, the attacker can push an update if they can successfully guess the window between you reviewing a file and you installing a file. Not nearly as reliable as that POC, but hardly impossible.
Best to avoid building bad habits. Perhaps worthwhile to build good ones - even when it's "safe" to skip.
I think your point about building good habits is really worth thinking about for anyone that thinks they can evaluate the entire set of risks every time they do something like this. Or pretty much anything really. You can't count on always having the clarity of mind you have at this moment. It's easy to get distracted and good habits protect you when you're vulnerable, not when you're at 100%.
Never, ever run a cli command from a website on the Internet that pipes through sudo...ever. There's nothing to save the latter, it's just not as common, and if you don't know the origin, the same advice applies: don't do it. Anyone executing a random executable is being stupid. Difference is, anyone directing users to install via a sudo piped command is just plain irresponsible. Don't ask your users to do something so daft!
Can't you checksum verify installers and packages? You can't do that with these curlpipesudos.
You are taking a leap of faith anytime you install something however you do it. The problem with the CPS seems to me that it's much easier for you to correctly trust the originator of the content, but have the content hijacked by a 3rd malicious party.
You are taking a leap of faith anytime you install something however you do it. The problem with the CPS seems to me that it's much easier for you to correctly trust the originator of the content, but have the content hijacked by a 3rd malicious party.
Checksum from where? The same site you download it from? What's the point?
Does anyone regularly use checksums as part of their 'routine' for downloading normal, or special files?
It seems like a great system, that isn't used regularly by people in my circle.
It seems like a great system, that isn't used regularly by people in my circle.
There's nothing at all wrong with this.
I'd say 99.999% of the time someone runs an installer script to install something, they don't read it first. And if you're not reading the script first, then there's no benefit whatsoever to downloading it prior to executing, as opposed to just executing directly. The only reason to say "don't pipe into sh" is if you're saying "review the installer script 100% of the time before executing it", which, honestly, is advice nobody's going to follow.
I'd say 99.999% of the time someone runs an installer script to install something, they don't read it first. And if you're not reading the script first, then there's no benefit whatsoever to downloading it prior to executing, as opposed to just executing directly. The only reason to say "don't pipe into sh" is if you're saying "review the installer script 100% of the time before executing it", which, honestly, is advice nobody's going to follow.
> There's nothing at all wrong with this.
Sure, no server has ever been compromised and his binaries replaced... The good old pgp signatures, circle of trusts, etc are not for show. Eck, it's not even served from github.com but from a random proxy
Sure, no server has ever been compromised and his binaries replaced... The good old pgp signatures, circle of trusts, etc are not for show. Eck, it's not even served from github.com but from a random proxy
Nothing you're describing applies to the scenario of "download, then execute" either, which is the alternative to "pipe to bash".
Anyone who's willing to read the script first, or verify PGP keys, or whatnot, is perfectly capable of doing so even if the instructions tell you to pipe to bash. But the overwhelming majority of people don't do that.
Anyone who's willing to read the script first, or verify PGP keys, or whatnot, is perfectly capable of doing so even if the instructions tell you to pipe to bash. But the overwhelming majority of people don't do that.
I feel this comment would be more justified if they didn't mention three other ways to install the tool.
This would be much more useful if it also polled calendars and code reviews!
In Mercurial:
hg log --rev "date(yesterday)" --template "{shortest(node, 6)} - {desc|firstline} ({date|age}) <{author|person}>\n"
This shows off both revsets (the language parsed by the --rev option) and templates (the language parsed by the --template option). The revset can be modified into "date(yesterday) and user(jordi)" to limit it to only a particular user.
As it stands, this revset+template combination won't colourise the output. For that we need to add labels to the template:
hg log -r "date(yesterday)" -T "{label('changeset.{phase}', shortest(node, 6))} - {label('log.summary', desc|firstline)} ({label('log.date', date|age)}) <{label('log.user', author|person)}>\n"
At this length, it starts to look unwieldy, but it should go into your hgrc anyway, where you can easily split it into multiple lines without having to worry about shell quoting. Here are more details about the general method:
http://jordi.inversethought.com/blog/customising-mercurial-l...
hg log --rev "date(yesterday)" --template "{shortest(node, 6)} - {desc|firstline} ({date|age}) <{author|person}>\n"
This shows off both revsets (the language parsed by the --rev option) and templates (the language parsed by the --template option). The revset can be modified into "date(yesterday) and user(jordi)" to limit it to only a particular user.
As it stands, this revset+template combination won't colourise the output. For that we need to add labels to the template:
hg log -r "date(yesterday)" -T "{label('changeset.{phase}', shortest(node, 6))} - {label('log.summary', desc|firstline)} ({label('log.date', date|age)}) <{label('log.user', author|person)}>\n"
At this length, it starts to look unwieldy, but it should go into your hgrc anyway, where you can easily split it into multiple lines without having to worry about shell quoting. Here are more details about the general method:
http://jordi.inversethought.com/blog/customising-mercurial-l...
I understand many don't agree with this, but this is my preference / opinion.