6 ms·

And yet, this is the help page for git push: Updates remote refs using local refs, while sending objects necessary to complete the given refs. That's

by tedks 12y ago

And yet, this is the help page for git push: Updates remote refs using local refs, while sending objects necessary to complete the given refs. That's helpful! Thanks Git!

kinghajj 12y ago
And for hg it's: > Push changesets from the local repository to the specified destination. :s/changesets/objects :s/local refs/local repository :s/specified destination/remote refs Is it really that much less easy? Both require that you understand the nomenclature chosen by their respective systems ('objects'/'changesets', 'refs'/'repository').
- illumen 12y ago
  hg uses English that people would more likely understand, because those words were being used before hg existed. Git uses jargon it made up.
  - kinghajj 12y ago
    And you could argue that it's better to use new terms rather than existing ones that carry possibly-incorrect assumptions, no? "Leaky abstractions" and all that.
- tedks 12y ago
  A change set is a set of changes. An object is totally unspecified. I know what a repository is when I work with version control. I've been using version control for years and I never was confused about what the repository was. What the fuck is a ``ref''? Git's shit.
  - deleted 12y ago
    [deleted]
  - kinghajj 12y ago
    The definition of 'object' is outside of the scope of the documentation for the 'push' command. Similarly with 'ref'. From "man git": "The object database contains objects of three main types: blobs, which hold file data; trees, which point to blobs and other trees to build up directory hierarchies; and commits, which each reference a single tree and some number of parent commits. The commit, equivalent to what other systems call a "changeset" or "version", represents a step in the project's history, and each parent represents an immediately preceding step. Commits with more than one parent represent merges of independent lines of development. All objects are named by the SHA-1 hash of their contents, normally written as a string of 40 hex digits. Such names are globally unique. The entire history leading up to a commit can be vouched for by signing just that commit. A fourth object type, the tag, is provided for this purpose. When first created, objects are stored in individual files, but for efficiency may later be compressed together into "pack files". Named pointers called refs mark interesting points in history. A ref may contain the SHA-1 name of an object or the name of another ref. Refs with names beginning ref/head/ contain the SHA-1 name of the most recent commit (or "head") of a branch under development. SHA-1 names of tags of interest are stored under ref/tags/. A special ref named HEAD contains the name of the currently checked-out branch."
    - tedks 12y ago
      You know what I literally never had to do when learning SVN, bazaar, or mercurial? Learn a bunch of bullshit like "refs" or "objects" or "heads" or whatever the fuck. It is genuinely insulting to assume me to have the time or the patience to read things like this. It's 2014. Interfaces need to be better and I refuse to use an interface that insults my time by attempting to make me learn a load of bullshit.
      - bronson 12y ago
        And yet you have time to rant and steam here, which took more time than reading what a "ref", "object", and "head" is. Interesting priorities.
  - phaemon 12y ago
    Usually, "refs" are things like branches or tags. A branch in git is just a text file that contains the hash of a commit (and that commit is the head of the branch). So it's a "reference" (or "ref") to that commit. "Objects" are the things that are stored in the repository, like commits and file contents. > Updates remote refs using local refs So, if you had a branch called "dev", and your local version pointed to a different commit than the remote version, it will update the remote "dev" to match what you've got in your local one. > while sending objects necessary to complete the given refs. Of course, it's likely that the whole reason that your "dev" doesn't match the remote repository's "dev" is because you've changed some stuff - why else would you be pushing? - so you've got to also upload the new commit objects that the refs refer to, plus the file-content objects that the commits specify. In other words, 'complete the given refs'.

by tedks 12y ago

And yet, this is the help page for git push: Updates remote refs using local refs, while sending objects necessary to complete the given refs. That's helpful! Thanks Git!

kinghajj 12y ago

And for hg it's: > Push changesets from the local repository to the specified destination. :s/changesets/objects :s/local refs/local repository :s/specified destination/remote refs Is it really that much less easy? Both require that you understand the nomenclature chosen by their respective systems ('objects'/'changesets', 'refs'/'repository').

illumen 12y ago
hg uses English that people would more likely understand, because those words were being used before hg existed. Git uses jargon it made up.
- kinghajj 12y ago
  And you could argue that it's better to use new terms rather than existing ones that carry possibly-incorrect assumptions, no? "Leaky abstractions" and all that.
tedks 12y ago
A change set is a set of changes. An object is totally unspecified. I know what a repository is when I work with version control. I've been using version control for years and I never was confused about what the repository was. What the fuck is a ``ref''? Git's shit.
- deleted 12y ago
  [deleted]
- kinghajj 12y ago
  The definition of 'object' is outside of the scope of the documentation for the 'push' command. Similarly with 'ref'. From "man git": "The object database contains objects of three main types: blobs, which hold file data; trees, which point to blobs and other trees to build up directory hierarchies; and commits, which each reference a single tree and some number of parent commits. The commit, equivalent to what other systems call a "changeset" or "version", represents a step in the project's history, and each parent represents an immediately preceding step. Commits with more than one parent represent merges of independent lines of development. All objects are named by the SHA-1 hash of their contents, normally written as a string of 40 hex digits. Such names are globally unique. The entire history leading up to a commit can be vouched for by signing just that commit. A fourth object type, the tag, is provided for this purpose. When first created, objects are stored in individual files, but for efficiency may later be compressed together into "pack files". Named pointers called refs mark interesting points in history. A ref may contain the SHA-1 name of an object or the name of another ref. Refs with names beginning ref/head/ contain the SHA-1 name of the most recent commit (or "head") of a branch under development. SHA-1 names of tags of interest are stored under ref/tags/. A special ref named HEAD contains the name of the currently checked-out branch."
  - tedks 12y ago
    You know what I literally never had to do when learning SVN, bazaar, or mercurial? Learn a bunch of bullshit like "refs" or "objects" or "heads" or whatever the fuck. It is genuinely insulting to assume me to have the time or the patience to read things like this. It's 2014. Interfaces need to be better and I refuse to use an interface that insults my time by attempting to make me learn a load of bullshit.
    - bronson 12y ago
      And yet you have time to rant and steam here, which took more time than reading what a "ref", "object", and "head" is. Interesting priorities.
- phaemon 12y ago
  Usually, "refs" are things like branches or tags. A branch in git is just a text file that contains the hash of a commit (and that commit is the head of the branch). So it's a "reference" (or "ref") to that commit. "Objects" are the things that are stored in the repository, like commits and file contents. > Updates remote refs using local refs So, if you had a branch called "dev", and your local version pointed to a different commit than the remote version, it will update the remote "dev" to match what you've got in your local one. > while sending objects necessary to complete the given refs. Of course, it's likely that the whole reason that your "dev" doesn't match the remote repository's "dev" is because you've changed some stuff - why else would you be pushing? - so you've got to also upload the new commit objects that the refs refer to, plus the file-content objects that the commits specify. In other words, 'complete the given refs'.