Closed GoogleCodeExporter closed 9 years ago
This doesn't mesh with vcscommand as a file-oriented utility.
Original comment by bob.hies...@gmail.com
on 29 Mar 2010 at 7:53
Agreed with OP, this seems to be a glaring omission present in most other
editor plugins. Agreed also that it doesn't mesh with vcscommand as
file-oriented, but this usage doesn't seem out of place overall for a vcs
front-end (and especially appropriate for distributed systems such as hg, git,
etc). (Workaround: map a key to !hg push.)
Original comment by CPaet...@gmail.com
on 12 Sep 2010 at 3:36
I disagree. Pushing a single file makes less sense outside the context of CVS
than it does within. Would such a push make a commit of just the single file
and try to push it? To which remote would it push? How would it handle
conflicts?
I don't see this as being useful at all.
Original comment by bob.hies...@gmail.com
on 12 Sep 2010 at 11:15
Now I see what you are saying. Since normally push (at least, in the context of
hg) pushes your most recent commit and not a single file, I would propose to
keep that behavior. When hg receives an hg push with no arguments, it just
pushes to the default repository. (The first manual push automatically sets the
default for future pushes.)
To me, your points make a lot of sense. I would propose that any VCSPush just
be a wrapper around the appropriate vcs "push" command, delivering
stderr/stdout as appropriate just as the rest of the commands do. In this
proposal, configuration would stay within the distributed vcs's own
configuration files, not vcscommand.
Original comment by CPaet...@gmail.com
on 17 Sep 2010 at 2:22
What do you think -- would a VCS Push in this context make sense?
Original comment by CPaet...@gmail.com
on 11 Oct 2010 at 1:09
This would be just great. I totally agree that the config should stay in the
VCS.
Original comment by 319carlo...@gmail.com
on 11 Oct 2010 at 2:36
Original issue reported on code.google.com by
319carlo...@gmail.com
on 2 Mar 2010 at 2:10