"Hashtags"?

[Dave Borowitz]

Wikipedia tells us:

"A hashtag is a word or an unspaced phrase prefixed with the number sign ("#"). It is a form of metadata tag." http://en.wikipedia.org/wiki/Hashtag

"In information systems, a tag is a non-hierarchical keyword or term assigned to a piece of information (such as an Internet bookmark, digital image, or computer file). This kind of metadata helps describe an item and allows it to be found again by browsing or searching." http://en.wikipedia.org/wiki/Tag_(metadata)

What we've called "hashtags" in Gerrit don't meet that definition; they are just "tags". Unfortunately "tag" is a loaded word in git so maybe just calling them "tags" is misleading. Also "hashtag" is a bit of a mouthful :)

I missed this part of the discussion last Monday, obviously. What alternative names were considered?

[Zu, Bruce]

 

As its objective is to mark a bunch related changes

How about

·         Bunch-Tags

·         Bunch-Marks

·         Bunches

 

/Bruce

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ping Yin]

how about label?
Ping Yin

[Zu, Bruce]

'Label' will make developer think of 'verify', 'code-review' ....

[Shawn Pearce]

On Wed, Sep 17, 2014 at 7:39 PM, Zu, Bruce <Bruc...@sonymobile.com> wrote:

'Label' will make developer think of 'verify', 'code-review' ....

Yes, because I had planned to make them the same. But labels with permissions became reserved ones that couldn't be applied randomly.

[Sven Selberg]

> I missed this part of the discussion last Monday, obviously. What
> alternative names were considered?

 

There was a discussion about what to call the feature in this thread [1]. Hashtags where a source of inspiration so naming them just that felt natural since the phrases 'tag' and 'label' where deemed unsuitable due to naming conflicts.

Hashtags are a subset of tags so the tag definition should be applicable for hahstags as well. 

Aside from Gerrit's hashtags not being prefixed with '#' (which we discussed briefly) I can't see in what way they don't meet the definition. 

You'll have to elaborate on why you feel that hashtags are an unsuitable term. 

/Sven

[1] https://groups.google.com/forum/#!topic/repo-discuss/-dHTaWt_LJA

[Goerler, Adrian]

Why not actually allow to use hashtags in commit messages (any word prefixed with #) and pick them up automatically? Manual assignment could still be supported for older commit messages.

Alternatively, how about “keyword” - http://en.wikipedia.org/wiki/Index_term ?

-Adrian

[Selberg, Sven]

Having the hashtags in the commit message could be quite confusing, at least the way hashtags are implemented today. Hashtags can be removed from the change but still present in the commit message.

Work is in progress to allow for them to be supplied in the git push [1].

 

‘Keyword’ is not a bad idea, if there’s a consensus that we should change the term.

I still think hashtag is viable.

 

/Sven

 

[1] https://gerrit-review.googlesource.com/#/c/60106/

[Gustaf Lundh]

Actually, we discussed it briefly during the Hackathon. While I am not sure that this functionality is suitable for core, it should be fairly easy to write a plug-in that parses commit-messages for #TAGS and adds them automatically to the change. I wanted to write one during the hackathon, but there was just not enough time.

Best regards

Gustaf

On Thursday, September 18, 2014 8:38:43 AM UTC+2, Adrian Görler wrote:

Why not actually allow to use hashtags in commit messages (any word prefixed with #) and pick them up automatically? Manual assignment could still be supported for older commit messages.

Alternatively, how about “keyword” - http://en.wikipedia.org/wiki/Index_term ?

-Adrian

From: Sven Selberg <sven.s...@sonymobile.com>
Date: Thursday 18 September 2014 08:26
To: "repo-d...@googlegroups.com" <repo-d...@googlegroups.com>
Cc: "Bruc...@sonymobile.com" <Bruc...@sonymobile.com>, "pkuf...@gmail.com" <pkuf...@gmail.com>, "dbor...@google.com" <dbor...@google.com>
Subject: Re: "Hashtags"?

> I missed this part of the discussion last Monday, obviously. What
> alternative names were considered?

 

There was a discussion about what to call the feature in this thread [1]. Hashtags where a source of inspiration so naming them just that felt natural since the phrases 'tag' and 'label' where deemed unsuitable due to naming conflicts.

Hashtags are a subset of tags so the tag definition should be applicable for hahstags as well. 

Aside from Gerrit's hashtags not being prefixed with '#' (which we discussed briefly) I can't see in what way they don't meet the definition. 

You'll have to elaborate on why you feel that hashtags are an unsuitable term. 

/Sven

[1] https://groups.google.com/forum/#!topic/repo-discuss/-dHTaWt_LJA

--
--

To unsubscribe, email repo-discus...@googlegroups.com

[Thomas Swindells (tswindel)]

I’d definitely appreciate allowing them to be autodetected from the commit message – preferably with the option of also defining regex’s to extract them. Amongst other things this would make searching for issues based on bug or task ids much simpler. The bug: search syntax only works if people have added it to the footer, and message: is slow and doesn’t always return the results – not sure if this is due to how our indexes are set up or the way it does the matching.

 

I’ve not got a problem with messages containing the tag but then people manually removing it – this is probably desirable even when people make mistakes. Its unlikely to happen often enough for people to care, and is easily rectified if someone does do it.

 

Agreed though that a plugin is probably the best way to implement it.

 

Thomas

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

[Selberg, Sven]

It would be inconsistent since you can remove the hashtags from the change and submit it. When reading the commit message you would be misled to believe that you would find the change by searching for the hashtag, but you wouldn’t find it.
Further more it introduces strange behavior. If you push a patchset with hashtags and want to remove them; you’ll have to remove them from the commit message as well (creating another patchset just for the sake of removing a hashtag). Otherwise the hashtag would be recreated with every new patchset (rebase, editing the commit message etc.).

 

If you delete a hashtag (introduced by the commit  message), submit the change without removing the hashtag from the commit message and then cherry-pick the change onto a different branch that would recreate the hashtag on the cherry-pick change.

 

But if it’s implemented in a plugin everyone can choose for themselves, just keep that in mind…

 

/Sven

 

From: Thomas Swindells (tswindel) [mailto:tswi...@cisco.com]

Sent: den 18 september 2014 11:46
To: Gustaf Lundh; repo-d...@googlegroups.com
Cc: Zu, Bruce; pkuf...@gmail.com; dbor...@google.com; Selberg, Sven

Subject: RE: "Hashtags"?

 

I’d definitely appreciate allowing them to be autodetected from the commit message – preferably with the option of also defining regex’s to extract them. Amongst other things this would make searching for issues based on bug or task ids much simpler. The bug: search syntax only works if people have added it to the footer, and message: is slow and doesn’t always return the results – not sure if this is due to how our indexes are set up or the way it does the matching.

 

I’ve not got a problem with messages containing the tag but then people manually removing it – this is probably desirable even when people make mistakes. Its unlikely to happen often enough for people to care, and is easily rectified if someone does do it.

 

Agreed though that a plugin is probably the best way to implement it.

 

Thomas.

[Motti Strom]

Just for the record, a common "commentlink" for Pivotal Tracker already uses #, although typically within square brackets and composed only of digits as in [Fixes #87654321], see https://www.pivotaltracker.com/help/api?version=v3#scm_post_commit_message_syntax.

This might work out being complementary not conflicting as the story IDs then become hashtags too which could be useful.

[Jacek Centkowski]

why not to present them with "#" in the UI - they are kind of a metadata to all patches and definition will be fulfilled ;)

Regards
Jacek

[Lundh, Gustaf]

Hi,

 

I had this in mind when the suggestion of calling it ”Hashtags” was brought up. Even tried it locally, but I just think it looked cleaner in the UI without prefixing the #. But sure, if it could help avoid confusion, then perhaps we should add the “#”.

 

Gustaf

 

From: repo-d...@googlegroups.com [mailto:repo-d...@googlegroups.com] On Behalf Of Jacek Centkowski
Sent: den 18 september 2014 12:44
To: repo-d...@googlegroups.com
Subject: Re: "Hashtags"?

 

why not to present them with "#" in the UI - they are kind of a metadata to all patches and definition will be fulfilled ;)

--

[Saša Živkov]

On Thu, Sep 18, 2014 at 12:36 PM, Selberg, Sven <Sven.S...@sonymobile.com> wrote:

It would be inconsistent since you can remove the hashtags from the change and submit it. When reading the commit message you would be misled to believe that you would find the change by searching for the hashtag, but you wouldn’t find it.
Further more it introduces strange behavior. If you push a patchset with hashtags and want to remove them; you’ll have to remove them from the commit message as well (creating another patchset just for the sake of removing a hashtag). Otherwise the hashtag would be recreated with every new patchset (rebase, editing the commit message etc.).

 

If you delete a hashtag (introduced by the commit  message), submit the change without removing the hashtag from the commit message and then cherry-pick the change onto a different branch that would recreate the hashtag on the cherry-pick change.

These are all very good points. We don't want such inconsistencies, I think.

However, maybe we can still accept the request for automatically creating the hash-tags out of the commit message

but then also make it impossible to delete them in any other way but removing them from the commit message?

Those hashtags which are added independently of the commit message can still be freely deleted.

 

 

But if it’s implemented in a plugin everyone can choose for themselves, just keep that in mind…

 

/Sven

 

From: Thomas Swindells (tswindel) [mailto:tswi...@cisco.com]
Sent: den 18 september 2014 11:46
To: Gustaf Lundh; repo-d...@googlegroups.com
Cc: Zu, Bruce; pkuf...@gmail.com; dbor...@google.com; Selberg, Sven
Subject: RE: "Hashtags"?

 

I’d definitely appreciate allowing them to be autodetected from the commit message – preferably with the option of also defining regex’s to extract them. Amongst other things this would make searching for issues based on bug or task ids much simpler. The bug: search syntax only works if people have added it to the footer, and message: is slow and doesn’t always return the results – not sure if this is due to how our indexes are set up or the way it does the matching.

 

I’ve not got a problem with messages containing the tag but then people manually removing it – this is probably desirable even when people make mistakes. Its unlikely to happen often enough for people to care, and is easily rectified if someone does do it.

 

Agreed though that a plugin is probably the best way to implement it.

 

Thomas.

--

[Thomas Swindells (tswindel)]

From: Saša Živkov [mailto:ziv...@gmail.com]
Sent: 18 September 2014 15:52
To: Selberg, Sven
Cc: Thomas Swindells (tswindel); Gustaf Lundh; repo-d...@googlegroups.com; Zu, Bruce; pkuf...@gmail.com; dbor...@google.com
Subject: Re: "Hashtags"?

 

 

 

On Thu, Sep 18, 2014 at 12:36 PM, Selberg, Sven <Sven.S...@sonymobile.com> wrote:

It would be inconsistent since you can remove the hashtags from the change and submit it. When reading the commit message you would be misled to believe that you would find the change by searching for the hashtag, but you wouldn’t find it.
Further more it introduces strange behavior. If you push a patchset with hashtags and want to remove them; you’ll have to remove them from the commit message as well (creating another patchset just for the sake of removing a hashtag). Otherwise the hashtag would be recreated with every new patchset (rebase, editing the commit message etc.).

 

If you delete a hashtag (introduced by the commit  message), submit the change without removing the hashtag from the commit message and then cherry-pick the change onto a different branch that would recreate the hashtag on the cherry-pick change.

 

These are all very good points. We don't want such inconsistencies, I think.

However, maybe we can still accept the request for automatically creating the hash-tags out of the commit message

but then also make it impossible to delete them in any other way but removing them from the commit message?

Those hashtags which are added independently of the commit message can still be freely deleted.

[Thomas Swindells] Personally I don’t think we necessarily need to solve this by a technical solution – just educate people that if you include the hashtag in the message and then manually remove it will come back if you push the change again.

Inline message editing allows you to quickly remedy the commit message if it is really important to you.

It depends on your usecase but I imagine in the majority of cases people will accept inconsistencies in the rare occurrence they happen. When will it be vital that the hashtag search does not return 1 or 2 extra results?

 

If you do want a technical solution one option may just be for the plugin (optionally) deduce the scenario – if the previous commit message had the hashtag but the Gerrit entry doesn’t then don’t include the hashtag from the new version of the commit message. ‘previous’ here could also be extended to be the source of a new cherry pick.

[Selberg, Sven]

“When will it be vital that the hashtag search does not return 1 or 2 extra results?”

I have no idea when, I just know that these things tend to jump up and bite you later.

 

Gustaf pointed out that you can always use the hashtag creation validation extensionpoint to check if hashtag is in the commit message of the change and refuse the deletion of such hashtags.

 

Alas these kind of inconsistencies are the default behavior of how adding reviewers from commit message works in Gerrit.

So by the power of “as it has always worked” I humbly rest my case.

/Sven

[Dave Borowitz]

On Wed, Sep 17, 2014 at 11:26 PM, Sven Selberg <sven.s...@sonymobile.com> wrote:

> I missed this part of the discussion last Monday, obviously. What
> alternative names were considered?

 

There was a discussion about what to call the feature in this thread [1]. Hashtags where a source of inspiration so naming them just that felt natural since the phrases 'tag' and 'label' where deemed unsuitable due to naming conflicts.

Hashtags are a subset of tags so the tag definition should be applicable for hahstags as well. 

Aside from Gerrit's hashtags not being prefixed with '#' (which we discussed briefly) I can't see in what way they don't meet the definition. 

You'll have to elaborate on why you feel that hashtags are an unsuitable term. 

The point I was getting at by bringing up the definitions was that the _only_ difference between a hashtag and any other kind of tag is the presence of #.

 

/Sven

[1] https://groups.google.com/forum/#!topic/repo-discuss/-dHTaWt_LJA

[Gustaf Lundh]

How about ChangeTag?

Gustaf

[Edwin Kempin]

I kind of like "hashtags" even if it means we should prefix them with '#'.

Anyway here are some other proposals: "(change) flags", "(change) marks", "metatags", "(change) tokens"

--

[Marcelo Ávila]

I also like "hashtags"... but I think it means we MUST prefix them with '#'

"Labels" can't be used because of the "Code-Review", "Verified"...

"Keywords" and "Flags" are good options too.

BTW It's impossible do not remember of this.

--

Marcelo Ávila de Oliveira

CPqD - Information Technology Engineer

Tel.: +55 19 3705-4125

mav...@cpqd.com.br

www.cpqd.com.br

[Saša Živkov]

Out of all proposals the "hashtags" is the only one I like.

[Lundh, Gustaf]

We will push a change that visualize the hashtags with ”#”. The users will get it.

 

/Gustaf

[Edwin Kempin]

2014-09-19 14:45 GMT+02:00 Lundh, Gustaf <Gustaf...@sonymobile.com>:

We will push a change that visualize the hashtags with ”#”. The users will get it.

+1
 

[Zu, Bruce]

+3

Sent from my Sony Xperia™ smartphone


---- Gustaf Lundh wrote ----

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com<mailto:repo-discuss...@googlegroups.com>.

[Dave Borowitz]

On Fri, Sep 19, 2014 at 5:50 AM, Edwin Kempin <edwin....@gmail.com> wrote:

2014-09-19 14:45 GMT+02:00 Lundh, Gustaf <Gustaf...@sonymobile.com>:

We will push a change that visualize the hashtags with ”#”. The users will get it.

+1

+1

Although it might not make sense the way the change info table is currently laid out, you could probably also omit the word "hashtags" from the UI if you do this.

[Gustaf Lundh]

The changes discussed in this thread have now been pushed.

https://gerrit-review.googlesource.com/#/q/topic:hashtags

/Gustaf

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.