[PATCH v4 4/8] t5520: test work tree fast-forward when fetch updates head
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull, upon detecting that git-fetch updated the current head, will fast-forward the working tree to the updated head commit. Implement tests to ensure that the fast-forward occurs in such a case, as well as to ensure that the user-friendly advice is printed upon failure. Signed-off-by: Paul Tan --- * Removed use of "verbose". t/t5520-pull.sh | 21 + 1 file changed, 21 insertions(+) diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh index 3bc0594..3a53a5e 100755 --- a/t/t5520-pull.sh +++ b/t/t5520-pull.sh @@ -184,6 +184,27 @@ test_expect_success 'fail if the index has unresolved entries' ' test_cmp expected file ' +test_expect_success 'fast-forwards working tree if branch head is updated' ' + git checkout -b third second^ && + test_when_finished "git checkout -f copy && git branch -D third" && + test "$(cat file)" = file && + git pull . second:third 2>err && + test_i18ngrep "fetch updated the current branch head" err && + test "$(cat file)" = modified && + test "$(git rev-parse third)" = "$(git rev-parse second)" +' + +test_expect_success 'fast-forward fails with conflicting work tree' ' + git checkout -b third second^ && + test_when_finished "git checkout -f copy && git branch -D third" && + test "$(cat file)" = file && + echo conflict >file && + test_must_fail git pull . second:third 2>err && + test_i18ngrep "Cannot fast-forward your working tree" err && + test "$(cat file)" = conflict && + test "$(git rev-parse third)" = "$(git rev-parse second)" +' + test_expect_success '--rebase' ' git branch to-rebase && echo modified again > file && -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] pull: handle --log=
Since efb779f (merge, pull: add '--(no-)log' command line option, 2008-04-06) git-pull supported the (--no-)log switch and would pass it to git-merge. 96e9420 (merge: Make '--log' an integer option for number of shortlog entries, 2010-09-08) implemented support for the --log= switch, which would explicitly set the number of shortlog entries. However, git-pull does not recognize this option, and will instead pass it to git-fetch, leading to "unknown option" errors. Fix this by matching --log=* in addition to --log and --no-log. Implement a test for this use case. Signed-off-by: Paul Tan --- This is a re-roll of [1]. The only change is the removal of "verbose". Thanks Matthieu for the review last round. [1] http://thread.gmane.org/gmane.comp.version-control.git/268961 git-pull.sh | 4 ++-- t/t5524-pull-msg.sh | 17 + 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/git-pull.sh b/git-pull.sh index 9ed01fd..5ff4545 100755 --- a/git-pull.sh +++ b/git-pull.sh @@ -81,8 +81,8 @@ do diffstat=--no-stat ;; --stat|--summary) diffstat=--stat ;; - --log|--no-log) - log_arg=$1 ;; + --log|--log=*|--no-log) + log_arg="$1" ;; --no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit) no_commit=--no-commit ;; --c|--co|--com|--comm|--commi|--commit) diff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh index 8cccecc..eebb8c9 100755 --- a/t/t5524-pull-msg.sh +++ b/t/t5524-pull-msg.sh @@ -17,6 +17,9 @@ test_expect_success setup ' git commit -m "add bfile" ) && test_tick && test_tick && + echo "second" >afile && + git add afile && + git commit -m "second commit" && echo "original $dollar" >afile && git add afile && git commit -m "do not clobber $dollar signs" @@ -32,4 +35,18 @@ test_expect_success pull ' ) ' +test_expect_failure '--log=1 limits shortlog length' ' +( + cd cloned && + git reset --hard HEAD^ && + test "$(cat afile)" = original && + test "$(cat bfile)" = added && + git pull --log=1 && + git log -3 && + git cat-file commit HEAD >result && + grep Dollar result && + ! grep "second commit" result +) +' + test_done -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] pull: parse pull.ff as a bool or string
Since b814da8 (pull: add pull.ff configuration, 2014-01-15) git-pull supported setting --(no-)ff via the pull.ff configuration value. However, as it only matches the string values of "true" and "false", it does not support other boolean aliases such as "on", "off", "1", "0". This is inconsistent with the merge.ff setting, which supports these aliases. Fix this by using the bool_or_string_config function to retrieve the value of pull.ff. Signed-off-by: Paul Tan --- git-pull.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-pull.sh b/git-pull.sh index e51dd37..09bc678 100755 --- a/git-pull.sh +++ b/git-pull.sh @@ -54,7 +54,7 @@ then fi # Setup default fast-forward options via `pull.ff` -pull_ff=$(git config pull.ff) +pull_ff=$(bool_or_string_config pull.ff) case "$pull_ff" in true) no_ff=--ff -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pull: use git-rev-parse --parseopt for option parsing
Hi Paul, On 2015-05-18 15:54, Paul Tan wrote: > diff --git a/git-pull.sh b/git-pull.sh > index 633c385..67f825c 100755 > --- a/git-pull.sh > +++ b/git-pull.sh > @@ -4,13 +4,53 @@ > # > # Fetch one or more remote refs and merge it/them into the current HEAD. > > -USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] > [--[no-]ff|--ff-only] [--[no-]rebase|--rebase=preserve] [-s > strategy]... [] ...' > -LONG_USAGE='Fetch one or more remote refs and integrate it/them with > the current HEAD.' > SUBDIRECTORY_OK=Yes > -OPTIONS_SPEC= > +OPTIONS_KEEPDASHDASH=Yes I have to admit that I was puzzled by this at first. But it seems that the intention is to handle a dashdash argument as an error, therefore we have to keep it. Is my understanding correct? Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] Make git-pull a builtin
This series directly depends on the changes made in jc/merge and pt/pull-tests. The commit messages assume that the behavioral changes proposed in pt/pull-log-n, pt/pull-tags-error-diag, pt/pull-ff-vs-merge-ff, and [1] have been introduced. git-pull is a commonly executed command to check for new changes in the upstream repository and, if there are, fetch and integrate them into the current branch. Currently it is implemented by the shell script git-pull.sh. However, compared to C, shell scripts have certain deficiencies: 1. Usually have to rely on spawning a lot of processes, which can be slow on systems that do not implement copy-on-write semantics. 2. They introduce a lot of dependencies, especially on non-POSIX systems. 3. They cannot take advantage of git's C API and internal caches. This series rewrites git-pull.sh into a C builtin, thus improving its performance and portability. It is part of my GSoC project to rewrite git-pull and git-am into builtins[2]. [1] http://thread.gmane.org/gmane.comp.version-control.git/269249 [2] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1 Paul Tan (14): pull: implement fetch + merge pull: pass verbosity, --progress flags to fetch and merge pull: pass git-merge's options to git-merge pull: pass git-fetch's options to git-fetch pull: error on no merge candidates pull: support pull.ff config pull: check if in unresolved merge state pull: fast-forward working tree if head is updated pull: implement pulling into an unborn branch pull: set reflog message pull: teach git pull about --rebase pull: configure --rebase via branch..rebase or pull.rebase pull --rebase: exit early when the working directory is dirty pull --rebase: error on no merge candidate cases Makefile | 2 +- advice.c | 8 + advice.h | 1 + builtin.h| 1 + builtin/pull.c | 919 +++ contrib/examples/git-pull.sh | 339 git-pull.sh | 339 git.c| 1 + 8 files changed, 1270 insertions(+), 340 deletions(-) create mode 100644 builtin/pull.c create mode 100755 contrib/examples/git-pull.sh delete mode 100755 git-pull.sh -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/14] pull: configure --rebase via branch..rebase or pull.rebase
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28),
fetch+rebase could be set by default by defining the config variable
branch..rebase. This setting can be overriden on the command line
by --rebase and --no-rebase.
Since 6b37dff (pull: introduce a pull.rebase option to enable --rebase,
2011-11-06), git-pull --rebase can also be configured via the
pull.rebase configuration option.
Re-implement support for these two configuration settings by introducing
config_get_rebase() which is called before parse_options() to set the
default value of opt_rebase.
Signed-off-by: Paul Tan
---
builtin/pull.c | 35 +++
t/t5520-pull.sh | 12 ++--
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/builtin/pull.c b/builtin/pull.c
index f18a21c..a0958a7 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -294,6 +294,39 @@ static const char *config_get_ff(void)
die(_("Invalid value for pull.ff: %s"), value);
}
+/**
+ * Returns the default configured value for --rebase. It first looks for the
+ * value of "branch.$curr_branch.rebase", where $curr_branch is the current
+ * branch, and if HEAD is detached or the configuration key does not exist,
+ * looks for the value of "pull.rebase". If both configuration keys do not
+ * exist, returns REBASE_FALSE.
+ */
+static int config_get_rebase(void)
+{
+ struct strbuf sb = STRBUF_INIT;
+ struct branch *curr_branch = branch_get("HEAD");
+ const char *key, *str;
+ int ret = -1, value;
+
+ if (curr_branch) {
+ strbuf_addf(&sb, "branch.%s.rebase", curr_branch->name);
+ key = sb.buf;
+ ret = git_config_get_value(sb.buf, &str);
+ }
+ if (ret) {
+ key = "pull.rebase";
+ ret = git_config_get_value(key, &str);
+ }
+ if (ret) {
+ strbuf_release(&sb);
+ return REBASE_FALSE;
+ }
+ if ((value = parse_config_rebase(str)) < 0)
+ die(_("Invalid value for %s: %s"), key, str);
+ strbuf_release(&sb);
+ return value;
+}
+
struct known_remote {
struct known_remote *next;
struct remote *remote;
@@ -730,6 +763,8 @@ int cmd_pull(int argc, const char **argv, const char
*prefix)
if (!getenv("GIT_REFLOG_ACTION"))
set_reflog_message(argc, argv);
+ opt_rebase = config_get_rebase();
+
argc = parse_options(argc, argv, prefix, pull_options, pull_usage, 0);
parse_repo_refspecs(argc, argv, &repo, &refspecs);
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 3798b96..17254ee 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -234,7 +234,7 @@ test_expect_success '--rebase fails with multiple branches'
'
test modified = "$(git show HEAD:file)"
'
-test_expect_failure 'pull.rebase' '
+test_expect_success 'pull.rebase' '
git reset --hard before-rebase &&
test_config pull.rebase true &&
git pull . copy &&
@@ -242,7 +242,7 @@ test_expect_failure 'pull.rebase' '
test new = "$(git show HEAD:file2)"
'
-test_expect_failure 'branch.to-rebase.rebase' '
+test_expect_success 'branch.to-rebase.rebase' '
git reset --hard before-rebase &&
test_config branch.to-rebase.rebase true &&
git pull . copy &&
@@ -280,7 +280,7 @@ test_expect_success 'pull.rebase=false create a new merge
commit' '
test file3 = "$(git show HEAD:file3.t)"
'
-test_expect_failure 'pull.rebase=true flattens keep-merge' '
+test_expect_success 'pull.rebase=true flattens keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase true &&
git pull . copy &&
@@ -288,7 +288,7 @@ test_expect_failure 'pull.rebase=true flattens keep-merge' '
test file3 = "$(git show HEAD:file3.t)"
'
-test_expect_failure 'pull.rebase=1 is treated as true and flattens keep-merge'
'
+test_expect_success 'pull.rebase=1 is treated as true and flattens keep-merge'
'
git reset --hard before-preserve-rebase &&
test_config pull.rebase 1 &&
git pull . copy &&
@@ -296,7 +296,7 @@ test_expect_failure 'pull.rebase=1 is treated as true and
flattens keep-merge' '
test file3 = "$(git show HEAD:file3.t)"
'
-test_expect_failure 'pull.rebase=preserve rebases and merges keep-merge' '
+test_expect_success 'pull.rebase=preserve rebases and merges keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase preserve &&
git pull . copy &&
@@ -304,7 +304,7 @@ test_expect_failure 'pull.rebase=preserve rebases and
merges keep-merge' '
test "$(git rev-parse HEAD^2)" = "$(git rev-parse keep-merge)"
'
-test_expect_failure 'pull.rebase=invalid fails' '
+test_expect_success 'pull.rebase=invalid fails' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase invalid &&
! git pull . copy
--
2.1.4
--
To unsubscribe from this list:
Re: [PATCH] t1020: cleanup subdirectory tests a little
Junio C Hamano writes: > Stefan Beller writes: > >> When looking through existing tests to point out good style I came across >> t1020, which has a test commented out and the comment wasn't helping me >> either of what the test should accomplish in the future. The code of the >> test is the same as the test before except setting GIT_DIR=. explicitly, >> so it did not ring a bell for me as well. > > I think this one should be clear, especially if you did notice the > one that sets GIT_DIR=. explicitly. It is saying that "git show -s > HEAD" inside the bare repository should be intelligent enough to > realize that it is inside bare repository (hence HEAD cannot be a > file in the working tree); the user's asking for "HEAD" therefore > must mean "the tip commit", and never "(by default the tip commit) > filtered to the pathspec HEAD". I forgot to conclude that sentence: "... and it should be able to do so without the help of an explicit GIT_DIR=." > If it does not still work, shouldn't it be marked as > test_expect_failure instead of being commented out? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Make git-pull a builtin
Hi Paul, I already commented on patches 1-10, and I will look in depth at 11-14 tomorrow. It is a very pleasant read so far. Thank you. Ciao, Dscho P.S.: I have the feeling about patch 12 that reading `opt_rebase` from the config could be delayed until after we know that the user did not specify `--rebase`, but I'll have to think about that more deeply. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sh -x -i -v with continuous integration, was Re: [PATCH 1/4] t7601: test for pull.ff=true overrides merge.ff=false
Jeff King writes: > What do you want to do with the "verbose" calls I have been sprinkling > through the test suite (and the function itself)? Leave them or remove > them? A grep for "verbose " (with the trailing space) shows some > examples. That was one of the things I wanted to do next, as I suspected that the small number of existing ones might be mostly "obviously good" ones (I never said any 'verbose test' is automatically bad; it is just 'verbose test "$a" = "$b"' that hides what $a and $b were are as useful as without 'verbose'), but I didn't offhand think of examples of obviously good ones. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git p4 clone - exclude file types
On 18/05/15 18:59, FusionX86 wrote: Hello, Anyone know of a way to 'git p4 clone' and exclude files by type or name? For example, I want to clone a depot, but not pull down any .exe files. Haven't been able to find an answer in docs or other searches. I think you can use a client spec which excludes the files you want. First, create a client spec that excludes the files you don't want: Client: myclient View: //depot/mystuff/... //myclient/... -//depot/mystuff/...exe //myclient/...exe Then clone with the --use-client-spec option: $ export P4CLIENT=myclient $ git p4 clone --use-client-spec //depot/mystuff And later on, when you want to catch up: $ cd mystuff $ git p4 sync --use-client-spec Luke -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 5/5] help: respect new common command grouping
Sébastien Guimmara writes: > 'git help' shows common commands in alphabetical order: > > The most commonly used git commands are: >addAdd file contents to the index >bisect Find by binary search the change that introduced a bug >branch List, create, or delete branches >checkout Checkout a branch or paths to the working tree >clone Clone a repository into a new directory >commit Record changes to the repository >[...] > > without any indication of how commands relate to high-level > concepts or each other. Revise the output to explain their relationship > with the typical Git workflow: > > The typical Git workflow includes: > > start a working area (see also: git help tutorial) >clone Clone a repository into a new directory >init Create an empty Git repository or reinitialize [...] > > work on the current change (see also: git help everyday) >addAdd file contents to the index >mv Move or rename a file, a directory, or a symlink >reset Reset current HEAD to the specified state >rm Remove files from the working tree and from the index > > examine the history and state (see also: git help revisions) >logShow commit logs >status Show the working tree status > >[...] > > Helped-by: Eric Sunshine > Signed-off-by: Sébastien Guimmara > --- I cannot exactly pinpoint what bothers me, but "The typical Git workflow includes:" sounds a bit awkward. What does a workflow "include"? What are components included in a workflow? Are "starting a repository", "working on a single thing", "collabolating", etc. components that are incuded in a workflow? If so, the fact that "clone", "init", etc. are "commands that are commonly used in each component of the workflow" is a more important thing to say; in other words, the header does not explain what list it is presenting the user. Or does a workflow consists of "clone", "init", "add", "mv", etc. that are included in it? Then it is left unexplained what the section headings stand for. Perhaps something like These are common Git commands used in various situations: may lessen the uneasiness I felt above. I dunno. Other than that, this round looks ready for 'next'. I am not absolutely sure if new dependency on "awk" will not present portability issues, though. So far we only used it in scripts in the fringes and only a few tests. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Server Repository Security?
On 05/18/2015 04:28 PM, John McIntyre wrote: > 2015-05-18 11:26 GMT+01:00 Heiko Voigt : >> If you want a simple tool using ssh-keys have a look at gitolite[1]. >> It quite simple to setup and with it you can specify all kinds of access >> rights. > > That's adding a separate level of complexity. > > I looked into filesystem-level permissions. I don't see any means of > doing so, because everyone accesses the repositories using the 'git' > user. So even if I add a group like 'devClient1' and then change the > group ownership of a repo to that user, they'll still be able to > access all repos..? My usual answer to this is http://gitolite.com/gitolite/overview.html#basic-use-case The first example is doable with file system permissions if you give everyone a separate userid, but it's a nightmare. The second one is not even possible. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students contributing to git
On Mon, May 18, 2015 at 4:23 PM, Antoine Delaite wrote: > Hello Git community, > > > We are a team of five students from the ENSIMAG (a french school of > engineering and computer science) who are going to contribute to git during a > month at least and after if we have the opportunity. We will work under the > supervision of Mr. Moy. > > > We are glad to contribute to git and we are looking forward to getting > advices and reviews from the git community. It will be a great experience for > us as young programmers. > > > We planned to work on « git pull –setupstream » for the first days if nobody > is currently working on it and then we thought of finishing the work of elder > contributors from the ensimag on : « git bisect fix/unfixed ». git pull is being converted from shell to C as part of the Google Summer of Code (cc'ing Paul Tan who is the student, and Johannes Schindelin and me who are the mentors) so there may be some merge conflicts arising if we go uncoordinated. See a planned timeline of Paul at [1]. Depending on your timeline, it might be wise to hold on a bit and then base your contributions on the C implementation rather than the bash implementation. git bisect fix/unfixed sounds interesting though (just today I tried to find a fix and messed up, again). I am not aware of the scope you're planning to contribute to within the git bisect fix/unfixed topic, though I'd like to share a result[2] of a discussion we had some time ago, on how git bisect can be improved (nobody did it yet though). Thanks, Stefan [1] http://permalink.gmane.org/gmane.comp.version-control.git/266198 [2] https://docs.google.com/document/d/1hzF8fZbsQtKwUPH60dsEwVZM2wmESFq713SeAsg_hkc/edit?usp=sharing -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
