Jay Soffian <jaysoffian@xxxxxxxxx> writes:
> This is just a start so I can get some feedback. Some things still missing:
>
> 1) "git remote prune <remote>" calls warn_dangling_symref(), but
> "git fetch --prune" does not. I ran out of time tonight to refactor
> warn_dangling_symref() to do something more intelligent than just spew to
> stdout (which doesn't get along with fetch, which spews to stderr...).
>
> 2) Perhaps "git remote update --prune" should be refactored to call
> "git fetch --prune". If so, then fetch should gain a "--prune-only" option
> so that "git remote prune" can just call "got fetch --prune-only".
>
> 3) Perhaps add a config option for users who wish to prune by default.
>
> Thoughts, comments, flames?
I usually refrain from talking about multi-year long term plans, because I
do not have one, but in a longer term (across 1.7.0 boundary and beyond),
the general direction would be:
- "fetch" will eventually prune by default; I expect we will have a
configuration option "fetch.autoprune = yes" to allow early adopters to
let it prune until 1.7.0, and in 1.7.0 we will change the default for
the configuration variable to "yes", i.e. we prune unless the user
explicitly declines with "fetch.autoprune = no".
- In general, "remote" should go back to its roots of being the
management interface to [remote "nick"] configuration section. We
should start planning to remove extra features that were piled on top
of the original "remote definition management tool". "update/prune"
should have been the duty of "fetch" in the first place, but they were
added to "remote" primarily because it was easier to do so ("remote"
used to be script but "fetch" was already written in "C").
This means two things:
* "remote prune" that only prunes without updating remaining tracking
will be largely become unnecessary [*1*], once we have a way to tell
"fetch" to prune at the same time. As soon as "fetch --prune"
becomes available, "remote prune" should become an alias to it. And
"remote prune" itself should eventually be removed.
* "remote update" that runs "fetch" for multiple remotes should be
deprecated and eventually removed. "remote update" is a band-aid
that exists only because "fetch" started as a strange chimera between
plumbing and Porcelain, and we did not want to add too much features
to it. "fetch" itself should learn to do the "from multiple places"
part as a full-fledged Porcelain.
Of course, a removal of a subcommand ("remote update" and "remote prune")
will have to happen way after 1.7.0 boundary, but the above should be the
longer term direction.
Don't worry about keeping the "only prune without updating" misfeature. If
omission of it simplifies what you are trying to do, it is Ok if "git
prune" becomes a synonym to "git update --prune" aka "git fetch --prune"
and starts updating the tracking refs.
[Footnote]
*1* "remote prune" is a band-aid that exists only because "fetch"
currently has no-way to prune at the same time.
One could argue that a user may want to prune _only_ stale refs without
getting the state of remaining refs updated to his tracking refs. That
certainly is _possible_ with "remote prune", but being possible and being
sensible are two different things.
What is the reason the user does not want to update a tracking ref that
corresponds to a branch that remains at the remote, when he runs "prune
only" version if it existed? It cannot be because the branch may have
been rewound and you may lose the only remaining history---the user is
actively asking to prune and is willing to lose the history of stale
branches.
In other words, once we have "fetch --prune" (either default or
optional---the important part is that there is a way to cause fetch to do
this), there is no sane reason to have a separate command that only prunes
without updating the remaining tracking refs.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html