git clone --depth: shallow clone problems
tl: skip to the second paragraph So here is what I just experienced: We had an emergency error in an application at work and as the responsible developer was unavailable, I was asked to check it out and look into it. We are a small branch of a bigger company and our connection to the company's source servers is really slow, so just to quickly start it up, I decided to take a shallow clone (that's what it is for, right?). After a while we realized, the clone I have made was not sufficient and was missing some newest work done on the project. I did git fetch --unshallow which finished surprisingly quickly, and it did not bring any newer commits. Unaware of the fine print hiding in the documentation of git clone, I blamed the repo (and in extension the person who provided me the address to it). After coming to a realization, a process which cost me time and embarrassment, I understood what is supposed to be the correct behaviour: --single-branch Clone only the history leading to the tip of a single branch, either specified by the --branch option or the primary branch remote's HEAD points at. When creating a shallow clone with the --depth option, this is the default, unless --no-single-branch is given to fetch the histories near the tips of all branches. Of course, the new commits were put on a custom branch, and I knew that all the time, but I expected the branch to show up eventually, at least after git fetch --unshallow. I hope you can see the faults in the usability of the commands I was exposed to: 1) git clone --depth should: -warn about only fetching the current HEAD (name it by a real name if applicable) and/or -require the --branch option so that it is not left to chance (current HEAD could be anything; is it really meaningful to talk about the current HEAD on a server?) and/or -make the --no-single-branch the default... and maybe -have the option to clone the most recent commits. 2) git fetch --unshallow should convert the clone into an actual equivalent of a normal, not shallow clone. 3) The documentation should be improved. The behaviour of --shallow is described partly in the description of --no-single-branch. This is the documentation equivalent of the infamous come from control flow structure. Regards, Michal Pomorski -- 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] connect: improve check for plink to reduce false positives
On Thu, Apr 23, 2015 at 08:50:17AM +0200, Johannes Schindelin wrote: + tortoiseplink = tplink == ssh || + (tplink is_dir_sep(tplink[-1])); Maybe have a helper function here? Something like `basename_matches(const char *path, const char *basename, int ignore_case)`? That would be easier to read (I have to admit that I had to wrap my head around the logic to ensure that tplink[-1] is valid; It is, but it requires more brain cycles to verify than I would like). Yeah, I had a similar thought when reading the patch. Also, I am really hesitant to just test the start of the basename; I would rather have an entire basename match so that something like PLinKoeln would not match. (And of course, for Windows I would want that hypothetical `basename_matches()` function to allow basenames to end in `.exe` automatically). What about plink-0.83 that was mentioned earlier in the thread? I think that is the reason brian's patch stuck to matching the start and not the end. But I have no idea if that is actually a real thing, or just a hypothetical. If I were writing from scratch, I would probably keep things as tight as possible, like: const char *base = basename(ssh); plink = !strcasecmp(base, plink) || !strcasecmp(base, plink.exe); tplink = !strcasecmp(base, tortoiseplink) || !strcasecmp(base, tortoiseplink.exe)); but maybe that is too tight at this point in time; we don't really know what's out there and working (or maybe _we_ do, but _I_ do not :) ). At any rate, brian's patch only looks for a dir-separator anywhere, not the actual basename. So: /path/to/plink/ssh would match, and I'm not sure if that's a good thing or not. So yet another variant is to use basename(), and then just check that the basename starts with plink (to catch plink.exe, plink-0.83, etc). That avoids cruft in the intermediate path, and unless your actual binary is named PlinKoeln, it will not false positive on the example you gave. -Peff -- 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 5/5] RelNotes: wordsmithing
Michael Haggerty mhag...@alum.mit.edu writes: On 04/23/2015 02:27 PM, Michael Haggerty wrote: Make many textual tweaks to the 2.4.0 release notes. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/RelNotes/2.4.0.txt | 336 --- 1 file changed, 172 insertions(+), 164 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index 7b23ca3..cde64be 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt [...] Oh, I just noticed that many of the same blurbs appear in the release notes for the maintenance versions. Once there is agreement on how many of the changes to accept, the analogous changes should probably be made in those other files. Thanks. FYI, these days the same text appears in (1) the topic description in What's cooking; (2) the merge commit for the topic when it is merged to 'next'; (3) the merge commit for the topic when it is merged to 'master'; (4) Release notes for the 'master' and 'maint', when it is merged. So the best time to catch mistakes and to rephrase it is when you see something questionable in What's cooking, ideally before it hits 'next', before it hits 'master'. -- 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/5] git tag: mention versionsort.prereleaseSuffix in manpage
Michael Haggerty mhag...@alum.mit.edu writes: Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Makes sense; will queue on nd/versioncmp-prereleases. Thanks. Documentation/git-tag.txt | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index bfba4ef..f5b267e 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -98,10 +98,13 @@ OPTIONS --sort=type:: Sort in a specific order. Supported type is refname (lexicographic order), version:refname or v:refname (tag - names are treated as versions). Prepend - to reverse sort - order. When this option is not given, the sort order defaults to the - value configured for the 'tag.sort' variable if it exists, or - lexicographic order otherwise. See linkgit:git-config[1]. + names are treated as versions). The version:refname sort + order can also be affected by the + versionsort.prereleaseSuffix configuration variable. Prepend + - to reverse sort order. When this option is not given, the + sort order defaults to the value configured for the 'tag.sort' + variable if it exists, or lexicographic order otherwise. See + linkgit:git-config[1]. --column[=options]:: --no-column:: -- 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 3/5] RelNotes: correct name of versionsort.prereleaseSuffix
Michael Haggerty mhag...@alum.mit.edu writes: Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Thanks. Documentation/RelNotes/2.4.0.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index a0ee37d..c02de8d 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt @@ -109,8 +109,8 @@ UI, Workflows Features cd '' which silently behaves as a no-op. (merge 6a536e2 kn/git-cd-to-empty later to maint). - * The versionsort.prerelease configuration variable can be used to - specify that v1.0-pre1 comes before v1.0. + * The versionsort.prereleaseSuffix configuration variable can be used + to specify that v1.0-pre1 comes before v1.0. * A new push.followTags configuration turns the --follow-tags option on by default for the git push command. -- 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 v2 02/16] refs: convert for_each_tag_ref to struct object_id
On Wed, Apr 22, 2015 at 4:24 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
To allow piecemeal conversion of the for_each_*_ref functions, introduce
an additional typedef for a callback function that takes struct
object_id * instead of unsigned char *. Provide an extra field in
struct ref_entry_cb for this callback and ensure at most one is set at a
time. Temporarily suffix these new entries with _oid to distinguish
them. Convert for_each_tag_ref and its callers to use the new _oid
functions, introducing temporary wrapper functions to avoid type
mismatches.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
I am currently running this patch series via
git rebase -i origin/next --exec=make --exec=make test
through the compilation and test suite one by one.
(My current view of origin/next is (c8da2d582, Sync with 2.4.0-rc3)
and this commit fails in t5312-prune-corruption.sh test 3 5 and 8
---
builtin/pack-objects.c | 4 ++--
builtin/rev-parse.c| 7 ++-
builtin/tag.c | 8
refs.c | 34 ++
refs.h | 10 +-
5 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c067107..0c69b0c 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -540,11 +540,11 @@ static enum write_one_status write_one(struct sha1file
*f,
return WRITE_ONE_WRITTEN;
}
-static int mark_tagged(const char *path, const unsigned char *sha1, int flag,
+static int mark_tagged(const char *path, const struct object_id *oid, int
flag,
void *cb_data)
{
unsigned char peeled[20];
- struct object_entry *entry = packlist_find(to_pack, sha1, NULL);
+ struct object_entry *entry = packlist_find(to_pack, oid-hash, NULL);
if (entry)
entry-tagged = 1;
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 4d10dd9..7b70650 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -198,6 +198,11 @@ static int show_reference(const char *refname, const
unsigned char *sha1, int fl
return 0;
}
+static int show_reference_oid(const char *refname, const struct object_id
*oid, int flag, void *cb_data)
+{
+ return show_reference(refname, oid-hash, flag, cb_data);
+}
+
static int anti_reference(const char *refname, const unsigned char *sha1,
int flag, void *cb_data)
{
show_rev(REVERSED, sha1, refname);
@@ -682,7 +687,7 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
continue;
}
if (!strcmp(arg, --tags)) {
- for_each_tag_ref(show_reference, NULL);
+ for_each_tag_ref(show_reference_oid, NULL);
clear_ref_exclusion(ref_excludes);
continue;
}
diff --git a/builtin/tag.c b/builtin/tag.c
index 6f07ac6..61399b7 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -215,7 +215,7 @@ free_return:
free(buf);
}
-static int show_reference(const char *refname, const unsigned char *sha1,
+static int show_reference(const char *refname, const struct object_id *oid,
int flag, void *cb_data)
{
struct tag_filter *filter = cb_data;
@@ -224,14 +224,14 @@ static int show_reference(const char *refname, const
unsigned char *sha1,
if (filter-with_commit) {
struct commit *commit;
- commit = lookup_commit_reference_gently(sha1, 1);
+ commit = lookup_commit_reference_gently(oid-hash, 1);
if (!commit)
return 0;
if (!contains(commit, filter-with_commit))
return 0;
}
- if (points_at.nr !match_points_at(refname, sha1))
+ if (points_at.nr !match_points_at(refname, oid-hash))
return 0;
if (!filter-lines) {
@@ -242,7 +242,7 @@ static int show_reference(const char *refname, const
unsigned char *sha1,
return 0;
}
printf(%-15s , refname);
- show_tag_lines(sha1, filter-lines);
+ show_tag_lines(oid-hash, filter-lines);
putchar('\n');
}
diff --git a/refs.c b/refs.c
index 522d15d..95863f2 100644
--- a/refs.c
+++ b/refs.c
@@ -694,6 +694,7 @@ struct ref_entry_cb {
int trim;
int flags;
each_ref_fn *fn;
+ each_ref_fn_oid *fn_oid;
void *cb_data;
};
@@ -717,8 +718,13 @@ static int do_one_ref(struct ref_entry *entry, void
*cb_data)
/* Store the old value, in case this is a
Re: [PATCHv3] refs.c: enable large transactions
Stefan Beller sbel...@google.com writes:
diff --git a/refs.c b/refs.c
index 4f495bd..7ce7b97 100644
--- a/refs.c
+++ b/refs.c
@@ -3041,6 +3041,13 @@ static int write_ref_sha1(struct ref_lock *lock,
errno = EINVAL;
return -1;
}
+ if (lock-lk-fd == -1 reopen_lock_file(lock-lk) == -1) {
Granted, we explicitly assign -1 to lk-fd when we know it is
closed, and the return value from reopen_lock_file() can come only
from the return value from open(2), which is defined to return -1
(i.e. not just any negative value) upon failure, but still, isn't it
customary to check with 0 rather than == -1 for errors?
+ int save_errno = errno;
+ error(Couldn't reopen %s, lock-lk-filename.buf);
No need to change this line, but I noticed that we might want to do
something about the first one of the following two:
$ git grep -e '[]error(_*[A-Z]' | wc -l
146
$ git grep -e '[]error(_*[a-z]' | wc -l
390
+ unlock_ref(lock);
+ errno = save_errno;
+ return -1;
+ }
Is this the only place in the entire codebase where a lockfile,
which may have been closed to save number of open file descriptors,
needs to be reopened? If I understand correctly, lockfile API is
not for sole use of refs (don't the index and the pack codepaths use
it, too?), so it may give us a better abstraction to have a helper
function in lockfile.[ch] that takes a lock object, i.e.
int make_lock_fd_valid(struct lock_file *lk)
{
if (lk-fd 0 reopen_lock_file(lk) 0) {
... error ...
return -1;
}
return 0;
}
and to call it at this point, i.e.
if (make_lock_fd_valid(lock-lk) 0)
return -1;
perhaps?
@@ -3733,6 +3741,20 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
return 0;
}
+ /*
+ * We need to open many files in a large transaction, so come up with
+ * a reasonable maximum. We still keep some spares for stdin/out and
+ * other open files. Experiments determined we need more fds when
+ * running inside our test suite than directly in the shell. It's
+ * unclear where these fds come from. 25 should be a reasonable large
+ * number though.
+ */
+ remaining_fds = get_max_fd_limit();
+ if (remaining_fds 25)
+ remaining_fds -= 25;
+ else
+ remaining_fds = 0;
Is the value of pack_open_fds visible from here? I am wondering if
we might want scratch fds Git can use for its own use accounting
so that the two subsystems can collectively say it is still safe
to use one more fd and leave 25 for other people. With the code
structure proposed here, the pack reader can grab all but 25 fds,
which would leave the rest of Git including this code only 25,
and the value in remaining_fds would become totally meaningless.
It certainly can wait to worry about that and we do not have to do
anything about it in this patch, but it may still be a good idea to
leave NEEDSWORK: comment here (and point at open_packed_git_1() in
sha1_file.c in the comment).
I do not think the other side needs to know about the fd consumption
in this function, as what is opened in here will be closed before
this function returns.
@@ -3762,6 +3784,12 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
update-refname);
goto cleanup;
}
+ if (!(flags REF_HAVE_NEW) ||
+ is_null_sha1(update-new_sha1) ||
+ remaining_fds == 0)
+ close_lock_file(update-lock-lk);
+ else
+ remaining_fds--;
}
--
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: Rebasing with submodule change causes red herring with --continue
On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote: I have a branch that contains a commit with a single change: A submodule pointing to a new SHA1. When I rebase this branch onto the tip of its parent branch AND that parent branch had modified that same submodule, the rebase stops at the commit on my branch that modified the submodule and asks me if I want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that the submodule is not staged (normally it would be). I do: $ git add my-submodule Then I do: $ git rebase --continue At this point, it fails asking me if I forgot to stage changes and recommends doing --skip. This is normally what you would see if the staging area was completely empty, however it isn't, since I see the submodule is in there. Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0 on Windows through MSYS. I'll provide more concrete examples if my summary of the issue doesn't ring any bells. I hit something similar in the past, but it was fixed with commit a6754cd (rebase -i continue: don't skip commits that only change submodules, 2012-04-07) so I think you must be hitting a slightly different problem, although the tests added in that commit look like they do test the scenario you describe (specifically 'rebase -i continue with only submodule staged'). I am still running into this issue on git 2.3.5 on Windows. Logs below. One interesting thing to note in the git trace output is that it is specifying --ignore-submodules option to `git diff-files` during the rebase continue. Is this due to a configuration option? It seems like git should not be ignoring submodules when continuing a rebase (this should only affect direct calls to diff) |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ git status rebase in progress; onto bb05e7c You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'. (all conflicts fixed: run git rebase --continue) Changes to be committed: (use git reset HEAD file... to unstage) modified: Core Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: Core (new commits) Untracked files: (use git add file... to include in what will be committed) Tools/FontTool/ |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ GIT_TRACE=1 git rebase --continue 19:15:33.569945 git.c:557 trace: exec: 'git-rebase' '--continue' 19:15:33.569945 run-command.c:351 trace: run_command: 'git-rebase' '--continue' 19:15:33.775097 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue' 19:15:33.931190 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:34.007242 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository' 19:15:34.059280 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:34.148343 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.stat' 19:15:34.227399 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autostash' 19:15:34.280437 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autosquash' 19:15:34.335476 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD' 19:15:34.389515 git.c:348 trace: built-in: git 'update-index' '--ignore-submodules' '--refresh' 19:15:34.554631 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' 19:15:34.902879 git.c:557 trace: exec: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:34.902879 run-command.c:351 trace: run_command: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.113028 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.290155 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:35.387224 git.c:348 trace: built-in: git 'rev-parse' '--show-prefix' 19:15:35.541332 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:35.598374 git.c:348 trace: built-in: git
Re: [PATCH 1/5] status: document the -v/--verbose option
Michael Haggerty mhag...@alum.mit.edu writes: Document `git status -v`, including its new doubled `-vv` form. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Will queue on mg/status-v-v series, which did add description for commit -v, but status -v did not have the description to begin with and we missed it. Thanks. Documentation/git-status.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index b3319f7..9ec5897 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -41,6 +41,15 @@ OPTIONS --long:: Give the output in the long-format. This is the default. +-v:: +--verbose:: + In addition to the names of files that have been changed, also + show the textual changes that are staged to be committed + (i.e., like the output of `git diff`). If `-v` is specified + twice, then also show the changes in the working tree that + have not yet been staged (i.e., like the output of `git diff + --cached`). + -u[mode]:: --untracked-files[=mode]:: Show untracked files. -- 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] merge: simplify code flow
One of the first things cmd_merge() does is to see if the --abort
option is given and run reset --merge and exit. When the control
reaches this point, we know --abort was not given.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/merge.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b0f8f9..0ab7142 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1158,15 +1158,15 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
option_commit = 0;
}
- if (!abort_current_merge) {
- if (!argc) {
- if (default_to_upstream)
- argc = setup_with_upstream(argv);
- else
- die(_(No commit specified and
merge.defaultToUpstream not set.));
- } else if (argc == 1 !strcmp(argv[0], -))
- argv[0] = @{-1};
+ if (!argc) {
+ if (default_to_upstream)
+ argc = setup_with_upstream(argv);
+ else
+ die(_(No commit specified and merge.defaultToUpstream
not set.));
+ } else if (argc == 1 !strcmp(argv[0], -)) {
+ argv[0] = @{-1};
}
+
if (!argc)
usage_with_options(builtin_merge_usage,
builtin_merge_options);
--
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: Installing git binaries on a non-default directory (Ubuntu)
On Mon, Apr 13, 2015 at 11:10:51AM +, Macario, Gianpaolo wrote: Unfortunately it looks to me that the `--prefix=xxx` option provided to configure will be hardcoded to the path returned by 'git --exec-path', and I do not see how this may actually be made dependent on the directory where the binary tarball will be extracted. Sorry for the late reply, but I just noticed this and happened to be looking at RUNTIME_PREFIX issues recently. You're right that no amount of --prefix or other settings can help you with making binaries that are relocatable after the fact. You do need something like RUNTIME_PREFIX, but as you found, it does not work very well on Unix systems. I do not know if there are other issues, but at least the _first_ issue that must be dealt with is that git_extract_argv0_path may get a bare name like git, without its PATH. So you will have to compute the full path to the binary in order to find the rest of the files. There was some minor discussion here: http://thread.gmane.org/gmane.comp.version-control.git/267143/focus=267606 (see the notes after the commit message, and the response from Jonathan). I hope that helps. -Peff -- 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 v2 02/16] refs: convert for_each_tag_ref to struct object_id
On Thu, Apr 23, 2015 at 11:13:32AM -0700, Stefan Beller wrote:
On Wed, Apr 22, 2015 at 4:24 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
To allow piecemeal conversion of the for_each_*_ref functions, introduce
an additional typedef for a callback function that takes struct
object_id * instead of unsigned char *. Provide an extra field in
struct ref_entry_cb for this callback and ensure at most one is set at a
time. Temporarily suffix these new entries with _oid to distinguish
them. Convert for_each_tag_ref and its callers to use the new _oid
functions, introducing temporary wrapper functions to avoid type
mismatches.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
I am currently running this patch series via
git rebase -i origin/next --exec=make --exec=make test
through the compilation and test suite one by one.
(My current view of origin/next is (c8da2d582, Sync with 2.4.0-rc3)
and this commit fails in t5312-prune-corruption.sh test 3 5 and 8
It's because of this hunk:
@@ -1950,6 +1956,21 @@ static int do_for_each_ref(struct ref_cache *refs,
const char *base,
data.trim = trim;
data.flags = flags;
data.fn = fn;
+ data.fn_oid = NULL;
+ data.cb_data = cb_data;
+
+ return do_for_each_entry(refs, base, do_one_ref, data);
+}
+
+static int do_for_each_ref_oid(struct ref_cache *refs, const char *base,
+ each_ref_fn_oid fn, int trim, int flags, void
*cb_data)
+{
+ struct ref_entry_cb data;
+ data.base = base;
+ data.trim = trim;
+ data.flags = flags;
+ data.fn = NULL;
+ data.fn_oid = fn;
data.cb_data = cb_data;
if (ref_paranoia 0)
The ref_paranoia code gets pushed down into do_for_each_ref_oid, but it
needs called in both do_for_each_ref variants. This is probably an
artifact of rebasing the patches (the ref_paranoia stuff was added
recently).
I think it would make sense to pull the setup of the data struct into a
shared function rather than duplicate it. But we want to avoid having to
update do_for_each_ref callsites, so we'll have to provide a wrapper.
Like this:
diff --git a/refs.c b/refs.c
index 95863f2..ad39d74 100644
--- a/refs.c
+++ b/refs.c
@@ -1948,29 +1948,16 @@ static int do_for_each_entry(struct ref_cache *refs,
const char *base,
* value, stop the iteration and return that value; otherwise, return
* 0.
*/
-static int do_for_each_ref(struct ref_cache *refs, const char *base,
- each_ref_fn fn, int trim, int flags, void *cb_data)
+static int do_for_each_ref_generic(struct ref_cache *refs, const char *base,
+ each_ref_fn fn, each_ref_fn_oid fn_oid,
+ int trim, int flags, void *cb_data)
{
struct ref_entry_cb data;
data.base = base;
data.trim = trim;
data.flags = flags;
data.fn = fn;
- data.fn_oid = NULL;
- data.cb_data = cb_data;
-
- return do_for_each_entry(refs, base, do_one_ref, data);
-}
-
-static int do_for_each_ref_oid(struct ref_cache *refs, const char *base,
- each_ref_fn_oid fn, int trim, int flags, void
*cb_data)
-{
- struct ref_entry_cb data;
- data.base = base;
- data.trim = trim;
- data.flags = flags;
- data.fn = NULL;
- data.fn_oid = fn;
+ data.fn_oid = fn_oid;
data.cb_data = cb_data;
if (ref_paranoia 0)
@@ -1981,6 +1968,18 @@ static int do_for_each_ref_oid(struct ref_cache *refs,
const char *base,
return do_for_each_entry(refs, base, do_one_ref, data);
}
+static int do_for_each_ref(struct ref_cache *refs, const char *base,
+ each_ref_fn fn, int trim, int flags, void *cb_data)
+{
+ return do_for_each_ref_generic(refs, base, fn, NULL, trim, flags,
cb_data);
+}
+
+static int do_for_each_ref_oid(struct ref_cache *refs, const char *base,
+ each_ref_fn_oid fn, int trim, int flags, void
*cb_data)
+{
+ return do_for_each_ref_generic(refs, base, NULL, fn, trim, flags,
cb_data);
+}
+
static int do_head_ref(const char *submodule, each_ref_fn fn, void *cb_data)
{
unsigned char sha1[20];
You can even dispense with the _oid variant wrapper, and just call into
the generic version directly from the new callsites.
-Peff
--
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: Rebasing with submodule change causes red herring with --continue
Am 23.04.2015 um 21:07 schrieb Robert Dailey: On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote: I have a branch that contains a commit with a single change: A submodule pointing to a new SHA1. When I rebase this branch onto the tip of its parent branch AND that parent branch had modified that same submodule, the rebase stops at the commit on my branch that modified the submodule and asks me if I want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that the submodule is not staged (normally it would be). I do: $ git add my-submodule Then I do: $ git rebase --continue At this point, it fails asking me if I forgot to stage changes and recommends doing --skip. This is normally what you would see if the staging area was completely empty, however it isn't, since I see the submodule is in there. Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0 on Windows through MSYS. I'll provide more concrete examples if my summary of the issue doesn't ring any bells. I hit something similar in the past, but it was fixed with commit a6754cd (rebase -i continue: don't skip commits that only change submodules, 2012-04-07) so I think you must be hitting a slightly different problem, although the tests added in that commit look like they do test the scenario you describe (specifically 'rebase -i continue with only submodule staged'). I am still running into this issue on git 2.3.5 on Windows. Logs below. One interesting thing to note in the git trace output is that it is specifying --ignore-submodules option to `git diff-files` during the rebase continue. Is this due to a configuration option? It seems like git should not be ignoring submodules when continuing a rebase (this should only affect direct calls to diff) |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ git status rebase in progress; onto bb05e7c You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'. (all conflicts fixed: run git rebase --continue) Changes to be committed: (use git reset HEAD file... to unstage) modified: Core Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: Core (new commits) Untracked files: (use git add file... to include in what will be committed) Tools/FontTool/ |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ GIT_TRACE=1 git rebase --continue 19:15:33.569945 git.c:557 trace: exec: 'git-rebase' '--continue' 19:15:33.569945 run-command.c:351 trace: run_command: 'git-rebase' '--continue' 19:15:33.775097 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue' 19:15:33.931190 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:34.007242 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository' 19:15:34.059280 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:34.148343 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.stat' 19:15:34.227399 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autostash' 19:15:34.280437 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autosquash' 19:15:34.335476 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD' 19:15:34.389515 git.c:348 trace: built-in: git 'update-index' '--ignore-submodules' '--refresh' 19:15:34.554631 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' 19:15:34.902879 git.c:557 trace: exec: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:34.902879 run-command.c:351 trace: run_command: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.113028 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.290155 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:35.387224 git.c:348 trace: built-in: git 'rev-parse' '--show-prefix' 19:15:35.541332 git.c:348
Re: Rebasing with submodule change causes red herring with --continue
On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote: Am 23.04.2015 um 21:07 schrieb Robert Dailey: On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote: I have a branch that contains a commit with a single change: A submodule pointing to a new SHA1. When I rebase this branch onto the tip of its parent branch AND that parent branch had modified that same submodule, the rebase stops at the commit on my branch that modified the submodule and asks me if I want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that the submodule is not staged (normally it would be). I do: $ git add my-submodule Then I do: $ git rebase --continue At this point, it fails asking me if I forgot to stage changes and recommends doing --skip. This is normally what you would see if the staging area was completely empty, however it isn't, since I see the submodule is in there. Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0 on Windows through MSYS. I'll provide more concrete examples if my summary of the issue doesn't ring any bells. I hit something similar in the past, but it was fixed with commit a6754cd (rebase -i continue: don't skip commits that only change submodules, 2012-04-07) so I think you must be hitting a slightly different problem, although the tests added in that commit look like they do test the scenario you describe (specifically 'rebase -i continue with only submodule staged'). I am still running into this issue on git 2.3.5 on Windows. Logs below. One interesting thing to note in the git trace output is that it is specifying --ignore-submodules option to `git diff-files` during the rebase continue. Is this due to a configuration option? It seems like git should not be ignoring submodules when continuing a rebase (this should only affect direct calls to diff) |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ git status rebase in progress; onto bb05e7c You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'. (all conflicts fixed: run git rebase --continue) Changes to be committed: (use git reset HEAD file... to unstage) modified: Core Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: Core (new commits) Untracked files: (use git add file... to include in what will be committed) Tools/FontTool/ |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ GIT_TRACE=1 git rebase --continue 19:15:33.569945 git.c:557 trace: exec: 'git-rebase' '--continue' 19:15:33.569945 run-command.c:351 trace: run_command: 'git-rebase' '--continue' 19:15:33.775097 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue' 19:15:33.931190 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:34.007242 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository' 19:15:34.059280 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:34.148343 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.stat' 19:15:34.227399 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autostash' 19:15:34.280437 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autosquash' 19:15:34.335476 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD' 19:15:34.389515 git.c:348 trace: built-in: git 'update-index' '--ignore-submodules' '--refresh' 19:15:34.554631 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' 19:15:34.902879 git.c:557 trace: exec: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:34.902879 run-command.c:351 trace: run_command: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.113028 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the
Re: Rebasing with submodule change causes red herring with --continue
On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote: I have a branch that contains a commit with a single change: A submodule pointing to a new SHA1. When I rebase this branch onto the tip of its parent branch AND that parent branch had modified that same submodule, the rebase stops at the commit on my branch that modified the submodule and asks me if I want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that the submodule is not staged (normally it would be). I do: $ git add my-submodule Then I do: $ git rebase --continue At this point, it fails asking me if I forgot to stage changes and recommends doing --skip. This is normally what you would see if the staging area was completely empty, however it isn't, since I see the submodule is in there. Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0 on Windows through MSYS. I'll provide more concrete examples if my summary of the issue doesn't ring any bells. I hit something similar in the past, but it was fixed with commit a6754cd (rebase -i continue: don't skip commits that only change submodules, 2012-04-07) so I think you must be hitting a slightly different problem, although the tests added in that commit look like they do test the scenario you describe (specifically 'rebase -i continue with only submodule staged'). I am still running into this issue on git 2.3.5 on Windows. Logs below. One interesting thing to note in the git trace output is that it is specifying --ignore-submodules option to `git diff-files` during the rebase continue. Is this due to a configuration option? It seems like git should not be ignoring submodules when continuing a rebase (this should only affect direct calls to diff) |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ git status rebase in progress; onto bb05e7c You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'. (all conflicts fixed: run git rebase --continue) Changes to be committed: (use git reset HEAD file... to unstage) modified: Core Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: Core (new commits) Untracked files: (use git add file... to include in what will be committed) Tools/FontTool/ |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ GIT_TRACE=1 git rebase --continue 19:15:33.569945 git.c:557 trace: exec: 'git-rebase' '--continue' 19:15:33.569945 run-command.c:351 trace: run_command: 'git-rebase' '--continue' 19:15:33.775097 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue' 19:15:33.931190 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:34.007242 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository' 19:15:34.059280 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:34.148343 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.stat' 19:15:34.227399 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autostash' 19:15:34.280437 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autosquash' 19:15:34.335476 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD' 19:15:34.389515 git.c:348 trace: built-in: git 'update-index' '--ignore-submodules' '--refresh' 19:15:34.554631 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' 19:15:34.902879 git.c:557 trace: exec: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:34.902879 run-command.c:351 trace: run_command: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.113028 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.290155 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:35.387224 git.c:348 trace: built-in: git 'rev-parse' '--show-prefix'
Re: [PATCH] merge: simplify code flow
On Thu, Apr 23, 2015 at 01:01:44PM -0700, Junio C Hamano wrote: One of the first things cmd_merge() does is to see if the --abort option is given and run reset --merge and exit. When the control reaches this point, we know --abort was not given. Signed-off-by: Junio C Hamano gits...@pobox.com Yeah, this looks obviously correct. As an aside, the fact that the actual if (abort_current_merge) conditional ends with a goto to a cleanup label that is 500 lines away is...kind of gross. -Peff -- 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] merge: simplify code flow
Jeff King p...@peff.net writes: Yeah, this looks obviously correct. It is funny that this dates back to the very beginning of defaulting to the upstream, the code that if () block implements, introduced at 93e535a5 (merge: merge with the default upstream branch without argument, 2011-03-23). As an aside, the fact that the actual if (abort_current_merge) conditional ends with a goto to a cleanup label that is 500 lines away is...kind of gross. Reading git show 93e535a5 output, I see that it is a more recent breakage ;-) -- 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-completion.tcsh
Hi, I did notice the problem a while ago and had traced it back to the fact that the bash completion scripts no longer adds the trailing '/' at the end of directories. Tcsh needs that '/' to know not to add that annoying extra space. Bash 3 needed to put it that trailing '/' but bash 4 did not. Two years ago (!) changes were made in commit 3ffa4df4b2a26768938fc6bf1ed0640885b2bdf1 to allow bash 3 to work without the trailing '/'. That caused the problem in the tcsh script. The thing is that with master of today, I don't see the problem any more. I can't tell you when it started working again. What is interesting is that the reason it now works is that the git-completion.bash script no longer returns anything for the case you mention: git add ftab Instead, it seems to rely on file completion only. File completion is simulated by the tcsh script, so things work. I tried with both git add and git rm and didn't see the problem as you described it. You can troubleshoot the git-completion.tcsh script by running the generated final script directly. For example, to see the completions for a command line like: git rm ftab you can run: bash ~/.git-completion.tcsh.bash git 'git rm f' I plan on posting a patch to add debug printouts to make this process simpler. Marc On Thu, Apr 9, 2015 at 12:41 AM, Perry Rajnovic perry.rajno...@gmail.com wrote: Gábor, I updated git to include the macports install with bash completion. under bash it does not exhibit the problem as I described it. To be sure that the completion scripts installed via macports weren’t newer/different (the .bash completion file had a few minor diffs from what I had been using), i reinstalled the tcsh completion using those files, but the same behavior happened. So i’m seeing what you’re seeing, bash completion works fine, it’s likely to be something in the wrapper handling. (updated) environment Darwin 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 (OS X 10.10.3) Apple Terminal Version 2.5.3 (343.7) git 2.3.4 (+bash_completion, via MacPorts) tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options wide,nls,dl,al,kan,sm,rh,color,filec GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin14.0.0) Thanks! Perry On Apr 1, 2015, at 20:55, SZEDER Gábor sze...@ira.uka.de wrote: Quoting Perry Rajnovic perry.rajno...@gmail.com: When using the auto-completion included with git for tcsh, several commands do directly completion with an additional space appended to the end, which defeats the ability to complete to a deeper sub-directory. For example, if I have a git repository including the following: basedir/foo/bar/somefile.c (works as expected, git add) $ cd basedir $ git add ftab $ git add foo/ $ git add foo/btab $ git add foo/bar/ $ git add foo/bar/stab $ git add foo/bar/somefile.c (works not as expected, git rm) $ cd basedir $ git rm ftab $ git rm foo $ git rm foobackspace/btab $ git rm foo/bar there’s a trailing space after foo and bar in the above lines, which means it’s not possible to initiate completion or immediately start typing, i must back-space before continuing. I’m fairly certain i’ve seen this for other commands as well, but i’m not sure to what extent this occurs throughout the commands. Environment info: OS: Darwin 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 (OSX 10.10.2) Apple Terminal Version 2.5.1 (343.6) git version 2.3.2 (via MacPorts) tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options wide,nls,dl,al,kan,sm,rh,color,filec The tcsh completion script is just a wrapper, it relies on the bash completion script to do the heavy lifting and tunnels its output int tcsh's completion infrastructure. Could you try bash completion in your environment first to see, whether it's a bash completion issue that I can't reproduce or an issue with the tcsh wrapper? Cc'ing Marc, author of the tcsh wrapper. Gábor -- 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: Rebasing with submodule change causes red herring with --continue
On Thu, Apr 23, 2015 at 09:35:38PM +0100, John Keeping wrote: On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote: Am 23.04.2015 um 21:07 schrieb Robert Dailey: On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote: I have a branch that contains a commit with a single change: A submodule pointing to a new SHA1. When I rebase this branch onto the tip of its parent branch AND that parent branch had modified that same submodule, the rebase stops at the commit on my branch that modified the submodule and asks me if I want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that the submodule is not staged (normally it would be). I do: $ git add my-submodule Then I do: $ git rebase --continue At this point, it fails asking me if I forgot to stage changes and recommends doing --skip. This is normally what you would see if the staging area was completely empty, however it isn't, since I see the submodule is in there. Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0 on Windows through MSYS. I'll provide more concrete examples if my summary of the issue doesn't ring any bells. I hit something similar in the past, but it was fixed with commit a6754cd (rebase -i continue: don't skip commits that only change submodules, 2012-04-07) so I think you must be hitting a slightly different problem, although the tests added in that commit look like they do test the scenario you describe (specifically 'rebase -i continue with only submodule staged'). I am still running into this issue on git 2.3.5 on Windows. Logs below. One interesting thing to note in the git trace output is that it is specifying --ignore-submodules option to `git diff-files` during the rebase continue. Is this due to a configuration option? It seems like git should not be ignoring submodules when continuing a rebase (this should only affect direct calls to diff) |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ git status rebase in progress; onto bb05e7c You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'. (all conflicts fixed: run git rebase --continue) Changes to be committed: (use git reset HEAD file... to unstage) modified: Core Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: Core (new commits) Untracked files: (use git add file... to include in what will be committed) Tools/FontTool/ |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ GIT_TRACE=1 git rebase --continue 19:15:33.569945 git.c:557 trace: exec: 'git-rebase' '--continue' 19:15:33.569945 run-command.c:351 trace: run_command: 'git-rebase' '--continue' 19:15:33.775097 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue' 19:15:33.931190 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:34.007242 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository' 19:15:34.059280 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:34.148343 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.stat' 19:15:34.227399 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autostash' 19:15:34.280437 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autosquash' 19:15:34.335476 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD' 19:15:34.389515 git.c:348 trace: built-in: git 'update-index' '--ignore-submodules' '--refresh' 19:15:34.554631 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' 19:15:34.902879 git.c:557 trace: exec: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:34.902879 run-command.c:351 trace: run_command: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.113028 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--'
Odd rev-list behaviour
Seeing some weird results out of rev-list, see my demo repo: https://github.com/bmcorser/rev-list-fail I was after a one-liner to sort a bunch of commit hashes into topological (or date) order. The commits were made by a script that forges the commit time with --date in the hope of seeing stable results. Any ideas welcome, Ben -- 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: [PATCHv3] refs.c: enable large transactions
Stefan Beller sbel...@google.com writes: On Thu, Apr 23, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: + int save_errno = errno; + error(Couldn't reopen %s, lock-lk-filename.buf); No need to change this line, but I noticed that we might want to do something about the first one of the following two: I personally like to have each error(...) to have a unique string, such that when you run into trouble (most likely reported by a user), you can easily pinpoint where the exact error is. I was hoping that the grep patterns were strong enough hint, but let me be explicit. I was commenting on Could not being spelled as could. $ git grep -e '[]error(_*[A-Z]' | wc -l 146 $ git grep -e '[]error(_*[a-z]' | wc -l 390 -- 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 1/5] status: document the -v/--verbose option
Junio writes: Michael Haggerty mhag...@alum.mit.edu writes: Document `git status -v`, including its new doubled `-vv` form. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Will queue on mg/status-v-v series, which did add description for commit -v, but status -v did not have the description to begin with and we missed it. [...] +-v:: +--verbose:: + In addition to the names of files that have been changed, also + show the textual changes that are staged to be committed + (i.e., like the output of `git diff`). If `-v` is specified Should this be `git diff --cached`? + twice, then also show the changes in the working tree that + have not yet been staged (i.e., like the output of `git diff + --cached`). ...and should this just be `git diff`? --Pete (Sorry for not replying to the email; bit of a mess here in my setup.) -- 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] Completion: Cleanup tcsh script and add debug flag
Remove overriding of __git_index_file_list_filter
since that method is no longer used in git-completion.bash.
Overriding that method was needed before to get
git-completion.bash to append a '/' to the end
of directories; this does not seem to be needed anymore since
that script no longer provides completions of directories/files.
Also add -d/--debug flag support to help troubleshoot
the script.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
I thought this would help when for people that experience issues with
the script.
Thanks!
Marc
contrib/completion/git-completion.tcsh | 50 +---
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index 6104a42..fd0b906 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -1,6 +1,6 @@
# tcsh completion support for core Git.
#
-# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Copyright (C) 2012, 2015 Marc Khouzam marc.khou...@gmail.com
# Distributed under the GNU General Public License, version 2.0.
#
# When sourced, this script will generate a new script that uses
@@ -22,6 +22,25 @@
# add the following line to your .tcshrc/.cshrc:
#set autolist=ambiguous
# It will tell tcsh to list the possible completion choices.
+#
+# To debug this script one can use the -d flag by running the
+# generated final script directly. For example, to see the completions
+# generated when pressing tab for the command line:
+# git co
+# one should run:
+# bash ~/.git-completion.tcsh.bash -d git 'git co'
+# and will obtain:
+# =
+# git-completion.bash returned:
+# commit config
+# =
+# Completions including tcsh additions:
+# commit config
+# =
+# Final completions returned:
+# commit
+# config
+#
set __git_tcsh_completion_version = `\echo ${tcsh} | \sed 's/\./ /g'`
if ( ${__git_tcsh_completion_version[1]} 6 || \
@@ -48,20 +67,17 @@ cat EOF ${__git_tcsh_completion_script}
# Do not modify it directly. Instead, modify git-completion.tcsh
# and source it again.
+# Allow for debug printouts when running the script by hand
+if [ \$1 == -d ] || [ \$1 == --debug ]; then
+ __git_tcsh_debug=true
+ shift
+fi
+
source ${__git_tcsh_completion_original_script}
# Remove the colon as a completion separator because tcsh cannot handle it
COMP_WORDBREAKS=\${COMP_WORDBREAKS//:}
-# For file completion, tcsh needs the '/' to be appended to directories.
-# By default, the bash script does not do that.
-# We can achieve this by using the below compatibility
-# method of the git-completion.bash script.
-__git_index_file_list_filter ()
-{
- __git_index_file_list_filter_compat
-}
-
# Set COMP_WORDS in a way that can be handled by the bash script.
COMP_WORDS=(\$2)
@@ -83,6 +99,12 @@ fi
# Call _git() or _gitk() of the bash script, based on the first argument
_\${1}
+if [ \$__git_tcsh_debug == true ]; then
+ echo =
+ echo git-completion.bash returned:
+ echo \${COMPREPLY[@]}
+fi
+
IFS=\$'\n'
if [ \${#COMPREPLY[*]} -eq 0 ]; then
# No completions suggested. In this case, we want tcsh to perform
@@ -108,6 +130,14 @@ if [ \${#COMPREPLY[*]} -eq 0 ]; then
fi
fi
+if [ \$__git_tcsh_debug == true ]; then
+ echo =
+ echo Completions including tcsh additions:
+ echo \${COMPREPLY[@]}
+ echo =
+ echo Final completions returned:
+fi
+
# tcsh does not automatically remove duplicates, so we do it ourselves
echo \${COMPREPLY[*]} | sort | uniq
--
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] connect: improve check for plink to reduce false positives
Hi Brian, On 2015-04-23 02:06, brian m. carlson wrote: + tortoiseplink = tplink == ssh || + (tplink is_dir_sep(tplink[-1])); Maybe have a helper function here? Something like `basename_matches(const char *path, const char *basename, int ignore_case)`? That would be easier to read (I have to admit that I had to wrap my head around the logic to ensure that tplink[-1] is valid; It is, but it requires more brain cycles to verify than I would like). Also, I am really hesitant to just test the start of the basename; I would rather have an entire basename match so that something like PLinKoeln would not match. (And of course, for Windows I would want that hypothetical `basename_matches()` function to allow basenames to end in `.exe` automatically). In contrast to Torsten, I am not so concerned about `myplink` scripts: that only affects power users who can easily add the `-batch` into the script, where it actually belongs. 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
Re: [PATCH] RFC/Add documentation for version protocol 2
On Wed, Apr 22, 2015 at 4:30 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: +action = noop / ls-remote / fetch / push / fetch-shallow ... If we are going in this in-protocol message switches the service route, we should also support archive as one of the actions, no? Yes, I know you named the document pack-protocol and archive does not give you packs, but ls-remote does not transfer pack data, either. I'll add that. Also I need to incorporate shallow in one way or another. This level of detail may not matter at this point yet, but it is unclear to me why you have fetch-shallow as a separate thing (while not having push-shallow). Right, this should have been done via plain fetch action but the mode parameter may be set to shallow,narrow or what we want. Sorry for my shortcut in thinking there. The current infrastructure does already allow fetching into shallow repositories without needing a separate action that is different from fetch (aka upload-pack). I would not be surprised if it were I can deepn you if you want capability, but I do not understand why you are singling out shallow as something that needs such a special treatment. I should not have done that. I just got confused. -- 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: Proposal for git stash : add --staged option
Hi,
the
```sh
git add config_real.xml
git stash -k
git reset
```
is not very well suited because the -k option to keep the index.
However, the index will still be put inside the stash.
So what you propose is equivalent to:
```sh
git stash
git stash apply stash@\{0\}
git checkout --config_test.xml
```
`git stash --patch` can do the job (and I think that's what I'm going to
use from now), but it's still a bit cumbersome in some situations.
Best,
Edgar
Le 2015-04-22 11:25, Johannes Schindelin a écrit :
Hi Edgar,
On 2015-04-22 10:30, edgar.h...@netapsys.fr wrote:
When you have a lot of unstaged files, and would like to test what
happens if you undo some of the changes that you think are unecessary,
you would rather keep a copy of those changes somewhere.
For example
Changed but not updated:
M config_test.xml
M config_real.xml
I have changed both config_test.xml and config_real.xml, but I think
the changes made in config_test.xml are unnecessary. However, I would
still like to keep them somewhere in case it breaks something.
In this case for example, I would like to be able to stash only the
file config_test.xml
Eg:
git add config_test.xml
git stash --staged
So that after this, my git looks like this:
Changed but not updated:
M config_real.xml
and my stash contains only the changes introduced in config_test.xml
`git stash --keep-index` doesn't give the necessary control, because
it will still stash everything (and create unnecessary merge
complications if I change the files and apply the stash)
I often have the same problem. How about doing this:
```sh
git add config_real.xml
git stash -k
git reset
```
The difference between our approaches is that I keep thinking of the
staging area as the place to put changes I want to *keep*, not that I
want to forget for a moment.
Having said that, I am sympathetic to your cause, although I would
rather have `git stash [--patch] -- [file...]` that would be used
like `git add -p` except that the selected changes are *not* staged,
but stashed instead.
Ciao,
Johannes
--
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 V3 0/2] git-p4: improve client path detection when branches are used
On April 22, 2015 9:47:42 PM GMT+01:00, Luke Diamand l...@diamand.org wrote: On 22/04/15 18:11, Junio C Hamano wrote: Vitor Antunes vitor@gmail.com writes: The updates introduced in the third revision of these two patches consist only on updates to the commit messages to better clarify what they implement. Vitor Antunes (2): t9801: check git-p4's branch detection with client spec enabled git-p4: improve client path detection when branches are used git-p4.py| 13 -- t/t9801-git-p4-branch.sh | 106 ++ 2 files changed, 115 insertions(+), 4 deletions(-) Thanks; will re-queue. Luke, could you comment? First off: kudos to Vitor for daring to enter this particular dragon's den. The combination of branch-detection and use-client-spec isn't so bad, but throwing in the handling of excluding bits of the tree via the P4 client spec (like, who would even do that?) makes it into a real mind twister! I've held off commenting as I don't feel I know the branch detection code as well as I would like. The change though seems a lot more robust now that the search is anchored. Having a test case is always good! However, playing around with this (incredibly complex and obscure) scenario, I'm not yet sure about it. I created a depot that had //depot/main and //depot/branch, and a branch mapping between the two. I cloned that in git using --use-client-spec and --branch-detect, and all was well. I then modified my client spec to exclude //depot/main/excluded, and then started adding files in git to the 'excluded' directory. When I submit them, I get: $ echo hello excluded/f1.c $ echo hello f2.c $ git add excluded/f1.c f2.c $ git commit -m 'Partially excluded' $ git-p4.py submit DEBUG: self.useClientSpec = True Perforce checkout for depot path //depot/main/ located at /home/lgd/p4-hacking/cli/main/ Synchronizing p4 checkout... ... - file(s) up-to-date. Applying 51f187b Excluded added from git excluded/c - file(s) not in client view. excluded/c - file(s) not opened on this client. Could not determine file type for excluded/c (result: '') When I reverted this change, it failed differently, and appeared to be extremely confused in the way that I think Vitor originally describes, getting hopelessly baffled by the client spec layout. It's entirely possibly I've messed up my manual testing though. I need to go and have a very strong cup of tea before I can look at this again. Thanks! Luke That was a good combination to test. In fact, I am using such a client spec at my work place to exclude the import from Perforce of a folder that only contains binary files, but I never even considered to add files to that folder from git! Although I do agree that git-p4 should be able to exit sanely in this scenario, it is also my opinion that this is a different scenario from the one I'm tryig to fix in this set of patches and that it should not be enough to stop this merge. I will take this scenario into consideration, create a new test case and finally fix git-p4 to exit sanely in such a scenario. This new test will also be able to show that folder exclusion is working perfectly during import, which is important to guarantee that that functionality is not broken in future. BTW, no kudos is necessary because I've already walked this path before :) I've introduced branchList and improved how git-p4 looks for the original changelist used to create the new branch in Perforce side. If I remember correctly, many of the test cases in 9801 file were also created by me before Pete started splitting the git-p4 test file into topics. -- 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 V3 0/2] git-p4: improve client path detection when branches are used
On 23 April 2015 at 09:37, Vitor Antunes vitor@gmail.com wrote: That was a good combination to test. In fact, I am using such a client spec at my work place to exclude the import from Perforce of a folder that only contains binary files, but I never even considered to add files to that folder from git! Although I do agree that git-p4 should be able to exit sanely in this scenario, it is also my opinion that this is a different scenario from the one I'm tryig to fix in this set of patches and that it should not be enough to stop this merge. I will take this scenario into consideration, create a new test case and finally fix git-p4 to exit sanely in such a scenario. This new test will also be able to show that folder exclusion is working perfectly during import, which is important to guarantee that that functionality is not broken in future. BTW, no kudos is necessary because I've already walked this path before :) I've introduced branchList and improved how git-p4 looks for the original changelist used to create the new branch in Perforce side. If I remember correctly, many of the test cases in 9801 file were also created by me before Pete started splitting the git-p4 test file into topics. Yes, I think you're right that this is a different, albeit related problem. It was broken before, and it's still broken. So I'm happy with this change - Ack. Teaching git-p4 to handle this corner case would be a good thing to do as a separate followup if you're OK to do that. Thanks! 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
[PATCH 1/5] status: document the -v/--verbose option
Document `git status -v`, including its new doubled `-vv` form. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/git-status.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index b3319f7..9ec5897 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -41,6 +41,15 @@ OPTIONS --long:: Give the output in the long-format. This is the default. +-v:: +--verbose:: + In addition to the names of files that have been changed, also + show the textual changes that are staged to be committed + (i.e., like the output of `git diff`). If `-v` is specified + twice, then also show the changes in the working tree that + have not yet been staged (i.e., like the output of `git diff + --cached`). + -u[mode]:: --untracked-files[=mode]:: Show untracked files. -- 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 0/5] Tweak the 2.4.0 release notes and related docs
Patches 1 and 2 add some manpage documentation for features mentioned in the release notes that were not adequately documented. Patches 3 and 4 correct a couple of concrete problems in the release notes. Patch 5 is a smörgåsbord of suggested stylistic changes to the release notes. Feel free to pick and choose the ones that you think are improvements. Michael Haggerty (5): status: document the -v/--verbose option git tag: mention versionsort.prereleaseSuffix in manpage RelNotes: correct name of versionsort.prereleaseSuffix RelNotes: refer to the rebase -i todo list, not insn sheet RelNotes: wordsmithing Documentation/RelNotes/2.4.0.txt | 338 --- Documentation/git-status.txt | 9 ++ Documentation/git-tag.txt| 11 +- 3 files changed, 189 insertions(+), 169 deletions(-) -- 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 2/5] git tag: mention versionsort.prereleaseSuffix in manpage
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/git-tag.txt | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index bfba4ef..f5b267e 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -98,10 +98,13 @@ OPTIONS --sort=type:: Sort in a specific order. Supported type is refname (lexicographic order), version:refname or v:refname (tag - names are treated as versions). Prepend - to reverse sort - order. When this option is not given, the sort order defaults to the - value configured for the 'tag.sort' variable if it exists, or - lexicographic order otherwise. See linkgit:git-config[1]. + names are treated as versions). The version:refname sort + order can also be affected by the + versionsort.prereleaseSuffix configuration variable. Prepend + - to reverse sort order. When this option is not given, the + sort order defaults to the value configured for the 'tag.sort' + variable if it exists, or lexicographic order otherwise. See + linkgit:git-config[1]. --column[=options]:: --no-column:: -- 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 3/5] RelNotes: correct name of versionsort.prereleaseSuffix
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/RelNotes/2.4.0.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index a0ee37d..c02de8d 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt @@ -109,8 +109,8 @@ UI, Workflows Features cd '' which silently behaves as a no-op. (merge 6a536e2 kn/git-cd-to-empty later to maint). - * The versionsort.prerelease configuration variable can be used to - specify that v1.0-pre1 comes before v1.0. + * The versionsort.prereleaseSuffix configuration variable can be used + to specify that v1.0-pre1 comes before v1.0. * A new push.followTags configuration turns the --follow-tags option on by default for the git push command. -- 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 5/5] RelNotes: wordsmithing
Make many textual tweaks to the 2.4.0 release notes. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/RelNotes/2.4.0.txt | 336 --- 1 file changed, 172 insertions(+), 164 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index 7b23ca3..cde64be 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt @@ -6,19 +6,19 @@ Backward compatibility warning(s) This release has a few changes in the user-visible output from Porcelain commands. These are not meant to be parsed by scripts, but -the users still may want to be aware of the changes: +users still may want to be aware of the changes: - * Output from git log --decorate (and %d format specifier used in - the userformat --format=string parameter git log family of - command takes) used to list HEAD just like other tips of branch - names, separated with a comma in between. E.g. + * The output from git log --decorate (and, more generally, the %d + format specifier used in the --format=string parameter to the + git log family of commands) has changed. It used to list HEAD + just like other branches; e.g., $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master) ... - This release updates the output slightly when HEAD refers to the tip - of a branch whose name is also shown in the output. The above is + This release changes the output slightly when HEAD refers to a + branch whose name is also shown in the output. The above is now shown as: $ git log --decorate -1 master @@ -26,15 +26,15 @@ the users still may want to be aware of the changes: ... * The phrasing git branch uses to describe a detached HEAD has been - updated to match that of git status: + updated to agree with the phrasing used by git status: -- When the HEAD is at the same commit as it was originally +- When HEAD is at the same commit as when it was originally detached, they now both show detached at commit object name. -- When the HEAD has moved since it was originally detached, - they now both show detached from commit object name. +- When HEAD has moved since it was originally detached, they now + both show detached from commit object name. -Earlier git branch always used from + Previously, git branch always used from. Updates since v2.3 @@ -46,8 +46,9 @@ Ports platforms with smaller SSIZE_MAX, leading to read(2)/write(2) failures. - * We did not check the curl library version before using - CURLOPT_PROXYAUTH feature that may not exist. + * We did not check the curl library version before using the + CURLOPT_PROXYAUTH feature, which did not exist in older versions of + the library. * We now detect number of CPUs on older BSD-derived systems. @@ -66,99 +67,105 @@ UI, Workflows Features * git log --invert-grep --grep=WIP will show only commits that do not have the string WIP in their messages. - * git push has been taught a --atomic option that makes push to - update more than one ref an all-or-none affair. + * git push has been taught an --atomic option that makes a push + that updates more than one ref an all-or-none affair. - * Extending the push to deploy added in 2.3, the behaviour of git - push when updating the branch that is checked out can now be - tweaked by push-to-checkout hook. + * Extending the push to deploy feature that was added in 2.3, the + behaviour of git push when updating the branch that is checked + out can now be tweaked by a push-to-checkout hook. - * Using environment variable LANGUAGE and friends on the client side, - HTTP-based transports now send Accept-Language when making requests. + * HTTP-based transports now send Accept-Language when making + requests. The languages to accept are inferred from environment + variables on the client side (LANGUAGE, etc). * git send-email used to accept a mistaken y (or yes) as an - answer to What encoding do you want to use [UTF-8]? without - questioning. Now it asks for confirmation when the answer looks - too short to be a valid encoding name. + answer to What encoding do you want to use [UTF-8]? without + questioning. Now it asks for confirmation when the answer looks too + short to be a valid encoding name. * When git apply --whitespace=fix fixed whitespace errors in the common context lines, the command reports that it did so. - * git status now allows the -v to be given twice to show the - differences that are left in the working tree not to be committed. + * git status now allows the -v option to be given twice, in which + case it also shows the differences in the working tree that are not + staged to be committed. - * git cherry-pick used to clean-up the log message even when it is - merely replaying an existing commit. It now replays the
[PATCH 4/5] RelNotes: refer to the rebase -i todo list, not insn sheet
Todo list is the name that is used in the user-facing documentation. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/RelNotes/2.4.0.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index c02de8d..7b23ca3 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt @@ -261,7 +261,7 @@ notes for details). user could have made was to choose nothing. (merge a9c4641 ak/add-i-empty-candidates later to maint). - * The insn sheet git rebase -i creates did not fully honor + * The todo list git rebase -i creates did not fully honor core.abbrev settings. (merge edb72d5 ks/rebase-i-abbrev later to maint). @@ -402,7 +402,7 @@ notes for details). (merge 77fdb8a nd/grep-exclude-standard-help-fix later to maint). * git rebase -i recently started to include the number of - commits in the insn sheet to be processed, but on a platform + commits in the todo list to be processed, but on a platform that prepends leading whitespaces to wc -l output, the numbers are shown with extra whitespaces that aren't necessary. (merge 2185d3b es/rebase-i-count-todo later to maint). -- 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 5/5] RelNotes: wordsmithing
On 04/23/2015 02:27 PM, Michael Haggerty wrote: Make many textual tweaks to the 2.4.0 release notes. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/RelNotes/2.4.0.txt | 336 --- 1 file changed, 172 insertions(+), 164 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index 7b23ca3..cde64be 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt [...] Oh, I just noticed that many of the same blurbs appear in the release notes for the maintenance versions. Once there is agreement on how many of the changes to accept, the analogous changes should probably be made in those other files. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 Question
Hi Luke, I found a silly mistake I was making in the command I've been using. The folder under the depot should have been capitalized, but it wasn't. Also, I expected that if there was a problem with the command, it would fail with some message instead of creating an empty local git repo. Now I'll move forward with setting up an automated and periodic sync of P4 to Git in preparation for the migration. Thanks Luke, your suggestions prompted me to look in the right location for the problem. On Tue, Apr 21, 2015 at 10:53 AM, Luke Diamand l...@diamand.org wrote: Can you post up the output from 'git p4 clone', and also see what the output from doing this is: $ p4 print //depot/some/branch/missingfile.c On 21 April 2015 at 14:33, FusionX86 fusion...@gmail.com wrote: Hi Luke, Using -v was a good suggestion. Unfortunately I still don't see what the problem is. I'm starting to think that maybe I should just create the client views I need and setup a cron job that p4 syncs and then git commits/pushes. The --preserve-user option is for submitting back to Perforce correct? I'm hoping to get away with a one-way sync from Perforce to Git...and then eventually just cut over to Git. I also looked at git fusion, but unfortunately the version of Perforce we're running (2012.1) doesn't meet the requirements for fusion. I wish it did. Good point on developer mindset. I think we definitely have some training and habit changing in the future. Thanks for the suggestions and pointers, it's much appreciated. On Mon, Apr 20, 2015 at 1:26 PM, Luke Diamand l...@diamand.org wrote: On 20/04/15 17:41, FusionX86 wrote: Hello, Hopefully this is an appropriate place to ask questions about git-p4. I started at a company that wants to migrate from Perforce to Git. I'm new to Perforce and have been trying to learn just enough about it to get through this migration. Anyway, I've been playing with git-p4 and have one question/problem to discuss. After setting up the p4 cli client I can 'p4 sync' some //depot/main/app1 which pulls down the files I would expect from the Perforce server. If I use 'git p4 clone //depot/main/app1', I get: Doing initial import of //depot/main/app1/ from revision #head into refs/remotes/p4/master But I don't get any files from that depot/folder pulled down. I can git p4 clone other depot/folders though and get some files. I suspect that I'm just not understanding how the git-p4 module works. You could try doing the clone with '-v' to get a bit more information. Basically, I'm hoping to setup a live sync of Perforce to Git of certain depots in preparation for the migration. Also, if anyone has pointers or guides for this type of migration, any help is appreciated. I've done something similar in the past. You'll want to enable the --preserve-user option, for which you will need admin rights. If it's a one-way mirror (p4-to-git) then just run git-p4 periodically (if you use cron, then try to avoid having two or more instances running at the same time). If you want it to be two-way then it gets a bit more complicated. You might also want to consider using git fusion, which is Perforce's take on this problem. I've not used it myself. From past experience though I would say the biggest problem is getting developers to switch from the P4 mindset (centralized; code review hard to do or ignored) to the git mindset (decentralized; code review actively supported by the version control system). -- 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 -- 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: [BUG] having 'plink' anywhere in the GIT_SSH environment variables sets putty = true
Torsten, The relevant part of the path in GIT_SSH was ‘/uplink_deploy/‘. I did begin to use GIT_SSH_COMMAND as a workaround, but regardless this still feels like an overly broad way to determine the value of the putty flag. I was kind of surprised to find it being inferred from the value of GIT_SSH instead of being explicitly set by some additional variable. GIT_USE_PUTTY or some such, though I can understand there may be some reluctance to put the onus of that on the end user. Part of the issue stemmed from not being able to find any documentation on this. After I discovered what was happening I found plenty of instructions that indicated to enable putty support set GIT_SSH to /path/to/plink.exe, but I didn’t find it stated anywhere that if ‘plink’ was found in GIT_SSH, then git will add the -batch option to the command args. In other words, I was able to find instructions on what to do if we had been using putty, but not instructions on unexpected behavior if using GIT_SHH while NOT using putty. On Apr 23, 2015, at 12:08 AM, Torsten Bögershausen tbo...@web.de wrote: On 04/22/2015 09:12 PM, Patrick Sharp wrote: Johannes, You’re correct, looking back over it, I was pretty vague. In truth, we are not using Windows OR putty at all. Running git on an Ubuntu system, but we are setting the GIT_SSH environment variable to point to a shell script to use. Upon attempting to run git ls-remote, the system was spitting out getaddrinfo errors for ‘atch’ . Setting GIT_TRACE=2 showed that -batch was being added to the git command. This was seen on several different servers with git versions 1.8.5.2, 1.9.1 and 2.3.5 After a bit we realized that it was the string ‘uplink’ in the GIT_SSH variable that was linked to the extra -batch flag. Finally, after searching the git source, we narrowed it down to the ‘plink’ portion of the string. https://github.com/git/git/blob/7c597ef345aed345576de616c51f27e6f4b342b3/connect.c#L747-L7 Brian, I got your patch, but can't see it in the list yet 1/2 looks good, thanks. (And add msygit) My feeling is that patch 2/2 may break things for an unknown amount of users which e.g. use myplink. Patrick, did you ever tell us, what you put into $GIT_SSH ? Can your use case be covered by using $GIT_SSH_COMMAND ? -- 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: Wrong gitignore precedence?
On Wed, 22 Apr 2015 11:59:04 -0700 Junio C Hamano gits...@pobox.com wrote: Swapping the order in the code this late in the game after 8 years may affect people who have come to rely on the current behaviour and never read the doc, which is somewhat worrying, though. I agree. I think the change should be well announced before the fix is applied, like when the implicit value of push.default was changed. Thanks. -- 遠藤 陽平 (Yohei Endo) yoh...@gmail.com -- 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] connect: improve check for plink to reduce false positives
On Thu, Apr 23, 2015 at 11:53:04AM -0400, Jeff King wrote: On Thu, Apr 23, 2015 at 08:50:17AM +0200, Johannes Schindelin wrote: + tortoiseplink = tplink == ssh || + (tplink is_dir_sep(tplink[-1])); Maybe have a helper function here? Something like `basename_matches(const char *path, const char *basename, int ignore_case)`? That would be easier to read (I have to admit that I had to wrap my head around the logic to ensure that tplink[-1] is valid; It is, but it requires more brain cycles to verify than I would like). Yeah, I had a similar thought when reading the patch. I was questioning whether a comment would have been helpful. Apparently the answer was yes. If I were writing from scratch, I would probably keep things as tight as possible, like: const char *base = basename(ssh); plink = !strcasecmp(base, plink) || !strcasecmp(base, plink.exe); tplink = !strcasecmp(base, tortoiseplink) || !strcasecmp(base, tortoiseplink.exe)); but maybe that is too tight at this point in time; we don't really know what's out there and working (or maybe _we_ do, but _I_ do not :) ). At any rate, brian's patch only looks for a dir-separator anywhere, not the actual basename. So: /path/to/plink/ssh would match, and I'm not sure if that's a good thing or not. This is true. In hindsight, I think it's probably better to be a bit stricter, so I'll reroll to use the stricter format. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCHv3] refs.c: enable large transactions
On Thu, Apr 23, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
diff --git a/refs.c b/refs.c
index 4f495bd..7ce7b97 100644
--- a/refs.c
+++ b/refs.c
@@ -3041,6 +3041,13 @@ static int write_ref_sha1(struct ref_lock *lock,
errno = EINVAL;
return -1;
}
+ if (lock-lk-fd == -1 reopen_lock_file(lock-lk) == -1) {
Granted, we explicitly assign -1 to lk-fd when we know it is
closed, and the return value from reopen_lock_file() can come only
from the return value from open(2), which is defined to return -1
(i.e. not just any negative value) upon failure, but still, isn't it
customary to check with 0 rather than == -1 for errors?
0 would be better here indeed.
+ int save_errno = errno;
+ error(Couldn't reopen %s, lock-lk-filename.buf);
No need to change this line, but I noticed that we might want to do
something about the first one of the following two:
I personally like to have each error(...) to have a unique string, such
that when you run into trouble (most likely reported by a user),
you can easily pinpoint where the exact error is.
Maybe we could think about overriding error to actually report
version, filename, linenumber, actual error message
$ git grep -e '[]error(_*[A-Z]' | wc -l
146
$ git grep -e '[]error(_*[a-z]' | wc -l
390
+ unlock_ref(lock);
+ errno = save_errno;
+ return -1;
+ }
Is this the only place in the entire codebase where a lockfile,
which may have been closed to save number of open file descriptors,
needs to be reopened? If I understand correctly, lockfile API is
not for sole use of refs (don't the index and the pack codepaths use
it, too?), so it may give us a better abstraction to have a helper
function in lockfile.[ch] that takes a lock object, i.e.
int make_lock_fd_valid(struct lock_file *lk)
{
if (lk-fd 0 reopen_lock_file(lk) 0) {
... error ...
return -1;
}
return 0;
}
and to call it at this point, i.e.
if (make_lock_fd_valid(lock-lk) 0)
return -1;
perhaps?
This is what I was originally looking for, thanks for the design guidance!
@@ -3733,6 +3741,20 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
return 0;
}
+ /*
+ * We need to open many files in a large transaction, so come up with
+ * a reasonable maximum. We still keep some spares for stdin/out and
+ * other open files. Experiments determined we need more fds when
+ * running inside our test suite than directly in the shell. It's
+ * unclear where these fds come from. 25 should be a reasonable large
+ * number though.
+ */
+ remaining_fds = get_max_fd_limit();
+ if (remaining_fds 25)
+ remaining_fds -= 25;
+ else
+ remaining_fds = 0;
Is the value of pack_open_fds visible from here? I am wondering if
we might want scratch fds Git can use for its own use accounting
so that the two subsystems can collectively say it is still safe
to use one more fd and leave 25 for other people. With the code
structure proposed here, the pack reader can grab all but 25 fds,
which would leave the rest of Git including this code only 25,
and the value in remaining_fds would become totally meaningless.
It certainly can wait to worry about that and we do not have to do
anything about it in this patch, but it may still be a good idea to
leave NEEDSWORK: comment here (and point at open_packed_git_1() in
sha1_file.c in the comment).
I do not think the other side needs to know about the fd consumption
in this function, as what is opened in here will be closed before
this function returns.
@@ -3762,6 +3784,12 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
update-refname);
goto cleanup;
}
+ if (!(flags REF_HAVE_NEW) ||
+ is_null_sha1(update-new_sha1) ||
+ remaining_fds == 0)
+ close_lock_file(update-lock-lk);
+ else
+ remaining_fds--;
}
--
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] blame: add blame.showemail config option
Thanks for the submission. See comments below...
On Thu, Apr 23, 2015 at 10:13 PM, Quentin Neill quentin.ne...@gmail.com wrote:
From: Quentin Neill quentin.ne...@gmail.com
You should drop this line. git-am will pluck your name and email
automatically from the email From: header.
If you prefer seeing emails in your git blame output, rather
than sprinkling '-e' options everywhere you can just set
the new config blame.showemail to true.
Drop the indentation from the commit message.
It's not clear what everywhere means in the above. It might be
sufficient to rephrase more simply as:
Complement existing --show-email option with fallback
configuration variable.
or something.
---
Missing Signed-off-by:. See Documentation/SubmittingPatches.
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index b299b59..9326115 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -1,6 +1,11 @@
-b::
Show blank SHA-1 for boundary commits. This can also
be controlled via the `blame.blankboundary` config option.
+-e::
+--show-email::
Insert a blank line before the -e line to separate it from the -b paragraph.
+ Show the author email instead of author name (Default: off).
+ This can also be controlled via the `blame.showemail` config
+ option.
Despite being case-insensitive and despite existing inconsistencies,
in documentation, it is customary to use camelCase for configuration
options, so blame.showEmail.
Also blame.showEmail probably ought to be documented in
Documentation/config.txt (although there is some inconsistency here in
that documentation for the other blame-specific variables is missing
from config.txt, so perhaps that's something that could be addressed
separately).
--root::
Do not treat root commits as boundaries. This can also be
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 9f23a86..50a9030 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -73,10 +73,6 @@ include::blame-options.txt[]
-s::
Suppress the author name and timestamp from the output.
--e::
---show-email::
- Show the author email instead of author name (Default: off).
-
It's not clear why you relocated documentation of --show-email from
git-blame.txt to blame-options.txt, and the commit message does not
explain the move. If there's a good reason for the relocation, the
justification should be spelled out so that people reviewing the patch
or looking through history later on will not have to guess about it.
It might also make sense to do the relocation as a separate
preparatory patch of a 2-patch series, in which the patch adding
blame.showemail is the second of the two.
-w::
Ignore whitespace when comparing the parent's version and
the child's to find where the lines came from.
diff --git a/builtin/blame.c b/builtin/blame.c
index 06484c2..70bfd0a 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -44,6 +44,7 @@ static int max_score_digits;
static int show_root;
static int reverse;
static int blank_boundary;
+static int show_email;
static int incremental;
static int xdl_opts;
static int abbrev = -1;
@@ -1926,7 +1927,7 @@ static void emit_other(struct scoreboard *sb, struct
blame_entry *ent, int opt)
printf(%.*s, length, hex);
if (opt OUTPUT_ANNOTATE_COMPAT) {
const char *name;
- if (opt OUTPUT_SHOW_EMAIL)
+ if ((opt OUTPUT_SHOW_EMAIL) || show_email)
The desired behavior is for a configuration setting to provide a
fallback, and for a command-line option to override the fallback. So,
for instance, if blame.showemail is true, then --no-show-email
should countermand that. Unfortunately, the way this patch is
implemented, it's impossible to override the setting from the
command-line since show_email==true will always win (when
blame.showemail is true).
More below.
name = ci.author_mail.buf;
else
name = ci.author.buf;
@@ -2185,6 +2186,10 @@ static int git_blame_config(const char *var, const
char *value, void *cb)
blank_boundary = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, blame.showemail)) {
+ show_email = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp(var, blame.date)) {
if (!value)
return config_error_nonbool(var);
You'll also want to add tests for the new blame.showemail
configuration. There's already one test in t8002-blame.sh which checks
that --show-email works, but you will want tests to ensure that you
get the expected results for all combinations of blame.showemail and
--show-email
Re: Odd rev-list behaviour
On Fri, Apr 24, 2015 at 12:48:43AM +0100, B M Corser wrote: Seeing some weird results out of rev-list, see my demo repo: https://github.com/bmcorser/rev-list-fail That repo has a whole bunch of commits with identical committer timestamps. The default order that git displays those in is going to depend on the order you provide them in. I was after a one-liner to sort a bunch of commit hashes into topological (or date) order. The commits were made by a script that forges the commit time with --date in the hope of seeing stable results. Using --date will just set the author date. You probably want to set GIT_COMMITTER_DATE in the environment if you are scripting imported commits from somewhere else (or better yet, consider using git-fast-import if you have a lot of commits). Even with identical commit timestamps, we should be able to show the commits in topo-order. Your README.md shows you trying: git rev-list --no-walk $(git log --format=%H | shuf) That is missing any mention of --topo-order, of course. But even adding that in, it does not seem to work, which is perhaps what you are getting at. I am not sure whether --no-walk plays well with other sorting options, and that may be the problem. Is there a reason that just: git rev-list --topo-order HEAD does not serve your purpose? It's hard to tell what you're trying to achieve from this obviously toy repository. In the meantime, you can also pipe the output of rev-list into your own sort routine, using --format to get whatever information you need (you can topo-sort with the information from --parents). -Peff -- 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 1/5] status: document the -v/--verbose option
Pete Harlan pchpubli...@gmail.com writes: Junio writes: Michael Haggerty mhag...@alum.mit.edu writes: Document `git status -v`, including its new doubled `-vv` form. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Will queue on mg/status-v-v series, which did add description for commit -v, but status -v did not have the description to begin with and we missed it. [...] +-v:: +--verbose:: + In addition to the names of files that have been changed, also + show the textual changes that are staged to be committed + (i.e., like the output of `git diff`). If `-v` is specified Should this be `git diff --cached`? + twice, then also show the changes in the working tree that + have not yet been staged (i.e., like the output of `git diff + --cached`). ...and should this just be `git diff`? --Pete (Sorry for not replying to the email; bit of a mess here in my setup.) Duh! I see git commit documentation does not have these extra like the output of... bits. Perhaps we can do without it for the sake of both brevity and risk avoidance? Will push out with --cached bit swapped for tonight on 'pu'. -- 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] blame: add blame.showemail config option
From: Quentin Neill quentin.ne...@gmail.com
If you prefer seeing emails in your git blame output, rather
than sprinkling '-e' options everywhere you can just set
the new config blame.showemail to true.
---
Documentation/blame-options.txt | 5 +
Documentation/git-blame.txt | 4
builtin/blame.c | 11 ---
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index b299b59..9326115 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -1,6 +1,11 @@
-b::
Show blank SHA-1 for boundary commits. This can also
be controlled via the `blame.blankboundary` config option.
+-e::
+--show-email::
+ Show the author email instead of author name (Default: off).
+ This can also be controlled via the `blame.showemail` config
+ option.
--root::
Do not treat root commits as boundaries. This can also be
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 9f23a86..50a9030 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -73,10 +73,6 @@ include::blame-options.txt[]
-s::
Suppress the author name and timestamp from the output.
--e::
---show-email::
- Show the author email instead of author name (Default: off).
-
-w::
Ignore whitespace when comparing the parent's version and
the child's to find where the lines came from.
diff --git a/builtin/blame.c b/builtin/blame.c
index 06484c2..70bfd0a 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -44,6 +44,7 @@ static int max_score_digits;
static int show_root;
static int reverse;
static int blank_boundary;
+static int show_email;
static int incremental;
static int xdl_opts;
static int abbrev = -1;
@@ -1926,7 +1927,7 @@ static void emit_other(struct scoreboard *sb, struct
blame_entry *ent, int opt)
printf(%.*s, length, hex);
if (opt OUTPUT_ANNOTATE_COMPAT) {
const char *name;
- if (opt OUTPUT_SHOW_EMAIL)
+ if ((opt OUTPUT_SHOW_EMAIL) || show_email)
name = ci.author_mail.buf;
else
name = ci.author.buf;
@@ -1949,7 +1950,7 @@ static void emit_other(struct scoreboard *sb, struct
blame_entry *ent, int opt)
if (!(opt OUTPUT_NO_AUTHOR)) {
const char *name;
int pad;
- if (opt OUTPUT_SHOW_EMAIL)
+ if ((opt OUTPUT_SHOW_EMAIL) || show_email)
name = ci.author_mail.buf;
else
name = ci.author.buf;
@@ -2098,7 +2099,7 @@ static void find_alignment(struct scoreboard *sb, int
*option)
struct commit_info ci;
suspect-commit-object.flags |= METAINFO_SHOWN;
get_commit_info(suspect-commit, ci, 1);
- if (*option OUTPUT_SHOW_EMAIL)
+ if ((*option OUTPUT_SHOW_EMAIL) || show_email)
num = utf8_strwidth(ci.author_mail.buf);
else
num = utf8_strwidth(ci.author.buf);
@@ -2185,6 +2186,10 @@ static int git_blame_config(const char *var, const char
*value, void *cb)
blank_boundary = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, blame.showemail)) {
+ show_email = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp(var, blame.date)) {
if (!value)
return config_error_nonbool(var);
--
1.9.1
--
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
