Desktop: Add and view Git tags

[renegadedata]

Update from GitHub Desktop team:

We're working on this! Initial support for this will include creating, pushing, and viewing tags in Desktop. After reading all the comments in this issue and talking with several people who feel like they're missing this, editing and deleting tags seemed fraught and had potential for unexpected things to happen between your local repo and the remote.

---

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
It would be awesome to have the ability to tag commits (e.g., the equivalent to the command-line git tag <tagname>), including the ability to move, delete, edit and push up tags to remote repository.

Describe alternatives you've considered
Just the command-line.

Teachability, Documentation, Adoption, Migration Strategy
Our team uses tags consistently for build and version numbers to keep deployments consistent and more easily trackable.

[crea7or]

@shiftkey is there any backend to fetch/store tags in desktop code? I really like to see the tags too and I'm deciding how hard it for me to implement it.

[shiftkey]

@crea7or before diving into the code I'd recommend starting from proposing how the user would interact with tags in the app, to illustrate the potential workflows and help size up the work.

An example of this is a mockup in an earlier thread about this: https://github.com/desktop/desktop/issues/257#issuecomment-239956457

We could do something similar to dotcom and separate out branches and tags using something like a segmented control:

Going beyond "Git has feature XYZ" and walking through how a feature would look or feel in Desktop is where I'd recommend starting with this - this will help get others behind a potential solution to the problem at hand.

[crea7or]

Why not in commit panel? There is a free space available right after the authors and commit date. Tags in separate list will be less useful. Tags can be created from the conext menu right here.

[renegadedata]

I think it would be helpful to have it as an option in the commit panel, right below summary, and, more importantly, to be able to go to the History tab, right click a commit, and have two options: Add Tag and Remove Tag.

The actual tag should also show in the history log, perhaps in green next to or below the commit summary.

The push to remote should replicate the tag information including moves, deletes, and changes.

[jeffreydking]

I agree with @renegadedata, tags should be implemented in two contexts.

First, on the "Changes" tab, just above the Commit button, add some user input to add a commit tag and a pre-release checkbox that appears when the tag input is non-empty.

Second, on the "History" tab, tags would be added as badges next to the commit name. On this tab, if you right-click on a commit, there would be an option to "edit tag" if there was already a tag, or "add tag" if there was not. These would bring up appropriate modals to accomplish the tag edit/add tasks.

[j-f1]

Perhaps we could have a “🏷➕” button, next to the “Add Co-Authors” button.

[shiftkey]

Thanks for the ideas, y'all. I'll add some of my thoughts to this from the backend side.

Displaying Tags

Why not in commit panel? There is a free space available right after the authors and commit date.

@crea7or @kingjeffrey I had a look at the docs to see if we can get this information from git log (which is the source of these commits). We use --pretty and these placeholders:

https://github.com/desktop/desktop/blob/57fe4f59955c74359a40fbe3d1bf02ea77f3a69c/app/src/lib/git/log.ts#L58-L69

%d or %D is the placeholder to add the refs associated with this commit, and each entry looks like this:

$ git log --decorate=short --pretty='%H %s %b %d' -n 2500 | grep 'tag:'
57fe4f59955c74359a40fbe3d1bf02ea77f3a69c Merge pull request #5130 from desktop/cut-a-new-beta time for a fresh beta  (HEAD -> master, tag: release-1.3.0-beta1, shiftkey/master, origin/master, origin/HEAD, github-desktop-agisilaos/master)
61d9aea2c1f19af9e3f9f1fd4d17f3f2495f5e09 bump for next beta   (tag: release-1.2.7-beta0)
908a2695640cbc6d00cad303d5c0c2d2eb864245 actually this is the right PR number   (tag: release-1.2.6)
0a1e96794fb9c8e87e3b501b5fdb85e372f5ee90 bump beta channel too   (tag: release-1.2.6-beta0)
02240059e44c1d856a930a51c7b6621bff327768 changelog for hotfix release   (tag: release-1.2.5)

I think if we can figure how how to extract these from the log output:

https://github.com/desktop/desktop/blob/57fe4f59955c74359a40fbe3d1bf02ea77f3a69c/app/src/lib/git/log.ts#L104-L111

And attach these to the Commit model:

https://github.com/desktop/desktop/blob/57fe4f59955c74359a40fbe3d1bf02ea77f3a69c/app/src/models/commit.ts#L27

We can then figure out whether the commit list makes sense or the commit detail form, like GitHub The Website does (we like to be consistent across products wherever this makes sense):

Managing Tags

I think it would be helpful to have it as an option in the commit panel, right below summary, and, more importantly, to be able to go to the History tab, right click a commit, and have two options: Add Tag and Remove Tag.

@renegadedata I haven't really thought much about adding and particularly removing tags in terms of the workflow, but I have some initial reservations around letting users delete tags which exist on a remote.

For reference, we prompt the user when they delete a local branch that is tracking a remote branch to confirm the action. But tags feel more permanent, so we should be cautious about this side of things.

The push to remote should replicate the tag information including moves, deletes, and changes.

I don't think we do any of this currently, and I think we could investigate the tradeoffs for adding --follow-tags to a git push so that we also push local tags that were created on the branch you are currently pushing - this seems like a responsible thing to do.

The code for that is in here - are you interested in submitting a fix for that so we can talk about this scenario further?

https://github.com/desktop/desktop/blob/57fe4f59955c74359a40fbe3d1bf02ea77f3a69c/app/src/lib/git/push.ts#L38-L45

[shiftkey]

I'm moving this to a user-research task because there's lots of ideas around the interactions that we need to think about some more.

[crea7or]

Can we start with displaying tags in history?

[shiftkey]

@crea7or we can't display things we don't have the data for, which i why i wrote up how to get that as a pre-requisite. But if someone wants to build upon that and get something working in the app then then sure, why not?

[jeffreydking]

@shiftkey In the logs used to populate history, I see tag information. I assume "pre-release" status is not exposed in the logs. If so, I assume that information is not available to the history tab. Is this correct?

[shiftkey]

@kingjeffrey I'm not sure what "pre-release status" refers to here, but the snippet above shows how we can get these from the logs when using the pretty formatting:

$ git log --pretty='%H %s %b %d' -n 2500 | grep 'tag:'
57fe4f59955c74359a40fbe3d1bf02ea77f3a69c Merge pull request #5130 from desktop/cut-a-new-beta time for a fresh beta  (HEAD -> master, tag: release-1.3.0-beta1, shiftkey/master, origin/master, origin/HEAD, github-desktop-agisilaos/master)
61d9aea2c1f19af9e3f9f1fd4d17f3f2495f5e09 bump for next beta   (tag: release-1.2.7-beta0)
908a2695640cbc6d00cad303d5c0c2d2eb864245 actually this is the right PR number   (tag: release-1.2.6)
0a1e96794fb9c8e87e3b501b5fdb85e372f5ee90 bump beta channel too   (tag: release-1.2.6-beta0)
02240059e44c1d856a930a51c7b6621bff327768 changelog for hotfix release   (tag: release-1.2.5)

[jeffreydking]

@shiftkey On the Github website, when adding a release tag, there is a "pre-release" checkbox that prevents the release from showing up in the/releases/latest url. When checked the release gets a red "Pre-release" text next to the tag on the releases page. (Also, see step 8 here: https://help.github.com/articles/creating-releases/) I assume this is a website only feature. Yes?

[shiftkey]

@kingjeffrey that's for GitHub releases, which is different to tags and requires API access

[mtrewartha]

What's the status of this? Still being considered, still doing research, implementing it... ? We tag builds that get deployed for easy tracking, so it would be great to see them in Desktop.

[potatoqualitee]

Agreed, would love to see tags in Desktop.

[billygriffin]

Hi @miketrewartha and @potatoqualitee and others. Thanks for following up on this, and sorry for the delay. We're getting our arms around all the open issues, and I wanted to revisit this one. It would be helpful for us to understand how you're using it and therefore how it might best fit into various workflows in Desktop. Would you mind describing the ways you're using tags and how them being missing in Desktop today slows down or inhibits your workflow today? I may also do a couple user interviews to better understand this as well, so if you'd be willing to participate in a ~30 min interview, please let me know that too. 😄 Thanks!

[potatoqualitee]

thanks for the follow up, @billygriffin - I am the BDFL for dbatools and currently, the defacto merger. Basically, because they aren't available in Desktop, I just avoid doing them. We release to master usually a few times daily and I prefer to keep the process manual because I've got some other things that occur during the release.

Actually, if I could get a release bot, I'd be happy with that. Oh cool, I'll probably just go with something like this

[ChrisKochAMX]

I'm glad to see this thread is still active! I've always wondered why GitHub Desktop seems to be the only Git client that doesn't support tagging.
(Until that day, we'll just stick with TortoiseGit and GitExtensions)

[potatoqualitee]

Yeah, we attempted Release Bot but I'd still have to tag. Would love to see tagging in GitHub Desktop.

[crea7or]

@billygriffin I use tags to mark releases.

[jeffreydking]

I use tags to trigger our CD via Google's Container Builder (which triggers
Spinniker). I currently need to go to GitHub.com to deploy. Prefer ability
via the desktop client.

On Thu, Nov 22, 2018, 11:41 AM Pavel <[email protected] wrote:

@billygriffin https://github.com/billygriffin I use tags to mark
releases.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/desktop/desktop/issues/4829#issuecomment-441109872,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAu0lyHA7eNYeIJGr3oXGnrGJVc5kL-Yks5uxv3dgaJpZM4UT_UT
.

[argyleink]

just the basics at first would be nice. leverage the branch workflows, keeps things simple. just let me create/push/pull tags?

[vitriolix]

@billygriffin

At the last 3-4 companies I've worked at we have used tags to flag a particular commit for a release, we use it to build and release from. Today the CEO of my company wanted to try building our latest firmware and I had to walk her through using command line git because the Github Desktop app (which she likes) doesn't support checking out a tag.

I'd be happy to participate in a user interview as well

[mtrewartha]

@billygriffin I'm currently working on an Android project, so I'll describe the workflow we follow for that, but I'm sure you'll find my flow similar to many, many others.

Our engineers do their feature/bug work on branches, then create PRs when they're done. Once a PR has been code-reviewed, it's merged into master and CI does a build. If the CI build is successful, the commit is tagged with the current version we're on (the version is SemVer plus an automatically generated build number based on the number of commits on master), then pushed up to our Internal Test track in the Google Play Store. From the Internal Test track, the build gets promoted up through the Alpha, Beta, and finally Production tracks to reach the end user.

We pretty much always have a minimum of two builds live in the Play Store (across two or more tracks) and get asked things like "Hey, did Feature X make it into the build that's in the Alpha track right now?" or "Should a user still be seeing Bug Y in the Production track right now?". From there, we rely on tags to be able to quickly walk through out Git history and see if a specific PR for Feature X or Bug Y was merged before the build tagged with the version in question.

Anywho, hope that sheds some light on how we use them. Let me know if there's anything else that would help!

[billygriffin]

Thanks everyone for the responses! We have our next couple releases planned and we're working on planning for the coming months. It's super helpful to understand how y'all are using tags to better determine how and when we might be able to support this. I can't promise a timeline but this allows us to have a more informed conversation about how we prioritize this alongside our other work. Thanks so much. ❤️

[mtrewartha]

Cool, thanks @billygriffin, glad to know it's on the table!

[ChrisKochAMX]

@billygriffin In my tiny little company, we use tags for a sort of version numbering. It helps people who need to switch between different versions keep track of which one they're supposed to be using. Also, to make it clear which commits are incremental and which represent stable releases.

[ipkpjersi]

Hi guys,

I have a question - I suppose it's somewhat related to this issue. Does anyone know if cloning a repository in GitHub Desktop also downloads all associated tags with it, or does cloning a repository in GitHub Desktop use the --no-tags flag indicating that it does not download all associated tags?

Thanks!

[shiftkey]

@ipkpjersi we don't set --no-tags when performing a git clone. The only things we vary for are:

• --progress if the application wants to report clone progress to the user
• -b if the clone should checkout a non-default branch after the clone is completed

The relevant source is here:

https://github.com/desktop/desktop/blob/4afc88602c9410d01fe2e522ae4fc55eaef23f8a/app/src/lib/git/clone.ts#L37-L69

[sraillard]

I would also appreciate to be able to manage the tags from the Github Desktop application, that's really the missing feature! Any roadmap for this feature?

[billygriffin]

It's definitely something we're interested in @sraillard, and thanks for your input! We're discussing internally how this interoperates with how Git tags are supported on GitHub.com at the moment in specing out what it might look like. We don't have a timetable but it's something we intend to support. It's not on our current roadmap but will be discussed in planning.

[ipkpjersi]

Will local repository git tags also be supported or only for GitHub repositories?

[billygriffin]

@ipkpjersi We're not sure yet. Would you mind sharing how you'd use it for local repos? If it makes sense to leverage in both cases, we're definitely open.

[ipkpjersi]

Well for one, presumably if it supported local repos it would likely support other remotes like self-hosted git repos, etc, right? To me I see no reason to make it work for GitHub only, especially since people use this program for far more than just GitHub repositories, so I don't think it would make sense to ignore those users.

[sraillard]

I agree: tags are not a specific Github feature, it's tied to git. They are really usefull to identify the releases and also when using CI tools.

[coobr01]

Agreed, I want to create a tag from the desktop so my CI flow kicks off and properly names my Release with the tag value.

[outofambit]

6648 brings up the issue of creating a release, which requires creating a new tag or using an existing one. I think that's important context for this issue as we think through solutions. Maybe creating and pushing tags can be the first part of an eventual higher level workflow.

[Paladin]

I'll add to the call. We tend to use tags to reference bug reports as well as release versions. They're easier to refer back to than searching through commit messages.

Edit/remove tags not such an important feature, I think. If you know the risks and how to recover from edited/removed tags that have already been published, you know how to use the command line to do it, so there's not a learning cost there. (I like the idea of having to switch to the command line to do things that have risk associated with them. It reminds me to be mindful of what I'm doing and why because there are risks involved. A GUI makes shooting everyone else in the foot all too easy to do accidentally. If you're going to inflict pain, best to only do it intentionally and then only if you're sure you have a good reason.)

[Borumer]

@all what is the status on this issue? Has anything been added yet?

[billygriffin]

@KnowledgeableKangaroo Nope, we’re working toward a big release in the next month or so, and our team is fully engaged on getting that tightened up so we haven’t made any progress on this. We do our best to communicate in various issues when we are working on something so it should be obvious when that’s happening. Thanks for following up!

[tierninho]

Get a list of tags and switch between them. Get a list of tags and show in the UI, the same as git tags. When double clicking a tag row, switch to that tag. The same as git checkout mytag.

Adding a request from #7458 related to this issue.

[litan1106]

Love the tags. I used tag for releases.

[clark-tan]

Hope for it to be online soon

[fisherwise]

hope we can close it before 2nd anniversary

[chrisva]

We want tags in Github Desktop. We use it to tag all our releases.

[GaMagenFOX]

We want tags in Github Desktop.

[bibiwatson]

We need tags in Github Desktop, please c:

[mtrewartha]

Folks, a simple 👍 on the original post is all that's needed instead of the "me too" comments. They just create a bunch of unnecessary noise for everyone following this issue.

[Korayem]

Folks, a simple 👍 on the original post is all that's needed instead of the "me too" comments. They just create a bunch of unnecessary noise for everyone following this issue.

mee too, I agree with ur comment

xD

[ipkpjersi]

Folks, a simple on the original post is all that's needed instead of the "me too" comments. They just create a bunch of unnecessary noise for everyone following this issue.

Actually, I kinda disagree with that sentiment. A thumbs up is simply a number, a comment is clearly a visible person that reminds you just how much people actually want this functionality that they take the time out of their day to leave an entire comment.

[mtrewartha]

Actually, I kinda disagree with that sentiment. A thumbs up is simply a number, a comment is clearly a visible person that reminds you just how much people actually want this functionality that they take the time out of their day to leave an entire comment.

I can understand and appreciate that aspect of it. That said, if you like to leave comments, I'm not stopping you. I'm simply making people aware that there are tons of us out there that are basically getting spammed by "me too" comments and that many of us appreciate use of the "+1" 👍 reaction to cut down on that while still offering the repo maintainers the opportunity to see how many folks are excited for an issue to get addressed.

[PaulRdi]

Adding to the list of use cases:

We use tags to identify student submissions, so we know which commit should be graded for which exercise.

I really like GitHub desktop for beginner programming courses since it is a very intuitive tool for using git and lets students focus on the actual content of the course in the beginning of the semester without having git issues.

[mike7ang1rdz]

no tags???? when will you support this?

[billygriffin]

Hi folks, just wanted to share an update that we're starting to work on this. After several interviews and reading through the feedback we've received about this, we're initially scoping the work to enabling people to add tags (and subsequently push them) and view them in commit history.

I did have one tactical question: is your expectation that when you add a tag it's a lightweight tag or an annotated tag? Reference in case anyone is unsure of the difference.

[sraillard]

Very good news! For me, lightweight is perfect as we are using them to point on some commit to trigger build processus.

[PaulRdi]

Lightweight would be good for me

[crgrafton]

lightweight should be sufficient

[Talyrius]

Can we not have both? I'd definitely like to annotate my tags—or at least, have the option to.

[ChrisKochAMX]

If lightweight takes less time to implement, it'd be great to have that first — leaving annotated tags as a feature request.

[slspencer]

Start with lightweight tags! There will always be users who urge you to 'do it all', but it's ALWAYS best to implement the minimum feature set first.

[billygriffin]

Follow up question based on your responses. It seems like we can create annotated tags with just the tag name and everything else empty, which would allow us to treat them just like lightweight tags from the user's perspective, but retain flexibility for potentially offering more functionality down the road. This would also allow us to constrain the tags we push to only annotated tags so people aren't inadvertently pushing a bunch of old lightweight tags to GitHub.

For those of you who suggested lightweight tags, if we were to use annotated tags with just the tag name instead, would that cause any problems for you?

[slspencer]

+1 Annotated tags with just the tag name

[billygriffin]

Hi folks, this is all now live on beta so I'm going to close this issue. 🎉 We expect the production release to happen next week! If you want to start using it immediately, you can download the beta here: https://github.com/desktop/desktop/#beta-channel

Thank you all SO much for all the input along the way - it has been immensely helpful. ❤️ ✨

[billygriffin]

This is now released to production! https://github.blog/2020-05-12-create-and-push-tags-in-the-latest-github-desktop-2-5-release/

[sraillard]

This is a very good news!
We can see tags on commits and add them, but is there way to delete a tag?
Do you plan to add an option to list all the tags of the repository, so we can find a commit from a tag?

[adipose]

Still cannot select existing tags like we can on github.com?

[mikermcneil]

This is tangential somewhat, but related to tags, and since GitHub+NPM is a thing now, figured I'd mention it in case any other package maintainers have run into this:

I would love a "Tag & publish" button, for NPM packages -- i.e. a GUI equivalent to npm version && git push && git push --tags && npm publish

e.g. a dropdown with options equivalent to:

• npm version patch
• npm version minor
• npm version major
• npm version

To recap: npm version does (1) update package.json, (2) commit, (3) tag

(P.S. at some point, support for NPM dist tags would be a nice bonus, e.g. for doing edge-tagged prerelease distributions)