Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

Why keep git "detached HEAD" warning? #36173

Closed
joelpurra opened this issue Jan 23, 2015 · 3 comments
Closed

Why keep git "detached HEAD" warning? #36173

joelpurra opened this issue Jan 23, 2015 · 3 comments

Comments

@joelpurra
Copy link
Contributor

I have a couple of formulae in a tap of my own. An hour ago I switched to using git plus tags instead of .tar.gz urls plus sha checksums. Already I have a jqnpm user (as well as developer of a related project) asking why this message came up; he seems worried users will be frightened off by talk about "detached HEADs".

Should the message be hidden, or perhaps cropped to display only the first line with the hash?

brew tap joelpurra/joelpurra
brew install jqnpm

(If you really want to use jqnpm, also do brew install --HEAD jq to get jq v1.5rc1+.)

Note: checking out '7d4174350a141a526a8a8758d12e55463a679b12'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name
@joelpurra joelpurra mentioned this issue Jan 23, 2015
Closed
@jacknagel
Copy link
Contributor

An hour ago I switched to using git plus tags instead of .tar.gz urls plus sha checksums.

Can I ask why? In core, we prefer tarballs unless the repository has submodules (which are not included in the generated tarballs).

Unfortunately this particular message comes from the checkout performed implicitly by git clone. As far as I can tell it can't be suppressed without suppressing all of the output. First-time clones are intentionally verbose, so we don't want that. Note that it only happens on the initial clone.

@joelpurra
Copy link
Contributor Author

Can I ask why? In core, we prefer tarballs unless the repository has submodules (which are not included in the generated tarballs).

Because I'm partial to git tags; while tarballs have their use, I don't "need" them as I "need" git. Separate sha256 checksums are nice too, but git already checks that the code isn't corrupted (I don't treat hashes as a security measure).

jqnpm itself is actually a package manager for jq, and uses git cloning with semver tags. Brew, being general purpose with much more complex software, has a valid reason to primarily use tarballs. The three formulae I have in the tap (so far) are for bash scripts, and the repos are small enough. Either way, I hope brew does something like git clone --branch <tag> --single-branch --depth 1 <remote> <cachedir>, which means no unnecessary git history.

Unfortunately this particular message comes from the checkout performed implicitly by git clone. As far as I can tell it can't be suppressed without suppressing all of the output. First-time clones are intentionally verbose, so we don't want that. Note that it only happens on the initial clone.

I'm sure the output can be captured and cleaned up. Displaying the commit hash makes a lot of sense, but don't really see the warning as having any kind of relevance to the output. Oh well, not a huge deal for me personally.

Thanks!

@joelpurra
Copy link
Contributor Author

Question answered, closing.

@Homebrew Homebrew locked and limited conversation to collaborators Feb 17, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jacknagel @joelpurra