Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
On jeu, jun 19, 2008 at 06:33:12 +0000, Junio C Hamano wrote:
Show 42 quoted lines
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Thu, Jun 19, 2008 at 03:11:10PM +0000, Jeff King wrote:
> >> On Thu, Jun 19, 2008 at 03:52:00PM +0200, Pierre Habouzit wrote:
> >> > > - there is a possible danger with "git push -f", in that you force
> >> > > both rejected branches as well as stale branches. Junio and I
> >> > Well afaict this is a separate issue, as we're (with such a patch)
> >> > only changing what gets printed on the console, not the internal
> >> > behavior. So solving this second issue should not really be a
> >> > precondition to the inclusion of such a patch.
> >>
> >> It is a separate issue, but it is exacerbated by hiding stale refs.
> >> Imagine:
> >>
> >> $ git push
> >> To /path/to/repo
> >> ! [rejected] master -> master (non-fast forward)
> >>
> >> $ git push -f
> >> To /path/to/repo
> >> + 0abfa88...c1ed93b master -> master (forced update)
> >> + 0329485...3498576 stale_branch -> stale_branch (forced update)
> >>
> >> I think that is a nasty surprise to spring on an unsuspecting user.
> >> Another solution might be "-f" not pushing rewound branches, but then we
> >> need a way to specify "no, really, push this rewound branch". Perhaps
> >> "-f -f"?
> >
> > Well then we could keep the [stalled] lines for now until this issue
> > is resolved then, despite what the people at the beginning of the other
> > thread complained about. My real issue is that I have my shell
> > configured so that my prompt becomes inverted if the last command
> > failed. So do many people I know, and well, git push for stalled
> > references should just not generate an error. _this_ is my sole concern
> > :)
>
> There are two cases the push does not fast forward. The case where you
> are truly behind (aka "stale") and you and the pushed-to repository have
> diverged history. Reporting success when you did not push due to the
> latter is unacceptable. I personally rely on the fast-forward safety in
> my push-out scripts, but I do not think it is just me. The exit status from
> commands are designed to be used that way.
Sure, but when you use `git push` or `git push <remote>` forms of the
commands, you usually don't mean to push "everything", but rather
"everything that has new stuff". Stalled branches that you didn't
fast-forwarded yet should not generate issues IMHO.
Of course, for git-push <remote> <branch> this could be different.
Show 6 quoted lines
> The thing is, the user asked to push certain refs, and some did not get
> updated. The user has the right to expect a failure indication from the
> command. If you choose to _ignore_ the failure, that is _your_ choice,
> like:
>
> $ git push || :
I don't want to ignore push failures. It's just that in my
workflow[0], stalled branches are _not_ a problem, whereas non
fast-forward are. I cannot rely on the exit status, to know if all was
fine, and that's annoying, really (Not a _major_ PITA, but an annoyance
nonetheless).
[0] we have quite a few branches for our different releases and
production branches. I rarely do fixes there, but still have
tracking branches for those, and when I'm pushing my master, I get
errors each time another coworker pushed a production fix, until I
git stash, git checkout <stalled-branch>, git merge
<origin/stalled-branch>, git checkout back, git stash apply
*PHEEEW* all that for git push[1] ? No thanks. [1] I know I can `git update-ref refs/heads/<stalled-branch> $(git
rev-parse origin/<stalled-branch>)` to fix that in one step but:
- it's plumbing ;
- if you forget the refs/heads it don't DWIM ;
- it's easy to mess things up with such use patterns
(sub-problem of `it's plumbing`).
So I don't really think this is the proper answer to my problem.--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>