Why can't I open a Pull Request targeting a tag?

[pedroreys]

We currently use tags to mark the last commit in master that are part of a previous release.

The reasoning being that when a patch for a past release is needed, I would simply create a branch from the tag, do the work and then open a Pull Request to have the commits from the patch branch applied on top of the tag's commit.

But currently, stash v.3.9.2 says I can't open a Pull Request with a Tag. Why is that?

StashPRTag.png

[eric_horodyski]

This interests me as well. While I have two branches, one for development and one for releases, I'm running into issues where devs are working faster than I can create pull requests!

For instance, I tag every version to be released in development before I create a pull request to move it into release. I also keep release locked down so that the only way to commit to it is via Pull Request. So as I tag the version, I ran into an issue where a new development commit was in place before I could create the request. 

It would be nice to pick the commit, if not the tag, to create a Pull Request on. But if that's a GIT limitation, that's just life.

[Tim Crall]

A pull request is basically just a way of allowing for a code review process before completing a merge.  It should really be called a merge request (the "pull request" name makes more sense in an open-source environment).

It sounds like all you really want to do is to move a tag to the end of a branch.  Which you can do, but you should't, because tags shouldn't be moved.  I'm not sure what you're trying to accomplish that isn't achieved by using the name or the release branch.

You can't "apply changes on top of a commit".  Commits are immutable once committed.  The contents of the commit and the SHA1 hash are immutably linked to one another.  The only way to "apply changes to a commit" is by creating a new commit, such as on a branch.

[Mike Friedrich]

This is not a limitation of stash. Thats so for all source control system. If you want to patch something not on the head, you will have to create a branch.

For releases i would recommend to maintain release branches, then you can create a pull request to merge from your branch into the release branch.

If you want to patch the master (or trunk or however you call it), then select that branch as the target.

[pedroreys]

"Thats so for all source control system". Sorry but you are wrong. To start, stash is not a source control system, git is the source control system. And no, this is not a limitation of git. A patch can be applied to any commit. I can merge or rebase using a commit sha1, no need for a branch. And while Pull Requests are not a git feature, but rather a github/stash/bitbucket feature, I was curious about this arbitrary restriction in stash. In github, for example, you can open a pull request that targets a branch, a tag or even a specific commit.

[Chris Ortman]

I have to guess this is some sort of artificial limitation of stash because of the way that it wants to track up dates to pull requests.

It would be really nice to be able to do this so that when you have a long lived feature branch  you could submit PR's that merge the branch up to a certain point.

Example

Long feature that lasts for 3 sprints. It is one logical feature though, and you want just a single conceptual branch that people are working off.

At points through the development of the feature you have things stable and want to merge / review up to that point. A tag would work well for this because the point is that it isn't supposed to change. So when I'm stable I'd create a tag like feature-stable-1 and do a pull request against that.

[Tim Crall]

You could do this by creating a branch rather than a tag. If you never commit on it, a branch will work just like a tag would and sit there pointing at the commit where it was created. And you can merge a branch.

[Chris Ortman]

I am well aware of that, my point is that to not be able to use a tag for it is a needless limitation of stash. I don't want a separate branch where someone can 'accidentally' commit to it.