8 ms·

Find out what you, or someone on your team, did on the last working day

85 points by sdomino 10y ago

Linell 10y ago
Plain old `git log` can handle most of this, if you care less for a nice interface. git log --author="tlbonnette@gmail.com" --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.
- deathanatos 10y ago
  While 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.
- Zikes 10y ago
  This tool wraps git log and offers multiple repository logging.
- mmagin 10y ago
  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 -w
_RPM 10y ago
`$ curl -L https://raw.githubusercontent.com/kamranahmedse/git-standup/master/installer.sh https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh ` nice. this shit again
- nuggien 10y ago
  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.
  - scaryclam 10y ago
    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!
  - toothbrush 10y ago
    https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ 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.
    - lifthrasiir 10y ago
      Good point, but the domain `raw.githubusercontent.com` is a dumb CDN that a possible attacker cannot control.
      - MaulingMonkey 10y ago
jmtulloss 10y ago
This would be much more useful if it also polled calendars and code reviews!
jordigh 10y ago
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-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l...
nkkollaw 10y ago
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/master/installer.sh https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh
- j_s 10y ago
  Especially in light of the recent article and discussion "Tactics, Techniques, and Procedures of the Yahoo Hack" https://news.ycombinator.com/item?id=13921524 https://news.ycombinator.com/item?id=13921524 JSP shell committed into Git, self-approved, and queued for deployment
- erelde 10y ago
  Plus, why would we install a bash script as sudo ?
  - eridius 10y ago
    I didn't look at the makefile but I imagine it installs into /usr/local/bin, which usually requires root permissions.
- nkkollaw 10y ago
  (I meant inspect, not expect)
bbcbasic 10y ago
I love those exciting stand-ups where you tell everyone what you did yesterday
- mattmanser 10y ago
  Yes, it reminds me of primary school. I love being treated like a small child.
  - brianwawok 10y ago
    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?
    - ashark 10y ago
      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.
    - mattmanser 10y ago
      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.
      - brianwawok 10y ago
        > 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.
deleted 10y ago
[deleted]
integricho 10y ago
This is not much related to the project itself, but I don't like this recent trend of implementing command line tools in Node. Command line tools are minimal and should be usable on bare-bones systems, without requiring a whole cutting edge runtime to be installed, be it Python or Node or whatever. I understand many don't agree with this, but this is my preference / opinion.
- devwastaken 10y ago
  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.
  - askmike 10y ago
    I'd argue async/await is almost no overhead, code flow becomes synchronous again.
- askmike 10y ago
  The code linked to is written in bash and doesn't require nodejs.
  - bartread 10y ago
    Yes, but it's packaged and distributed via npm: https://www.npmjs.com/package/git-standup https://www.npmjs.com/package/git-standup. (And note the package.json in the repo.)
- bartread 10y ago
  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.
amichal 10y ago
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 }
zhte415 10y ago
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.
benchaney 10y ago
What happens if someone's name is "all"

85 points by sdomino 10y ago

Plain old `git log` can handle most of this, if you care less for a nice interface. git log --author="tlbonnette@gmail.com" --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.

deathanatos 10y ago
While 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.
Zikes 10y ago
This tool wraps git log and offers multiple repository logging.
mmagin 10y ago
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 -w

_RPM 10y ago

`$ curl -L https://raw.githubusercontent.com/kamranahmedse/git-standup/master/installer.sh https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh ` nice. this shit again

nuggien 10y ago
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.
- scaryclam 10y ago
  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!
- toothbrush 10y ago
  https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ 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.
  - lifthrasiir 10y ago
    Good point, but the domain `raw.githubusercontent.com` is a dumb CDN that a possible attacker cannot control.
    - MaulingMonkey 10y ago

jmtulloss 10y ago

This would be much more useful if it also polled calendars and code reviews!

jordigh 10y ago

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-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l...

nkkollaw 10y ago

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/master/installer.sh https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh

j_s 10y ago
Especially in light of the recent article and discussion "Tactics, Techniques, and Procedures of the Yahoo Hack" https://news.ycombinator.com/item?id=13921524 https://news.ycombinator.com/item?id=13921524 JSP shell committed into Git, self-approved, and queued for deployment
erelde 10y ago
Plus, why would we install a bash script as sudo ?
- eridius 10y ago
  I didn't look at the makefile but I imagine it installs into /usr/local/bin, which usually requires root permissions.
nkkollaw 10y ago
(I meant inspect, not expect)

bbcbasic 10y ago

I love those exciting stand-ups where you tell everyone what you did yesterday

mattmanser 10y ago
Yes, it reminds me of primary school. I love being treated like a small child.
- brianwawok 10y ago
  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?
  - ashark 10y ago
    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.
  - mattmanser 10y ago
    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.
    - brianwawok 10y ago
      > 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.

deleted 10y ago

[deleted]

integricho 10y ago

This is not much related to the project itself, but I don't like this recent trend of implementing command line tools in Node. Command line tools are minimal and should be usable on bare-bones systems, without requiring a whole cutting edge runtime to be installed, be it Python or Node or whatever. I understand many don't agree with this, but this is my preference / opinion.

devwastaken 10y ago
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.
- askmike 10y ago
  I'd argue async/await is almost no overhead, code flow becomes synchronous again.
askmike 10y ago
The code linked to is written in bash and doesn't require nodejs.
- bartread 10y ago
  Yes, but it's packaged and distributed via npm: https://www.npmjs.com/package/git-standup https://www.npmjs.com/package/git-standup. (And note the package.json in the repo.)
bartread 10y ago
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.

amichal 10y ago

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 }

zhte415 10y ago

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.

benchaney 10y ago

What happens if someone's name is "all"