Degraded performance Customers may experience intermittent errors using Community search. Our platform vendor is investigating.
If a problem appears to be common to Git itself (e.g. not unique to Bitbucket, or Atlassian SourceTree, or Git on Windows, etc.), what are ways that one could report the issue such that future versions of Git (or at least the tools that are built upon Git) might correct the situation?
As a possible illustrating example (or not – see below*), the git subtree functionality (cf. Alternatives To Git Submodule: Git Subtree by Atlassian's Nicola Paolucci) is somewhat new within standard git (being an extra earlier). Normally one should be able to add or pull subtree commits using --squash to treat the shared content as a single commit in the parent repository, without cluttering up the parent repository history with the potentially numerous commits in the shared code's history. However, if one uses the convenience of defining a remote for the shared repository (to make subtree operations easier), that will create a remote tracking branch in the parent repository that pulls in all the tags from the shared repository. These tags then cause the shared repository's history to show up in depictions of the parent repository history DAG starting from the most recent such tag and earlier – regardless of the use of --squash for subtree operations. Thus, it largely defeats the point of using --squash. While there is a way to repair the damage after the fact, it involves avoiding the convenience of using a remote to represent the shared repository for the subtree.
As far as I can tell, all versions of Git have this flaw as an unfortunate consequence of having subtree repository tags pulled into the parent repository, regardless of using --squash in subtree operations, whenever a remote and its remote tracking branch are used. The repercussions affect SourceTree and Bitbucket, but do not appear to be limited to or unique to those tools.
Would fixing a problem like this depend on changes to Git itself? If so, what would be the best ways to propose such changes? Or else, is there another way to deal with such an issue?
*p.s. Addendum: Regarding the particular issue I supplied as a possible illustrating example, before I could act on the process supplied below by Seth Foss, I discovered that there is an existing option within Git by which one can avoid the problem I described. When using a remote for implementing squashed git subtrees, there is a way to exclude tags in the remote tracking branch.
git remote add --no-tags ...
This prevents the tags that would defeat the purpose of using --squash with git subtree operations involving that remote.
In any case, I appreciate having the answer supplied by Seth Foss for the question I asked.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
It's Monday morning here is sunny California! (86 degrees in April, what is happening right now??) Time for another Miscellaneous Monday! I was having a random conversation with my nine-year-old thi...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs