* [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"
From: Jeff King @ 2016-10-20 6:24 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
When we default to ".git" without having done any kind of
repository setup, the results quite often do what the user
expects. But this has also historically been the cause of
some poorly behaved corner cases. These cases can be hard to
find, because they happen at the conjunction of two
relatively rare circumstances:
1. We are running some code which assumes there's a
repository present, but there isn't necessarily one
(e.g., low-level diff code triggered by "git diff
--no-index" might try to look at some repository data).
2. We have an unusual setup, like being in a subdirectory
of the working tree, or we have a .git file (rather
than a directory), or we are running a tool like "init"
or "clone" which may operate on a repository in a
different directory.
Our test scripts often cover (1), but miss doing (2) at the
same time, and so the fallback appears to work but has
lurking bugs. We can flush these bugs out by refusing to do
the fallback entirely., This makes potential problems a lot
more obvious by complaining even for "usual" setups.
This passes the test suite (after the adjustments in the
previous patches), but there's a risk of regression for any
cases where the fallback usually works fine but the code
isn't exercised by the test suite. So by itself, this
commit is a potential step backward, but lets us take two
steps forward once we've identified and fixed any such
instances.
Signed-off-by: Jeff King <peff@peff.net>
---
environment.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/environment.c b/environment.c
index cd5aa57..b1743e6 100644
--- a/environment.c
+++ b/environment.c
@@ -164,8 +164,11 @@ static void setup_git_env(void)
const char *replace_ref_base;
git_dir = getenv(GIT_DIR_ENVIRONMENT);
- if (!git_dir)
+ if (!git_dir) {
+ if (!startup_info->have_repository)
+ die("BUG: setup_git_env called without repository");
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
+ }
gitfile = read_gitfile(git_dir);
git_dir = xstrdup(gitfile ? gitfile : git_dir);
if (get_common_dir(&sb, git_dir))
--
2.10.1.619.g16351a7
^ permalink raw reply related
* (no subject)
From: Jordan DE GEA @ 2016-10-20 6:22 UTC (permalink / raw)
To: git
unsubscribe alsa-devel
^ permalink raw reply
* [PATCH 6/7] diff: handle sha1 abbreviations outside of repository
From: Jeff King @ 2016-10-20 6:21 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
When generating diffs outside a repository (e.g., with "diff
--no-index"), we may write abbreviated sha1s as part of
"--raw" output or the "index" lines of "--patch" output.
Since we have no object database, we never find any
collisions, and these sha1s get whatever static abbreviation
length is configured (typically 7).
However, we do blindly look in ".git/objects" to see if any
objects exist, even though we know we are not in a
repository. This is usually harmless because such a
directory is unlikely to exist, but could be wrong in rare
circumstances.
Let's instead notice when we are not in a repository and
behave as if the object database is empty (i.e., just use
the default abbrev length). It would perhaps make sense to
be conservative and show full sha1s in that case, but
showing the default abbreviation is what we've always done
(and is certainly less ugly).
Note that this does mean that:
cd /not/a/repo
GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ...
used to look for collisions in /some/real/objdir but now
does not. This could be considered either a bugfix (we do
not look at objects if we have no repository) or a
regression, but it seems unlikely that anybody would care
much either way.
Signed-off-by: Jeff King <peff@peff.net>
---
diff.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 8f0f309..ef11001 100644
--- a/diff.c
+++ b/diff.c
@@ -3049,6 +3049,19 @@ static int similarity_index(struct diff_filepair *p)
return p->score * 100 / MAX_SCORE;
}
+static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
+{
+ if (startup_info->have_repository)
+ return find_unique_abbrev(oid->hash, abbrev);
+ else {
+ char *hex = oid_to_hex(oid);
+ if (abbrev < 0 || abbrev > GIT_SHA1_HEXSZ)
+ die("BUG: oid abbreviation out of range: %d", abbrev);
+ hex[abbrev] = '\0';
+ return hex;
+ }
+}
+
static void fill_metainfo(struct strbuf *msg,
const char *name,
const char *other,
@@ -3107,9 +3120,9 @@ static void fill_metainfo(struct strbuf *msg,
(!fill_mmfile(&mf, two) && diff_filespec_is_binary(two)))
abbrev = 40;
}
- strbuf_addf(msg, "%s%sindex %s..", line_prefix, set,
- find_unique_abbrev(one->oid.hash, abbrev));
- strbuf_add_unique_abbrev(msg, two->oid.hash, abbrev);
+ strbuf_addf(msg, "%s%sindex %s..%s", line_prefix, set,
+ diff_abbrev_oid(&one->oid, abbrev),
+ diff_abbrev_oid(&two->oid, abbrev));
if (one->mode == two->mode)
strbuf_addf(msg, " %06o", one->mode);
strbuf_addf(msg, "%s\n", reset);
@@ -4144,7 +4157,7 @@ const char *diff_aligned_abbrev(const struct object_id *oid, int len)
if (len == GIT_SHA1_HEXSZ)
return oid_to_hex(oid);
- abbrev = find_unique_abbrev(oid->hash, len);
+ abbrev = diff_abbrev_oid(oid, len);
abblen = strlen(abbrev);
/*
--
2.10.1.619.g16351a7
^ permalink raw reply related
* [PATCH 5/7] diff_aligned_abbrev: use "struct oid"
From: Jeff King @ 2016-10-20 6:20 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
Since we're modifying this function anyway, it's a good time
to update it to the more modern "struct oid". We can also
drop some of the magic numbers in favor of GIT_SHA1_HEXSZ,
along with some descriptive comments.
Signed-off-by: Jeff King <peff@peff.net>
---
combine-diff.c | 4 ++--
diff.c | 20 +++++++++++---------
diff.h | 2 +-
3 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index b36c2d1..59501db 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1203,9 +1203,9 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re
/* Show sha1's */
for (i = 0; i < num_parent; i++)
- printf(" %s", diff_aligned_abbrev(p->parent[i].oid.hash,
+ printf(" %s", diff_aligned_abbrev(&p->parent[i].oid,
opt->abbrev));
- printf(" %s ", diff_aligned_abbrev(p->oid.hash, opt->abbrev));
+ printf(" %s ", diff_aligned_abbrev(&p->oid, opt->abbrev));
}
if (opt->output_format & (DIFF_FORMAT_RAW | DIFF_FORMAT_NAME_STATUS)) {
diff --git a/diff.c b/diff.c
index 2d8b74b..8f0f309 100644
--- a/diff.c
+++ b/diff.c
@@ -4136,14 +4136,15 @@ void diff_free_filepair(struct diff_filepair *p)
free(p);
}
-const char *diff_aligned_abbrev(const unsigned char *sha1, int len)
+const char *diff_aligned_abbrev(const struct object_id *oid, int len)
{
int abblen;
const char *abbrev;
- if (len == 40)
- return sha1_to_hex(sha1);
- abbrev = find_unique_abbrev(sha1, len);
+ if (len == GIT_SHA1_HEXSZ)
+ return oid_to_hex(oid);
+
+ abbrev = find_unique_abbrev(oid->hash, len);
abblen = strlen(abbrev);
/*
@@ -4165,15 +4166,16 @@ const char *diff_aligned_abbrev(const unsigned char *sha1, int len)
* the automatic sizing is supposed to give abblen that ensures
* uniqueness across all objects (statistically speaking).
*/
- if (abblen < 37) {
- static char hex[41];
+ if (abblen < GIT_SHA1_HEXSZ - 3) {
+ static char hex[GIT_SHA1_HEXSZ + 1];
if (len < abblen && abblen <= len + 2)
xsnprintf(hex, sizeof(hex), "%s%.*s", abbrev, len+3-abblen, "..");
else
xsnprintf(hex, sizeof(hex), "%s...", abbrev);
return hex;
}
- return sha1_to_hex(sha1);
+
+ return oid_to_hex(oid);
}
static void diff_flush_raw(struct diff_filepair *p, struct diff_options *opt)
@@ -4184,9 +4186,9 @@ static void diff_flush_raw(struct diff_filepair *p, struct diff_options *opt)
fprintf(opt->file, "%s", diff_line_prefix(opt));
if (!(opt->output_format & DIFF_FORMAT_NAME_STATUS)) {
fprintf(opt->file, ":%06o %06o %s ", p->one->mode, p->two->mode,
- diff_aligned_abbrev(p->one->oid.hash, opt->abbrev));
+ diff_aligned_abbrev(&p->one->oid, opt->abbrev));
fprintf(opt->file, "%s ",
- diff_aligned_abbrev(p->two->oid.hash, opt->abbrev));
+ diff_aligned_abbrev(&p->two->oid, opt->abbrev));
}
if (p->score) {
fprintf(opt->file, "%c%03d%c", p->status, similarity_index(p),
diff --git a/diff.h b/diff.h
index f2b04b6..01afc70 100644
--- a/diff.h
+++ b/diff.h
@@ -344,7 +344,7 @@ extern void diff_warn_rename_limit(const char *varname, int needed, int degraded
* This is different from find_unique_abbrev() in that
* it stuffs the result with dots for alignment.
*/
-extern const char *diff_aligned_abbrev(const unsigned char *sha1, int);
+extern const char *diff_aligned_abbrev(const struct object_id *sha1, int);
/* do not report anything on removed paths */
#define DIFF_SILENT_ON_REMOVED 01
--
2.10.1.619.g16351a7
^ permalink raw reply related
* [PATCH 4/7] diff_unique_abbrev: rename to diff_aligned_abbrev
From: Jeff King @ 2016-10-20 6:19 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
The word "align" describes how the function actually differs
from find_unique_abbrev, and will make it less confusing
when we add more diff-specific abbrevation functions that do
not do this alignment.
Since this is a globally available function, let's also move
its descriptive comment to the header file, where we
typically document function interfaces.
Signed-off-by: Jeff King <peff@peff.net>
---
combine-diff.c | 6 +++---
diff.c | 10 +++-------
diff.h | 6 +++++-
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 8e2a577..b36c2d1 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1203,9 +1203,9 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re
/* Show sha1's */
for (i = 0; i < num_parent; i++)
- printf(" %s", diff_unique_abbrev(p->parent[i].oid.hash,
- opt->abbrev));
- printf(" %s ", diff_unique_abbrev(p->oid.hash, opt->abbrev));
+ printf(" %s", diff_aligned_abbrev(p->parent[i].oid.hash,
+ opt->abbrev));
+ printf(" %s ", diff_aligned_abbrev(p->oid.hash, opt->abbrev));
}
if (opt->output_format & (DIFF_FORMAT_RAW | DIFF_FORMAT_NAME_STATUS)) {
diff --git a/diff.c b/diff.c
index f5d6d7e..2d8b74b 100644
--- a/diff.c
+++ b/diff.c
@@ -4136,11 +4136,7 @@ void diff_free_filepair(struct diff_filepair *p)
free(p);
}
-/*
- * This is different from find_unique_abbrev() in that
- * it stuffs the result with dots for alignment.
- */
-const char *diff_unique_abbrev(const unsigned char *sha1, int len)
+const char *diff_aligned_abbrev(const unsigned char *sha1, int len)
{
int abblen;
const char *abbrev;
@@ -4188,9 +4184,9 @@ static void diff_flush_raw(struct diff_filepair *p, struct diff_options *opt)
fprintf(opt->file, "%s", diff_line_prefix(opt));
if (!(opt->output_format & DIFF_FORMAT_NAME_STATUS)) {
fprintf(opt->file, ":%06o %06o %s ", p->one->mode, p->two->mode,
- diff_unique_abbrev(p->one->oid.hash, opt->abbrev));
+ diff_aligned_abbrev(p->one->oid.hash, opt->abbrev));
fprintf(opt->file, "%s ",
- diff_unique_abbrev(p->two->oid.hash, opt->abbrev));
+ diff_aligned_abbrev(p->two->oid.hash, opt->abbrev));
}
if (p->score) {
fprintf(opt->file, "%c%03d%c", p->status, similarity_index(p),
diff --git a/diff.h b/diff.h
index 25ae60d..f2b04b6 100644
--- a/diff.h
+++ b/diff.h
@@ -340,7 +340,11 @@ extern void diff_warn_rename_limit(const char *varname, int needed, int degraded
#define DIFF_STATUS_FILTER_AON '*'
#define DIFF_STATUS_FILTER_BROKEN 'B'
-extern const char *diff_unique_abbrev(const unsigned char *, int);
+/*
+ * This is different from find_unique_abbrev() in that
+ * it stuffs the result with dots for alignment.
+ */
+extern const char *diff_aligned_abbrev(const unsigned char *sha1, int);
/* do not report anything on removed paths */
#define DIFF_SILENT_ON_REMOVED 01
--
2.10.1.619.g16351a7
^ permalink raw reply related
* [PATCH 3/7] find_unique_abbrev: use 4-buffer ring
From: Jeff King @ 2016-10-20 6:19 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
Some code paths want to format multiple abbreviated sha1s in
the same output line. Because we use a single static buffer
for our return value, they have to either break their output
into several calls or allocate their own arrays and use
find_unique_abbrev_r().
Intead, let's mimic sha1_to_hex() and use a ring of several
buffers, so that the return value stays valid through
multiple calls. This shortens some of the callers, and makes
it harder to for them to make a silly mistake.
Signed-off-by: Jeff King <peff@peff.net>
---
It feels a little funny in these callers to be moving from a reentrant
function to one that relies on a static buffer. But I feel like the
result is more obvious and less error-prone, and the "ring of buffers"
concept has proven useful and safe in sha1_to_hex().
My ulterior motive is that while refactoring one of the later patches, I
just assumed that we did have a ring of buffers, and introduced a subtle
bug.
builtin/merge.c | 11 +++++------
builtin/receive-pack.c | 16 ++++++----------
cache.h | 4 ++--
sha1_name.c | 4 +++-
4 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index a8b57c7..b65eeaa 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1374,12 +1374,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct commit *commit;
if (verbosity >= 0) {
- char from[GIT_SHA1_HEXSZ + 1], to[GIT_SHA1_HEXSZ + 1];
- find_unique_abbrev_r(from, head_commit->object.oid.hash,
- DEFAULT_ABBREV);
- find_unique_abbrev_r(to, remoteheads->item->object.oid.hash,
- DEFAULT_ABBREV);
- printf(_("Updating %s..%s\n"), from, to);
+ printf(_("Updating %s..%s\n"),
+ find_unique_abbrev(head_commit->object.oid.hash,
+ DEFAULT_ABBREV),
+ find_unique_abbrev(remoteheads->item->object.oid.hash,
+ DEFAULT_ABBREV));
}
strbuf_addstr(&msg, "Fast-forward");
if (have_message)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 04ed38e..680759d 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -1163,10 +1163,6 @@ static void check_aliased_update(struct command *cmd, struct string_list *list)
struct string_list_item *item;
struct command *dst_cmd;
unsigned char sha1[GIT_SHA1_RAWSZ];
- char cmd_oldh[GIT_SHA1_HEXSZ + 1],
- cmd_newh[GIT_SHA1_HEXSZ + 1],
- dst_oldh[GIT_SHA1_HEXSZ + 1],
- dst_newh[GIT_SHA1_HEXSZ + 1];
int flag;
strbuf_addf(&buf, "%s%s", get_git_namespace(), cmd->ref_name);
@@ -1197,14 +1193,14 @@ static void check_aliased_update(struct command *cmd, struct string_list *list)
dst_cmd->skip_update = 1;
- find_unique_abbrev_r(cmd_oldh, cmd->old_sha1, DEFAULT_ABBREV);
- find_unique_abbrev_r(cmd_newh, cmd->new_sha1, DEFAULT_ABBREV);
- find_unique_abbrev_r(dst_oldh, dst_cmd->old_sha1, DEFAULT_ABBREV);
- find_unique_abbrev_r(dst_newh, dst_cmd->new_sha1, DEFAULT_ABBREV);
rp_error("refusing inconsistent update between symref '%s' (%s..%s) and"
" its target '%s' (%s..%s)",
- cmd->ref_name, cmd_oldh, cmd_newh,
- dst_cmd->ref_name, dst_oldh, dst_newh);
+ cmd->ref_name,
+ find_unique_abbrev(cmd->old_sha1, DEFAULT_ABBREV),
+ find_unique_abbrev(cmd->new_sha1, DEFAULT_ABBREV),
+ dst_cmd->ref_name,
+ find_unique_abbrev(dst_cmd->old_sha1, DEFAULT_ABBREV),
+ find_unique_abbrev(dst_cmd->new_sha1, DEFAULT_ABBREV));
cmd->error_string = dst_cmd->error_string =
"inconsistent aliased update";
diff --git a/cache.h b/cache.h
index 05ecb88..6e06311 100644
--- a/cache.h
+++ b/cache.h
@@ -901,8 +901,8 @@ extern char *sha1_pack_index_name(const unsigned char *sha1);
* The result will be at least `len` characters long, and will be NUL
* terminated.
*
- * The non-`_r` version returns a static buffer which will be overwritten by
- * subsequent calls.
+ * The non-`_r` version returns a static buffer which remains valid until 4
+ * more calls to find_unique_abbrev are made.
*
* The `_r` variant writes to a buffer supplied by the caller, which must be at
* least `GIT_SHA1_HEXSZ + 1` bytes. The return value is the number of bytes
diff --git a/sha1_name.c b/sha1_name.c
index 4092836..36ce9b9 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -472,7 +472,9 @@ int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len)
const char *find_unique_abbrev(const unsigned char *sha1, int len)
{
- static char hex[GIT_SHA1_HEXSZ + 1];
+ static int bufno;
+ static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
+ char *hex = hexbuffer[3 & ++bufno];
find_unique_abbrev_r(hex, sha1, len);
return hex;
}
--
2.10.1.619.g16351a7
^ permalink raw reply related
* [PATCH 2/7] test-*-cache-tree: setup git dir
From: Jeff King @ 2016-10-20 6:16 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
These test helper programs access the index, but do not ever
setup_git_directory(), meaning we just blindly looked in
".git/index". This happened to work for the purposes of our
tests (which do not run from subdirectories, nor in
non-repos), but it's a bad habit.
Signed-off-by: Jeff King <peff@peff.net>
---
t/helper/test-dump-cache-tree.c | 1 +
t/helper/test-scrap-cache-tree.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/t/helper/test-dump-cache-tree.c b/t/helper/test-dump-cache-tree.c
index 44f3290..7af116d 100644
--- a/t/helper/test-dump-cache-tree.c
+++ b/t/helper/test-dump-cache-tree.c
@@ -58,6 +58,7 @@ int cmd_main(int ac, const char **av)
{
struct index_state istate;
struct cache_tree *another = cache_tree();
+ setup_git_directory();
if (read_cache() < 0)
die("unable to read index file");
istate = the_index;
diff --git a/t/helper/test-scrap-cache-tree.c b/t/helper/test-scrap-cache-tree.c
index 5b2fd09..27fe040 100644
--- a/t/helper/test-scrap-cache-tree.c
+++ b/t/helper/test-scrap-cache-tree.c
@@ -7,6 +7,7 @@ static struct lock_file index_lock;
int cmd_main(int ac, const char **av)
{
+ setup_git_directory();
hold_locked_index(&index_lock, 1);
if (read_cache() < 0)
die("unable to read index file");
--
2.10.1.619.g16351a7
^ permalink raw reply related
* [PATCH 1/7] read info/{attributes,exclude} only when in repository
From: Jeff King @ 2016-10-20 6:16 UTC (permalink / raw)
To: git
In-Reply-To: <20161020061536.6fqh23xb2nhxodpa@sigill.intra.peff.net>
The low-level attribute and gitignore code will try to look
in $GIT_DIR/info for any repo-level configuration files,
even if we have not actually determined that we are in a
repository (e.g., running "git grep --no-index"). In such a
case they end up looking for ".git/info/attributes", etc.
This is generally harmless, as such a file is unlikely to
exist outside of a repository, but it's still conceptually
the wrong thing to do.
Let's detect this situation explicitly and skip reading the
file (i.e., the same behavior we'd get if we were in a
repository and the file did not exist).
Signed-off-by: Jeff King <peff@peff.net>
---
attr.c | 6 +++++-
dir.c | 12 ++++++------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/attr.c b/attr.c
index eec5d7d..1fcf042 100644
--- a/attr.c
+++ b/attr.c
@@ -531,7 +531,11 @@ static void bootstrap_attr_stack(void)
debug_push(elem);
}
- elem = read_attr_from_file(git_path_info_attributes(), 1);
+ if (startup_info->have_repository)
+ elem = read_attr_from_file(git_path_info_attributes(), 1);
+ else
+ elem = NULL;
+
if (!elem)
elem = xcalloc(1, sizeof(*elem));
elem->origin = NULL;
diff --git a/dir.c b/dir.c
index 3bad1ad..6cde773 100644
--- a/dir.c
+++ b/dir.c
@@ -2195,8 +2195,6 @@ static GIT_PATH_FUNC(git_path_info_exclude, "info/exclude")
void setup_standard_excludes(struct dir_struct *dir)
{
- const char *path;
-
dir->exclude_per_dir = ".gitignore";
/* core.excludefile defaulting to $XDG_HOME/git/ignore */
@@ -2207,10 +2205,12 @@ void setup_standard_excludes(struct dir_struct *dir)
dir->untracked ? &dir->ss_excludes_file : NULL);
/* per repository user preference */
- path = git_path_info_exclude();
- if (!access_or_warn(path, R_OK, 0))
- add_excludes_from_file_1(dir, path,
- dir->untracked ? &dir->ss_info_exclude : NULL);
+ if (startup_info->have_repository) {
+ const char *path = git_path_info_exclude();
+ if (!access_or_warn(path, R_OK, 0))
+ add_excludes_from_file_1(dir, path,
+ dir->untracked ? &dir->ss_info_exclude : NULL);
+ }
}
int remove_path(const char *name)
--
2.10.1.619.g16351a7
^ permalink raw reply related
* [PATCH 0/7] stop blind fallback to ".git"
From: Jeff King @ 2016-10-20 6:15 UTC (permalink / raw)
To: git
This is a follow-on to the series in:
http://public-inbox.org/git/20160913032242.coyuhyhn6uklewuk@sigill.intra.peff.net/
That series avoided looking at ".git/config" when we haven't discovered
whether we are in a git repo. This takes that further and avoids ever
looking at ".git" as a fallback.
Patches 1-6 just teach various low-level code to detect and handle the
case when we are not in a configure repository (along with associated
cleanups). The final patch actually disallows this case (and the early
fixes were found by running the test suite with just the final patch).
I think this is a step in the right direction, both in fixing bugs, but
also in making our setup and repository-access code easier to reason
about. However, it does carry a risk of regression, if there are more
"fixes" that I missed. If we wanted to be really conservative, we could
hold back the 7th patch as a separate topic and cook it in "next" for an
extra release cycle or something. I'm not all that worried, though.
I built this on top of jc/diff-unique-abbrev-comments, as it refactors
that same function (and it didn't seem like a bad topic to be held
hostage by).
[1/7]: read info/{attributes,exclude} only when in repository
[2/7]: test-*-cache-tree: setup git dir
[3/7]: find_unique_abbrev: use 4-buffer ring
[4/7]: diff_unique_abbrev: rename to diff_aligned_abbrev
[5/7]: diff_aligned_abbrev: use "struct oid"
[6/7]: diff: handle sha1 abbreviations outside of repository
[7/7]: setup_git_env: avoid blind fall-back to ".git"
attr.c | 6 +++++-
builtin/merge.c | 11 +++++-----
builtin/receive-pack.c | 16 ++++++---------
cache.h | 4 ++--
combine-diff.c | 6 +++---
diff.c | 43 +++++++++++++++++++++++++---------------
diff.h | 6 +++++-
dir.c | 12 +++++------
environment.c | 5 ++++-
sha1_name.c | 4 +++-
t/helper/test-dump-cache-tree.c | 1 +
t/helper/test-scrap-cache-tree.c | 1 +
12 files changed, 68 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: tools for easily "uncommitting" parts of a patch I just commited?
From: Jacob Keller @ 2016-10-20 5:53 UTC (permalink / raw)
To: Jeff King; +Cc: Git mailing list
In-Reply-To: <20161020021323.tav5glu7xy4u7mtj@sigill.intra.peff.net>
On Wed, Oct 19, 2016 at 7:13 PM, Jeff King <peff@peff.net> wrote:
> I suspect both of those would complain about legitimate workflows.
>
> I dunno. I do not ever use "git commit <file>" myself. I almost
> invariably use one of "git add -p" (to review changes as I add them) or
> "git add -u" (when I know everything is in good shape, such as after
> merge resolution; I'll sometimes just "git commit -a", too).
>
> But it sounds like you want a third mode besides "--include" and
> "--only". Basically "commit what has been staged already, but restrict
> the commit to the paths I mentioned". Something like "--only-staged" or
> something. I do not think we would want to change the default from
> --only, but I could see a config option or something to select that
> behavior.
>
> I suspect nobody has really asked for such a thing before because
> separate staging and "git commit <file>" are really two distinct
> workflows. Your pain comes from mix-and-matching them.
>
> -Peff
No. What I want is to *prevent* mix-and-match from happening.
Basically, sometimes I use "git add -p" to stage changes. But if I
just did a "git diff" and I know all the changes that I want are in
the file I will just do "git commit <file>" or "git commit -a". The
problem is that sometimes I stage stuff, forget or just make a brain
mistake, and I go ahead and use "git commit <file>"
What I want is to make it so that when you run "git commit <file>"
that it is smart enough to go "hey! You already staged something from
that file in the index and it doesn't match what you're asking me to
commit now, so I'm going to stop and make sure you either reset, don't
run "git commit <file>" or run "git commit --only <file>" or similar.
It's just about making it so that if I happen to make the mistake in
the future it doesn't generate a commit and instead tells me that I
was being an idiot. I don't want this check to just be "you can't
stage with the index and then tell me to commit -a or commit <files>"
because I think that's too restrictive and might make people complain.
Essentially, I want the tool to become smart enough to make it so that
an obvious mistake is caught early before I have to undo things.
That being said, it's much less of a pain point now that I know I can
go "git reset -p HEAD^". It never occurred to me that git reset -p
would work that way, so I didn't even try it.
Thanks,
Jake
^ permalink raw reply
* Re: tools for easily "uncommitting" parts of a patch I just commited?
From: Jeff King @ 2016-10-20 2:13 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xprKV1Y7VShLR9uNgcpVdZk39xoTfkwiin1bVQYTe_TAA@mail.gmail.com>
On Wed, Oct 19, 2016 at 04:36:36PM -0700, Jacob Keller wrote:
> > # undo selectively
> > git reset -p HEAD^
> > git commit --amend
>
> AHA! I knew about git reset -p but I didn't know about git reset -p
> allowed passing a treeish. Does this reset modify my local files at
> all? I think it doesn't, right?
Correct. If you wanted to modify the working tree, too, use "git
checkout -p HEAD^".
> I still think it's worth while to add a check for git-commit which
> does something like check when we say "git commit <files>" and if the
> index already has those files marked as being changed, compare them
> with the current contents of the file as in the checkout and quick
> saying "please don't do that" so as to avoid the problem in the first
> place.
>
> A naive approach would just be "if index already has staged
> differences dont allow path selection" but that doesn't let me do
> something like "git add -p <files>" "git commit <other files>"
I suspect both of those would complain about legitimate workflows.
I dunno. I do not ever use "git commit <file>" myself. I almost
invariably use one of "git add -p" (to review changes as I add them) or
"git add -u" (when I know everything is in good shape, such as after
merge resolution; I'll sometimes just "git commit -a", too).
But it sounds like you want a third mode besides "--include" and
"--only". Basically "commit what has been staged already, but restrict
the commit to the paths I mentioned". Something like "--only-staged" or
something. I do not think we would want to change the default from
--only, but I could see a config option or something to select that
behavior.
I suspect nobody has really asked for such a thing before because
separate staging and "git commit <file>" are really two distinct
workflows. Your pain comes from mix-and-matching them.
-Peff
^ permalink raw reply
* Re: Problems with "git svn clone"
From: Eric Wong @ 2016-10-20 0:49 UTC (permalink / raw)
To: K Richard Pixley; +Cc: git
In-Reply-To: <dea3ab60-be6b-ebcc-1047-6ab28a25979b@zebra.com>
K Richard Pixley <cnp637@zebra.com> wrote:
> On 10/19/16 13:41 , Eric Wong wrote:
> >K Richard Pixley <cnp637@zebra.com> wrote:
> >>error: git-svn died of signal 11
> >>
> >>This seems awfully early and blatant for a core dump. What can I do to
> >>get this running?
> >Can you show us a backtrace? Thanks.
> There is none. I ran it in gdb and bt produced no results. Nor did the
> thread send bt command.
You probably need to install the debug package(s) for subversion.
In case it's a different bug, maybe the debug package for Perl, too.
> >>Initially discovered on git-2.7.4, (ubuntu-16.04), but also reproduced
> >>on freshly built top of tree git-2.10.1.445.g3cdd5d1.
> >This could be a problem with the SVN Perl libraries, and should
> >be fixed in newer versions (not sure if it's made it to distros,
> >yet):
> >
> >https://public-inbox.org/git/0BCA1E695085C645B9CD4A27DD59F6FA39AAD5CF@GBWGCEUHUBD0101.rbsres07.net/T/
> >
> >Seems like it is fixed in latest Debian, maybe it needs to trickle
> >into Ubuntu: https://bugs.debian.org/780246
> Thanks. I'll try adding that.
>
> Er... which debian would that be? testing? Or sid?
It looks like it (1.9.4-3) has trickled into stretch (testing)
by now:
https://packages.debian.org/src:subversion
^ permalink raw reply
* [ANNOUNCE] git-log-compact v1.0
From: Kyle J. McKay @ 2016-10-20 0:13 UTC (permalink / raw)
To: Git mailing list; +Cc: Jakub Narebski, Christian Couder
> NOTE: If you read the excellent Git Rev News [1], then you
> already know all about git-log-compact :)
The git-log-compact script provides a compact alternative to the
`git log --oneline` output that includes dates, times and author
and/or committer initials in a space efficient output format.
`git-log-compact` is intended to fill the gap between the single line
`--oneline` log output format and the multiline `--pretty=short` /
`--pretty=medium` output formats.
It is not strictly a one line per commit output format (but almost) and
while it only shows the title of each commit (like the short format) it
does include author and date information (similarly to the medium format)
except that timestamps are shown very compactly and author/committer
names are shown as initials.
This allows one to get a complete view of repository activity in a very
compact output format that can show many commits per screen full and is
fully compatible with the `--graph` option.
Simple example output from the Git repository:
git log-compact --graph --date-order --decorate --no-merges -n 5 v2.5.3
=== 2015-09-17 ===
* ee6ad5f4 12:16 jch (tag: v2.5.3) Git 2.5.3
=== 2015-09-09 ===
* b9d66899 14:22 js am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
| === 2015-09-04 ===
| * 27ea6f85 10:46 jch (tag: v2.5.2) Git 2.5.2
* 74b67638 10:36 jch (tag: v2.4.9) Git 2.4.9
..........
* ecad27cf 10:32 jch (tag: v2.3.9) Git 2.3.9
I have been wanting a compact one line output format that included dates,
times and initials for some time that is compatible with --graph, clearly
shows root commits and eliminates confusion over whether or not two adjacent
lines in the output are related as parent/child (the --show-linear-break
option does not work with --graph).
The git-log-compact utility is the result. Except for --notes, --pretty and
--format options (which would make the output a non-oneline format) any
other `git log` option may be used (including things like --cherry-mark,
--patch, --raw, --stat, --summary, --show-linear-break etc.),
There are a few new options specific to git-log-compact which are described
in the README and the `git-log-compact -h` output that can be used to alter
the dates, times and/or initials displayed.
The project page with detailed help and many screen shots is located at:
https://mackyle.github.io/git-log-compact/
Alternatively the repository can be cloned from:
https://github.com/mackyle/git-log-compact.git
Or the script file itself (which is really all you need) can be
viewed/fetched from:
https://github.com/mackyle/git-log-compact/blob/HEAD/git-log-compact
The git-log-compact script should work with any version of Git released
in the last several years.
--Kyle
[1] https://git.github.io/rev_news/2016/10/19/edition-20/
^ permalink raw reply
* Re: tools for easily "uncommitting" parts of a patch I just commited?
From: Jacob Keller @ 2016-10-19 23:36 UTC (permalink / raw)
To: Jeff King; +Cc: Git mailing list
In-Reply-To: <20161019224211.k4anavgqrhmunz6p@sigill.intra.peff.net>
On Wed, Oct 19, 2016 at 3:42 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote:
>
>> I recently (and in the past) had an issue where I was using git add
>> --interactive and accidentally did something like the following:
>>
>> # hack lots of randmo changes, then begin trying to commit then separately
>> git add -i
>> # set only the changes I want
>> # accidentally add <file> to the commit
>> $git commit -s <file>
>> # type up a long commit message
>> # notice that I committed everything
>>
>> At this point I'd like to be able to do something like:
>> $git unstage -i
>> # select each hunk to unstage
>
> I'd usually do one of:
>
> # undo selectively
> git reset -p HEAD^
> git commit --amend
AHA! I knew about git reset -p but I didn't know about git reset -p
allowed passing a treeish. Does this reset modify my local files at
all? I think it doesn't, right?
>
> or:
>
> # roll back the whole commit
> git reset HEAD
> # do it right this time
> git add -p
> # and steal the commit message from the previous attempt
> git commit -c HEAD@{1}
>
> -Peff
Also nice to know about git commit -c
Thanks a lot! This should save me some headaches.
I still think it's worth while to add a check for git-commit which
does something like check when we say "git commit <files>" and if the
index already has those files marked as being changed, compare them
with the current contents of the file as in the checkout and quick
saying "please don't do that" so as to avoid the problem in the first
place.
A naive approach would just be "if index already has staged
differences dont allow path selection" but that doesn't let me do
something like "git add -p <files>" "git commit <other files>"
We could even make it work so that "commit --only" doesn't run this so
that way people can easily override, and we can give suggestions for
how to fix it in the output of the message. I can't really think if a
reasonable objection to such a change. I'll try to code something up
in the next few days when I can find some spare time.
Regards,
Jake
^ permalink raw reply
* Re: [PATCH] submodules: update documentaion for submodule branches
From: Brandon Williams @ 2016-10-19 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sbeller
In-Reply-To: <xmqqzim0hsdz.fsf@gitster.mtv.corp.google.com>
On 10/19, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Brandon Williams <bmwill@google.com> writes:
> >
> >> Update the documentaion for the the special value `.` to indicate that
> >> it signifies that the tracking branch in the submodule should be the
> >> same as the current branch in the superproject.
> >
> > Thanks. Will typofix while extending with info supplied by Stefan
> > like so:
>
> Ugh. Should have proof-read before sending it out.
>
> > 4d7bc52b17 ("submodule update: allow '.' for branch value",
> > 2016-08-03) adopted from Gerrit a feature to set "." as a special
> > value of "submodule.<name>.branch" in .gitmodules file to indicate
> > that it signifies that the tracking branch in the submodule should
> > be the same as the current branch in the superproject.
>
> ... in .gitmodules file to indicate that the tracking branch in
> the submodule should be ...
>
> "to indicate that it signifies that" was overly redundant.
Sorry that seems to have stemed from my poor commit message.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH] submodules: update documentaion for submodule branches
From: Junio C Hamano @ 2016-10-19 22:43 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller
In-Reply-To: <xmqqmvi0j9rv.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Williams <bmwill@google.com> writes:
>
>> Update the documentaion for the the special value `.` to indicate that
>> it signifies that the tracking branch in the submodule should be the
>> same as the current branch in the superproject.
>
> Thanks. Will typofix while extending with info supplied by Stefan
> like so:
Ugh. Should have proof-read before sending it out.
> 4d7bc52b17 ("submodule update: allow '.' for branch value",
> 2016-08-03) adopted from Gerrit a feature to set "." as a special
> value of "submodule.<name>.branch" in .gitmodules file to indicate
> that it signifies that the tracking branch in the submodule should
> be the same as the current branch in the superproject.
... in .gitmodules file to indicate that the tracking branch in
the submodule should be ...
"to indicate that it signifies that" was overly redundant.
^ permalink raw reply
* Re: tools for easily "uncommitting" parts of a patch I just commited?
From: Jeff King @ 2016-10-19 22:42 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xqFOn4NSfZ2zpa_y1za3uHZrGGG3ktEtuOcvJLCrAYUhQ@mail.gmail.com>
On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote:
> I recently (and in the past) had an issue where I was using git add
> --interactive and accidentally did something like the following:
>
> # hack lots of randmo changes, then begin trying to commit then separately
> git add -i
> # set only the changes I want
> # accidentally add <file> to the commit
> $git commit -s <file>
> # type up a long commit message
> # notice that I committed everything
>
> At this point I'd like to be able to do something like:
> $git unstage -i
> # select each hunk to unstage
I'd usually do one of:
# undo selectively
git reset -p HEAD^
git commit --amend
or:
# roll back the whole commit
git reset HEAD
# do it right this time
git add -p
# and steal the commit message from the previous attempt
git commit -c HEAD@{1}
-Peff
^ permalink raw reply
* Re: [PATCH] rev-list: restore the NUL commit separator in --header mode
From: Junio C Hamano @ 2016-10-19 22:41 UTC (permalink / raw)
To: Dennis Kaarsemaker
Cc: git, jacob.e.keller, stefanbeller, peff, j6t, jacob.keller
In-Reply-To: <20161019210448.aupphybw5qar6mqe@hurricane>
Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:
> + touch expect &&
> + printf "\0" > expect &&
What's the point of that "touch", especially if you are going to
overwrite it immediately after?
> + git rev-list --header --max-count=1 HEAD | tail -n1 >actual &&
As "tail" is a tool for text files, it is likely unportable to use
"tail -n1" to grab the "last incomplete line that happens to contain
a single NUL".
> + test_cmp_bin expect actual
> +'
^ permalink raw reply
* Re: [PATCH] rev-list: restore the NUL commit separator in --header mode
From: Junio C Hamano @ 2016-10-19 22:39 UTC (permalink / raw)
To: Jacob Keller
Cc: Dennis Kaarsemaker, Git mailing list, Jacob Keller, Stefan Beller,
Jeff King, Johannes Sixt
In-Reply-To: <CA+P7+xogHOCbPV+rx7yrur85m=HX5ms9kGQYvTpQ7n2i7Hzuvw@mail.gmail.com>
Jacob Keller <jacob.keller@gmail.com> writes:
> Hi,
>
> On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker
> <dennis@kaarsemaker.net> wrote:
>> Commit 660e113 (graph: add support for --line-prefix on all graph-aware
>> output) changed the way commits were shown. Unfortunately this dropped
>> the NUL between commits in --header mode. Restore the NUL and add a test
>> for this feature.
>>
>
> Oops! Thanks for the bug fix.
>
>> Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
>> ---
>> builtin/rev-list.c | 4 ++++
>> t/t6000-rev-list-misc.sh | 7 +++++++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
>> index 8479f6e..cfa6a7d 100644
>> --- a/builtin/rev-list.c
>> +++ b/builtin/rev-list.c
>> @@ -157,6 +157,10 @@ static void show_commit(struct commit *commit, void *data)
>> if (revs->commit_format == CMIT_FMT_ONELINE)
>> putchar('\n');
>> }
>> + if (revs->commit_format == CMIT_FMT_RAW) {
>> + putchar(info->hdr_termination);
>> + }
>> +
>
> This seems right to me. My one concern is that we make sure we restore
> it for every case (in case it needs to be there for other formats?)
> I'm not entirely sure about whether other non-raw modes need this or
> not?
Right. The original didn't do anything special for CMIT_FMT_RAW,
and 660e113 did not remove anything special for CMIT_FMT_RAW, so it
isn't immediately obvious why this patch is sufficient.
Dennis, care to elaborate?
^ permalink raw reply
* Re: [regression] `make profile-install` fails in 2.10.1
From: Jeff King @ 2016-10-19 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Keromnes, git
In-Reply-To: <xmqqd1iwj7jf.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 19, 2016 at 03:30:44PM -0700, Junio C Hamano wrote:
> > Ouch. Thanks for a reminder. How about doing this for now?
>
> And the hack I used to quickly test it looks like this:
>
> $ cd t
> $ GIT_I_AM_INSANE=Yes sh ./t3700-add.sh
>
> We may want a more general
>
> GIT_OVERRIDE_PREREQ='!SANITY,!POSIXPERM,MINGW' make test
>
> or something like that, though.
I don't think I've ever wanted to do that myself, but I can see how it
might be useful (e.g., claiming we don't support symlinks is another
one).
I usually just try to recreate the actual environment (e.g., run the
tests as root, run them on a loopback case-insensitive fs, etc) as that
gives a more realistic recreation.
-Peff
^ permalink raw reply
* Re: [regression] `make profile-install` fails in 2.10.1
From: Jeff King @ 2016-10-19 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Keromnes, git
In-Reply-To: <xmqqh988j7oo.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 19, 2016 at 03:27:35PM -0700, Junio C Hamano wrote:
> Ouch. Thanks for a reminder. How about doing this for now?
> [...]
> test_expect_success 'git add --chmod=[+-]x changes index with already added file' '
> + rm -f foo3 xfoo3 &&
> echo foo >foo3 &&
Yeah, this makes sense. It does make me feel like the test should simply
be using xfoo27, or some name that is not otherwise used in the rest of
the script, but I don't mind doing the minimal thing.
-Peff
^ permalink raw reply
* Re: [regression] `make profile-install` fails in 2.10.1
From: Junio C Hamano @ 2016-10-19 22:30 UTC (permalink / raw)
To: Jeff King; +Cc: Jan Keromnes, git
In-Reply-To: <xmqqh988j7oo.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Ouch. Thanks for a reminder. How about doing this for now?
And the hack I used to quickly test it looks like this:
$ cd t
$ GIT_I_AM_INSANE=Yes sh ./t3700-add.sh
We may want a more general
GIT_OVERRIDE_PREREQ='!SANITY,!POSIXPERM,MINGW' make test
or something like that, though.
t/test-lib.sh | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0055ebba46..9c5bcd9d1d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -89,6 +89,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $("$PERL_PATH" -e '
UNZIP
PERF_
CURL_VERBOSE
+ I_AM_INSANE
));
my @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);
print join("\n", @vars);
@@ -1081,6 +1082,12 @@ test_lazy_prereq NOT_ROOT '
# containing directory doesn't have read or execute permissions.
test_lazy_prereq SANITY '
+
+ if test -n "$GIT_I_AM_INSANE"
+ then
+ return 1
+ fi &&
+
mkdir SANETESTD.1 SANETESTD.2 &&
chmod +w SANETESTD.1 SANETESTD.2 &&
^ permalink raw reply related
* Re: [regression] `make profile-install` fails in 2.10.1
From: Junio C Hamano @ 2016-10-19 22:27 UTC (permalink / raw)
To: Jeff King; +Cc: Jan Keromnes, git
In-Reply-To: <20161019210519.ubk5q54rrvbafch7@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I can't reproduce any problems with raciness there, but there is a known
> problem with running the script as root (which I guess you might be
> doing from your "make prefix=/usr" call). There's some discussion in
> http://public-inbox.org/git/20161010035756.38408-1-jeremyhu@apple.com/T/#u,
> but it looks like the patch stalled.
Ouch. Thanks for a reminder. How about doing this for now?
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 10 Oct 2016 10:41:51 -0700
Subject: [PATCH] t3700: fix broken test under !SANITY
An "add --chmod=+x" test recently added by 610d55af0f ("add: modify
already added files when --chmod is given", 2016-09-14) used "xfoo3"
as a test file. The paths xfoo[1-3] were used by earlier tests for
symbolic links but they were expected to have been removed by the
test script reached this new test.
The removal with "git reset --hard" however happened in tests that
are protected by POSIXPERM,SANITY prerequisites. Platforms and test
environments that lacked these would have seen xfoo3 as a leftover
symbolic link, pointing somewhere else, and chmod test would have
given a wrong result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t3700-add.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 924a266126..53c0cb6dea 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add --chmod=+x with symlinks' '
'
test_expect_success 'git add --chmod=[+-]x changes index with already added file' '
+ rm -f foo3 xfoo3 &&
echo foo >foo3 &&
git add foo3 &&
git add --chmod=+x foo3 &&
--
2.10.1-633-g7f0e449216
^ permalink raw reply related
* tools for easily "uncommitting" parts of a patch I just commited?
From: Jacob Keller @ 2016-10-19 22:26 UTC (permalink / raw)
To: Git mailing list
Hi,
I recently (and in the past) had an issue where I was using git add
--interactive and accidentally did something like the following:
# hack lots of randmo changes, then begin trying to commit then separately
git add -i
# set only the changes I want
# accidentally add <file> to the commit
$git commit -s <file>
# type up a long commit message
# notice that I committed everything
At this point I'd like to be able to do something like:
$git unstage -i
# select each hunk to unstage
and end up with a commit that only has what I originally wanted,
without having to re-write the commit message, nor having to do a lot
of weird things, or anything.
I can ofcourse use reset HEAD^ and lose my commit message, but then
I'd have to retype that out or copy paste it from somewhere else.
I ended up doing something like:
# save the current tree
$git rev-parse HEAD >savetree
# checkout the old files and re-write
$git checkout HEAD^ <file>
# update commit removing all changes from this file
$git commit --allow-empty --amend <file>
# now checkout the tree again to the contents of the saved tree
$git checkout $(cat savetree) <file>
# now add only the parts I wanted before
$git add -i
# finally amend the commit
$git commit --amend
That's a lot of steps and forces me to save my own file.
I thought of a few alternatives:
1. Create an advice setting which basically allows me to say "git,
please prevent me from staging files + an index if the files I marked
also conflict with paths already added to the index, maybe unless I
passed a force option"
or
2. somehow streamline the process of what I did above so I could just
do something like:
git commit --amend --set-tree=HEAD^
which would force the commit tree up one and avoid the double checkout
stuff, without actually changing my checked out copy at all
Then I'd be able to quickly re-add what I wanted.
3. somehow allow an unstage option.
So for the TL;DR; .. does anyone know of any tools which would help
automate the process so I could simply do
"git uncommit -i" and run a tool just like git add interactive or git add -p?
Thanks,
Jake
^ permalink raw reply
* Re: Problems with "git svn clone"
From: K Richard Pixley @ 2016-10-19 20:49 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20161019204118.GA5982@starla>
On 10/19/16 13:41 , Eric Wong wrote:
> K Richard Pixley <cnp637@zebra.com> wrote:
>> error: git-svn died of signal 11
>>
>> This seems awfully early and blatant for a core dump. What can I do to
>> get this running?
> Can you show us a backtrace? Thanks.
There is none. I ran it in gdb and bt produced no results. Nor did the
thread send bt command.
>> Initially discovered on git-2.7.4, (ubuntu-16.04), but also reproduced
>> on freshly built top of tree git-2.10.1.445.g3cdd5d1.
> This could be a problem with the SVN Perl libraries, and should
> be fixed in newer versions (not sure if it's made it to distros,
> yet):
>
> https://public-inbox.org/git/0BCA1E695085C645B9CD4A27DD59F6FA39AAD5CF@GBWGCEUHUBD0101.rbsres07.net/T/
>
> Seems like it is fixed in latest Debian, maybe it needs to trickle
> into Ubuntu: https://bugs.debian.org/780246
Thanks. I'll try adding that.
Er... which debian would that be? testing? Or sid?
--rich
________________________________
- CONFIDENTIAL-
This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
^ permalink raw reply
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