Re: [RFC/PATCH 0/2] Test the Git version string
Philip Oakley philipoak...@iee.org writes: If the parsing is done for white/blacklist purposes, is there a need to straight-jacket the verison string format like this series? The purpose is to document what we felt we could guarantee, and that which was open to variation, so that those, like the Git-Gui, can code in a sensible check for the version. Two digits (X.Y) should pass the existing Git Gui check. I'll drop the length limit, and keep to an X.Y check Is the end of t-basic.sh a sensible place for the check? Sorry, but I still do not understand what you are trying to achieve. What kind of benefit are you envisioning out of this? For a future version, people would not know what incompatibilities it would introduce, so case $(git version) in git verison[2-9].*) echo unsupported version exit 1 ;; esac is a nonsense check. For all released versions, people know how they looked like and we do not have anything further to specify. Git 1.5.0 will forever identify itself as: $ git version git version 1.5.0 Worse yet, for an untagged version, you may get something like git version 1.8.2.1-515-g78d2372 and it may or may not behave the same way as 1.8.2.1 depending on what trait you are interested in. -- 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] rebase-am: fix regression with new cover-letter config
Felipe Contreras felipe.contre...@gmail.com writes: If you have a cover-letter configuration set to anything other than 'false', 'git format-patch' might generate a cover letter, and 'git am' doesn't seem to like that. Ideally 'git am' should skip the cover-letter, but for now lets just fix the regression. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- This is a follow-up to the fc/send-email-annotate topic, right? You are mean to say fix regression, which gave me a small heart attack ;-). I was worried if we had already merged it to 'next'. As I already wrote in the recent What's cooking, the series looks good to me. I am inclined to say that we should merge it (together with this update) to 'next'. Thanks for catching this before breaking the real world users. git-rebase--am.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index 97f31dc..f84854f 100644 --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -31,8 +31,8 @@ else rm -f $GIT_DIR/rebased-patches git format-patch -k --stdout --full-index --ignore-if-in-upstream \ - --src-prefix=a/ --dst-prefix=b/ \ - --no-renames $root_flag $revisions $GIT_DIR/rebased-patches + --src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \ + $root_flag $revisions $GIT_DIR/rebased-patches ret=$? if test 0 != $ret -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
15 git rebase --stash, git pull --rebase --stash It seems that Ramkumar Ramachandra is working on this in his [PATCH v2 0/3] Introduce pull.autostash series Ping Yin On Mon, Apr 15, 2013 at 4:04 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Hi, Like the years before, I'm going to offer my students a 1 month project (end of May - end of June) where they can contribute to a free software, in particular Git. Students are free to pick the feature they want, but I maintain a list of small project ideas on the wiki to help them: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas fell free to edit and comment. Students will anyway have to discuss here before starting to code anything non-trivial. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [PATCH v2] branch: colour upstream branches
On Sun, Apr 14, 2013 at 8:52 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote: +if (want_color(branch_use_color)) +snprintf(fancy, sizeof(fancy), %s%s%s, + branch_get_color(BRANCH_COLOR_UPSTREAM), +ref, branch_get_color(BRANCH_COLOR_RESET)); +else +strncpy(fancy, ref, sizeof(fancy)); $ man strncpy | grep -C1 Warning The strncpy() function is similar, except that at most n bytes of src are copied. Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated. Is there a reason to avoid strbuf_addf() here? We are talking about output for human consumption and not performance critical code, no? It's not about the performance, it's about the amount of code. But I already agreed to do this. -- Felipe Contreras -- 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 v3] branch: colour upstream branches
Otherwise when using 'git branch -vv' it's hard to see them among so
much output.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
This time with strbuf.
Documentation/config.txt | 3 ++-
builtin/branch.c | 38 ++
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bc750d5..302533f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -794,7 +794,8 @@ color.branch::
color.branch.slot::
Use customized color for branch coloration. `slot` is one of
`current` (the current branch), `local` (a local branch),
- `remote` (a remote-tracking branch in refs/remotes/), `plain` (other
+ `remote` (a remote-tracking branch in refs/remotes/),
+ `upstream` (upstream tracking branch), `plain` (other
refs).
+
The value for these configuration variables is a list of colors (at most
diff --git a/builtin/branch.c b/builtin/branch.c
index 00d17d2..26e9322 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -40,13 +40,15 @@ static char branch_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RED, /* REMOTE */
GIT_COLOR_NORMAL, /* LOCAL */
GIT_COLOR_GREEN,/* CURRENT */
+ GIT_COLOR_BLUE, /* UPSTREAM */
};
enum color_branch {
BRANCH_COLOR_RESET = 0,
BRANCH_COLOR_PLAIN = 1,
BRANCH_COLOR_REMOTE = 2,
BRANCH_COLOR_LOCAL = 3,
- BRANCH_COLOR_CURRENT = 4
+ BRANCH_COLOR_CURRENT = 4,
+ BRANCH_COLOR_UPSTREAM = 5,
};
static enum merge_filter {
@@ -71,6 +73,8 @@ static int parse_branch_color_slot(const char *var, int ofs)
return BRANCH_COLOR_LOCAL;
if (!strcasecmp(var+ofs, current))
return BRANCH_COLOR_CURRENT;
+ if (!strcasecmp(var+ofs, upstream))
+ return BRANCH_COLOR_UPSTREAM;
return -1;
}
@@ -417,36 +421,54 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
int ours, theirs;
char *ref = NULL;
struct branch *branch = branch_get(branch_name);
+ struct strbuf fancy;
+
+ strbuf_init(fancy, 0);
if (!stat_tracking_info(branch, ours, theirs)) {
if (branch branch-merge branch-merge[0]-dst
- show_upstream_ref)
- strbuf_addf(stat, [%s] ,
- shorten_unambiguous_ref(branch-merge[0]-dst, 0));
+ show_upstream_ref) {
+ ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
+ if (want_color(branch_use_color))
+ strbuf_addf(stat, [%s%s%s] ,
+
branch_get_color(BRANCH_COLOR_UPSTREAM),
+ ref,
branch_get_color(BRANCH_COLOR_RESET));
+ else
+ strbuf_addf(stat, [%s] , ref);
+ }
return;
}
- if (show_upstream_ref)
+ if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
+ if (want_color(branch_use_color))
+ strbuf_addf(fancy, %s%s%s,
+ branch_get_color(BRANCH_COLOR_UPSTREAM),
+ ref,
branch_get_color(BRANCH_COLOR_RESET));
+ else
+ strbuf_addstr(fancy, ref);
+ }
+
if (!ours) {
if (ref)
- strbuf_addf(stat, _([%s: behind %d]), ref, theirs);
+ strbuf_addf(stat, _([%s: behind %d]), fancy.buf,
theirs);
else
strbuf_addf(stat, _([behind %d]), theirs);
} else if (!theirs) {
if (ref)
- strbuf_addf(stat, _([%s: ahead %d]), ref, ours);
+ strbuf_addf(stat, _([%s: ahead %d]), fancy.buf, ours);
else
strbuf_addf(stat, _([ahead %d]), ours);
} else {
if (ref)
strbuf_addf(stat, _([%s: ahead %d, behind %d]),
- ref, ours, theirs);
+ fancy.buf, ours, theirs);
else
strbuf_addf(stat, _([ahead %d, behind %d]),
ours, theirs);
}
+ strbuf_release(fancy);
strbuf_addch(stat, ' ');
free(ref);
}
--
1.8.2.1.643.ge3cc75d
--
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: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
Junio C Hamano gits...@pobox.com writes: If the envisioned use of this is to use it as a building block of something else that is user-facing (e.g. the user says git add, and before the command finishes, somewhere we internally run git clone), then would it be possible that you are better off running that clone with --separate-git-dir and let it make the gitfile for you? As you may have already guessed, in principle I am all for teaching git add not just to add a submodule itself (which we already do) but also to record information about the submodule, without having to delegate it to git submodule. git submodule add was meant as an interim measure until we figure out what kind of metainformation is necessary, and doing things in git add has always been a longer term goal. There are two ways to add a submodule to a superproject. You may bring an existing project with git clone inside the working tree of a superproject (which I am guessing is the use case that inspired this patch), but it will leave the git dir of the submodule embedded in its working tree. You could continue git clone and then teach git add (or git submodule add) to relocate the embedded git directory from the submodule working tree, you could git clone with separate-git-dir from the beginning, or you could extend git add, perhaps git add --url=git://up.stre.am/repository [--name=name] sub/mod/ule and do that git clone --separate-git-dir internally (which will mean that the end user will not run git clone). Another way ti add a submodule is to run git init to originate a new project inside the working tree of a superproject. The resulting submodule working tree will have the embedded git dir, and again git add (or git submodule add) could notice and relocate it, but if the extended git add wants to help that use case as well, I think it is the matter of running git init --separate-git-dir, just like add by cloning from elsewhere can do the same with the flag to git clone. -- 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] rebase-am: fix regression with new cover-letter config
Felipe Contreras felipe.contre...@gmail.com writes: You are mean to say fix regression, which gave me a small heart attack ;-). I was worried if we had already merged it to 'next'. As I already wrote in the recent What's cooking, the series looks good to me. I am inclined to say that we should merge it (together with this update) to 'next'. Yeah, after thinking about it, it's not even really a regression, because people don't have format.coverletter=auto in their configs (yet), so the bug can't can possibly affect them. Here is what I tentatively queued. rebase-am: explicitly disable cover-letter If the user has a cover-letter configuration set to anything other than 'false', 'git format-patch' may generate a cover letter, which has no place in format-patch | am pipeline. The internal invocatoin of format-patch must explicitly override the configuration from the command line, just like --src-prefix and other options already do. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.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 v3] branch: colour upstream branches
Felipe Contreras felipe.contre...@gmail.com writes:
Otherwise when using 'git branch -vv' it's hard to see them among so
much output.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
This time with strbuf.
Documentation/config.txt | 3 ++-
builtin/branch.c | 38 ++
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bc750d5..302533f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -794,7 +794,8 @@ color.branch::
color.branch.slot::
Use customized color for branch coloration. `slot` is one of
`current` (the current branch), `local` (a local branch),
- `remote` (a remote-tracking branch in refs/remotes/), `plain` (other
+ `remote` (a remote-tracking branch in refs/remotes/),
+ `upstream` (upstream tracking branch), `plain` (other
refs).
+
The value for these configuration variables is a list of colors (at most
diff --git a/builtin/branch.c b/builtin/branch.c
index 00d17d2..26e9322 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -40,13 +40,15 @@ static char branch_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RED, /* REMOTE */
GIT_COLOR_NORMAL, /* LOCAL */
GIT_COLOR_GREEN,/* CURRENT */
+ GIT_COLOR_BLUE, /* UPSTREAM */
};
enum color_branch {
BRANCH_COLOR_RESET = 0,
BRANCH_COLOR_PLAIN = 1,
BRANCH_COLOR_REMOTE = 2,
BRANCH_COLOR_LOCAL = 3,
- BRANCH_COLOR_CURRENT = 4
+ BRANCH_COLOR_CURRENT = 4,
+ BRANCH_COLOR_UPSTREAM = 5,
};
We had to fix these trailing comma in enums to help other peoples'
compilers a few times. Yes, they happily take the trailing comma at
the end of array values above. Don't complain to me ;-)
@@ -417,36 +421,54 @@ static void fill_tracking_info(struct strbuf *stat,
const char *branch_name,
int ours, theirs;
char *ref = NULL;
struct branch *branch = branch_get(branch_name);
+ struct strbuf fancy;
+
+ strbuf_init(fancy, 0);
if (!stat_tracking_info(branch, ours, theirs)) {
if (branch branch-merge branch-merge[0]-dst
- show_upstream_ref)
- strbuf_addf(stat, [%s] ,
- shorten_unambiguous_ref(branch-merge[0]-dst, 0));
+ show_upstream_ref) {
+ ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
+ if (want_color(branch_use_color))
+ strbuf_addf(stat, [%s%s%s] ,
+
branch_get_color(BRANCH_COLOR_UPSTREAM),
+ ref,
branch_get_color(BRANCH_COLOR_RESET));
+ else
+ strbuf_addf(stat, [%s] , ref);
+ }
return;
}
- if (show_upstream_ref)
+ if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
+ if (want_color(branch_use_color))
+ strbuf_addf(fancy, %s%s%s,
+ branch_get_color(BRANCH_COLOR_UPSTREAM),
+ ref,
branch_get_color(BRANCH_COLOR_RESET));
+ else
+ strbuf_addstr(fancy, ref);
+ }
+
if (!ours) {
if (ref)
- strbuf_addf(stat, _([%s: behind %d]), ref, theirs);
+ strbuf_addf(stat, _([%s: behind %d]), fancy.buf,
theirs);
else
strbuf_addf(stat, _([behind %d]), theirs);
} else if (!theirs) {
if (ref)
- strbuf_addf(stat, _([%s: ahead %d]), ref, ours);
+ strbuf_addf(stat, _([%s: ahead %d]), fancy.buf, ours);
else
strbuf_addf(stat, _([ahead %d]), ours);
} else {
if (ref)
strbuf_addf(stat, _([%s: ahead %d, behind %d]),
- ref, ours, theirs);
+ fancy.buf, ours, theirs);
else
strbuf_addf(stat, _([ahead %d, behind %d]),
ours, theirs);
}
+ strbuf_release(fancy);
strbuf_addch(stat, ' ');
free(ref);
}
Fairly straight-forward and looks good.
--
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: [RFC/PATCH] push: introduce implicit push
Ramkumar Ramachandra artag...@gmail.com writes: ... In my proposal, the precedence order branch.name.pushremote, remote.pushdefault, branch.name.remote, remote.default, origin, remains the same: we just want to change which branch that name refers to. That changing the meaning of name in the middle, and doing so will be confusing to the users, is exactly the issue, isn't it? In my opinion, it is a much more subtle change than the entirely new precedence order that you're inventing. Adding -- has never been my itch. I just brought it up out of thin air as a possible alternative that is less confusing. If it does not work well, we do not have to add it, but it is dubious that we would want to add something that is even more confusing. Just like Peff, I am sympathetic to people who want to omit where to and have Git automatically make a guess, and would be happy if we can find a reasonable solution to that problem. But I am not convinced what we discussed in these threads are good solutions. At least not yet. -- 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] bisect: Store first bad commit as comment in log file
From: Torstein Hegge he...@resisty.net
Subject: [PATCH] bisect: Store first bad commit as comment in log file
Date: Sat, 13 Apr 2013 17:22:57 +0200
When bisect successfully finds a single revision, the first bad commit
should be shown to human readers of 'git bisect log'.
This resolves the apparent disconnect between the bisection result and
the log when a bug reporter says I know that the first bad commit is
$rev, as you can see from $(git bisect log).
I agree that it's a good idea to do that.
I wonder if we should also write something into the bisect log if for
example the bisection stopped because there are only 'skip'ped commits
left to test. But maybe this could go into another patch after this
one.
Signed-off-by: Torstein Hegge he...@resisty.net
---
I don't know how useful the added test is, I didn't find any existing
tests that looks at the comment parts of bisect log.
Thanks for adding a test. It's always appreciated.
git-bisect.sh |8 +++-
t/t6030-bisect-porcelain.sh | 18 ++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 99efbe8..c58eea7 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -311,7 +311,13 @@ bisect_next() {
res=$?
# Check if we should exit because bisection is finished
- test $res -eq 10 exit 0
+ if test $res -eq 10
+ then
+ bad_rev=$(git show-ref --hash --verify refs/bisect/bad)
I had a look to make sure that refs/bisect/bad always refered to the
first bad commit at this point, and it is true indeed.
Maybe you could have used git rev-parse --verify instead of git
show-ref --hash --verify. It looks simpler to me.
And maybe, just in case, you could have added: || die $(gettext Bad rev:
refs/bisect/bad)
Otherwise this patch looks good to me.
+ bad_commit=$(git show-branch $bad_rev)
+ echo # first bad commit: $bad_commit $GIT_DIR/BISECT_LOG
+ exit 0
+ fi
Thanks,
Christian.
--
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: State of CVS-to-git conversion tools (Was: Re: cvsps: bad usage: invalid argument --norc)
On 04/14/2013 01:33 PM, Eric S. Raymond wrote: [...] I wish I could point you at a convertor I really trust. I can't. There is a third tool, cvs2git (based on the analyzer from cvs2svn) that I don't maintain, which has problems of its own. ^ Again I request that instead of spreading non-specific FUD about cvs2git, you describe concrete problems so that I can improve the tool. So far about the only problems that you have mentioned that have not been addressed have been stylistic trivia like that you object that cvs2git writes its outputs by pass, to two separate files, rather than writing all of its output to stdout, and that you are bothered that it names its temporary directory cvs2svn-tmp rather than cvs2git-tmp. I would like to fix any conversion deficiencies you can find. I stand behind this tool and think it is the best one out there for extracting history from CVS. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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 3/3] pull: introduce --[no-]autostash and pull.autostash
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, executing a 'git pull' on a dirty worktree gives the
following annoying message:
s/annoying//;
In general, avoid forcing your value judgement to readers when you
do not have to. Instead, you can just highlight the source of your
annoyance and let them naturally feel the annoyance themselves,
perhaps like this:
When the user runs git pull with local changes in the
working tree that interfere with the merge (or any change if
the user is using --rebase), the user is told that the merge
or rebase cannot be done _after_ the command spends time to
download necessary objects.
The user can then decide not to perform the pull and finish
what he was in the middle of doing (e.g. by git checkout -b
topic and then finishing the work), before coming back to
the branch and running git pull again, or git stash the
work in progress, run git pull and then git stash pop.
Introduce a new flag git pull --autostash to perform the
latter automatically. Also add pull.autostash configuration
to do so without giving the command line flag, whose effect
can be overriden by the --no-autostash option.
While I understand where this wish comes from, I am not sure if this
is generally a good idea, or if we are solving a wrong problem.
Saved working directory and index state WIP on master: 8ea73ed baz
HEAD is now at 8ea73ed baz
... # The merge/rebase process
I think there is one step missing after The merge/rebase process
above, which is
... # The 'stash pop' process
Dropped refs/stash@{0} (83f47fbfb07a741817633f9191dc4a1530f79249)
If the pull-merge were something that would induce the annoyance
that triggered this topic, by definition, the local change overlaps
with the merge, and this internal stash pop will touch the paths
the merge touched and it is likely not result in Dropped but leave
further conflicts to be resolved.
In the end, simple cases (the canonical example being Linus keeping
a local change to Name = Unicycling Gorilla in his Makefile while
running dozens of git pull every day) would not be helped with
this feature very much because there is rarely overlap, while in a
complex case the user really needs help to save away his WIP, the
user is forced to resolve the conflict immediately upon the failed
stash pop at the end of git pull. If the conflict turns out to
be something the user would not want to resolve at that moment, the
user needs to know the way out, something like:
git reset --hard;# go back to the result of pull
git checkout -b wip ORIG_HEAD ;# start from before the pull
git stash pop ;# recover his wip
... perhaps work a bit more ...
git commit -a -m wip;# save it away for safety
git checkout - ;# result of pull
so that he can come back tomorrow, check out wip branch, and
decide what to do.
The --autosquash option (or not adding either the configuration or
the option) would encourage the user to think about the nature of
WIP he has in the working tree before running git pull. Is it a
too complex beast that may interfere with what others are doing, or
is it a trivial change that he can stash away and pop it back? If
the former, he will be far better off doing checkout -b, keep
working until the local change gets into somewhat a better shape and
commit, before pulling into the original branch. If the latter,
he is better off doing either
- git pull, after finding it conflicts, run git stash, git
merge FETCH_HEAD and git stash pop; or
- git pull --autostash.
And not having --autostash would mean he would do the former, and
will do stash only when it matters. --autostash is a good to
neutral addition in that sense. But I suspect that pull.autostash
configuration is not a good addition because it encourages a bad,
pain-inducing workflow. In simple cases it may not hurt, but when
local changes are complex, it would actively hurt than not having it,
and the configuration robs the incentive to choose.
The equation is somewhat different for pull-rebase, as rebase
insists you to start from a clean working tree, so download and
then stop annoyance feels bigger. I have a suspicion that
loosening that may be a more productive fix to the real problem.
+stash_required () {
+ ! (git diff-files --quiet --ignore-submodules
+ git diff-index --quiet --cached HEAD --ignore-submodules)
+}
require_clean_work_tree refreshes the index before running
diff-files to make this check safe, but you do not do that here. Do
you know the index has been refreshed when this is called?
Even though this is mere two-line logic, the duplication of the
logic look a bit wasteful. Is it too hard to teach dry-run, quiet
mode to require_clean_work_tree helper? Then the auto-stash
codepath can
