Marco Costalba <[EMAIL PROTECTED]> writes:

> A suggestion I would like to present is if can be useful a
> kind of scheduling/list of planned compatibility break features so
>  that developers can know in advance when and what will break
>  their stuff and users can know when they will need to upgrade.

Yes, that is a valid concern.  Fortunately this is the only
backward incompatible thing I currently see on the horizon.

Here are the list of things I am currently thinking about

 - The format-patch, rebase and cherry parameters you already
   know about.  I do not think the "ugly" two parameter
   compromise is too much baggage to keep around, so my original
   plan was not to break the backward compatibility.

 - Fetch and pull.  Currently git fetch (and git pull) takes the
   following forms:

    $ git fetch <remote>
    $ git fetch <remote> <head>
    $ git fetch <remote> tag <tag>

   I am planning to update it to take:

    $ git fetch <remote> <refspec>...

   but in a backward compatible way.

   <refspec> can take the following forms:

    - A <refspec> of form "<src>:<dst>" is to fetch the objects
      needed for the remote ref that matches <src>, and if <dst>
      is not empty, store it to the local that matches <dst>.
      The same rule as "git push" applies for <dst>.  <src> can
      be either a ref pattern or the SHA1 object name.  If <src>
      is not an SHA1 object name, and it does not match exactly
      one remote ref, it is an error.

    - "tag" followed by <next> is just an old way of saying
      "refs/tags/<next>:refs/tags/<next>"; this mimics the
      current behaviour of the third form above and means "fetch
      that tag and store it under the same name".

    - A single token <refspec> without colon is a shorthand for
      "<refspec>:"  That is, "fetch that ref but do not store

    - when there is no <refspec> specified

      - if <remote> is the name of a file under
        $GIT_DIR/branches/ (i.e. a shorthand without trailing
        path), then it is the same as giving a single <refspec>
        "<remote-name>:refs/heads/<remote>" on the command line,
        where <remote-name> is the remote branch name (defaults
        to HEAD, but can be overridden by .git/branches/<remote>
        file having the URL fragment notation).  That is, "fetch
        that branch head and store it in refs/heads/<remote>".

      - otherwise, it is the same as giving a single <refspec>
        that is "HEAD:".

    The SHA1 object names of fetched refs are stored in FETCH_HEAD
    [*1*], one name per line.  There will be an empty line for the
    ref that was not available on the remote end.

  I have pull enhancements that takes more than one remote refs
  in mind, but that will not be in the immediate future.  What
  will happen when the above fetch enhancement happens is that
  pull will accept the same set of parameters as the updated
  fetch does, runs the fetch, but refuses to run resolve when
  more than one remote ref is involved.  When resolve is updated
  to do an octopus (or a king ghidorah), this restriction can be
  lifted without breaking backward compatibility.

*1* git-fetch-pack most likely will just output SHA1 to its
standard output like Linus suggested earlier.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to