Philip Oakley wrote:
A sentence, in the Documentation/config.txt, is needed to clarify the
Central workflow and any distinction with the non-central workflow(s). We
cannot assume the new reader has the same world view of that concept (they
may be thinking it means we do a centralised VCS, not
Junio C Hamano wrote:
I do no think the remainder (snipped) belongs to the log message.
Oh, it was never intended to be a proper commit message. I'll write a
proper one when I send it in with the implementation.
- To understand if central, works as upstream, otherwise works as
current,
Matthieu Moy wrote:
I'd put it the other way around: the intuitive explanation first, and
the technical one after. For people not totally familiar with Git, the
first part does not make much sense (and when I learn a new tool, I
really don't like when the doc assumes I already know too much
Junio C Hamano gits...@pobox.com writes:
+* `matching` - push the refspec :. In other words, push all
+ branches having the same name in both ends, even if it means
+ non-fast-forward updates. This is for those who prepare all the
+ branches into a publishable shape and then push them
Matthieu Moy matthieu@grenoble-inp.fr writes:
But then the place to warn loudly is the doc for --force. What about
this?
Sounds sensible. I am not sure if --all is all that common to be
singled out, though. I always push these out refspecs, like
[remote origin]
From: Matthieu Moy matthieu@grenoble-inp.fr
Sent: Monday, June 17, 2013 12:09 PM
Junio C Hamano gits...@pobox.com writes:
+* `matching` - push the refspec :. In other words, push all
+ branches having the same name in both ends, even if it means
+ non-fast-forward updates. This is for
Philip Oakley philipoak...@iee.org writes:
+ Note that `--force` applies to all the refs that are pushed,
+ hence using `git push --all --force`, or `git push --force`
+ with `push.default` set to `matching` may override refs other
+ than the current branch (including
From: Matthieu Moy matthieu@grenoble-inp.fr
Sent: Monday, June 17, 2013 6:20 PM
Philip Oakley philipoak...@iee.org writes:
+ Note that `--force` applies to all the refs that are pushed,
+ hence using `git push --all --force`, or `git push --force`
+ with `push.default`
Design by Junio.
By detaching descriptions from the implementation, we're only confusing
users. I've chosen to use the term central workflow to make the
descriptions terse and readable, although I've stayed way from
triangular workflow (referred to as non-central workflow).
Yes, I hate writing
From: Ramkumar Ramachandra artag...@gmail.com
Sent: Sunday, June 16, 2013 11:06 AM
Design by Junio.
By detaching descriptions from the implementation, we're only
confusing
users. I've chosen to use the term central workflow to make the
descriptions terse and readable, although I've stayed
Ramkumar Ramachandra artag...@gmail.com writes:
+* `current` - push the refspec $HEAD. HEAD is resolved early to a
+ branch name (referred to as $HEAD). In other words, push the
+ current branch to update a branch with the same name on the pushing
+ side.
I'd put it the other way
Ramkumar Ramachandra artag...@gmail.com writes:
Design by Junio.
Not necessary. The conclusion of discussion is a result of
collaboration.
Thanks for writing it down. It is a good start, but I agree with
reviews by Philip Oakley and Matthieu Moy we already saw.
- To understand if
12 matches
Mail list logo
