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 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
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,
From: "Matthieu Moy"
Sent: Monday, June 17, 2013 6:20 PM
"Philip Oakley" 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
+
"Philip Oakley" 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 local refs
From: "Matthieu Moy"
Sent: Monday, June 17, 2013 12:09 PM
Junio C Hamano 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
Matthieu Moy 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"]
push = refs/heads/mast
Junio C Hamano 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 out with a
Ramkumar Ramachandra 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 central, works as upstre
Ramkumar Ramachandra 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 around: the intuiti
From: "Ramkumar Ramachandra"
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 way from
"triangu
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 writi
12 matches
Mail list logo
