* [PATCH v3 5/5] stash: teach 'push' (and 'create') to honor pathspec
From: Thomas Gummerer @ 2017-02-05 20:26 UTC (permalink / raw)
To: git
Cc: Stephan Beyer, Junio C Hamano, Marc Strapetz, Jeff King,
Johannes Schindelin, Øyvind A . Holm, Jakub Narębski,
Thomas Gummerer
In-Reply-To: <20170205202642.14216-1-t.gummerer@gmail.com>
While working on a repository, it's often helpful to stash the changes
of a single or multiple files, and leave others alone. Unfortunately
git currently offers no such option. git stash -p can be used to work
around this, but it's often impractical when there are a lot of changes
over multiple files.
Allow 'git stash push' to take pathspec to specify which paths to stash.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
Documentation/git-stash.txt | 11 ++++++++++
git-stash.sh | 30 ++++++++++++++++++++-------
t/t3903-stash.sh | 42 ++++++++++++++++++++++++++++++++++++++
t/t3905-stash-include-untracked.sh | 26 +++++++++++++++++++++++
4 files changed, 102 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index a138ed6a24..be55e456fa 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -15,9 +15,13 @@ SYNOPSIS
'git stash' branch <branchname> [<stash>]
'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [<message>]]
+'git stash' push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] [-m|--message <message>]]
+ [--] [<pathspec>...]
'git stash' clear
'git stash' create [<message>]
'git stash' create [-m <message>] [-u|--include-untracked <untracked|all>]
+ [-- <paths>...]
'git stash' store [-m|--message <message>] [-q|--quiet] <commit>
DESCRIPTION
@@ -47,6 +51,7 @@ OPTIONS
-------
save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
+push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--] [<pathspec>...]::
Save your local modifications to a new 'stash' and roll them
back to HEAD (in the working tree and in the index).
@@ -56,6 +61,12 @@ save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q
only <message> does not trigger this action to prevent a misspelled
subcommand from making an unwanted stash.
+
+When pathspec is given to 'git stash push', the new stash records the
+modified states only for the files that match the pathspec. The index
+entries and working tree files are then rolled back to the state in
+HEAD only for these files, too, leaving files that do not match the
+pathspec intact.
++
If the `--keep-index` option is used, all changes already added to the
index are left intact.
+
diff --git a/git-stash.sh b/git-stash.sh
index 33b2d0384c..46367d40aa 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -41,7 +41,7 @@ no_changes () {
untracked_files () {
excl_opt=--exclude-standard
test "$untracked" = "all" && excl_opt=
- git ls-files -o -z $excl_opt
+ git ls-files -o -z $excl_opt -- "$@"
}
clear_stash () {
@@ -72,6 +72,11 @@ create_stash () {
untracked="$1"
new_style=t
;;
+ --)
+ shift
+ new_style=t
+ break
+ ;;
*)
if test -n "$new_style"
then
@@ -99,6 +104,10 @@ create_stash () {
if test -z "$new_style"
then
stash_msg="$*"
+ while test $# != 0
+ do
+ shift
+ done
fi
git update-index -q --refresh
@@ -134,7 +143,7 @@ create_stash () {
# Untracked files are stored by themselves in a parentless commit, for
# ease of unpacking later.
u_commit=$(
- untracked_files | (
+ untracked_files "$@" | (
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
rm -f "$TMPindex" &&
@@ -157,7 +166,7 @@ create_stash () {
git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
- git diff-index --name-only -z HEAD -- >"$TMP-stagenames" &&
+ git diff-index --name-only -z HEAD -- "$@" >"$TMP-stagenames" &&
git update-index -z --add --remove --stdin <"$TMP-stagenames" &&
git write-tree &&
rm -f "$TMPindex"
@@ -171,7 +180,7 @@ create_stash () {
# find out what the user wants
GIT_INDEX_FILE="$TMP-index" \
- git add--interactive --patch=stash -- &&
+ git add--interactive --patch=stash -- "$@" &&
# state of the working tree
w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
@@ -307,18 +316,25 @@ push_stash () {
git reflog exists $ref_stash ||
clear_stash || die "$(gettext "Cannot initialize stash")"
- create_stash -m "$stash_msg" -u "$untracked"
+ create_stash -m "$stash_msg" -u "$untracked" -- "$@"
store_stash -m "$stash_msg" -q $w_commit ||
die "$(gettext "Cannot save the current status")"
say "$(eval_gettext "Saved working directory and index state \$stash_msg")"
if test -z "$patch_mode"
then
- git reset --hard ${GIT_QUIET:+-q}
+ if test $# != 0
+ then
+ git ls-files -z -- "$@" | xargs -0 git reset --
+ git ls-files -z --modified -- "$@" | xargs -0 git checkout HEAD --
+ git ls-files -z --others -- "$@" | xargs -0 git clean --force --
+ else
+ git reset --hard ${GIT_QUIET:+-q}
+ fi
test "$untracked" = "all" && CLEAN_X_OPTION=-x || CLEAN_X_OPTION=
if test -n "$untracked"
then
- git clean --force --quiet -d $CLEAN_X_OPTION
+ git clean --force --quiet -d $CLEAN_X_OPTION -- "$@"
fi
if test "$keep_index" = "t" && test -n "$i_tree"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index b859e51086..461fe46045 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -811,4 +811,46 @@ test_expect_success 'new style stash create stores correct message' '
test_cmp expect actual
'
+test_expect_success 'stash -- <filename> stashes and restores the file' '
+ >foo &&
+ >bar &&
+ git add foo bar &&
+ git stash push -- foo &&
+ test_path_is_file bar &&
+ test_path_is_missing foo &&
+ git stash pop &&
+ test_path_is_file foo &&
+ test_path_is_file bar
+'
+
+test_expect_success 'stash with multiple filename arguments' '
+ >foo &&
+ >bar &&
+ >extra &&
+ git add foo bar extra &&
+ git stash push -- foo bar &&
+ test_path_is_missing bar &&
+ test_path_is_missing foo &&
+ test_path_is_file extra &&
+ git stash pop &&
+ test_path_is_file foo &&
+ test_path_is_file bar &&
+ test_path_is_file extra
+'
+
+test_expect_success 'stash with file including $IFS character' '
+ >"foo bar" &&
+ >foo &&
+ >untracked &&
+ git add foo* &&
+ git stash push -- foo* &&
+ test_path_is_missing "foo bar" &&
+ test_path_is_missing foo &&
+ test_path_is_file untracked &&
+ git stash pop &&
+ test_path_is_file "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file untracked
+'
+
test_done
diff --git a/t/t3905-stash-include-untracked.sh b/t/t3905-stash-include-untracked.sh
index f372fc8ca8..9a98e31a3e 100755
--- a/t/t3905-stash-include-untracked.sh
+++ b/t/t3905-stash-include-untracked.sh
@@ -185,4 +185,30 @@ test_expect_success 'stash save --all is stash poppable' '
test -s .gitignore
'
+test_expect_success 'stash push --include-untracked with pathspec' '
+ >foo &&
+ >bar &&
+ git stash push --include-untracked -- foo &&
+ test_path_is_file bar &&
+ test_path_is_missing foo &&
+ git stash pop &&
+ test_path_is_file bar &&
+ test_path_is_file foo
+'
+
+test_expect_success 'stash push with $IFS character' '
+ >"foo bar" &&
+ >foo &&
+ >bar &&
+ git add foo* &&
+ git stash push --include-untracked -- foo* &&
+ test_path_is_missing "foo bar" &&
+ test_path_is_missing foo &&
+ test_path_is_file bar &&
+ git stash pop &&
+ test_path_is_file "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar
+'
+
test_done
--
2.12.0.rc0.208.g81c5d00b20.dirty
^ permalink raw reply related
* [PATCH] difftool: fix bug when printing usage
From: David Aguilar @ 2017-02-05 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML, Johannes Schindelin, Denton Liu
In-Reply-To: <20170205201751.z4rfmy5xxaqg472l@gmail.com>
"git difftool -h" reports an error:
fatal: BUG: setup_git_env called without repository
Defer repository setup so that the help option processing happens before
the repository is initialized.
Add tests to ensure that the basic usage works inside and outside of a
repository.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This bug exists in both "master" and "next".
This patch has been tested on both branches.
builtin/difftool.c | 8 ++++----
t/t7800-difftool.sh | 13 +++++++++++++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/builtin/difftool.c b/builtin/difftool.c
index b5e85ab079..d13350ce83 100644
--- a/builtin/difftool.c
+++ b/builtin/difftool.c
@@ -647,10 +647,6 @@ int cmd_difftool(int argc, const char **argv, const char *prefix)
OPT_END()
};
- /* NEEDSWORK: once we no longer spawn anything, remove this */
- setenv(GIT_DIR_ENVIRONMENT, absolute_path(get_git_dir()), 1);
- setenv(GIT_WORK_TREE_ENVIRONMENT, absolute_path(get_git_work_tree()), 1);
-
git_config(difftool_config, NULL);
symlinks = has_symlinks;
@@ -661,6 +657,10 @@ int cmd_difftool(int argc, const char **argv, const char *prefix)
if (tool_help)
return print_tool_help();
+ /* NEEDSWORK: once we no longer spawn anything, remove this */
+ setenv(GIT_DIR_ENVIRONMENT, absolute_path(get_git_dir()), 1);
+ setenv(GIT_WORK_TREE_ENVIRONMENT, absolute_path(get_git_work_tree()), 1);
+
if (use_gui_tool && diff_gui_tool && *diff_gui_tool)
setenv("GIT_DIFF_TOOL", diff_gui_tool, 1);
else if (difftool_cmd) {
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index aa0ef02597..21e2ac4ad6 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -23,6 +23,19 @@ prompt_given ()
test "$prompt" = "Launch 'test-tool' [Y/n]? branch"
}
+test_expect_success 'basic usage requires no repo' '
+ lines=$(git difftool -h | grep ^usage: | wc -l) &&
+ test "$lines" -eq 1 &&
+ # create a ceiling directory to prevent Git from finding a repo
+ mkdir -p not/repo &&
+ ceiling="$PWD/not" &&
+ lines=$(cd not/repo &&
+ GIT_CEILING_DIRECTORIES="$ceiling" git difftool -h |
+ grep ^usage: | wc -l) &&
+ test "$lines" -eq 1 &&
+ rmdir -p not/repo
+'
+
# Create a file on master and change it on branch
test_expect_success 'setup' '
echo master >file &&
--
2.12.0.rc0.209.g3d1e53e462
^ permalink raw reply related
* [PATCH] tag: generate useful reflog message
From: cornelius.weig @ 2017-02-05 21:42 UTC (permalink / raw)
To: git; +Cc: bitte.keine.werbung.einwerfen, Cornelius Weig, karthik.188, peff
From: Cornelius Weig <cornelius.weig@tngtech.com>
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
"6e3a7b3 refs/tags/tag_with_reflog@{0}:"
Now, a reflog message is generated when creating a tag. The message
follows the pattern "commit: <subject>" where the subject is taken from
the commit the tag points to. For example:
"6e3a7b3 refs/tags/tag_with_reflog@{0}: commit: Git 2.12-rc0"
If the tag points to a tree/blob/tag object, the following static
messages are used instead:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
---
Notes:
While playing around with tag reflogs I also found a bug that was present
before this patch. It manifests itself when the sha1-ref in the reflog does not
point to a commit object but something else.
For example,
- when the referenced sha1 is a tag object:
$ git tag --create-reflog -f -m'annotated tag' tag_with_reflog
- when the referenced sha1 is a blob object:
$ git tag --create-reflog -f tag_with_reflog HEAD:<filename>
- when the referenced sha1 is a tree object:
$ git tag --create-reflog -f tag_with_reflog HEAD^{tree}
In each case, a proper reflog entry is generated, but
$ git reflog tag_with_reflog
will sometimes segfault (if it does, it does so consistently), or only show the
first few entries. The tree/blob cases are IMHO not so important, but the
broken reflog for annotated tags I find quite severe.
I guess it's because the reflog is funneled through the log.c code, where every
reflog-entry is assumed to be a commit object? If this is the case, a fix would
probably be quite involved.
builtin/tag.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
t/t7004-tag.sh | 14 +++++++++++++-
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a9..c0d9478 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -302,6 +302,43 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
+static void create_reflog_msg(const unsigned char *object, struct strbuf *sb)
+{
+ enum object_type type;
+ char *buf;
+ unsigned long size;
+ int subject_len = 0;
+ const char *subject_start;
+
+ type = sha1_object_info(object, NULL);
+ switch (type) {
+ default:
+ strbuf_addstr(sb, "internal object");
+ break;
+ case OBJ_COMMIT:
+ strbuf_addstr(sb, "commit: ");
+ buf = read_sha1_file(object, &type, &size);
+ if (buf) {
+ subject_len = find_commit_subject(buf, &subject_start);
+ strbuf_insert(sb, 8, subject_start, subject_len);
+ free(buf);
+ } else {
+ die("commit object %s could not be read",
+ sha1_to_hex(repl));
+ }
+ break;
+ case OBJ_TREE:
+ strbuf_addstr(sb, "tree object");
+ break;
+ case OBJ_BLOB:
+ strbuf_addstr(sb, "blob object");
+ break;
+ case OBJ_TAG:
+ strbuf_addstr(sb, "other tag object");
+ break;
+ }
+}
+
struct msg_arg {
int given;
struct strbuf buf;
@@ -335,6 +372,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
+ struct strbuf reflog_msg = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct create_tag_options opt;
@@ -494,6 +532,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
+ create_reflog_msg(object, &reflog_msg);
+
if (create_tag_object) {
if (force_sign_annotate && !annotate)
opt.sign = 1;
@@ -504,7 +544,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
- NULL, &err) ||
+ reflog_msg.buf, &err) ||
ref_transaction_commit(transaction, &err))
die("%s", err.buf);
ref_transaction_free(transaction);
@@ -514,5 +554,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
strbuf_release(&err);
strbuf_release(&buf);
strbuf_release(&ref);
+ strbuf_release(&reflog_msg);
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 072e6c6..0a92b2c 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -83,7 +83,19 @@ test_expect_success 'creating a tag using default HEAD should succeed' '
test_expect_success 'creating a tag with --create-reflog should create reflog' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
- git reflog exists refs/tags/tag_with_reflog
+ git reflog exists refs/tags/tag_with_reflog &&
+ git log -1 --format="format:commit: %s%n" > expected &&
+ sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
+'
+
+test_expect_success 'annotated tag with --create-reflog has correct message' '
+ test_when_finished "git tag -d tag_with_reflog" &&
+ git tag -m "annotated tag" --create-reflog tag_with_reflog &&
+ git reflog exists refs/tags/tag_with_reflog &&
+ git log -1 --format="format:commit: %s%n" > expected &&
+ sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
'
test_expect_success '--create-reflog does not create reflog on failure' '
--
2.10.2
^ permalink raw reply related
* In-body from headers ignored
From: Liam Breck @ 2017-02-05 21:45 UTC (permalink / raw)
To: git
git format-patch & send-email generate the in-body From header.
git am recognizes it.
git commit & format-patch & send-email ignore it. (The latter two will
add a new header above an extant one.) Is there a rationale for this?
If not, maybe this is a bug?
^ permalink raw reply
* Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Jacob Keller @ 2017-02-05 22:45 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Jeff King, Git mailing list
In-Reply-To: <CACsJy8CTRcDuRiNeutG82iAj8qQFp+z2nadFfdkkHQGk6GKppA@mail.gmail.com>
On Sun, Feb 5, 2017 at 2:39 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sat, Jan 21, 2017 at 2:16 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> I would be interested in the code for this.. I'm curious if I can
>> adapt it to my use of tmux.
>
> I stumbled upon this which does mention about git SHA-1. Maybe you'll
> find it useful. Haven't tried it out though.
>
> https://github.com/morantron/tmux-fingers
>
> --
> Duy
This sounds almost exactly like what I want! :)
Thanks,
Jake
^ permalink raw reply
* [PATCH v2] tag: generate useful reflog message
From: cornelius.weig @ 2017-02-05 23:18 UTC (permalink / raw)
To: git; +Cc: bitte.keine.werbung.einwerfen, Cornelius Weig, karthik.188, peff
In-Reply-To: <20170205214254.24560-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
"6e3a7b3 refs/tags/test@{0}:"
Now, a reflog message is generated when creating a tag, following the
pattern "<action>: <description>". Here, action is the command line with
all arguments, or the value of GIT_REFLOG_ACTION if it is set. The
description is the commit subject, if the tag points to a commit. For
example:
"6e3a7b3 refs/tags/test@{0}: tag --create-reflog test: Git 2.12-rc0"
If the tag points to a tree/blob/tag object, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
---
Notes:
*This patch supersedes the version submitted a few hours earlier.*
Sorry for the messup, but I realized that the pattern for the reflog message
from my first draft did not comply to standard git behavior.
Please also note my remarks from v1 (repeated here):
While playing around with tag reflogs I also found a bug that was present
before this patch. It manifests itself when the sha1-ref in the reflog does not
point to a commit object but something else.
For example,
- when the referenced sha1 is a tag object:
$ git tag --create-reflog -f -m'annotated tag' tag_with_reflog
- when the referenced sha1 is a blob object:
$ git tag --create-reflog -f tag_with_reflog HEAD:<filename>
- when the referenced sha1 is a tree object:
$ git tag --create-reflog -f tag_with_reflog HEAD^{tree}
In each case, a proper reflog entry is generated, but
$ git reflog tag_with_reflog
will sometimes segfault (if it does, it does so consistently), or only show the
first few entries. The tree/blob cases are IMHO not so important, but the
broken reflog for annotated tags I find quite severe.
I guess it's because the reflog is funneled through the log.c code, where every
reflog-entry is assumed to be a commit object? If this is the case, a fix would
probably be quite involved.
builtin/tag.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
t/t7004-tag.sh | 16 +++++++++++++++-
2 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a9..3d9e105 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -30,6 +30,7 @@ static const char * const git_tag_usage[] = {
static unsigned int colopts;
static int force_sign_annotate;
+static struct strbuf default_rla = STRBUF_INIT;
static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting, const char *format)
{
@@ -302,6 +303,48 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
+static void create_reflog_msg(const unsigned char *object, struct strbuf *sb)
+{
+ enum object_type type;
+ char *buf;
+ unsigned long size;
+ int subject_len = 0;
+ const char *subject_start;
+
+ char *rla = getenv("GIT_REFLOG_ACTION");
+ if (!rla)
+ rla = default_rla.buf;
+
+ strbuf_addf(sb, "%s: ", rla ? rla : default_rla.buf);
+
+ type = sha1_object_info(object, NULL);
+ switch (type) {
+ default:
+ strbuf_addstr(sb, "internal object");
+ break;
+ case OBJ_COMMIT:
+ buf = read_sha1_file(object, &type, &size);
+ if (buf) {
+ subject_len = find_commit_subject(buf, &subject_start);
+ strbuf_insert(sb, sb->len, subject_start, subject_len);
+ free(buf);
+ } else {
+ die("commit object %s could not be read",
+ sha1_to_hex(object));
+ }
+ break;
+ case OBJ_TREE:
+ strbuf_addstr(sb, "tree object");
+ break;
+ case OBJ_BLOB:
+ strbuf_addstr(sb, "blob object");
+ break;
+ case OBJ_TAG:
+ strbuf_addstr(sb, "other tag object");
+ break;
+ }
+}
+
struct msg_arg {
int given;
struct strbuf buf;
@@ -335,6 +378,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
+ struct strbuf reflog_msg = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct create_tag_options opt;
@@ -349,7 +393,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct ref_filter filter;
static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
const char *format = NULL;
- int icase = 0;
+ int icase = 0, i;
struct option options[] = {
OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'),
{ OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
@@ -391,6 +435,11 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
git_config(git_tag_config, sorting_tail);
+ /* Record the command line for the reflog */
+ strbuf_addstr(&default_rla, "tag");
+ for (i = 1; i < argc; i++)
+ strbuf_addf(&default_rla, " %s", argv[i]);
+
memset(&opt, 0, sizeof(opt));
memset(&filter, 0, sizeof(filter));
filter.lines = -1;
@@ -494,6 +543,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
+ create_reflog_msg(object, &reflog_msg);
+
if (create_tag_object) {
if (force_sign_annotate && !annotate)
opt.sign = 1;
@@ -504,7 +555,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
- NULL, &err) ||
+ reflog_msg.buf, &err) ||
ref_transaction_commit(transaction, &err))
die("%s", err.buf);
ref_transaction_free(transaction);
@@ -514,5 +565,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
strbuf_release(&err);
strbuf_release(&buf);
strbuf_release(&ref);
+ strbuf_release(&reflog_msg);
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 072e6c6..9c80bc9 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -80,10 +80,24 @@ test_expect_success 'creating a tag using default HEAD should succeed' '
test_must_fail git reflog exists refs/tags/mytag
'
+git log -1 > expected \
+ --format="format:tag --create-reflog tag_with_reflog: %s%n"
test_expect_success 'creating a tag with --create-reflog should create reflog' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
- git reflog exists refs/tags/tag_with_reflog
+ git reflog exists refs/tags/tag_with_reflog &&
+ sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
+'
+
+git log -1 > expected \
+ --format='format:tag -m annotated tag --create-reflog tag_with_reflog: %s%n'
+test_expect_success 'annotated tag with --create-reflog has correct message' '
+ test_when_finished "git tag -d tag_with_reflog" &&
+ git tag -m "annotated tag" --create-reflog tag_with_reflog &&
+ git reflog exists refs/tags/tag_with_reflog &&
+ sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
'
test_expect_success '--create-reflog does not create reflog on failure' '
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] tag: generate useful reflog message
From: Junio C Hamano @ 2017-02-05 23:25 UTC (permalink / raw)
To: cornelius.weig; +Cc: git, bitte.keine.werbung.einwerfen, karthik.188, peff
In-Reply-To: <20170205214254.24560-1-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> Now, a reflog message is generated when creating a tag. The message
> follows the pattern "commit: <subject>" where the subject is taken from
> the commit the tag points to. For example:
> "6e3a7b3 refs/tags/tag_with_reflog@{0}: commit: Git 2.12-rc0"
Because the reflog records the actions, shouldn't it be saying that
you "tagged"? The reflog for HEAD says things like "reset: moving
to...", "am: $subject", and the reflog for a branch says things like
"branch: created from master", "am: $subject", "rebase -i (finish)".
For a tag, I would imagine something like "tag: tagged 4e59582ff7
("Seventh batch for 2.12", 2017-01-23)" would be more appropriate.
> Notes:
> While playing around with tag reflogs I also found a bug that was present
> before this patch. It manifests itself when the sha1-ref in the reflog does not
> point to a commit object but something else.
The underlying machinery for "log" and "rev-list" is about showing a
stream of commits, and most of the reflog entries point at commits.
On the other hand, the "walking reflogs to and show the sequence of
the tip of refs", and there is no reason to expect the tip of refs
will always be commits, but an ancient design mistake bolted the
latter on top of the former (perhaps because in practice the tip of
refs are almost always commits); "reflog" aka "log -g" and "rev-list
--walk-reflogs" share the same issue coming from that misdesign,
which needs to be corrected to solve this issue.
The exact same design mistake also makes "git reflog" to accept
options like "--topo-order", even though many of the options that
make sense for the "commit DAG walking" (which is what "log" and
"rev-list" are about) do not make any sense when walking a reflog.
And the command would give nonsense output when given such an
option, because a reflog is a single strand of pearl of objects (not
necessarily commits) and the order in which these objects appear in
the reflog does not have anything to do with the underlying commit
DAG topology. Fixing the ancient misdesign would fix this issue,
too.
I think the fix would involve first ripping out the "reflog walking"
code that was bolted on and stop allowing it to inject the entries
taken from the reflog into the "walk the commit DAG" machinery.
Then "reflog walking" code needs to be taught to have its own "now
we got a single object to show, show it (using the helper functions
to show a single object that is already used by 'git show')" code,
instead of piggy-backing on the output codepath used by "log" and
"rev-list".
^ permalink raw reply
* Re: In-body from headers ignored
From: Junio C Hamano @ 2017-02-05 23:43 UTC (permalink / raw)
To: Liam Breck; +Cc: git
In-Reply-To: <CAKvHMgQLKccm2LcL4LGhz0afVthaS2gvEcLtoHX2TcDnr1npbw@mail.gmail.com>
Liam Breck <liam@networkimprov.net> writes:
> git format-patch & send-email generate the in-body From header.
>
> git am recognizes it.
>
> git commit & format-patch & send-email ignore it. (The latter two will
> add a new header above an extant one.) Is there a rationale for this?
I may be misunderstanding you, but I am guessing that you are
expecting
$ GIT_AUTHOR_NAME="Liam Breck" GIT_AUTHOR_EMAIL='liam@n.net' \
git commit -m 'The title of the patch
From: Somebody Else <somebody@else.xz>
Subject: The real title of the patch
This is the (true) first line of the body of the message.'
to record a commit object that would give
$ git cat-file commit HEAD
tree ....
parent ....
author Somebody Else <somebody@else.xz> ....
committer ...
The real title of the patch
This is the (true) first line of the body of the message.
and seeing that the real author is still you, the title is "The real
title of the patch", and the first paragraph of the body consists of
these two lines that begin with "From: and "Subject:".
This is very much deliberate. "git commit" does not care if the
second paragraph in the body of the message resembles e-mail
headers, because it is a command that can be used by people who do
not even e-mail patches.
"git format-patch" and "git am" are all about passing the commit
between people over e-mail, and they know that the second paragraph
can have "From:", "Subject:" or "Date:" to override what "am"
obtains from the header lines of the e-mail that carried the
message, because the e-mail headers can be different (e.g. you may
be forwarding somebody else's e-mail but you may not be able to
forge the real "From:" line to your MUA/MTA) from what you really
want to use. On the receiving end, "am" tells "mailinfo" program to
inspect the message body with "--inbody-headers" option. After
"mailinfo" inspects the message, "am" invokes the underlying
machinery to actually make the commit (which corresponds to "git
commit"), but at that point the invoked "git commit" does not even
see these in-body header lines. That is how division of labor
between these layers of the commands are structured.
^ permalink raw reply
* Re: In-body from headers ignored
From: Liam Breck @ 2017-02-06 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqa8a0431z.fsf@gitster.mtv.corp.google.com>
On Sun, Feb 5, 2017 at 3:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Liam Breck <liam@networkimprov.net> writes:
>
>> git format-patch & send-email generate the in-body From header.
>>
>> git am recognizes it.
>>
>> git commit & format-patch & send-email ignore it. (The latter two will
>> add a new header above an extant one.) Is there a rationale for this?
>
> I may be misunderstanding you, but I am guessing that you are
> expecting
>...
> and seeing that the real author is still you, the title is "The real
> title of the patch", and the first paragraph of the body consists of
> these two lines that begin with "From: and "Subject:".
>
> This is very much deliberate. "git commit" does not care if the
> second paragraph in the body of the message resembles e-mail
> headers, because it is a command that can be used by people who do
> not even e-mail patches.
> ...
Hi, thanks for the detailed reply :-)
OK, that resolves my Q about git commit.
But should not git format-patch & send-email detect an extant in-body
From or Subject header?
Suppose I need to forward a patchset and cannot amend the commits in
git? Or that a patchset author is not the copyright holder, whom I
want to be logged as the author upstream?
There is a workaround: delete the From headers in the patches, but I
was looking for a command-line option or alternate default behavior
:-)
^ permalink raw reply
* Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"
From: Junio C Hamano @ 2017-02-06 0:15 UTC (permalink / raw)
To: Siddharth Kannan; +Cc: git, pranit.bauva, Matthieu.Moy, peff, pclouds, sandals
In-Reply-To: <1486299439-2859-1-git-send-email-kannan.siddharth12@gmail.com>
Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
> @@ -158,6 +158,51 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
>
> if (quiet)
> rev->diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;
> +
> + /*
> + * Check if any argument has a "-" in it, which has been referred to as a
> + * shorthand for @{-1}. Handles methods that might be used to list commits
> + * as mentioned in git rev-list --help
> + */
> +
> + for(i = 0; i < argc; ++i) {
> + if (!strcmp(argv[i], "-")) {
> + argv[i] = "@{-1}";
> + } else if (!strcmp(argv[i], "^-")) {
> + argv[i] = "^@{-1}";
> + } else if (strlen(argv[i]) >= 4) {
> +
> + ...
> + }
> + }
> +
> argc = setup_revisions(argc, argv, rev, opt);
"Turn '-' to '@{-1}' before we do the real parsing" can never be a
reasonable strategy to implement the desired "'-' means the tip of
the previous branch" correctly. To understand why, you only need to
imagine what happens to this command:
$ git log --grep '^-'
Turning it into "git log --grep '^@{-1}'" obviously is not what the
end-users want, so that is an immediate bug in the version of Git
with this patch applied.
Even if this were not a patch for the "log" command but for some
other command, a change with the above approach is very much
unwelcome, even if that other command does not currently have any
option that takes arbitrary string the user may want to specify
(like "find commit with a line that matches this pattern" option
called "--grep" the "log" command has). That is because it will
make it impossible to enhance the command by adding such an option
in the future. So it is also adding the problems to future
developers (and users) of Git.
A correct solution needs to know if the argument is at the position
where a revision (or revision range) is expected and then give the
tip of the previous branch when it sees "-" (and other combinations
this patch tries to cover). In other words, the parser always knows
what it is parsing, and if and only if it is parsing a rev, react to
"-" and think "ah, the user wants me to use the tip of the previous
branch".
But the code that knows that it expects to see a revision already
exists, and it is the real parser. In the above snippet,
setup_revisions() is the one that does the real parsing of argv[].
The code there knows when it wants to see a rev, and takes argv[i]
and turns into an object to call add_pending_object(). That codepath
may not yet know that "-" means the tip of the previous branch, and
that is where the change needs to go.
Such a properly-done update does not need to textually replace "-"
with "@{-1}" in argv[]; the codepath is where it understands what
any textual representation of a rev the user gave it means, and it
understands "@{-1}" there. It would be the matter of updating it to
also understand what "-" means.
A correct solution will be a lot more involved, of course, and I
think it will be larger than a reasonable microproject for people
new to the codebase.
I didn't check the microproject ideas page myself; whether it says
that turning "-" unconditionally to "@{-1}" is a good idea, or it
hints that supporting "-" as "the tip of the previous branch" in
more commands is a reasonable byte-sized microproject, I think it is
misleading and misguided. Can somebody remove that entry so that we
won't waste time of new developers (which would lead to discouraging
them)? Thanks.
^ permalink raw reply
* Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"
From: Siddharth Kannan @ 2017-02-06 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, pranit.bauva, Matthieu.Moy, peff, pclouds, sandals
In-Reply-To: <xmqqtw882n08.fsf@gitster.mtv.corp.google.com>
Hey Junio,
On Sun, Feb 05, 2017 at 04:15:03PM -0800, Junio C Hamano wrote:
> Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
>
> > @@ -158,6 +158,51 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
> >
> > if (quiet)
> > rev->diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;
> > +
> > + /*
> > + * Check if any argument has a "-" in it, which has been referred to as a
> > + * shorthand for @{-1}. Handles methods that might be used to list commits
> > + * as mentioned in git rev-list --help
> > + */
> > +
> > + for(i = 0; i < argc; ++i) {
> > + if (!strcmp(argv[i], "-")) {
> > + argv[i] = "@{-1}";
> > + } else if (!strcmp(argv[i], "^-")) {
> > + argv[i] = "^@{-1}";
> > + } else if (strlen(argv[i]) >= 4) {
> > +
> > + ...
> > + }
> > + }
> > +
> > argc = setup_revisions(argc, argv, rev, opt);
>
> "Turn '-' to '@{-1}' before we do the real parsing" can never be a
> reasonable strategy to implement the desired "'-' means the tip of
> the previous branch" correctly. To understand why, you only need to
> imagine what happens to this command:
>
> $ git log --grep '^-'
>
> Turning it into "git log --grep '^@{-1}'" obviously is not what the
> end-users want, so that is an immediate bug in the version of Git
> with this patch applied.
>
> Even if this were not a patch for the "log" command but for some
> other command, a change with the above approach is very much
> unwelcome, even if that other command does not currently have any
> option that takes arbitrary string the user may want to specify
> (like "find commit with a line that matches this pattern" option
> called "--grep" the "log" command has). That is because it will
> make it impossible to enhance the command by adding such an option
> in the future. So it is also adding the problems to future
> developers (and users) of Git.
Understood!
>
> A correct solution needs to know if the argument is at the position
> where a revision (or revision range) is expected and then give the
> tip of the previous branch when it sees "-" (and other combinations
> this patch tries to cover). In other words, the parser always knows
> what it is parsing, and if and only if it is parsing a rev, react to
> "-" and think "ah, the user wants me to use the tip of the previous
> branch".
Ah, okay. I will do another one of the suggestions as my micro project
but continue to look into this part of the code and try to find the
right place to write the code to implement the present patch.
>
> But the code that knows that it expects to see a revision already
> exists, and it is the real parser. In the above snippet,
> setup_revisions() is the one that does the real parsing of argv[].
> The code there knows when it wants to see a rev, and takes argv[i]
> and turns into an object to call add_pending_object(). That codepath
> may not yet know that "-" means the tip of the previous branch, and
> that is where the change needs to go.
>
> Such a properly-done update does not need to textually replace "-"
> with "@{-1}" in argv[]; the codepath is where it understands what
> any textual representation of a rev the user gave it means, and it
> understands "@{-1}" there. It would be the matter of updating it to
> also understand what "-" means.
>
> A correct solution will be a lot more involved, of course, and I
> think it will be larger than a reasonable microproject for people
> new to the codebase.
>
> I didn't check the microproject ideas page myself; whether it says
> that turning "-" unconditionally to "@{-1}" is a good idea, or it
> hints that supporting "-" as "the tip of the previous branch" in
> more commands is a reasonable byte-sized microproject, I think it is
> misleading and misguided. Can somebody remove that entry so that we
> won't waste time of new developers (which would lead to discouraging
> them)? Thanks.
Thanks a lot for writing this detailed reply! I will definitely take
into account all of the points mentioned here in the future patches I
send.
- Siddharth Kannan
^ permalink raw reply
* Re: [PATCH v3] parse-remote: remove reference to unused op_prep
From: Siddharth Kannan @ 2017-02-06 2:28 UTC (permalink / raw)
To: Pranit Bauva; +Cc: Git List
In-Reply-To: <CAFZEwPOdL4mOAnmTUqs5LmfdG2GQCieVGVQ7T3ZWR0n+d6tCQQ@mail.gmail.com>
Hey Pranit,
On Sun, Feb 05, 2017 at 02:45:46AM +0530, Pranit Bauva wrote:
> Hey Siddharth,
>
> On Sat, Feb 4, 2017 at 8:01 PM, Siddharth Kannan
> <kannan.siddharth12@gmail.com> wrote:
> > The error_on_missing_default_upstream helper function learned to
> > take op_prep argument with 15a147e618 ("rebase: use @{upstream}
> > if no upstream specified", 2011-02-09), but as of 045fac5845
> > ("i18n: git-parse-remote.sh: mark strings for translation",
> > 2016-04-19), the argument is no longer used. Remove it.
> >
> > Signed-off-by: Siddharth Kannan <kannan.siddharth12@gmail.com>
>
> This looks good to me! Thanks :)
>
> Regards,
> Pranit Bauva
Should I send this patch with "To:" set to Junio and "Cc:" set to the
mailing list, as mentioend in the SubmittingPatches document?
- Siddharth Kannan
^ permalink raw reply
* [PATCH] Document the --no-gui option in difftool
From: Denton Liu @ 2017-02-06 3:41 UTC (permalink / raw)
To: git; +Cc: davvid
Prior to this, the `--no-gui` option was not documented in the manpage.
This commit introduces this into the manpage
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
Documentation/git-difftool.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 224fb3090..a2661d9cc 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -87,9 +87,11 @@ instead. `--no-symlinks` is the default on Windows.
-g::
--gui::
+--no-gui::
When 'git-difftool' is invoked with the `-g` or `--gui` option
the default diff tool will be read from the configured
- `diff.guitool` variable instead of `diff.tool`.
+ `diff.guitool` variable instead of `diff.tool`. The `--no-gui`
+ option can be used to override this setting.
--[no-]trust-exit-code::
'git-difftool' invokes a diff tool individually on each file.
--
2.12.0.rc0.208.g81c5d00b2
^ permalink raw reply related
* Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
From: Stefan Beller @ 2017-02-06 4:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Benjamin Fuchs, git@vger.kernel.org, SZEDER Gábor,
brian m. carlson, ville.skytta
In-Reply-To: <xmqqk29bsz2o.fsf@gitster.mtv.corp.google.com>
On Mon, Jan 30, 2017 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Benjamin Fuchs <email@benjaminfuchs.de> writes:
>
>> In [2/4] I got rid of the loop by feedback of Gábor.
>> Sorry if my patch wasn't well formed.
>
> While it might be the way other development communities work, in the
> Git development community, we do not work that way when presenting
> your second and subsequent attempt to the community.
>
> Having the initial draft from the original developers that records
> the bugs and misdesigns in an earlier parts of a series and separate
> patches that record how the problems were fixed to arrive at the
> final shape of the codebase might be interesting to the original
> developers, and they may even find such a history valuable, but in
> the context of the history that will be recorded in the official
> tree of the project for eternity, that just adds useless noise.
>
> Instead of keeping the original, in which problems were pointed out,
> and adding later commits to correct them incrementally, a patch is
> "rerolled". That is, you are expected to learn from the review
> comments and pretend as if you did the work from scratch and you
> already possessed the wisdom lent by the reviewers when you started
> your work. In the "rerolled" patches you send, you pretend as if
> you worked without making mistakes you made in the earlier rounds at
> all, producing (more) perfect patches from the beginning.
>
> In reality, you may locally be using Git tools like rebase,
> cherry-pick and "add -p" while preparing these "rerolled" rounds of
> patches, but the name of the game is to hide that effort from the
> public and pretend to be a perfect human, recording the result of
> exercising your best ability in the official history ;-).
>
> So this is OK:
>
> 0/3: I want to improve X, and for that I identified that I need
> A, B and C done. A or B alone is already an improvement, but A
> and B together makes it even more useful, and implementation of
> C requires patches to do A and B.
>
> 1/3: do A
> 2/3: do B
> 3/3: do C, building on A and B
>
> This is not:
>
> 0/3: I want to improve X, and for that I need to do C.
> 1/3: I couldn't do C, and I did A instead.
> 2/3: A was totally useless. I fix it to do B.
> 3/3: B is not very useful, either. I fix it to do C.
>
I agree with Junio here,
"git rebase --interactive" and then editing/squashing commits
is your friend.
(unrelated side note:)
At GitMerge facebook presented their improvements on mercurial
and one of the things was "hg absorb". It would take the dirty hunks/lines
of the working tree and amend them into the "stack of commits", i.e. into
your local unpublished history. So instead of making fixup commits
and doing the whole interactive rebase thing, it would do it automatically
for you. I think that is a neat time saver.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
From: Jacob Keller @ 2017-02-06 5:55 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Benjamin Fuchs, git@vger.kernel.org,
SZEDER Gábor, brian m. carlson, ville.skytta
In-Reply-To: <CAGZ79kY_1ELUZ2wZwNbQ+HrDnRBM3ngt9HKHKPmvaJEcoAFTtg@mail.gmail.com>
On Sun, Feb 5, 2017 at 8:23 PM, Stefan Beller <sbeller@google.com> wrote:
>
> (unrelated side note:)
> At GitMerge facebook presented their improvements on mercurial
> and one of the things was "hg absorb". It would take the dirty hunks/lines
> of the working tree and amend them into the "stack of commits", i.e. into
> your local unpublished history. So instead of making fixup commits
> and doing the whole interactive rebase thing, it would do it automatically
> for you. I think that is a neat time saver.
>
> Thanks,
> Stefan
How exactly was it different from doing "git commit --fixup xyz" and
"git rebase -i --autosquash"? Like, what was the advantage to the user
facing workflow? Just curious to see if we could learn something from
it.
Regards,
Jake
^ permalink raw reply
* git/git-scm.com GH Issue Tracker
From: Samuel Lijin @ 2017-02-06 6:15 UTC (permalink / raw)
To: git@vger.kernel.org
I've went through a bunch of open issues on the git/git-scm.com repo
(specifically, everything after #600) and I think the bulk of them can
be closed.
I've taken the liberty of classifying them as shown below.
- Sam
# Irrelevant but someone should take a look
693
# Irrelevant to git-scm.com and should be closed
# Each of these had had someone comment on it saying as much
939 912 906 905 901 896 894 886 885 884 883 879 877 871 868 865 861 840
837 834 828 813 811 807 796 795 790 774 751 748 745 744 729 727 721 719
711 690 686 686 674 673 671 667 660 653 635 631 621 615 613 612 611 610
609 608
# Resolved, duplicate, or non-issue
936 875 863 858 856 839 786 785 761 760 754 752 736 723 720 704 684 683
675 663 662 661 657 651 649 640 637 634 633 628 623 616 614 605 602 601
# Relevant and should be kept open
929 890 859 855 854 826 812 808 804 787 777 768 747 715 703 701 695 694
678 668 665 649 646 639 620 617
^ permalink raw reply
* subtree merging fails
From: Stavros Liaskos @ 2017-02-06 8:48 UTC (permalink / raw)
To: git
Hi,
Please check this issue for a description of the bug:
https://github.com/git/git-scm.com/issues/896#issuecomment-277587626
Regards,
Stavros
^ permalink raw reply
* Re: git/git-scm.com GH Issue Tracker
From: Thomas Ferris Nicolaisen @ 2017-02-06 8:59 UTC (permalink / raw)
To: Samuel Lijin; +Cc: git@vger.kernel.org, Jeff King
In-Reply-To: <CAJZjrdX_8tjMhRac9QQOW8m_S2DprFPV=uZp8mFT+g6bASVd-w@mail.gmail.com>
Adding Peff to cc as he is the current maintainer of the git-scm.com site/repo.
On Mon, Feb 6, 2017 at 7:15 AM, Samuel Lijin <sxlijin@gmail.com> wrote:
>
> I've taken the liberty of classifying them as shown below.
>
As a community member who cares a lot about that site, thank you! I
would love to contribute by reviewing your reviews, but personally
can't find the time (focusing free time on podcast production from
Git-Merge instead ;)).
^ permalink raw reply
* Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
From: Stefan Beller @ 2017-02-06 10:13 UTC (permalink / raw)
To: Jacob Keller
Cc: Junio C Hamano, Benjamin Fuchs, git@vger.kernel.org,
SZEDER Gábor, brian m. carlson, ville.skytta
In-Reply-To: <CA+P7+xp0QJZkiYzgBhPvYPsG7iqRDhRQUjcdgf_GHU-93bSO-g@mail.gmail.com>
On Sun, Feb 5, 2017 at 9:55 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Sun, Feb 5, 2017 at 8:23 PM, Stefan Beller <sbeller@google.com> wrote:
>>
>> (unrelated side note:)
>> At GitMerge facebook presented their improvements on mercurial
>> and one of the things was "hg absorb". It would take the dirty hunks/lines
>> of the working tree and amend them into the "stack of commits", i.e. into
>> your local unpublished history. So instead of making fixup commits
>> and doing the whole interactive rebase thing, it would do it automatically
>> for you. I think that is a neat time saver.
>>
>> Thanks,
>> Stefan
>
> How exactly was it different from doing "git commit --fixup xyz" and
> "git rebase -i --autosquash"? Like, what was the advantage to the user
> facing workflow? Just curious to see if we could learn something from
> it.
My impression is that all local changes were split up and the "xyz"
was determined based off a heuristic, e.g. blame(?) and then the
rebase is run automatically after that, i.e. having just one command for
a complete workflow here, moving up a whole level in abstraction.
^ permalink raw reply
* Re: git/git-scm.com GH Issue Tracker
From: Duy Nguyen @ 2017-02-06 10:18 UTC (permalink / raw)
To: Samuel Lijin; +Cc: git@vger.kernel.org
In-Reply-To: <CAJZjrdX_8tjMhRac9QQOW8m_S2DprFPV=uZp8mFT+g6bASVd-w@mail.gmail.com>
On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
> # Irrelevant but someone should take a look
>
> 693
To save people some time (and since i looked at it anyway), this is
about whether "warning in tree xxx: contains zero-padded file modes:
from fsck should be a warning or error. It is a warning now even
though "git -c transfer.fsckobjects=true clone" treats it as an error.
There are some discussions in the past [1] [2] about this.
There's also a question "And I failed to find in the documentation if
transfer.fsckobjects could be disabled per repository, can you confirm
it's not possible for now ?"
(sorry no answer from me)
[1] http://public-inbox.org/git/%3CCAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=Q@mail.gmail.com%3E/
[2] http://public-inbox.org/git/%3C20100326215600.GA10910@spearce.org%3E/
--
Duy
^ permalink raw reply
* Re: gitconfig get out of sync with submodule entries on branch switch
From: Stefan Beller @ 2017-02-06 10:35 UTC (permalink / raw)
To: Benjamin Schindler; +Cc: git@vger.kernel.org
In-Reply-To: <0f14df64-1aa2-e671-9785-4e5e0a076ae6@gmail.com>
Answering the original email, as I feel we're going down the wrong rabbit
hole in the existing thread.
On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler
<beschindler@gmail.com> wrote:
> Hi
>
> Consider the following usecase: I have the master branch where I have a
> submodule A. I create a branch where I rename the submodule to be in the
> directory B. After doing all of this, everything looks good.
> Now, I switch back to master. The first oddity is, that it fails to remove
> the folder B because there are still files in there:
>
> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout
> master
> warning: unable to rmdir other_submodule: Directory not empty
> Switched to branch 'master'
checkout currently doesn't support submodules, so it should neither
try to delete B nor try to repopulate A when switching back to master.
checkout ought to not even touch the existing submodule B.
>
> Git submodule deinit on B fails because the submodule is not known to git
> anymore (after all, the folder B exists only in the other branch). I can
> easily just remove the folder B from disk and initialize the submodule A
> again, so all seems good.
by initializing you mean populating(?), i.e.
git submodule update
would work without the --init flag or preceding "git submodule init A".
That ought to not redownload A, but just put files back in the working tree
from the submodule git directory inside the superprojects git dir.
>
> However, what is not good is that the submodule b is still known in
> .git/config.
Oh, I see. You did not just rename the path, but also the name
in the .gitmodules?
> This is in particular a problem for us, because I know a number
> of tools which use git config to retrieve the submodule list. Is it
> therefore a bug that upon branch switch, the submodule gets deregistered,
> but its entry in .git/config remains?
The config remains as it indicates that you express(ed) interest in
submodule A, such that when switching branches
master->renamedToB->master
then we'd still care about A. As for the tools, I'd rather see them use
git submodule status/summary
instead of directly looking at the config, because the config may
change in the future.
>
> thanks a lot
> Benjamin Schindler
>
> P.s. I did not subscribe to the mailing list, please add me at least do CC.
> Thanks
^ permalink raw reply
* Re: gitconfig get out of sync with submodule entries on branch switch
From: Benjamin Schindler @ 2017-02-06 12:17 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
In-Reply-To: <CAGZ79kaZUOO4qusCDF9=VJ-6QPjAvc5eSaazjWWEocRMHuTSug@mail.gmail.com>
On 06.02.2017 11:35, Stefan Beller wrote:
> Answering the original email, as I feel we're going down the wrong rabbit
> hole in the existing thread.
>
> On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler
> <beschindler@gmail.com> wrote:
>> Hi
>>
>> Consider the following usecase: I have the master branch where I have a
>> submodule A. I create a branch where I rename the submodule to be in the
>> directory B. After doing all of this, everything looks good.
>> Now, I switch back to master. The first oddity is, that it fails to remove
>> the folder B because there are still files in there:
>>
>> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout
>> master
>> warning: unable to rmdir other_submodule: Directory not empty
>> Switched to branch 'master'
>
> checkout currently doesn't support submodules, so it should neither
> try to delete B nor try to repopulate A when switching back to master.
> checkout ought to not even touch the existing submodule B.
Well, it tried to remove the folder (the rmdir warning) but it failed so
in some sense you are right. Is there a technical reason for this
default though? Here, I frequently have to point out to people that they
need to initialize/update the submodule on e.g. clone.
>
>>
>> Git submodule deinit on B fails because the submodule is not known to git
>> anymore (after all, the folder B exists only in the other branch). I can
>> easily just remove the folder B from disk and initialize the submodule A
>> again, so all seems good.
>
> by initializing you mean populating(?), i.e.
>
> git submodule update
>
> would work without the --init flag or preceding "git submodule init A".
> That ought to not redownload A, but just put files back in the working tree
> from the submodule git directory inside the superprojects git dir.
>
>>
>> However, what is not good is that the submodule b is still known in
>> .git/config.
>
> Oh, I see. You did not just rename the path, but also the name
> in the .gitmodules?
I wasn't even aware that the submodule name was something different from
the path because the name is by default set to be the path to it. So
yes, I didn't just relocate it, it had a different name.
>
>> This is in particular a problem for us, because I know a number
>> of tools which use git config to retrieve the submodule list. Is it
>> therefore a bug that upon branch switch, the submodule gets deregistered,
>> but its entry in .git/config remains?
>
> The config remains as it indicates that you express(ed) interest in
> submodule A, such that when switching branches
>
> master->renamedToB->master
>
> then we'd still care about A. As for the tools, I'd rather see them use
>
> git submodule status/summary
>
> instead of directly looking at the config, because the config may
> change in the future.
That was my feeling but its good to know to have more solid reasons why
that would be.
Cheers
Benjamin
>
>>
>> thanks a lot
>> Benjamin Schindler
>>
>> P.s. I did not subscribe to the mailing list, please add me at least do CC.
>> Thanks
^ permalink raw reply
* A little help understanding output from git blame --reverse
From: Edmundo Carmona Antoranz @ 2017-02-06 12:38 UTC (permalink / raw)
To: Git List
Hi!
While doing some research developing difflame I found some output from
git blame --reverse that I can't quite understand. Perhaps another set
of eyeballs could help me.
I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
(066fb0494e6398eb). Specifically file abspath.c.
If we diff (as in plain old git diff) HEAD~100..HEAD we can see that
line 63 (from HEAD~100 revision) was deleted between HEAD~100 and
HEAD:
@@ -58,86 +95,136 @@ blah blah
goto error_out;
}
- strbuf_reset(&sb);
- strbuf_addstr(&sb, path);
-
- while (depth--) {
- if (!is_directory(sb.buf)) {
So, if I do a "reverse" blame operation on the file, I would expect to
see the last revision where that line was _present_ on the file:
c5f3cba126 61) strbuf_reset(&sb);
c5f3cba126 62) strbuf_addstr(&sb, path);
066fb0494e 63)
c5f3cba126 64) while (depth--) {
c5f3cba126 65) if (!is_directory(sb.buf)) {
line 63 shows up as if it had been last present on the file on
revision 066fb0494e, which is HEAD, which kind of doesn't make a lot
of sense to me because given that the line is not present on the file
on HEAD (as we can guess from diff output) it means it was "forcefully
present" on some previous revision (and that's what I would expect to
see reported on blame --reverse output).
What am I missing? Thanks in advance.
^ permalink raw reply
* Re: A little help understanding output from git blame --reverse
From: Edmundo Carmona Antoranz @ 2017-02-06 12:40 UTC (permalink / raw)
To: Git List
In-Reply-To: <CAOc6etZ7iuPKRQkYSZDrDRW0hxbu1aYMRuzB1iXAPv+EEnXJEg@mail.gmail.com>
On Mon, Feb 6, 2017 at 6:38 AM, Edmundo Carmona Antoranz
<eantoranz@gmail.com> wrote:
> I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
> (066fb0494e6398eb). Specifically file abspath.c.
I just noticed that I'm standing on a private branch. Replace HEAD for
"4e59582ff" when doing your analysis. You should get the same results.
^ permalink raw reply
* [PATCH] worktree: fix option descriptions for `prune`
From: Patrick Steinhardt @ 2017-02-06 13:13 UTC (permalink / raw)
To: git; +Cc: Patrick Steinhardt, Nguyễn Thái Ngọc Duy, ps
The `verbose` and `expire` options of the `git worktree prune`
subcommand have wrong descriptions in that they pretend to relate to
objects. But as the git-worktree(1) correctly states, these options have
nothing to do with objects but only with worktrees. Fix the description
accordingly.
Signed-off-by: Patrick Steinhardt <patrick.steinhardt@elego.de>
---
builtin/worktree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 9a97e37a3..831fe058a 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -125,9 +125,9 @@ static int prune(int ac, const char **av, const char *prefix)
{
struct option options[] = {
OPT__DRY_RUN(&show_only, N_("do not remove, show only")),
- OPT__VERBOSE(&verbose, N_("report pruned objects")),
+ OPT__VERBOSE(&verbose, N_("report pruned working trees")),
OPT_EXPIRY_DATE(0, "expire", &expire,
- N_("expire objects older than <time>")),
+ N_("expire working trees older than <time>")),
OPT_END()
};
--
2.11.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox