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: #257 (comment)

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:

desktop/app/src/lib/git/log.ts

Lines 58 to 69 in 57fe4f5

	const prettyFormat = [
	'%H', // SHA
	'%s', // summary
	'%b', // body
	// author identity string, matching format of GIT_AUTHOR_IDENT.
	// author name <author email> <author date>
	// author date format dependent on --date arg, should be raw
	'%an <%ae> %ad',
	'%cn <%ce> %cd',
	'%P', // parent SHAs,
	'%(trailers:unfold,only)',
	].join(`%x${delimiter}`)

%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:

desktop/app/src/lib/git/log.ts

Lines 104 to 111 in 57fe4f5

	const commits = lines.map(line => {
	const pieces = line.split(delimiterString)
	const sha = pieces[0]
	const summary = pieces[1]
	const body = pieces[2]
	const authorIdentity = pieces[3]
	const committerIdentity = pieces[4]
	const shaList = pieces[5]

And attach these to the Commit model:

desktop/app/src/models/commit.ts

Line 27 in 57fe4f5

export class Commit {

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?

desktop/app/src/lib/git/push.ts

Lines 38 to 45 in 57fe4f5

	export async function push(
	repository: Repository,
	account: IGitAccount | null,
	remote: string,
	localBranch: string,
	remoteBranch: string | null,
	progressCallback?: (progress: IPushProgress) => void
	): Promise<void> {

[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 ***@***.*** 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 <#4829 (comment)>, 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!

[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)

[MiguelRipoll23]

@mikermcneil found something for that, check this out.

[ImanCol]

so many comments and none gives a solution to what was proposed by OP, to be able to change between tags?

[OverLordGoldDragon]

@ImanCol Another meaning of "tags" is invoked in OP. I agree the one you mention is useful, and opened #17185.