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
updating.
- 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
anywhere".
- 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.
[Footnote]
*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 http://vger.kernel.org/majordomo-info.html
