@@ -186,13 +186,6 @@ static int option_parse_n(const struct option *opt,return0;}-staticintoption_parse_ff_only(conststructoption*opt,-constchar*arg,intunset)-{-fast_forward=FF_ONLY;-return0;-}-staticstructoptionbuiltin_merge_options[]={{OPTION_CALLBACK,'n',NULL,NULL,NULL,N_("do not show a diffstat at the end of the merge"),
@@ -210,9 +203,9 @@ static struct option builtin_merge_options[] = {OPT_BOOL('e',"edit",&option_edit,N_("edit message before committing")),OPT_SET_INT(0,"ff",&fast_forward,N_("allow fast-forward (default)"),FF_ALLOW),-{OPTION_CALLBACK,0,"ff-only",NULL,NULL,+{OPTION_SET_INT,0,"ff-only",&fast_forward,NULL,N_("abort if fast-forward is not possible"),-PARSE_OPT_NOARG|PARSE_OPT_NONEG,option_parse_ff_only},+PARSE_OPT_NOARG|PARSE_OPT_NONEG,NULL,FF_ONLY},OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),OPT_BOOL(0,"verify-signatures",&verify_signatures,N_("Verify that the named commit has a valid GPG signature")),
From: Felipe Contreras <hidden> Date: 2016-06-15 22:59:09
'origin/master' is very clear, no need to specify the 'remotes/' prefix,
or babysit the user.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -39,7 +39,7 @@ Assume the following history exists and the current branch is "`master`": ------------- A---B---C master on origin+ A---B---C origin/master / D---E---F---G master ------------
@@ -51,7 +51,7 @@ result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. ------------- A---B---C remotes/origin/master+ A---B---C origin/master / \ D---E---F---G---H master ------------
From: Felipe Contreras <hidden> Date: 2016-06-15 22:59:09
There's no mention of the 'origin' default, or the fact that the
upstream tracking branch remote is used.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/git-fetch.txt | 3 +++
1 file changed, 3 insertions(+)
@@ -37,6 +37,9 @@ or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See linkgit:git-config[1]).+When no remote is specified, by the default the `origin` remote will be used,+unless there's an upstream branch configured for the current branch.+ OPTIONS ------- include::fetch-options.txt[]
@@ -429,7 +429,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)argc--;argv++;-if(0<=addremove_explicit)+if(addremove_explicit>=0)addremove=addremove_explicit;elseif(take_worktree_changes&&ADDREMOVE_DEFAULT)addremove=0;/* "-u" was given but not "-A" */
@@ -578,7 +578,7 @@ static const char *setup_git_directory_gently_1(int *nongit_ok)if(nongit_ok)*nongit_ok=0;-if(!getcwd(cwd,sizeof(cwd)-1))+if(!getcwd(cwd,sizeof(cwd)-1))die_errno("Unable to read current working directory");offset=len=strlen(cwd);
On 31.10.2013, at 10:25, Felipe Contreras [off-list ref] wrote:
Most of these have been sent before, but were not applied for one reason or
another.
All of these look fine and sensible to me. Some of the latter patches in the series might be a bit subjective (e.g. I personally don't mind "yoda" conditions at all), but none do harm, and most are a clear improvement. So I am all for applying this.
Cheers,
Max
From: Junio C Hamano <hidden> Date: 2016-06-15 22:59:09
Felipe Contreras [off-list ref] writes:
quoted hunk
There's no mention of the 'origin' default, or the fact that the
upstream tracking branch remote is used.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/git-fetch.txt | 3 +++
1 file changed, 3 insertions(+)
@@ -37,6 +37,9 @@ or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See linkgit:git-config[1]).+When no remote is specified, by the default the `origin` remote will be used,
I recall there were typofix comments on this line.
+unless there's an upstream branch configured for the current branch.
Also there was a phrasing comment on this one, I think.
Resending without rerolling is not very much appreciated.
@@ -5,6 +5,7 @@#include"grep.h"#include"notes.h"#include"commit.h"+#include"diff.h"#define SEEN (1u<<0)#define UNINTERESTING (1u<<1)
This is a step in the right direction to change the contract between
this header file and its consumers, but I think it falls short of
doing a good job at it.
The rule used to be that "if you use a declaration in revision.h,
you must include diff.h before including it, even if you do not use
any declaration made in diff.h yourself".
The new rule this patch introduces is "if you use a declaration in
foo.h, include foo.h, period---foo.h should handle its requirement
on its own internally and consumers should not have to care", which
is much saner.
But the patch needs to also remove '#include "diff.h"' from existing
consumers that themselves do not use any declaration from "diff.h"
(e.g. bundle.c; there are others), while keeping the inclusion in
those that do (e.g. builtin/commit.c). That can be a separate patch
that immediately follow this one, or a part of the same patch.
Thanks.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:59:09
Felipe Contreras [off-list ref] writes:
quoted hunk
'origin/master' is very clear, no need to specify the 'remotes/' prefix,
or babysit the user.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -39,7 +39,7 @@ Assume the following history exists and the current branch is "`master`": ------------- A---B---C master on origin+ A---B---C origin/master / D---E---F---G master ------------
This change is wrong; the illustration depicts the distributed world
(i.e. a fetch has not happened yet). The next sentence after this
picture reads:
Then "`git pull`" will fetch and replay the changes from the remote
`master` branch since it diverged from the local `master`
In other words, your (remotes/)origin/master has _not_ caught up to
the reality.
quoted hunk
@@ -51,7 +51,7 @@ result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. ------------- A---B---C remotes/origin/master+ A---B---C origin/master / \ D---E---F---G---H master ------------
This is a good change, especially in today's world.
Thanks.
@@ -39,7 +39,7 @@ Assume the following history exists and the current branch is "`master`": ------------- A---B---C master on origin+ A---B---C origin/master / D---E---F---G master ------------
This change is wrong; the illustration depicts the distributed world
(i.e. a fetch has not happened yet).
That is an irrelevant implementation detail, specially at this high
level. In the user's mind origin/master means master on origin.
If you want to be pedantic, this is the "reality":
------------
D---E---F---G master
------------
--
Felipe Contreras
@@ -37,6 +37,9 @@ or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See linkgit:git-config[1]).+When no remote is specified, by the default the `origin` remote will be used,
I recall there were typofix comments on this line.
@@ -37,7 +37,7 @@ or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See linkgit:git-config[1]).-When no remote is specified, by the default the `origin` remote will be used,+When no remote is specified, by default the `origin` remote will be used, unless there's an upstream branch configured for the current branch. OPTIONS
quoted
+unless there's an upstream branch configured for the current branch.
Also there was a phrasing comment on this one, I think.
There was no constructive comment, no alternative was proposed.
The conclusion of the discussion (at least mine) is that the phrasing is fine.
Resending without rerolling is not very much appreciated.
I missed a valid comment in one of my 160 pending patches. Sue me.
--
Felipe Contreras
From: Martin von Zweigbergk <hidden> Date: 2016-06-15 22:59:09
I was recently confused by the yoda condition in this block of code from [1]
+ for (i = 0; i < revs.nr; i++)
+ if (&bases->item->object == &revs.commit[i]->object)
+ break; /* found */
+ if (revs.nr <= i)
I think I was particularly surprised because it came so soon after the
"i < revs.nr". I didn't bother commenting because it seemed too
subjective and the code base has tons of these. Something as simple as
git grep '[0-9] [<>]' *.c
finds a bunch (probably with lots of false positives and negatives).
I guess what I'm trying to say is that either we accept them and get
used to reading them without being surprised, or we can change a bit
more than one at a time perhaps? I understand that this was an
occurrence you just happened to run into, and I'm not saying that a
patch has to deal with _all_ occurrences. I'm more just wondering if
we want mention our position, whatever it is, in CodingGuidelines.
Martin
[1] http://thread.gmane.org/gmane.comp.version-control.git/236252/focus=236716
On Thu, Oct 31, 2013 at 2:25 AM, Felipe Contreras
[off-list ref] wrote:
@@ -429,7 +429,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)argc--;argv++;-if(0<=addremove_explicit)+if(addremove_explicit>=0)addremove=addremove_explicit;elseif(take_worktree_changes&&ADDREMOVE_DEFAULT)addremove=0;/* "-u" was given but not "-A" */--
1.8.4.2+fc1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Felipe Contreras <hidden> Date: 2016-06-15 22:59:09
On Thu, Oct 31, 2013 at 1:48 PM, Martin von Zweigbergk
[off-list ref] wrote:
I guess what I'm trying to say is that either we accept them and get
used to reading them without being surprised, or we can change a bit
more than one at a time perhaps? I understand that this was an
occurrence you just happened to run into, and I'm not saying that a
patch has to deal with _all_ occurrences. I'm more just wondering if
we want mention our position, whatever it is, in CodingGuidelines.
Yes, I'm all in favor of updating CodingGuidelines with that.
--
Felipe Contreras