thomas sabo sale Modern Charm Necklaces for you

[ponkeylee]

This item of jewellery is the charm pendant. Charm necklaces have been around
for centuries, but today necklaces and charm necklaces come alive in the
charms of fashion-conscious designers like Thomas Sabo. * thomas sabo charms
  * are area of the new
generation of charm jewellery. Choosing Thomas Sabo charms to make a charm
pendant or necklace gives you a precisely personal joint of jewellery.


* thomas sabo uk   * are items
of jewellery with attached decorative necklaces or objects that signify
expressive things to the person. For example, a horse charm relates to the
person love of horses, the performance car to her wish to drive one in the
future, and a heart to signify her love for her partner. 



* http://www.genuinethomassaboringsshop.co.uk/  *



--
View this message in context: 
http://git.661346.n2.nabble.com/thomas-sabo-sale-Modern-Charm-Necklaces-for-you-tp7585250.html
Sent from the git mailing list archive at Nabble.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 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head

[Jeff King]

On Wed, May 08, 2013 at 02:12:29PM -0700, Junio C Hamano wrote:

> The original API read "checkout: moving from (.*) to ..." from the
> reflog of the HEAD, and returned the substring between "from" and
> "to", but there was no way, if the substring was a 40-hex string, to
> tell if we were on a detached HEAD at that commit object, or on a
> branch whose name happened to be the 40-hex string.
> 
> At this point, we cannot afford to change the format recorded in the
> reflog, so introduce a heuristics to see if the 40-hex matches the
> object name of the commit we are switching out of.  This will
> unfortunately mishandle this case:
> 
>   HEX=$(git rev-parse master)
>   git checkout -b $HEX master
>   git checkout master

I do not think I've ever seen a 40-hex branch name in practice, but I
would think a branch named after the commit tip would be a reasonably
common reason to have one, and would trigger this case.

Since the point of marking the detached HEAD is to turn off things like
"@{-1}@{u}", we would want to be generous and err on the side of
assuming it is a branch if it _might_ be one. IOW, shouldn't we treat
the above sequence as a branch, and therefore mishandle:

  git checkout $HEX^0 master
  git checkout master

by erroneously assuming that we moved to the branch $HEX?

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] msvc: Fix compilation errors caused by poll.h emulation

[Sven Strickroth]

Am 31.01.2013 19:28 schrieb Ramsay Jones:
> Commit 0f77dea9 ("mingw: move poll out of sys-folder", 24-10-2011), along
> with other commits in the 'ef/mingw-upload-archive' branch (see commit
> 7406aa20), effectively reintroduced the same problem addressed by commit
> 56fb3ddc ("msvc: Fix compilation errors in compat/win32/sys/poll.c",
> 04-12-2010).
> 
> In order to fix the compilation errors, we use the same solution adopted
> in that earlier commit. In particular, we set _WIN32_WINNT to 0x0502
> (which would target Windows Server 2003) prior to including the winsock2.h
> header file.

This change causes problems compiling with MSVC2012 for me. If I don't
define NO_SYS_POLL_H git-compat-util.h now tries to include 
which does not exist for MSVC and if I define NO_SYS_POLL_H
git-compat-util.h now tries to include  which also doesn't exist
for MSVC.

Including compat/poll into the includes path causes redefinition errors.

How have you tested this?

I think the check in git-compat-util.h has to be extended to only
include any poll.h if _MSC_VER is defined.

-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] transport-helper: add support for old:new refspec

[Felipe Contreras]

By using fast-export's new --refspec option.

Signed-off-by: Felipe Contreras 
---
 t/t5801-remote-helpers.sh |  2 +-
 transport-helper.c| 14 --
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index dbb02e2..d15f794 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -92,7 +92,7 @@ test_expect_success 'push new branch by name' '
compare_refs local HEAD server refs/heads/new-name
 '
 
-test_expect_failure 'push new branch with old:new refspec' '
+test_expect_success 'push new branch with old:new refspec' '
(cd local &&
 git push origin new-name:new-refspec
) &&
diff --git a/transport-helper.c b/transport-helper.c
index 835815f..b1fdd39 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -787,7 +787,7 @@ static int push_refs_with_export(struct transport 
*transport,
struct ref *ref;
struct child_process *helper, exporter;
struct helper_data *data = transport->data;
-   struct string_list revlist_args = STRING_LIST_INIT_NODUP;
+   struct string_list revlist_args = STRING_LIST_INIT_DUP;
struct strbuf buf = STRBUF_INIT;
 
helper = get_helper(transport);
@@ -814,14 +814,24 @@ static int push_refs_with_export(struct transport 
*transport,
die("remote-helpers do not support ref deletion");
}
 
-   if (ref->peer_ref)
+   if (ref->peer_ref) {
+   if (strcmp(ref->name, ref->peer_ref->name)) {
+   struct strbuf buf = STRBUF_INIT;
+   strbuf_addf(&buf, "%s:%s", ref->peer_ref->name, 
ref->name);
+   string_list_append(&revlist_args, "--refspec");
+   string_list_append(&revlist_args, buf.buf);
+   strbuf_release(&buf);
+   }
string_list_append(&revlist_args, ref->peer_ref->name);
+   }
 
}
 
if (get_exporter(transport, &exporter, &revlist_args))
die("Couldn't run fast-export");
 
+   string_list_clear(&revlist_args, 1);
+
if (finish_command(&exporter))
die("Error while running fast-export");
push_update_refs_status(data, remote_refs);
-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] fast-export: add new --refspec option

[Felipe Contreras]

So that we can covert the exported ref names.

Signed-off-by: Felipe Contreras 
---
 Documentation/git-fast-export.txt |  4 
 builtin/fast-export.c | 30 ++
 t/t9350-fast-export.sh|  7 +++
 3 files changed, 41 insertions(+)

diff --git a/Documentation/git-fast-export.txt 
b/Documentation/git-fast-export.txt
index 03fc8c3..d1985d3 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -105,6 +105,10 @@ marks the same across runs.
in the commit (as opposed to just listing the files which are
different from the commit's first parent).
 
+--refspec::
+   Apply the specified refspec to each ref exported. Multiple of them can
+   be specified.
+
 [...]::
A list of arguments, acceptable to 'git rev-parse' and
'git rev-list', that specifies the specific objects and references
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 6e46057..0097103 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -17,6 +17,7 @@
 #include "utf8.h"
 #include "parse-options.h"
 #include "quote.h"
+#include "remote.h"
 
 static const char *fast_export_usage[] = {
N_("git fast-export [rev-list-opts]"),
@@ -30,6 +31,8 @@ static int fake_missing_tagger;
 static int use_done_feature;
 static int no_data;
 static int full_tree;
+static struct refspec *refspecs;
+static int refspecs_nr;
 
 static int parse_opt_signed_tag_mode(const struct option *opt,
 const char *arg, int unset)
@@ -502,6 +505,15 @@ static void get_tags_and_duplicates(struct 
rev_cmdline_info *info,
if (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)
continue;
 
+   if (refspecs) {
+   char *private;
+   private = apply_refspecs(refspecs, refspecs_nr, 
full_name);
+   if (private) {
+   free(full_name);
+   full_name = private;
+   }
+   }
+
switch (e->item->type) {
case OBJ_COMMIT:
commit = (struct commit *)e->item;
@@ -653,6 +665,7 @@ int cmd_fast_export(int argc, const char **argv, const char 
*prefix)
struct commit *commit;
char *export_filename = NULL, *import_filename = NULL;
uint32_t lastimportid;
+   struct string_list refspecs_list;
struct option options[] = {
OPT_INTEGER(0, "progress", &progress,
N_("show progress after  objects")),
@@ -673,6 +686,8 @@ int cmd_fast_export(int argc, const char **argv, const char 
*prefix)
OPT_BOOLEAN(0, "use-done-feature", &use_done_feature,
 N_("Use the done feature to terminate the 
stream")),
OPT_BOOL(0, "no-data", &no_data, N_("Skip output of blob 
data")),
+   OPT_STRING_LIST(0, "refspec", &refspecs_list, N_("refspec"),
+N_("Apply refspec to exported refs")),
OPT_END()
};
 
@@ -692,6 +707,19 @@ int cmd_fast_export(int argc, const char **argv, const 
char *prefix)
if (argc > 1)
usage_with_options (fast_export_usage, options);
 
+   if (refspecs_list.nr) {
+   const char *refspecs_str[refspecs_list.nr];
+   int i;
+
+   for (i = 0; i < refspecs_list.nr; i++)
+   refspecs_str[i] = refspecs_list.items[i].string;
+
+   refspecs_nr = refspecs_list.nr;
+   refspecs = parse_fetch_refspec(refspecs_nr, refspecs_str);
+
+   string_list_clear(&refspecs_list, 1);
+   }
+
if (use_done_feature)
printf("feature done\n");
 
@@ -726,5 +754,7 @@ int cmd_fast_export(int argc, const char **argv, const char 
*prefix)
if (use_done_feature)
printf("done\n");
 
+   free_refspec(refspecs_nr, refspecs);
+
return 0;
 }
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index 2471bc6..ef2d76e 100755
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -505,4 +505,11 @@ test_expect_success 'refs are updated even if no commits 
need to be exported' '
test_cmp expected actual
 '
 
+test_expect_success 'use refspec' '
+   git fast-export --refspec refs/heads/master:refs/heads/foobar master | \
+   grep "^commit " | sort | uniq > actual &&
+   echo "commit refs/heads/foobar" > expected &&
+   test_cmp expected actual
+'
+
 test_done
-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] fast-export: improve argument parsing

[Felipe Contreras]

We don't want to pass arguments specific to fast-export to
setup_revisions.

Signed-off-by: Felipe Contreras 
---
 builtin/fast-export.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index d60d675..6e46057 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -686,8 +686,9 @@ int cmd_fast_export(int argc, const char **argv, const char 
*prefix)
revs.topo_order = 1;
revs.show_source = 1;
revs.rewrite_parents = 1;
+   argc = parse_options(argc, argv, prefix, options, fast_export_usage,
+   PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN);
argc = setup_revisions(argc, argv, &revs, NULL);
-   argc = parse_options(argc, argv, prefix, options, fast_export_usage, 0);
if (argc > 1)
usage_with_options (fast_export_usage, options);
 
-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Support for old:new remote-helper push

[Felipe Contreras]

Hi,

In order to support pushing old:new refspecs in remote-helpers, the best way to
do what is to add an option to fast-export to rename the refs in the stream, so
here it is:

Felipe Contreras (3):
  fast-export: improve argument parsing
  fast-export: add new --refspec option
  transport-helper: add support for old:new refspec

 Documentation/git-fast-export.txt |  4 
 builtin/fast-export.c | 33 -
 t/t5801-remote-helpers.sh |  2 +-
 t/t9350-fast-export.sh|  7 +++
 transport-helper.c| 14 --
 5 files changed, 56 insertions(+), 4 deletions(-)

-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] poll.h lies in the same folder, so use normal quotes for include

[Sven Strickroth]

Am 09.05.2013 03:12 schrieb Sven Strickroth:
> Some compilers, like Visual C++ complain when <> is used instead of
> double quotes for non system includes.

I just noticed that this patch isn't necessary for 1.8.3 (since
41f2999180f5a58f2a4214d896359c1587c9024f) any more. Sorry for the noise
- I was still building against 1.8.2.2.

-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] MSVC fixes

[Sven Strickroth]

Hi,

I've 3 patches fixing warnings and errors when compiling with latest
MSVC (2012).

-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] Initialize variables with values

[Sven Strickroth]

With MSVC initializing a variable with "int a=a" causes a warning about
using an uninitialized value.

Signed-off-by: Sven Strickroth 
---
 builtin/rev-list.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 67701be..13afacd 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -338,7 +338,7 @@ int cmd_rev_list(int argc, const char **argv, const char 
*prefix)
mark_edges_uninteresting(revs.commits, &revs, show_edge);
 
if (bisect_list) {
-   int reaches = reaches, all = all;
+   int reaches = 0, all = 0;
 
revs.commits = find_bisection(revs.commits, &reaches, &all,
  bisect_find_all);
-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] poll.h lies in the same folder, so use normal quotes for include

[Sven Strickroth]

Some compilers, like Visual C++ complain when <> is used instead of
double quotes for non system includes.

Signed-off-by: Sven Strickroth 
---
 compat/poll/poll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index 7d226ec..b85386a 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -31,7 +31,7 @@
 #include 
 
 /* Specification.  */
-#include 
+#include "poll.h"
 
 #include 
 #include 
-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] mingw.h: Define only if necessary

[Sven Strickroth]

Since the latest version of MSVC EWOULDBLOCK, EAFNOSUPPORT and
ECONNABORTED are defined in errno.h. When used with MSVC mingw.h
is included from msvc.h and causes warnings about redefinitions.

Signed-off-by: Sven Strickroth 
---
 compat/mingw.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/compat/mingw.h b/compat/mingw.h
index 685cd2c..c424333 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -32,7 +32,9 @@ typedef int socklen_t;
 #define WEXITSTATUS(x) ((x) & 0xff)
 #define WTERMSIG(x) SIGTERM
 
+#ifndef EWOULDBLOCK
 #define EWOULDBLOCK EAGAIN
+#endif
 #define SHUT_WR SD_SEND
 
 #define SIGHUP 1
@@ -46,8 +48,12 @@ typedef int socklen_t;
 #define F_SETFD 2
 #define FD_CLOEXEC 0x1
 
+#ifndef EAFNOSUPPORT
 #define EAFNOSUPPORT WSAEAFNOSUPPORT
+#endif
+#ifndef ECONNABORTED
 #define ECONNABORTED WSAECONNABORTED
+#endif
 
 struct passwd {
char *pw_name;
-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
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] git-svn: added an --include-path flag

[Eric Wong]

Paul Walmsley  wrote:
> The SVN::Fetcher module is now able to filter for inclusion as well
> as exclusion (as used by --ignore-path). Also added tests, documentation
> changes and git completion script.
> 
> If you have an SVN repository with many top level directories and you
> only want a git-svn clone of some of them then using --ignore-path is
> difficult as it requires a very long regexp. In this case it's much
> easier to filter for inclusion.
> 
> Signed-off-by: Paul Walmsley 

Thanks, signed-off and applied, will push.
--
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 4/4] fast-export: trivial cleanup

[Felipe Contreras]

Cast the object to a commit, only to get the object back?

Signed-off-by: Felipe Contreras 
---
 builtin/fast-export.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 8091354..d24b4d9 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -550,7 +550,6 @@ static void get_tags_and_duplicates(struct rev_cmdline_info 
*info,
 
 static void handle_tags_and_duplicates(struct string_list *extra_refs)
 {
-   struct commit *commit;
int i;
 
for (i = extra_refs->nr - 1; i >= 0; i--) {
@@ -562,9 +561,7 @@ static void handle_tags_and_duplicates(struct string_list 
*extra_refs)
break;
case OBJ_COMMIT:
/* create refs pointing to already seen commits */
-   commit = (struct commit *)object;
-   printf("reset %s\nfrom :%d\n\n", name,
-  get_object_mark(&commit->object));
+   printf("reset %s\nfrom :%d\n\n", name, 
get_object_mark(object));
show_progress();
break;
}
-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] {fast-export,transport-helper}: style cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras 
---
 builtin/fast-export.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index d60d675..8091354 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -135,7 +135,7 @@ static void export_blob(const unsigned char *sha1)
 
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
-   die ("Could not read blob %s", sha1_to_hex(sha1));
+   die("Could not read blob %s", sha1_to_hex(sha1));
if (check_sha1_signature(sha1, buf, size, typename(type)) < 0)
die("sha1 mismatch in blob %s", sha1_to_hex(sha1));
object = parse_object_buffer(sha1, type, size, buf, &eaten);
@@ -146,7 +146,7 @@ static void export_blob(const unsigned char *sha1)
 
printf("blob\nmark :%"PRIu32"\ndata %lu\n", last_idnum, size);
if (size && fwrite(buf, size, 1, stdout) != 1)
-   die_errno ("Could not write blob '%s'", sha1_to_hex(sha1));
+   die_errno("Could not write blob '%s'", sha1_to_hex(sha1));
printf("\n");
 
show_progress();
@@ -289,13 +289,13 @@ static void handle_commit(struct commit *commit, struct 
rev_info *rev)
parse_commit(commit);
author = strstr(commit->buffer, "\nauthor ");
if (!author)
-   die ("Could not find author in commit %s",
+   die("Could not find author in commit %s",
 sha1_to_hex(commit->object.sha1));
author++;
author_end = strchrnul(author, '\n');
committer = strstr(author_end, "\ncommitter ");
if (!committer)
-   die ("Could not find committer in commit %s",
+   die("Could not find committer in commit %s",
 sha1_to_hex(commit->object.sha1));
committer++;
committer_end = strchrnul(committer, '\n');
@@ -395,7 +395,7 @@ static void handle_tag(const char *name, struct tag *tag)
 
buf = read_sha1_file(tag->object.sha1, &type, &size);
if (!buf)
-   die ("Could not read tag %s", sha1_to_hex(tag->object.sha1));
+   die("Could not read tag %s", sha1_to_hex(tag->object.sha1));
message = memmem(buf, size, "\n\n", 2);
if (message) {
message += 2;
@@ -421,11 +421,11 @@ static void handle_tag(const char *name, struct tag *tag)
if (signature)
switch(signed_tag_mode) {
case ABORT:
-   die ("Encountered signed tag %s; use "
+   die("Encountered signed tag %s; use "
 "--signed-tags= to handle it.",
 sha1_to_hex(tag->object.sha1));
case WARN:
-   warning ("Exporting signed tag %s",
+   warning("Exporting signed tag %s",
 sha1_to_hex(tag->object.sha1));
/* fallthru */
case VERBATIM:
@@ -446,7 +446,7 @@ static void handle_tag(const char *name, struct tag *tag)
if (!tagged_mark) {
switch(tag_of_filtered_mode) {
case ABORT:
-   die ("Tag %s tags unexported object; use "
+   die("Tag %s tags unexported object; use "
 "--tag-of-filtered-object= to handle it.",
 sha1_to_hex(tag->object.sha1));
case DROP:
@@ -454,7 +454,7 @@ static void handle_tag(const char *name, struct tag *tag)
return;
case REWRITE:
if (tagged->type != OBJ_COMMIT) {
-   die ("Tag %s tags unexported %s!",
+   die("Tag %s tags unexported %s!",
 sha1_to_hex(tag->object.sha1),
 typename(tagged->type));
}
@@ -467,7 +467,7 @@ static void handle_tag(const char *name, struct tag *tag)
if (!(p->object.flags & TREESAME))
break;
if (!p->parents)
-   die ("Can't find replacement commit for 
tag %s\n",
+   die("Can't find replacement commit for 
tag %s\n",
 sha1_to_hex(tag->object.sha1));
p = p->parents->item;
}
@@ -677,7 +677,7 @@ int cmd_fast_export(int argc, const char **argv, const char 
*prefix)
};
 
if (argc == 1)
-   usage_with_options (fast_export_usage, options);
+   usage_with_options(fast_export_usage, options);
 
/* we handle encodings */
g

[PATCH 2/4] transport-helper: trivial style cleanup

[Felipe Contreras]

Signed-off-by: Felipe Contreras 
---
 transport-helper.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/transport-helper.c b/transport-helper.c
index 835815f..522d791 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -214,9 +214,8 @@ static struct child_process *get_helper(struct transport 
*transport)
int i;
data->refspec_nr = refspec_nr;
data->refspecs = parse_fetch_refspec(refspec_nr, refspecs);
-   for (i = 0; i < refspec_nr; i++) {
+   for (i = 0; i < refspec_nr; i++)
free((char *)refspecs[i]);
-   }
free(refspecs);
}
strbuf_release(&buf);
-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] documentation: trivial style cleanups

[Felipe Contreras]

White-spaces, missing braces, standardize --[no-]foo.

Signed-off-by: Felipe Contreras 
---
 Documentation/git-am.txt   |  7 +++
 Documentation/git-archive.txt  |  2 +-
 Documentation/git-check-ref-format.txt |  3 +--
 Documentation/git-clone.txt|  4 ++--
 Documentation/git-commit.txt   |  2 +-
 Documentation/git-config.txt   |  3 +--
 Documentation/git-daemon.txt   |  5 ++---
 Documentation/git-difftool.txt |  3 +--
 Documentation/git-fast-export.txt  | 10 +-
 Documentation/git-fetch-pack.txt   |  6 +++---
 Documentation/git-fmt-merge-msg.txt|  3 +--
 Documentation/git-fsck.txt |  6 ++
 Documentation/git-grep.txt |  2 +-
 Documentation/git-mailinfo.txt |  2 +-
 Documentation/git-merge.txt|  3 +--
 Documentation/git-mergetool.txt|  2 +-
 Documentation/git-push.txt |  3 +--
 Documentation/git-remote.txt   |  2 +-
 Documentation/git-revert.txt   |  2 +-
 Documentation/git-update-index.txt | 10 --
 20 files changed, 34 insertions(+), 46 deletions(-)

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 19d57a8..5bbe7b6 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -9,12 +9,12 @@ git-am - Apply a series of patches from a mailbox
 SYNOPSIS
 
 [verse]
-'git am' [--signoff] [--keep] [--keep-cr | --no-keep-cr] [--utf8 | --no-utf8]
+'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8]
 [--3way] [--interactive] [--committer-date-is-author-date]
 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 [--whitespace=] [-C] [-p] [--directory=]
 [--exclude=] [--include=] [--reject] [-q | --quiet]
-[--scissors | --no-scissors]
+[--[no-]scissors]
 [( | )...]
 'git am' (--continue | --skip | --abort)
 
@@ -43,8 +43,7 @@ OPTIONS
 --keep-non-patch::
Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
 
---keep-cr::
---no-keep-cr::
+--[no-]keep-cr::
With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1])
with the same option, to prevent it from stripping CR at the end of
lines. `am.keepcr` configuration variable can be used to specify the
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 250e522..b97aaab 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 
 [verse]
 'git archive' [--format=] [--list] [--prefix=/] []
- [-o | --output=] [--worktree-attributes]
+ [-o  | --output=] [--worktree-attributes]
  [--remote= [--exec=]] 
  [...]
 
diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index ec1739a..a49be1b 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -83,8 +83,7 @@ typed the branch name.
 
 OPTIONS
 ---
---allow-onelevel::
---no-allow-onelevel::
+--[no-]allow-onelevel::
Controls whether one-level refnames are accepted (i.e.,
refnames that do not contain multiple `/`-separated
components).  The default is `--no-allow-onelevel`.
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 5c16e31..a0727d7 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -14,7 +14,7 @@ SYNOPSIS
  [-o ] [-b ] [-u ] [--reference ]
  [--separate-git-dir ]
  [--depth ] [--[no-]single-branch]
- [--recursive|--recurse-submodules] [--] 
+ [--recursive | --recurse-submodules] [--] 
  []
 
 DESCRIPTION
@@ -188,7 +188,7 @@ objects from the source repository into a pack in the 
cloned repository.
with a long history, and would want to send in fixes
as patches.
 
---single-branch::
+--[no-]single-branch::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
branch remote's `HEAD` points at. When creating a shallow
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 8172938..1a7616c 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -12,7 +12,7 @@ SYNOPSIS
   [--dry-run] [(-c | -C | --fixup | --squash) ]
   [-F  | -m ] [--reset-author] [--allow-empty]
   [--allow-empty-message] [--no-verify] [-e] [--author=]
-  [--date=] [--cleanup=] [--status | --no-status]
+  [--date=] [--cleanup=] [--[no-]status]
   [-i | -o] [-S[]] [--] [...]
 
 DESCRIPTION
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 9ae2508..d88a6fc 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -186,8 +186,7 @@ See also <>.
Opens an editor to modify the specified config file; either
'--system', '--gl

[PATCH 0/4] trivial patches

[Felipe Contreras]

Hi,

Here's a bunch of trivial style cleanup patches.

Felipe Contreras (4):
  documentation: trivial style cleanups
  transport-helper: trivial style cleanup
  {fast-export,transport-helper}: style cleanups
  fast-export: trivial cleanup

 Documentation/git-am.txt   |  7 +++
 Documentation/git-archive.txt  |  2 +-
 Documentation/git-check-ref-format.txt |  3 +--
 Documentation/git-clone.txt|  4 ++--
 Documentation/git-commit.txt   |  2 +-
 Documentation/git-config.txt   |  3 +--
 Documentation/git-daemon.txt   |  5 ++---
 Documentation/git-difftool.txt |  3 +--
 Documentation/git-fast-export.txt  | 10 +-
 Documentation/git-fetch-pack.txt   |  6 +++---
 Documentation/git-fmt-merge-msg.txt|  3 +--
 Documentation/git-fsck.txt |  6 ++
 Documentation/git-grep.txt |  2 +-
 Documentation/git-mailinfo.txt |  2 +-
 Documentation/git-merge.txt|  3 +--
 Documentation/git-mergetool.txt|  2 +-
 Documentation/git-push.txt |  3 +--
 Documentation/git-remote.txt   |  2 +-
 Documentation/git-revert.txt   |  2 +-
 Documentation/git-update-index.txt | 10 --
 builtin/fast-export.c  | 29 +
 transport-helper.c |  3 +--
 22 files changed, 48 insertions(+), 64 deletions(-)

-- 
1.8.3.rc1.553.gac13664

--
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] Git::SVN::*: add missing "NAME" section to perldoc

[Eric Wong]

Jonathan Nieder  wrote:
> Just noticed this by running a tool to sanity-check my build result.
> I hadn't noticed before because I hadn't been installing the manpages.
> Anyway, perhaps the patch can be useful.

Thanks, signed-off and applied, will push.
--
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 4/5] git-svn: fix bottleneck in stash_placeholder_list()

[Eric Wong]

Ilya Basin  wrote:
> Hi Eric. I'm out of spare time and I still unable to import my repo.
> The code of SVN.pm is too complex. Please help me.

Sorry, most what I do nowadays for git-svn is ACK/NACK changes.

git-svn has made itself obsolete for most contributors, myself included;
so it's hard for us to devote significant amounts of time on it since
we no longer see SVN repos in our day-to-day work.

Given the differences between branching/tagging in SVN and git, I
suspect some history may always be too complex/convoluted to
automatically import.  Perhaps an interactive mode can be introduced
to follow history...

Anyways, thank you for documenting these issues and suggesting fixes.
Hopefully somebody with sufficient motivation can continue your work
down the line.
--
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 1/2] help: add help_unknown_ref

[Junio C Hamano]

Vikrant Varma  writes:

> When a ref is not known, currently functions call die() with an
> error message.

The first part read somewhat awkward, so I started rewriting the
above like so:

When the user gives an unknown string to a command that expects
to see a ref, we could be more helpful than just saying "that's
not a ref" and die.

which in turn made me realize that some commands may not even know
if the user mistyped a ref.  It is not an objection to this patch
per-se, but a useful future enhancement may be to allow the callers
call guess_mistyped_ref() directly and let them decide what to do
when they suspect the string they did not understand is not a
mistyped ref but something else, i.e. not let help_unknown_ref() die
unconditionally but allow it to return.  Then the caller can do:

commit = get_commit_from_string(argv[i]);
if (!commit) {
... I do not understand argv[i], but ...
... it may be a mistyped ref ...
help_unknown_ref(argv[i], "expected a revision");
... it is not likely to be a typo ...
... perhaps it was meant to be a filename? ...
if (file_exists(argv[i])) {
... yes! ...
... do the "file" thing instead ...
}
}

> Add helper function help_unknown_ref to take care of displaying an
> error message along with a list of suggested refs the user might
> have meant.

OK.

> Example:
>   $ git merge foo
>   merge: foo - not something we can merge

That leading "merge: " looks somewhat strange, especially when it
immediately follows the command line to invoke "merge", making it
appear to waste space by stating the obvious.

Our messages are generally marked with "error:", "fatal:",
"warning:", etc. at the beginning.

>
>   Did you mean one of these?
>   origin/foo
>   upstream/foo
>
> Signed-off-by: Vikrant Varma 

> ...
> +struct string_list guess_refs(const char *ref)
> +{
> + struct similar_ref_cb ref_cb;
> + struct string_list similar_refs = STRING_LIST_INIT_NODUP;
> +
> + ref_cb.base_ref = ref;
> + ref_cb.similar_refs = &similar_refs;
> + for_each_ref(append_similar_ref, &ref_cb);
> + return similar_refs;
> +}
> +
> +void help_unknown_ref(const char *ref, const char *cmd, const char *error)
> +{
> + int i;
> + struct string_list suggested_refs = guess_refs(ref);
> +
> + fprintf_ln(stderr, _("%s: %s - %s"), cmd, ref, error);
> +
> + if (suggested_refs.nr > 0) {
> + fprintf_ln(stderr,
> +Q_("\nDid you mean this?",
> +   "\nDid you mean one of these?",
> +   suggested_refs.nr));
> + for (i = 0; i < suggested_refs.nr; i++)
> + fprintf(stderr, "\t%s\n", 
> suggested_refs.items[i].string);
> + }
> +
> + string_list_clear(&suggested_refs, 0);
> + exit(1);
> +}

Looks sensible.

> diff --git a/help.h b/help.h
> index 0ae5a12..5003423 100644
> --- a/help.h
> +++ b/help.h
> @@ -27,4 +27,9 @@ extern void exclude_cmds(struct cmdnames *cmds, struct 
> cmdnames *excludes);
>  extern int is_in_cmdlist(struct cmdnames *cmds, const char *name);
>  extern void list_commands(unsigned int colopts, struct cmdnames *main_cmds, 
> struct cmdnames *other_cmds);
>  
> +/*
> + * This function has been called because ref is not known.
> + * Print a list of refs that the user might have meant, and exit.
> + */

The wording is a bit funny; I'll amend it somehow before queuing.

> +extern void help_unknown_ref(const char *ref, const char *cmd, const char 
> *error);
>  #endif /* HELP_H */
--
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 10/11] sha1_name: reorganize get_sha1_basic()

[Felipe Contreras]

On Wed, May 8, 2013 at 4:51 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Wed, May 8, 2013 at 1:18 PM, Junio C Hamano  wrote:
>>> Felipe Contreras  writes:
>>>
 Through the years the functionality to handle @{-N} and @{u} has moved
 around the code, and as a result, code that once made sense, doesn't any
 more.

 There is no need to call this function recursively with the branch of
 @{-N} substituted because dwim_{ref,log} already replaces it.

 However, there's one corner-case where @{-N} resolves to a detached
 HEAD, in which case we wouldn't get any ref back.

 So we parse the nth-prior manually, and deal with it depending on
 weather it's a SHA-1, or a ref.
 ...
>>>
>>> s/weather/whether/;
>>>
 @@ -447,6 +448,10 @@ static int get_sha1_basic(const char *str, int len, 
 unsigned char *sha1)
   if (len && str[len-1] == '}') {
   for (at = len-4; at >= 0; at--) {
   if (str[at] == '@' && str[at+1] == '{') {
 + if (at == 0 && str[2] == '-') {
 + nth_prior = 1;
 + continue;
 + }
>>>
>>> Does this have to be inside the loop?
>>
>> Yes, the whole purpose is to avoid reflog_len to be set.
>
> What I meant was the "@{-" check, which happens only at==0.
>
> if (!memcmp(str, "@{-", 3) && len > 3)
> nth_prior = 1;
> else
> for (at = len - 4; at; at--) {
> ... look for and break at the first "@{" ...
> }
>
> or something.

That's doable, but would screw up the next patch.

>>> Ahh, OK, the new code will now let dwim_ref/log to process @{-N}
>>> again (the log message hints this but it wasn't all that clear),
>>
>> I thought it was clear we would let dwim_{ref,log} do the job:
>
> Yes, the reason I did not immediately think of that is because I
> knew @{-N} was expensive (need to read reflog backwards) and didn't
> think anybody would redo the code to deliberately do that twice ;-)

But that's what the commit message said.

>>> Also, a few points this patch highlights in the code before the
>>> change:
>>>
>>>  - If we were on a branch with 40-hex name at nth prior checkout,
>>>would we mistake it as being detached at the commit?
>>>
>>>  - If we were on a branch 'foo' at nth prior checkout, would our
>>>previous get_sha1_1() have made us mistake it as referring to a
>>>tag 'foo' with the same name if it exists?
>>
>> I don't know, but I suspect there's no change after this patch.
>
> Yes, didn't I say "the code before the change" above?
>
> These two correctness issues look more important issues to me, with
> or without the restructure patch (in other words, they are
> independent).

Right, if you are interested in correctness, you might want to try
@{-1}{0}; it resolves to @{-1} currently, and it fails correctly with
my patch.

Cheers.

-- 
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

Re: [PATCH v2 10/11] sha1_name: reorganize get_sha1_basic()

[Junio C Hamano]

Felipe Contreras  writes:

> On Wed, May 8, 2013 at 1:18 PM, Junio C Hamano  wrote:
>> Felipe Contreras  writes:
>>
>>> Through the years the functionality to handle @{-N} and @{u} has moved
>>> around the code, and as a result, code that once made sense, doesn't any
>>> more.
>>>
>>> There is no need to call this function recursively with the branch of
>>> @{-N} substituted because dwim_{ref,log} already replaces it.
>>>
>>> However, there's one corner-case where @{-N} resolves to a detached
>>> HEAD, in which case we wouldn't get any ref back.
>>>
>>> So we parse the nth-prior manually, and deal with it depending on
>>> weather it's a SHA-1, or a ref.
>>> ...
>>
>> s/weather/whether/;
>>
>>> @@ -447,6 +448,10 @@ static int get_sha1_basic(const char *str, int len, 
>>> unsigned char *sha1)
>>>   if (len && str[len-1] == '}') {
>>>   for (at = len-4; at >= 0; at--) {
>>>   if (str[at] == '@' && str[at+1] == '{') {
>>> + if (at == 0 && str[2] == '-') {
>>> + nth_prior = 1;
>>> + continue;
>>> + }
>>
>> Does this have to be inside the loop?
>
> Yes, the whole purpose is to avoid reflog_len to be set.

What I meant was the "@{-" check, which happens only at==0.

if (!memcmp(str, "@{-", 3) && len > 3)
nth_prior = 1;
else
for (at = len - 4; at; at--) {
... look for and break at the first "@{" ...
}

or something.

>> Ahh, OK, the new code will now let dwim_ref/log to process @{-N}
>> again (the log message hints this but it wasn't all that clear),
>
> I thought it was clear we would let dwim_{ref,log} do the job:

Yes, the reason I did not immediately think of that is because I
knew @{-N} was expensive (need to read reflog backwards) and didn't
think anybody would redo the code to deliberately do that twice ;-)

>> Also, a few points this patch highlights in the code before the
>> change:
>>
>>  - If we were on a branch with 40-hex name at nth prior checkout,
>>would we mistake it as being detached at the commit?
>>
>>  - If we were on a branch 'foo' at nth prior checkout, would our
>>previous get_sha1_1() have made us mistake it as referring to a
>>tag 'foo' with the same name if it exists?
>
> I don't know, but I suspect there's no change after this patch.

Yes, didn't I say "the code before the change" above?

These two correctness issues look more important issues to me, with
or without the restructure patch (in other words, they are
independent).
--
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

[non PATCH */2] preparatory analysis of remaining @{...} issues

[Junio C Hamano]

Currently interpret_branch_name() takes either @{-N}, @{u}, or
some@{u} and returns an abbreviated refname, or a detached HEAD if
@{-N} resolves to such a state.  Local branch names coming back for
@{-N} are returned as branch names without "refs/heads/", upstream
names coming back for @{u} are given after cleaning it up with
shorten_unambiguous_ref().  @{-N} resolved to a detached HEAD yields
a bare 40-HEX.

This makes the caller unnecessarily fragile.  I started asking

(1) perhaps interpret_branch_name() can be updated to return a full
refname when it does return a ref;

(2) perhaps it can also be updated to say if its input @{-N} refers
to a detached HEAD state.

I looked at all existing callers of interpret_branch_name() to see
how feasible such a change is.  Here is a preparatory analysis.


refs.c: substitute_branch_name()

The call to interpret_branch_name() by this function only wants to
see the branch name replaced to a full refname for the consumption
of dwim_ref() and dwim_log(), and does not want to see a detached
HEAD state at all.

Changing @{-N} that returns the bare branch name to return
refs/heads/$name is welcome.  Changing $name@{u} that returns an
abbreviation to return a full refname is also welcome.
And we can error out early if @{-N} referred to a detached HEAD.

[answer: Yes/Yes]


revision.c: add_pending_object_with_mode()

The call to interpret_branch_name() by this function wants to turn
@{-N} and $name@{u} to a refname so that it can be passed to
add_reflog_for_walk().  Obviously it does not want to see a
detached state.

Again, this benefits if interpret_branch_name returned a full
refname, as add_reflog_for_walk() eventually ends up passing the
name to dwim_log().

[answer: Yes/Yes]


sha1_name.c: get_sha1_basic()

The call to interpret_branch_name() by this function wants to turn
@{-N} and $name@{u} to a string that can be fed to get_sha1_1() to
get an object name.  Returning full refname or full object name is
a good change.

[answer: Yes/Yes]


sha1_name.c: interpret_branch_name()

@{-N}@{u} is first given to interpret_nth_prior_checkout() to turn
@{-N} into a branch name, and then appends @{u} to the result and
recursively call this function to expand $branch@{u}.  Expansion
of @{-N} to full refname can break the second expansion, and needs
to be adjusted, but if @{-N} turns out to be a detaches state, we
would want to error out the resulting $HEX@{u} anyway, so updating
the API would result in a pair of real bug fixes.

[answer: Yes/Yes -- but this caller needs further adjustment]


sha1_name.c: strbuf_branchname()

The function wants to return an abbreviated branch name.
The callers of this function are:

builtin/branch.c: delete_branches()

"git branch -d -r master@{u}" may expand to "git branch -d -r
origin/master" and delete "refs/remotes/origin/master", and "git
branch -d @{-2}" would expand to "git branch -d next" and delete
"refs/heads/next".

strbuf_branchname() that returns a full refname would break
this caller and the caller needs to be updated to shorten
its output.

But if strbuf_branchname() can tell @{-N} were detached, we
can prevent removal of an unintended local branch.

builtin/checkout.c: setup_branch_path()

With the current code, "git checkout -b master@{u}" would
expand to "git checkout -b origin/master" and end up creating
"refs/heads/origin/master", which may not be a good thing.

strbuf_branchname() that returns a full refname would break
this caller and the caller needs to be updated to shorten
its output.

If strbuf_branchname() can tell @{-N} were detached, we can
error out instead of creating a bogus local branch.

builtin/merge.c: merge_name()

Uses strbuf_branchname() to turn @{-N} and $name@{u} into
something that can be fed to dwim_ref().

This does benefit if strbuf_branchname() can find out the
full refname.

If strbuf_branchname() can tell @{-N} were detached, we can
error out instead of creating a bogus local branch.

sha1_name.c: strbuf_check_branch_ref()

Used to see if the name is reasonable when appended to
refs/heads/.

strbuf_branchname() that returns a full refname would break
this caller and the caller needs to be updated to shorten
its output.

So strbuf_branchname() itself can tolerate an updated
interpret_branch_name() that returns full refname and it will
benefit if it can learn about detached state (many of its
callers would appreciate the latter).

[answer: Yes/Yes -- but this caller and its callers need some
adjustment].


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v

[PATCH 2/2] interpret_branch_name(): unconfuse @{-1}@{u} when @{-1} is detached

[Junio C Hamano]

Now interpret_nth_prior_checkout() can tell the caller if the result
of expansion of @{-1} is a real branch name or the commit object
name for a detached HEAD state, let's avoid re-interpreting $HEX@{u}
in the latter case.

Signed-off-by: Junio C Hamano 
---

 * This prevents us from mistakenly refering to the upstream of an
   unrelated branch in this sequence:

 HEX=$(git rev-parse --verify HEAD)
 git branch $HEX 
 git checkout HEAD^0
 git checkout -
 git log @{-1}@{u}

   The branch created in the first step has never been checked out,
   and @{-1} does not refer to it.  @{-1}@{u} would first turn into 
   $HEX@{u} but we should not look for upstream of refs/heads/$HEX.

 sha1_name.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 1473bb6..d3b6897 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1004,15 +1004,21 @@ int interpret_branch_name(const char *name, struct 
strbuf *buf)
char *cp;
struct branch *upstream;
int namelen = strlen(name);
-   int len = interpret_nth_prior_checkout(name, buf, NULL);
+   int detached;
+   int len = interpret_nth_prior_checkout(name, buf, &detached);
int tmp_len;
 
if (!len)
return len; /* syntax Ok, not enough switches */
if (0 < len && len == namelen)
return len; /* consumed all */
-   else if (0 < len) {
-   /* we have extra data, which might need further processing */
+   else if (0 < len && !detached) {
+   /*
+* We have extra data, which might need further
+* processing.  E.g. for the original "@{-1}@{u}" we
+* have converted @{-1} into buf and yet to process
+* the remaining @{u} part.
+*/
struct strbuf tmp = STRBUF_INIT;
int used = buf->len;
int ret;
-- 
1.8.3-rc1-182-gc61d106

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head

[Junio C Hamano]

The original API read "checkout: moving from (.*) to ..." from the
reflog of the HEAD, and returned the substring between "from" and
"to", but there was no way, if the substring was a 40-hex string, to
tell if we were on a detached HEAD at that commit object, or on a
branch whose name happened to be the 40-hex string.

At this point, we cannot afford to change the format recorded in the
reflog, so introduce a heuristics to see if the 40-hex matches the
object name of the commit we are switching out of.  This will
unfortunately mishandle this case:

HEX=$(git rev-parse master)
git checkout -b $HEX master
git checkout master

where we were indeed on a non-detached $HEX branch (i.e. HEAD was
pointing at refs/heads/$HEX, not storing $HEX), of course, but
otherwise should be fairly reliable.

Signed-off-by: Junio C Hamano 
---

 * This is a preparatory step for the beginning of a much larger
   series.  Peff is Cc'ed because one of the most tricky issue
   involves what d46a8301930a (fix parsing of @{-1}@{u} combination,
   2010-01-28) did.

 sha1_name.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..1473bb6 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -862,6 +862,7 @@ static int get_sha1_oneline(const char *prefix, unsigned 
char *sha1,
 struct grab_nth_branch_switch_cbdata {
int remaining;
struct strbuf buf;
+   int detached;
 };
 
 static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
@@ -880,9 +881,14 @@ static int grab_nth_branch_switch(unsigned char *osha1, 
unsigned char *nsha1,
if (!match || !target)
return 0;
if (--(cb->remaining) == 0) {
+   unsigned char sha1[20];
+
len = target - match;
strbuf_reset(&cb->buf);
strbuf_add(&cb->buf, match, len);
+   cb->detached = (len == 40 &&
+   !get_sha1_hex(match, sha1) &&
+   !hashcmp(osha1, sha1));
return 1; /* we are done */
}
return 0;
@@ -891,8 +897,12 @@ static int grab_nth_branch_switch(unsigned char *osha1, 
unsigned char *nsha1,
 /*
  * Parse @{-N} syntax, return the number of characters parsed
  * if successful; otherwise signal an error with negative value.
+ * The string in buf.buf is either a branch name (needs to be
+ * prefixed with "refs/heads/" if the caller wants to make it
+ * a fully spelled refname) or 40-hex object name of the detached
+ * HEAD, and *detached is set to true for the latter.
  */
-static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf)
+static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf, 
int *detached)
 {
long nth;
int retval;
@@ -917,6 +927,8 @@ static int interpret_nth_prior_checkout(const char *name, 
struct strbuf *buf)
if (0 < for_each_reflog_ent_reverse("HEAD", grab_nth_branch_switch, 
&cb)) {
strbuf_reset(buf);
strbuf_add(buf, cb.buf.buf, cb.buf.len);
+   if (detached)
+   *detached = cb.detached;
retval = brace - name + 1;
}
 
@@ -992,7 +1004,7 @@ int interpret_branch_name(const char *name, struct strbuf 
*buf)
char *cp;
struct branch *upstream;
int namelen = strlen(name);
-   int len = interpret_nth_prior_checkout(name, buf);
+   int len = interpret_nth_prior_checkout(name, buf, NULL);
int tmp_len;
 
if (!len)
-- 
1.8.3-rc1-182-gc61d106

--
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 10/11] sha1_name: reorganize get_sha1_basic()

[Felipe Contreras]

On Wed, May 8, 2013 at 1:18 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> Through the years the functionality to handle @{-N} and @{u} has moved
>> around the code, and as a result, code that once made sense, doesn't any
>> more.
>>
>> There is no need to call this function recursively with the branch of
>> @{-N} substituted because dwim_{ref,log} already replaces it.
>>
>> However, there's one corner-case where @{-N} resolves to a detached
>> HEAD, in which case we wouldn't get any ref back.
>>
>> So we parse the nth-prior manually, and deal with it depending on
>> weather it's a SHA-1, or a ref.
>> ...
>
> s/weather/whether/;
>
>> @@ -447,6 +448,10 @@ static int get_sha1_basic(const char *str, int len, 
>> unsigned char *sha1)
>>   if (len && str[len-1] == '}') {
>>   for (at = len-4; at >= 0; at--) {
>>   if (str[at] == '@' && str[at+1] == '{') {
>> + if (at == 0 && str[2] == '-') {
>> + nth_prior = 1;
>> + continue;
>> + }
>
> Does this have to be inside the loop?

Yes, the whole purpose is to avoid reflog_len to be set.

>> @@ -460,19 +465,22 @@ static int get_sha1_basic(const char *str, int len, 
>> unsigned char *sha1)
>>   if (len && ambiguous_path(str, len))
>>   return -1;
>>
>> - if (!len && reflog_len) {
>> + if (nth_prior) {
>>   struct strbuf buf = STRBUF_INIT;
>> - int ret;
>> - /* try the @{-N} syntax for n-th checkout */
>> - ret = interpret_branch_name(str, &buf);
>> - if (ret > 0)
>> - /* substitute this branch name and restart */
>> - return get_sha1_1(buf.buf, buf.len, sha1, 0);
>> - else if (ret == 0)
>> - return -1;
>> + int detached;
>> +
>> + if (interpret_nth_prior_checkout(str, &buf) > 0) {
>> + detached = (buf.len == 40 && !get_sha1_hex(buf.buf, 
>> sha1));
>> + strbuf_release(&buf);
>> + if (detached)
>> + return 0;
>> + }
>> + }
>
> Earlier, if @{-N} resolved to a detached head, we just fed it to
> get_sha1_1().  If it resolved to a concrete refname, we also fed it
> to get_sha1_1().  We ended up calling ourselves again and did the
> right thing either way.
>
> The new code bypasses the recursive call when we get a detached head
> back, because we know that calling get_sha1_1() with the 40-hex will
> eventually take us back to this codepath, and immediately return
> when it sees get_sha1_hex() succeeds.
>
> What happens when str @{-N} leaves a concrete refname in buf.buf?
> The branch name is lost with strbuf_release(), and then where do we
> go from here?  Continuing down from here would run dwim_ref/log on
> str which is still @{-N}, no?
>
> Ahh, OK, the new code will now let dwim_ref/log to process @{-N}
> again (the log message hints this but it wasn't all that clear),

I thought it was clear we would let dwim_{ref,log} do the job:

---
There is no need to call this function recursively with the branch of
@{-N} substituted because dwim_{ref,log} already replaces it.
---

> That is somewhat contrived, and I am not so sure if that is a good
> reorganization.

But much less contrived than before, because the code that deals with
@{-N} is in one place, instead of sprinkled all over as many
corner-cases, and there's no recursion.

> Also, a few points this patch highlights in the code before the
> change:
>
>  - If we were on a branch with 40-hex name at nth prior checkout,
>would we mistake it as being detached at the commit?
>
>  - If we were on a branch 'foo' at nth prior checkout, would our
>previous get_sha1_1() have made us mistake it as referring to a
>tag 'foo' with the same name if it exists?

I don't know, but I suspect there's no change after this patch.

-- 
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

Re: [PATCHv2] CodingGuidelines: make it clear which files in Documentation/ are the sources

[Junio C Hamano]

wor...@alum.mit.edu (Dale R. Worley) writes:

> From e87227498ef3d50dc20584c24c53071cce63c555 Mon Sep 17 00:00:00 2001
> From: Dale Worley 
> Date: Tue, 7 May 2013 13:39:46 -0400
> Subject: [PATCH] CodingGuidelines:  make it clear which files in
>  Documentation/ are the sources

These five lines are present in the output of the format-patch only
to help you fill in the MUA's mail header (instead of typing the
subject, you can cut and paste from here, for example); after you
are done with the MUA headers, remove them and do not leave them in
the body of the message.

>
> Signed-off-by: Dale R. Worley 

The title looks a bit too long.  For a small and obviously correct
patch like this, I do not think you would need anything in the log
message, some of what you wrote below the three-dash line may
deserve to be said here.  Perhaps:

Subject: [PATCH] CodingGuidelines: Documentation/*.txt are the sources

People not familiar with AsciiDoc may not realize they are
supposed to update *.txt files and not *.html/*.1 files when
preparing patches to the project.

But it invites a question.  Why do people patching Git not to know *.txt
are the sources in the first place?  Generated *.html files are not
even tracked.

>  Documentation/CodingGuidelines |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 7e4d571..b8eef7c 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -238,7 +238,9 @@ For Python scripts:
>  Writing Documentation:
>  
>   Most (if not all) of the documentation pages are written in AsciiDoc
> - and processed into HTML output and manpages.
> + and processed into HTML output and manpages.  This means that the *.txt
> + files in this directory are usually the sources from which the
> + corresponding *.html, *.1, and *.xml files are generated.

Whenever you see somebody writing "This means that" or "In other
words", it is a good habit to ask if the existing text can be
improved so that it does not need such a follow-up clarification.

Most (if not all) of the documentation pages are written in the
AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
processed into HTML and manpages (e.g. git.html and git.1 in the
same directory).

>  
>   Every user-visible change should be reflected in the documentation.
>   The same general rule as for code applies -- imitate the existing
--
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

[PATCHv2] CodingGuidelines: make it clear which files in Documentation/ are the sources

[Dale R. Worley]

>From e87227498ef3d50dc20584c24c53071cce63c555 Mon Sep 17 00:00:00 2001
From: Dale Worley 
Date: Tue, 7 May 2013 13:39:46 -0400
Subject: [PATCH] CodingGuidelines:  make it clear which files in
 Documentation/ are the sources

Signed-off-by: Dale R. Worley 
---
While learning about making a documentation patch, I noticed that
Documentation/CodingGuideles isn't as clear as it could be regarding
how to edit the documentation.  In particular, it says "Most (if not
all) of the documentation pages are written in AsciiDoc - and
processed into HTML output and manpages." without really specifying
the details for those of us who aren't familiar with AsciiDoc.  So I
added a sentence stating explicitly which files are the sources and
which are derived.

It's also a test for submitting a patch.  I've read SubmittingPatches
again, more carefully, and have corrected some problem with my
previous message.

 Documentation/CodingGuidelines |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 7e4d571..b8eef7c 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -238,7 +238,9 @@ For Python scripts:
 Writing Documentation:
 
  Most (if not all) of the documentation pages are written in AsciiDoc
- and processed into HTML output and manpages.
+ and processed into HTML output and manpages.  This means that the *.txt
+ files in this directory are usually the sources from which the
+ corresponding *.html, *.1, and *.xml files are generated.
 
  Every user-visible change should be reflected in the documentation.
  The same general rule as for code applies -- imitate the existing
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] shallow clones over http

[Junio C Hamano]

Jeff King  writes:

> I'm trying to track down a protocol bug that happens with shallow clones
> over smart-http. As far as I can tell, the bug has existed in all
> versions.
>
> You can reproduce it using the attached repository, which is a shallow
> clone of https://github.com/mileszs/ack.vim.git, like:
>
>   $ tar xzf repo.tar.gz
>   $ cd repo.git
>   $ git fetch --depth=10
>   fatal: git fetch-pack: expected shallow list
>
> In that test my fetch actually hit github.com as the upstream full repo,
> but you can also clone it down locally and demonstrate it with purely
> local copies of git (but it's more of a pain, because you have to set up
> a smart http server).
>
> The last part of the conversation looks like this:
>
>   packet:   fetch-pack< 
>   packet:   fetch-pack< ACK f183a345a0c10caed7684d07dabae33e007c7590 common
>   packet:   fetch-pack> have f183a345a0c10caed7684d07dabae33e007c7590
>   packet:   fetch-pack< ACK 33312d4db4e91468957b1b41dd039c5d88e85fda common
>   packet:   fetch-pack< ACK 34d0b2fbc182b31d926632d170bc07d6a6fc3f9b common
>   packet:   fetch-pack< ACK 45c802e07c60686986474b6b05b2c7048330b6b5 common
>   packet:   fetch-pack< ACK e93f693fd2a9940d6421bf9e4ddd1f535994eaa5 common
>   packet:   fetch-pack< ACK 132ee41e8e2c8c545b3aed120171e1596c9211a4 common
>   packet:   fetch-pack< ACK 973deb3145a2638b2301cfd654721cf35d68 common
>   packet:   fetch-pack< ACK e53a88a4e72d84562493313e8911ada4def787da common
>   packet:   fetch-pack< ACK 90be0bf3eee6f7a0cb9c2377a50610f4ce738da3 common
>   packet:   fetch-pack< ACK aeab88ccf41bf216fde37983bd403d9b913391e7 common
>   packet:   fetch-pack< ACK 5f480935d3ce431c393657c3000337bcbdbd5535 common
>   packet:   fetch-pack< ACK db81e01b433501b159983ea38690aeb01eea1e6b common
>   packet:   fetch-pack< ACK 06c44b8cab93e780a29ff7f7b5b1dd41dba4b2d5 common
>   packet:   fetch-pack< ACK 65f3966becdb2d931d5afbdcc6a28008d154668a common
>   packet:   fetch-pack< ACK 10e8caef9f2ed308231ce1abc326c512e86a5d4c common
>   packet:   fetch-pack< ACK 6b55dd91f2e7fc64c23eea57e85171cb958f9cd2 common
>   packet:   fetch-pack< ACK 6b55dd91f2e7fc64c23eea57e85171cb958f9cd2 ready
>   packet:   fetch-pack< NAK
>   packet:   fetch-pack< ACK 6b55dd91f2e7fc64c23eea57e85171cb958f9cd2
>   fatal: git fetch-pack: expected shallow list
>
> So we see that upload-pack sends a bunch of detailed ACKs, followed by a
> NAK, and then it sends another ACK.
>
> Fetch-pack is inside find_common, reading these acks. At the beginning
> of each stateless-rpc response, it expects to consume any
> shallow/unshallow lines up to a flush packet (the call to
> consume_shallow_list). And then it reads the acks in a loop. After it
> sees the NAK, it assumes that the server is done sending the packet, and
> loops again, expecting another set of shallow/unshallow lines. But we
> get the next ACK instead, and die.
>
> So who is wrong? Is upload-pack wrong to send an ACK after the NAK?

3e63b21aced1 (upload-pack: Implement no-done capability, 2011-03-14)
claims that the above sequence of acks and naks is what upload-pack
wants to show.

What happens when you disable no-done extension handling on the
server end, I wonder?
--
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 10/11] sha1_name: reorganize get_sha1_basic()

[Junio C Hamano]

Junio C Hamano  writes:

> Also, a few points this patch highlights in the code before the
> change:
>
>  - If we were on a branch with 40-hex name at nth prior checkout,
>would we mistake it as being detached at the commit?
>
>  - If we were on a branch 'foo' at nth prior checkout, would our
>previous get_sha1_1() have made us mistake it as referring to a
>tag 'foo' with the same name if it exists?
>
> The former needs a fix to either writing of reflog or reading by
> interpret_nth_prior_checkout() so that we can tell these cases apart
> more reliably.  Then the latter can be solved by splicing
> refs/heads/ in front of the branch name before recursively calling
> get_sha1_1() in the original code (and similar fix can be
> forward-ported to this patch).
>
> Incidentally, I think if we prefix refs/heads/ in front and feed
> that to dwim_ref/log, we would also avoid running @{-N} twice (which
> I suspect might be more expensive than a simple recursion, as it
> needs to go through the reflog file), which may be a nice side
> effect of such a fix we would get for free.

Here is the first step (i.e. more reliable interpret_nth_prior).

I looked at all the existing callers of interpret_branch_name() and
it appears to me that most of them currently assume they are getting
a branch name, because they want to work on a ref, and some of them
do not care, because they are working on a revision.  For the
former, they can (and should) error out instead of relying on not
having refs/heads/$detached_SHA1 that will prevent them from working
on a ref which is what they currently do, if they had the "detached"
information.  For the latter, if we give "detached" information,
they can either prefix "refs/heads/" (if the result is "not
detached") to call resolve_ref(), or call get_sha1_hex (if the
result is "detached"), which would be the solution for the second
issue I noticed in the message I am replying to.

The next step on top of this patch may be to expose the "detached"
bit up in the API chain to let callers of interpret_branch_name() to
know about the distinction.

 sha1_name.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..3dd6667 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -862,6 +862,7 @@ static int get_sha1_oneline(const char *prefix, unsigned 
char *sha1,
 struct grab_nth_branch_switch_cbdata {
int remaining;
struct strbuf buf;
+   int detached;
 };
 
 static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
@@ -880,9 +881,14 @@ static int grab_nth_branch_switch(unsigned char *osha1, 
unsigned char *nsha1,
if (!match || !target)
return 0;
if (--(cb->remaining) == 0) {
+   unsigned char sha1[20];
+
len = target - match;
strbuf_reset(&cb->buf);
strbuf_add(&cb->buf, match, len);
+   cb->detached = (len == 40 &&
+   !get_sha1_hex(match, sha1) &&
+   !hashcmp(osha1, sha1));
return 1; /* we are done */
}
return 0;
@@ -892,7 +898,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, 
unsigned char *nsha1,
  * Parse @{-N} syntax, return the number of characters parsed
  * if successful; otherwise signal an error with negative value.
  */
-static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf)
+static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf, 
int *detached)
 {
long nth;
int retval;
@@ -917,6 +923,8 @@ static int interpret_nth_prior_checkout(const char *name, 
struct strbuf *buf)
if (0 < for_each_reflog_ent_reverse("HEAD", grab_nth_branch_switch, 
&cb)) {
strbuf_reset(buf);
strbuf_add(buf, cb.buf.buf, cb.buf.len);
+   if (detached)
+   *detached = cb.detached;
retval = brace - name + 1;
}
 
@@ -992,7 +1000,7 @@ int interpret_branch_name(const char *name, struct strbuf 
*buf)
char *cp;
struct branch *upstream;
int namelen = strlen(name);
-   int len = interpret_nth_prior_checkout(name, buf);
+   int len = interpret_nth_prior_checkout(name, buf, NULL);
int tmp_len;
 
if (!len)
--
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 10/11] sha1_name: reorganize get_sha1_basic()

[Junio C Hamano]

Felipe Contreras  writes:

> Through the years the functionality to handle @{-N} and @{u} has moved
> around the code, and as a result, code that once made sense, doesn't any
> more.
>
> There is no need to call this function recursively with the branch of
> @{-N} substituted because dwim_{ref,log} already replaces it.
>
> However, there's one corner-case where @{-N} resolves to a detached
> HEAD, in which case we wouldn't get any ref back.
>
> So we parse the nth-prior manually, and deal with it depending on
> weather it's a SHA-1, or a ref.
> ...

s/weather/whether/;

> @@ -447,6 +448,10 @@ static int get_sha1_basic(const char *str, int len, 
> unsigned char *sha1)
>   if (len && str[len-1] == '}') {
>   for (at = len-4; at >= 0; at--) {
>   if (str[at] == '@' && str[at+1] == '{') {
> + if (at == 0 && str[2] == '-') {
> + nth_prior = 1;
> + continue;
> + }

Does this have to be inside the loop?

> @@ -460,19 +465,22 @@ static int get_sha1_basic(const char *str, int len, 
> unsigned char *sha1)
>   if (len && ambiguous_path(str, len))
>   return -1;
>  
> - if (!len && reflog_len) {
> + if (nth_prior) {
>   struct strbuf buf = STRBUF_INIT;
> - int ret;
> - /* try the @{-N} syntax for n-th checkout */
> - ret = interpret_branch_name(str, &buf);
> - if (ret > 0)
> - /* substitute this branch name and restart */
> - return get_sha1_1(buf.buf, buf.len, sha1, 0);
> - else if (ret == 0)
> - return -1;
> + int detached;
> +
> + if (interpret_nth_prior_checkout(str, &buf) > 0) {
> + detached = (buf.len == 40 && !get_sha1_hex(buf.buf, 
> sha1));
> + strbuf_release(&buf);
> + if (detached)
> + return 0;
> + }
> + }

Earlier, if @{-N} resolved to a detached head, we just fed it to
get_sha1_1().  If it resolved to a concrete refname, we also fed it
to get_sha1_1().  We ended up calling ourselves again and did the
right thing either way.

The new code bypasses the recursive call when we get a detached head
back, because we know that calling get_sha1_1() with the 40-hex will
eventually take us back to this codepath, and immediately return
when it sees get_sha1_hex() succeeds.

What happens when str @{-N} leaves a concrete refname in buf.buf?
The branch name is lost with strbuf_release(), and then where do we
go from here?  Continuing down from here would run dwim_ref/log on
str which is still @{-N}, no?

Ahh, OK, the new code will now let dwim_ref/log to process @{-N}
again (the log message hints this but it wasn't all that clear), so
even though we already learned the branch name in buf here and
discard it, we will eventually discover the same information later.

That is somewhat contrived, and I am not so sure if that is a good
reorganization.

Also, a few points this patch highlights in the code before the
change:

 - If we were on a branch with 40-hex name at nth prior checkout,
   would we mistake it as being detached at the commit?

 - If we were on a branch 'foo' at nth prior checkout, would our
   previous get_sha1_1() have made us mistake it as referring to a
   tag 'foo' with the same name if it exists?

The former needs a fix to either writing of reflog or reading by
interpret_nth_prior_checkout() so that we can tell these cases apart
more reliably.  Then the latter can be solved by splicing
refs/heads/ in front of the branch name before recursively calling
get_sha1_1() in the original code (and similar fix can be
forward-ported to this patch).

Incidentally, I think if we prefix refs/heads/ in front and feed
that to dwim_ref/log, we would also avoid running @{-N} twice (which
I suspect might be more expensive than a simple recursion, as it
needs to go through the reflog file), which may be a nice side
effect of such a fix we would get for free.

> +
> + if (!len && reflog_len)
>   /* allow "@{...}" to mean the current branch reflog */
>   refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
> - } else if (reflog_len)
> + else if (reflog_len)
>   refs_found = dwim_log(str, len, sha1, &real_ref);
>   else
>   refs_found = dwim_ref(str, len, sha1, &real_ref);
--
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 v7 04/10] git-clean: use a git-add-interactive compatible UI

[Junio C Hamano]

Nice (I didn't read the code, though).
--
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 v7 02/10] Show items of interactive git-clean in columns

[Junio C Hamano]

Nice (I didn't read the code, though).
--
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 v7 01/10] Add support for -i/--interactive to git-clean

[Junio C Hamano]

Jiang Xin  writes:

> Show what would be done and the user must confirm before actually
> cleaning. In the confirmation dialog, the user has three choices:
>
>  * y/yes:  Start to do cleaning.
>  * n/no:   Nothing will be deleted.
>  * e/edit: Exclude items from deletion using ignore patterns.
>
> When the user chooses the edit mode, the user can input space-
> separated patterns (the same syntax as gitignore), and each clean
> candidate that matches with one of the patterns will be excluded
> from cleaning. When the user feels it's OK, presses ENTER and back
> to the confirmation dialog.
>
> Signed-off-by: Jiang Xin 
> Suggested-by: Junio C Hamano 
> Spelling-checked-by: Eric Sunshine 
> Comments-by: Matthieu Moy 
> Suggested-by: Eric Sunshine 

Listing everybody who has ever said anything in the review thread?
I can understand that you may want to give credit to those who
significantly helped, but please do not overdo it.

In any case, with the help of their inputs, you brought the patch
into its final shape.  Please sign-off at the _end_.

> ---
>  Documentation/git-clean.txt |  15 +++-
>  builtin/clean.c | 198 
> +++-
>  2 files changed, 192 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index bdc3a..f5572 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
>  SYNOPSIS
>  
>  [verse]
> -'git clean' [-d] [-f] [-n] [-q] [-e ] [-x | -X] [--] ...
> +'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ...
>  
>  DESCRIPTION
>  ---
> @@ -34,7 +34,18 @@ OPTIONS
>  -f::
>  --force::
>   If the Git configuration variable clean.requireForce is not set
> - to false, 'git clean' will refuse to run unless given -f or -n.
> + to false, 'git clean' will refuse to run unless given -f, -n or
> + -i.
> +
> +-i::
> +--interactive::
> + Show what would be done and the user must confirm before actually
> + cleaning. In the confirmation dialog, the user can choose to abort
> + the cleaning, or enter into an edit mode. In the edit mode, the
> + user can input space-separated patterns (the same syntax as
> + gitignore), and each clean candidate that matches with one of the
> + patterns will be excluded from cleaning. When the user feels it's
> + OK, presses ENTER and back to the confirmation dialog.
>  
>  -n::
>  --dry-run::
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 04e39..49aab 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -15,9 +15,12 @@
>  #include "quote.h"
>  
>  static int force = -1; /* unset */
> +static int interactive;
> +static struct string_list del_list = STRING_LIST_INIT_DUP;
> +static const char **the_prefix;

Ehh, why?

>  static const char *const builtin_clean_usage[] = {
> - N_("git clean [-d] [-f] [-n] [-q] [-e ] [-x | -X] [--] 
> ..."),
> + N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] 
> ..."),
>   NULL
>  };
>  
> @@ -142,6 +145,139 @@ static int remove_dirs(struct strbuf *path, const char 
> *prefix, int force_flag,
>   return ret;
>  }
>  
> +static void edit_by_patterns_cmd()

static void edit_by_patterns_cmd(void)

> +{
> + struct dir_struct dir;
> + struct strbuf confirm = STRBUF_INIT;
> + struct strbuf buf = STRBUF_INIT;
> + struct strbuf **ignore_list;
> + struct string_list_item *item;
> + struct exclude_list *el;
> + const char *qname;
> + int changed = -1, i;
> +
> + while (1) {
> + /* dels list may become empty when we run 
> string_list_remove_empty_items later */

An unnecessary and overlong comment.  The message shown already
tells the reader what is going on anyway, no?

> + if (!del_list.nr) {
> + printf_ln(_("No more files to clean, exiting."));
> + break;
> + }
> +
> + if (changed) {
> + putchar('\n');
> +
> + /* Display dels in "Would remove ..." format */
> + for_each_string_list_item(item, &del_list) {
> + qname = quote_path_relative(item->string, -1, 
> &buf, *the_prefix);
> + printf(_(msg_would_remove), qname);
> + }
> + putchar('\n');
> + }
> +
> + printf(_("Input ignore patterns>> "));
> + if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
> + strbuf_trim(&confirm);
> + } else {
> + putchar('\n');
> + break;

Why break here?  If we got nothing, wouldn't confirm.len be zero?
If we did get something but the input got flushed without line-end,
sending '\n' to the terminal may be justified, but in that case you
would may have something useful, and asking confirm.len i

Avoiding broken Gitweb links and deleted objects

[Matt McClure]

On Wed, May 8, 2013 at 12:05 PM, Matt McClure  wrote:
> On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt  wrote:
>> git gc moves unreachable objects that were packed before to the loose
>> object store, from where they can be pruned.
>
> Thanks. That was the piece I was missing. I assumed `git gc` did the opposite.

That begs a follow-up question. It sounds as though Git will typically
delete unreachable objects. My team often shares links like
https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90
. If I later rebase the branch containing those commits and d590517
becomes unreachable, do I risk that link breaking when Git deletes
d590517?

What's a good strategy for avoiding breaking those links?

-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
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 v7 00/10] interactive git clean

[Junio C Hamano]

Eric Sunshine  writes:

> On Wed, May 8, 2013 at 7:38 AM, Jiang Xin  wrote:
>> When the command enters the interactive mode, it shows the
>> files and directories to be cleaned, and goes into its
>> interactive command loop.
>
> Your current implementation only allows excluding items from the list
> of files to delete. If you accidentally exclude some file which you
> actually want in the deletion list, there is no way to re-add it.

If you accidentally dropped items from the list, is it such a big
deal?  I would imagine, if I were in that situation, that I would
simply continue and concentrate on making sure the remaining list
does not include anything I want to keep, clean them and then run
the command again, at which point the list of untracked paths in the
list will be much smaller.

We cannot make the same argument against the approach to first
present a list and _remove_ items that should not be dropped. That
is a genuine improvement, without which you cannot do a similar
incremental removal, whose first invocation removes only a subset
(but still a subset with no precious files you need to keep) of
files to allow the list subsequent invocations presents to *shrink*.

Cleaning all unneeded files inside a single interactive session
should *never* be the goal---that will lead to an over-engineered
design (e.g. switching "clean -x" flags in the middle? why?).  I
think Jiang's latest series is already way over-engineered, and I
suspect your suggestion leads it more into that direction.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git prune` doc or implementation defect, or user misunderstanding

[Matt McClure]

On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt  wrote:
> git gc moves unreachable objects that were packed before to the loose
> object store, from where they can be pruned.

Thanks. That was the piece I was missing. I assumed `git gc` did the opposite.

-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
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 v7 00/10] interactive git clean

[Eric Sunshine]

On Wed, May 8, 2013 at 11:15 AM, Eric Sunshine  wrote:
> On Wed, May 8, 2013 at 7:38 AM, Jiang Xin  wrote:
>> *** Commands ***
>>   1: clean   2: edit by patterns3: edit by numbers 
>> 4: rm -i
>>   5: flags: none 6: quit7: help
>> What now> 2
>>
>> You also could say `c` or `clean` above as long as the choice is unique.
>
> It is not obvious by reading the menu that "edit by patterns" can be
> abbreviated as 'p', and "edit by numbers" by 'n'. If you change the
> names a bit, then the abbreviations become more obvious. For instance,
> one possibility:
>
>   2. filter by pattern
>   3. select by number
>   5. toggle flags: none

By "more obvious", I meant that the initial letter of each option is
now unique across the entire menu:

  2. [f]ilter by pattern
  3. [s]elect by number
  4. [t]oggle flags: none
--
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 v7 00/10] interactive git clean

[Eric Sunshine]

On Wed, May 8, 2013 at 7:38 AM, Jiang Xin  wrote:
> When the command enters the interactive mode, it shows the
> files and directories to be cleaned, and goes into its
> interactive command loop.

Your current implementation only allows excluding items from the list
of files to delete. If you accidentally exclude some file which you
actually want in the deletion list, there is no way to re-add it.
Would it make sense to change the behavior so that it lists all files
but stars those which are to be deleted. This is similar to how the
"edit by numbers" mode operates, but would apply to the deletion list
printed for the top-level menu as well. For example:

  Will remove starred items:
file1  *file2  *file3
*file4  file5  file6
  *** Commands ***
  ...
  What now> clean
  Removing file2
  Removing file3
  Removing file4

> The command loop shows the list of subcommands available, and
> gives a prompt "What now> ".  In general, when the prompt ends
> with a single '>', you can pick only one of the choices given
> and type return, like this:
>
> *** Commands ***
>   1: clean   2: edit by patterns3: edit by numbers 4: 
> rm -i
>   5: flags: none 6: quit7: help
> What now> 2
>
> You also could say `c` or `clean` above as long as the choice is unique.

It is not obvious by reading the menu that "edit by patterns" can be
abbreviated as 'p', and "edit by numbers" by 'n'. If you change the
names a bit, then the abbreviations become more obvious. For instance,
one possibility:

  2. filter by pattern
  3. select by number
  5. toggle flags: none

Also, the abbreviation 'i' for "rm -i" is not obvious.

> edit by patterns::
>
>This shows the files and directories to be deleted and issues an
>"Input ignore patterns>>" prompt. You can input a space-seperated
>patterns to exclude files and directories from deletion.
>E.g. "*.c *.h" will excludes files end with ".c" and ".h" from
>deletion. When you are satisfied with the filtered result, press
>ENTER (empty) back to the main menu.
>
> edit by numbers::
>
>This shows the files and directories to be deleted and issues an
>"Select items to delete>>" prompt. When the prompt ends with double
>'>>' like this, you can make more than one selection, concatenated
>with whitespace or comma.  Also you can say ranges.  E.g. "2-5 7,9"
>to choose 2,3,4,5,7,9 from the list.  If the second number in a
>range is omitted, all remaining patches are taken.  E.g. "7-" to
>choose 7,8,9 from the list.  You can say '*' to choose everything.
>Also when you are satisfied with the filtered result, press ENTER
>(empty) back to the main menu.

It seems odd that "edit by patterns" _excludes_ files from deletion,
but "edit by patterns" _includes_ them in the deletion list. These
opposing behaviors force the user to invert his mode of thought when
editing by patterns vs. numbers. While playing with "edit by numbers",
I repeatedly found myself incorrectly inputting numbers of items I
wanted to exclude rather than those I wanted to keep in the list,
since my brain had not made the 180 degree flip from "edit by
patterns".

More generally, there are cases when it is more convenient to filter
the list by exclusion, and other cases when inclusion is more
convenient. For example, in a list of 20 files, I may want to delete
18 but keep 2. In this case, it typically is easier to specify the two
I want to keep. On the other hand, if I want to delete 2 files but
keep 18, it may be easier to specify the two I want to delete. Would
it makes sense to support pattern negation (via '!' perhaps) in order
to make this possible?

One thing not mentioned here is that "edit by numbers" (as with
git-add-interactive) also accepts input "foo" to match item "foo" in
the list. This suggests that it might make sense to accept patterns
also, so that "*oo" can match "foo". This, together with negation and
the idea mentioned above of always listing all files and only deleting
starred ones, would allow you to combine "edit by patterns" and "edit
by numbers" into a single mode of operation.

> rm -i::
>
>   This will show a "rm -i" style cleaning, that you must confirm one
>   by one in order to delete items. This action is not as efficient
>   as the above two actions.

The name "rm -i" is rather Unixy, and Windows users might not
understand it, nor people who don't use rm's -i option. Other
potentially better names might be: "ask", "ask each", "confirm",
"confirm each", "prompt", or "prompt each".

Functionally, the current implementation of this mode makes it an
oddball. "edit by patterns" and "edit by numbers" both return to the
top-level menu, allowing the user to invoke "clean" or "quit" (or some
other option), but "rm -i" always finishes by running "clean"
unconditionally. This is strangely inconsistent. Shouldn't it also
return to the top-level menu to give the user an opportunity to review
the final se

Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Torsten Bögershausen]

On 2013-05-08 02.30, Mark Levedahl wrote:
> On 05/07/2013 10:27 AM, Torsten Bögershausen wrote:
>> On 2013-05-04 01.14, Junio C Hamano wrote:
>>>
>>>   Cygwin portability; both were reviewed by Jonathan, and the tip one
>>>   seems to want a bit further explanation.  Needs positive report
>>>   from Cygwin 1.7 users who have been on 1.7 to make sure it does not
>>>   regress for them.
>>
>> I was trying to verify that cygwin 1.7 is still Ok, but got puzzled.
>>
>> Running the test suite under cygwin doesn't seem to work any more (?):
>>
>> Scenario 1:
>> The PC is running alone, and goes into the screen saver.
>> Pressing CTRL-ALT-DEL didn't get any effect.
>>
>> Scenario 2:
>> The PC didn't react any more, when the test suite was run in background.
>> In 3 or 4 cases the PC needed to be reboot hardly.
>>
>> Using the commits before and after this change makes the test suite hang
>> as well at some point, then it hangs somewhere at TC 3000--4000.
>>
>> Scenario 4:
>> The I disabled the screensaver, upgdated cygwin,
>>   and went back to an older commit:
>> The latest run from commit 52d63e70, April 28,
>> hangs in TC 5500, ok 26 clone shallow object count.
>>
>> I can see 2 times
>> git.exe pull --depth 4 ..A
>>
>> Scenario 5:
>> The run of today 1.8.3-rc1, hangs in t5510,
>> some git.exe are running fetch. (or pull)
>>
>>
>> It seems as if some process/exes are not terminated
>> in the way it should be.
>>
>> I will try on a different machine,
>> comments are wellcome
>> /Torsten
>>
> 
> I have run into very similar problems trying to test these patches, so I 
> declined to reply thinking someone else might have better or at least 
> explicable results. I am able to build git on cygwin 1.7 using the proposed 
> patches, it seems to work, but I've run into strange problems such as the 
> main git repo becoming corrupted, no idea how or why.
> 
> Mark

I tried 1.8.3-rc1 on a different PC, and it seems to have the same hanging.
So I will do some bisecting on master, and try to find out more.


 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git prune` doc or implementation defect, or user misunderstanding

[Johannes Sixt]

Am 5/8/2013 16:19, schrieb Matt McClure:
> My interpretation of that is that `git prune` will not prune packed objects
> by default. The following behavior seems inconsistent with that
> interpretation.
> 
> [git@438587-beefcake01 panama.git]$ git prune -n | wc -l
> 9210

You have 9210 unreachable, loose objects.

> [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l
> 9468

You have 9468 unreachable objects in total.

> [git@438587-beefcake01 panama.git]$ git gc --no-prune
> Counting objects: 531223, done.
> Delta compression using up to 24 threads.
> Compressing objects: 100% (109848/109848), done.
> Writing objects: 100% (531223/531223), done.
> Total 531223 (delta 405288), reused 530894 (delta 404961)

Only reachable objects go into the new pack. Unreachable objects that were
in the pack before, are evicted and are now loose.

> [git@438587-beefcake01 panama.git]$ git prune -n | wc -l
> 9468
> [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l
> 9468

Now all 9468 unreachable objects are loose and eligible for being pruned.

> It looks like `git prune -n` is telling me that it would prune the objects
> that I just packed. What am I misunderstanding?

git gc moves unreachable objects that were packed before to the loose
object store, from where they can be pruned.

-- Hannes
--
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: 3 way merge during git p4 rebase is attempting to reapply past commits

[Christopher Yee Mon]

git p4 rebase and git p4 submit don't work on a bare repo (at least it
didn't for me) This is weird since there is a --bare option for git p4
clone, but then you can't do git p4 submit's on that bare repo back up
to perforce?

I got an error stating:

git p4 rebase
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/path.to/folder/
No changes to import!
fatal: This operation must be run in a work tree
Some files in your working directory are modified and different than
what is in your index. You can use git update-index  to
bring the index up-to-date or stash away all your changes with git
stash.

And I got this error for git p4 submit stating

Perforce checkout for depot path //depot/path.to/folder/ located at
/home/user1/path/to/perforce.folder/
Synchronizing p4 checkout...
... - file(s) up-to-date.
fatal: Not a git repository: '.'
Command failed: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']

http://stackoverflow.com/questions/15512357/how-to-run-git-p4-submit-on-a-bare-repo
(The workaround described seemed particularly convoluted.)

My only (simple) workaround for that is doing the git checkout -f and
git clean -f before and after doing git p4 rebase and git p4 submit (
http://stackoverflow.com/questions/15512700/replace-working-copy-of-git-repo-with-actual-contents-of-repo-in-git
)

I've encountered so many errors over time that I can't trust to leave
the operation scheduled, because some problem like this might crop up
again.

On Wed, May 8, 2013 at 1:35 AM, Luke Diamand  wrote:
> On 08/05/13 00:12, Christopher Yee Mon wrote:
>>
>> Hello,
>>
>> I have a setup where I have a remote non-bare repo cloned from a
>> perforce workspace. It is used as a remote repo that people clone into
>> their own user repos, make commits to, then push back into the remote
>> repo.
>
> Why is your p4 clone non-bare? I thought pushing into a non-bare repo tended
> to cause problems?
>
>
>> Then I periodically run the following commands in a script to
>> push those changes back to perforce.
>
> % man cron
>
> :-)
>
>
>>
>> git checkout -f
>> git clean -f
>> git p4 rebase --import-labels
>> git p4 submit -M --export-labels
>> git checkout -f
>> git clean -f
>>
>> Sometimes, always after commits from one user's machine specifically,
>> I get the following error below when pushing back to perforce at the
>> remote repo. It seems to happen randomly, or at least intermittently,
>> since I often can't discern any major error during git committing to
>> the remote repo that precipitates this error. It does happen pretty
>> reliably when I get a file conflict that I resolve and fix during
>> committing though.
>>
>> Performing incremental import into refs/remotes/p4/master git branch
>> Depot paths: //depot/sub/folder/
>> No changes to import!
>> Rebasing the current branch onto remotes/p4/master
>> First, rewinding head to replay your work on top of it...
>> Applying: A commit that has already been made previously
>> Applying: A second commit that has already been made in a previous commit
>> Using index info to reconstruct a base tree...
>> :15: space before tab in indent.
>>  a line of text
>> :24: space before tab in indent.
>>  another line of text
>> :25: space before tab in indent.
>>  a third line of text
>> :33: trailing whitespace.
>>  a forth line of text
>> :71: trailing whitespace.
>>
>> warning: squelched 1 whitespace error
>> warning: 6 lines add whitespace errors.
>> Falling back to patching base and 3-way merge...
>> Auto-merging file from second
>> CONFLICT (content): Merge conflict in
>> a/file/in/the/second/pre-existing/commit/file.php
>> Auto-merging a/file/in/the/second/pre-existing/commit/file.php
>> Failed to merge in the changes.
>> Patch failed at 0002 A second commit that has already been made in a
>> previous commit
>>
>> When you have resolved this problem run "git rebase --continue".
>> If you would prefer to skip this patch, instead run "git rebase --skip".
>> To check out the original branch and stop rebasing run "git rebase
>> --abort".
>>
>> Traceback (most recent call last):
>>File "/usr/lib/git-core/git-p4", line 3373, in
>>  main()
>>File "/usr/lib/git-core/git-p4", line 3367, in main
>>  if not cmd.run(args):
>>File "/usr/lib/git-core/git-p4", line 3150, in run
>>  return self.rebase()
>>File "/usr/lib/git-core/git-p4", line 3167, in rebase
>>  system("git rebase %s" % upstream)
>>File "/usr/lib/git-core/git-p4", line 183, in system
>>  raise CalledProcessError(retcode, cmd)
>> subprocess.CalledProcessError: Command 'git rebase remotes/p4/master'
>> returned non-zero exit status 1
>>
>> The patch is usually one that is already in the remote git repo and in
>> perforce. At that point I have to run git rebase --skip, to skip the
>> patch, then rerun the commands in the script again. Sometimes it's
>> multiple patches that cause this p

`git prune` doc or implementation defect, or user misunderstanding

[Matt McClure]

The `git prune` documentation says:

   This runs git fsck --unreachable using all the refs
   available in refs/, optionally with additional set of
   objects specified on the command line, and prunes all
   unpacked objects unreachable from any of these head
   objects from the object database. In addition, it prunes
   the unpacked objects that are also found in packs by
   running git prune-packed.

   Note that unreachable, packed objects will remain. If this
   is not desired, see git-repack(1).

My interpretation of that is that `git prune` will not prune packed objects
by default. The following behavior seems inconsistent with that
interpretation.

[git@438587-beefcake01 panama.git]$ git prune -n | wc -l
9210
[git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l
9468
[git@438587-beefcake01 panama.git]$ git gc --no-prune
Counting objects: 531223, done.
Delta compression using up to 24 threads.
Compressing objects: 100% (109848/109848), done.
Writing objects: 100% (531223/531223), done.
Total 531223 (delta 405288), reused 530894 (delta 404961)
[git@438587-beefcake01 panama.git]$ git prune -n | wc -l
9468
[git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l
9468

It looks like `git prune -n` is telling me that it would prune the objects
that I just packed. What am I misunderstanding?

--
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
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 v7 10/10] git-clean: change clean flags in interactive mode

[Jiang Xin]

Add new action in the interactive mode, so that the user can change
git-clean flags, such as -x/-X/-d/-ff, and refresh the cleaning
candidates list.

Signed-off-by: Jiang Xin 
---
 Documentation/git-clean.txt |  11 +++--
 builtin/clean.c | 117 +---
 2 files changed, 108 insertions(+), 20 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 47e8e..c7885 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -82,14 +82,14 @@ and type return, like this:
 
 
 *** Commands ***
-  1: clean 2: edit by patterns   3: edit by numbers
-  4. rm -i 5. quit   6. help
+  1: clean   2: edit by patterns3: edit by numbers 4: 
rm -i
+  5: flags: none 6: quit7: help
 What now> 2
 
 
 You also could say `c` or `clean` above as long as the choice is unique.
 
-The main command loop has 6 subcommands.
+The main command loop has 7 subcommands.
 
 clean::
 
@@ -122,6 +122,11 @@ rm -i::
   by one in order to delete items. This action is not as efficient
   as the above two actions.
 
+flags::
+
+  This lets you change the flags for git-clean, such as -x/-X/-d/-ff,
+  and refresh the cleaning candidates list automatically.
+
 quit::
 
   This lets you quit without do cleaning.
diff --git a/builtin/clean.c b/builtin/clean.c
index 0d8561..b2941 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -850,6 +850,66 @@ static int rm_i_cmd()
return MENU_RETURN_NO_LOOP;
 }
 
+static int flags_cmd()
+{
+   struct menu_opts menu_opts;
+   struct menu_stuff menu_stuff;
+   struct menu_item menus[] = {
+   {'d', "(-d) remove directories",
+   clean_flags & CLEAN_OPTS_REMOVE_DIRECTORIES,NULL},
+   {'x', "(-x) show ignored",
+   clean_flags & CLEAN_OPTS_SHOW_IGNORED,  NULL},
+   {'X', "(-X) ignored only",
+   clean_flags & CLEAN_OPTS_IGNORED_ONLY,  NULL},
+   {'f', "(-ff) remove nested.git",
+   clean_flags & CLEAN_OPTS_REMOVE_NESTED_GIT, NULL},
+   };
+   int new_flags = 0;
+   int *chosen;
+   int i;
+
+   menu_opts.header = NULL;
+   menu_opts.prompt = "Change flags";
+   menu_opts.flag = 0;
+
+   menu_stuff.type = MENU_STUFF_TYPE_MENU_ITEM;
+   menu_stuff.stuff = menus;
+   menu_stuff.nr = sizeof(menus) / sizeof(struct menu_item);
+
+   chosen = list_and_choose(&menu_opts, &menu_stuff);
+
+   for (i = 0; chosen[i] != EOF; i++) {
+   switch (chosen[i]) {
+   case 0:
+   new_flags |= CLEAN_OPTS_REMOVE_DIRECTORIES;
+   break;
+   case 1:
+   new_flags |= CLEAN_OPTS_SHOW_IGNORED;
+   break;
+   case 2:
+   new_flags |= CLEAN_OPTS_IGNORED_ONLY;
+   break;
+   case 3:
+   new_flags |= CLEAN_OPTS_REMOVE_NESTED_GIT;
+   break;
+   default:
+   break;
+   }
+   }
+
+   if (new_flags & CLEAN_OPTS_IGNORED_ONLY &&
+   new_flags & CLEAN_OPTS_SHOW_IGNORED) {
+   clean_print_color(CLEAN_COLOR_ERROR);
+   printf_ln(_("-x and -X cannot be used together"));
+   clean_print_color(CLEAN_COLOR_RESET);
+   } else {
+   clean_flags = new_flags;
+   }
+
+   free(chosen);
+   return 0;
+}
+
 static int quit_cmd()
 {
string_list_clear(&del_list, 0);
@@ -865,6 +925,7 @@ static int help_cmd(int x)
"edit by patterns - exclude items from deletion\n"
"edit by numbers  - select items to be deleted by numbers\n"
"rm -i- delete items one by one, like \"rm 
-i\"\n"
+   "flags- change git-clean flags and update the 
cleaning candidates\n"
"quit - stop cleaning\n"
"help - this screen\n"
"?- help for prompt selection"
@@ -873,10 +934,13 @@ static int help_cmd(int x)
return 0;
 }
 
-static void interactive_main_loop()
+static void interactive_main_loop(const char **pathspec, struct string_list 
exclude_list)
 {
+   int cached_clean_flags = clean_flags;
+   char flags_title[20];
+
/* dels list may become empty after return back from edit mode */
-   while (del_list.nr) {
+   while (1) {
struct menu_opts menu_opts;
struct menu_stuff menu_stuff;
struct menu_item menus[] = {
@@ -884,11 +948,24 @@ static void interactive_main_loop()
{'p', "edit by patterns",   0, 
edit_by_patterns_cmd},

[PATCH v7 08/10] git-clean refactor: save some options in clean_flags

[Jiang Xin]

Save some options in variable clean_flags, such as -ff (force > 1),
-x (ignored), -X (ignored_only), and -d (remove_directories). We may
change clean_flags later in the interactive git-clean.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 46 +++---
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 5bb36..d46f3 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -16,7 +16,13 @@
 #include "column.h"
 #include "color.h"
 
+#define CLEAN_OPTS_SHOW_IGNORED01
+#define CLEAN_OPTS_IGNORED_ONLY02
+#define CLEAN_OPTS_REMOVE_DIRECTORIES  04
+#define CLEAN_OPTS_REMOVE_NESTED_GIT   010
+
 static int force = -1; /* unset */
+static int clean_flags = 0;
 static int interactive;
 static struct string_list del_list = STRING_LIST_INIT_DUP;
 static const char **the_prefix;
@@ -843,7 +849,6 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
int i, res;
int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, config_set = 0, errors = 0, gone = 1;
-   int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf directory = STRBUF_INIT;
struct dir_struct dir;
static const char **pathspec;
@@ -879,13 +884,6 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
argc = parse_options(argc, argv, *the_prefix, options, 
builtin_clean_usage,
 0);
 
-   memset(&dir, 0, sizeof(dir));
-   if (ignored_only)
-   dir.flags |= DIR_SHOW_IGNORED;
-
-   if (ignored && ignored_only)
-   die(_("-x and -X cannot be used together"));
-
if (interactive) {
if (!isatty(0) || !isatty(1))
die(_("interactive clean can not run without a valid 
tty; "
@@ -899,15 +897,29 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
  "refusing to clean"));
}
 
+   if (read_cache() < 0)
+   die(_("index file corrupt"));
+
if (force > 1)
-   rm_flags = 0;
+   clean_flags |= CLEAN_OPTS_REMOVE_NESTED_GIT;
+   if (ignored)
+   clean_flags |= CLEAN_OPTS_SHOW_IGNORED;
+   if (ignored_only)
+   clean_flags |= CLEAN_OPTS_IGNORED_ONLY;
+   if (remove_directories)
+   clean_flags |= CLEAN_OPTS_REMOVE_DIRECTORIES;
 
-   dir.flags |= DIR_SHOW_OTHER_DIRECTORIES;
+   memset(&dir, 0, sizeof(dir));
+   if (clean_flags & CLEAN_OPTS_IGNORED_ONLY)
+   dir.flags |= DIR_SHOW_IGNORED;
 
-   if (read_cache() < 0)
-   die(_("index file corrupt"));
+   if (clean_flags & CLEAN_OPTS_IGNORED_ONLY &&
+   clean_flags & CLEAN_OPTS_SHOW_IGNORED)
+   die(_("-x and -X cannot be used together"));
+
+   dir.flags |= DIR_SHOW_OTHER_DIRECTORIES;
 
-   if (!ignored)
+   if (!(clean_flags & CLEAN_OPTS_SHOW_IGNORED))
setup_standard_excludes(&dir);
 
el = add_exclude_list(&dir, EXC_CMDL, "--exclude option");
@@ -961,7 +973,8 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
}
 
if (S_ISDIR(st.st_mode)) {
-   if (remove_directories || (matches == MATCHED_EXACTLY))
+   if ((clean_flags & CLEAN_OPTS_REMOVE_DIRECTORIES) ||
+   (matches == MATCHED_EXACTLY))
string_list_append(&del_list, ent->name);
} else {
if (pathspec && !matches)
@@ -981,7 +994,10 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
 
if (S_ISDIR(st.st_mode)) {
strbuf_addstr(&directory, item->string);
-   if (remove_dirs(&directory, *the_prefix, rm_flags, 
dry_run, quiet, &gone))
+   if (remove_dirs(&directory, *the_prefix,
+   clean_flags & 
CLEAN_OPTS_REMOVE_NESTED_GIT ?
+   0 : REMOVE_DIR_KEEP_NESTED_GIT,
+   dry_run, quiet, &gone))
errors++;
if (gone && !quiet) {
qname = quote_path_relative(directory.buf, 
directory.len, &buf, *the_prefix);
-- 
1.8.3.rc1.341.g1c24ab7

--
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 v7 09/10] git-clean refactor: wrap in scan_clean_candidates

[Jiang Xin]

Add new function `scan_clean_candidates`, which determines the del_list
(i.e. the cleaning candidates). This function will be reused later in
the interactive git-clean, so we can change flags of git-clean and
refresh the del_list.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 169 ++--
 1 file changed, 92 insertions(+), 77 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index d46f3..0d8561 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -254,6 +254,95 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
return ret;
 }
 
+static void scan_clean_candidates(const char **pathspec, struct string_list 
exclude_list)
+{
+   struct dir_struct dir;
+   struct exclude_list *el;
+   char *seen = NULL;
+   const char **pathspec_p = pathspec;
+   int pathspec_nr = 0;
+   int i;
+
+   while (pathspec_p && *(pathspec_p++))
+   pathspec_nr++;
+
+   memset(&dir, 0, sizeof(dir));
+   if (clean_flags & CLEAN_OPTS_IGNORED_ONLY)
+   dir.flags |= DIR_SHOW_IGNORED;
+
+   if (clean_flags & CLEAN_OPTS_IGNORED_ONLY &&
+   clean_flags & CLEAN_OPTS_SHOW_IGNORED)
+   die(_("-x and -X cannot be used together"));
+
+   dir.flags |= DIR_SHOW_OTHER_DIRECTORIES;
+
+   if (!(clean_flags & CLEAN_OPTS_SHOW_IGNORED))
+   setup_standard_excludes(&dir);
+
+   el = add_exclude_list(&dir, EXC_CMDL, "--exclude option");
+   for (i = 0; i < exclude_list.nr; i++)
+   add_exclude(exclude_list.items[i].string, "", 0, el, -(i+1));
+
+   fill_directory(&dir, pathspec);
+
+   if (pathspec)
+   seen = xmalloc(pathspec_nr > 0 ? pathspec_nr : 1);
+
+   string_list_clear(&del_list, 0);
+
+   for (i = 0; i < dir.nr; i++) {
+   struct dir_entry *ent = dir.entries[i];
+   int len, pos;
+   int matches = 0;
+   struct cache_entry *ce;
+   struct stat st;
+
+   /*
+* Remove the '/' at the end that directory
+* walking adds for directory entries.
+*/
+   len = ent->len;
+   if (len && ent->name[len-1] == '/')
+   len--;
+   pos = cache_name_pos(ent->name, len);
+   if (0 <= pos)
+   continue;   /* exact match */
+   pos = -pos - 1;
+   if (pos < active_nr) {
+   ce = active_cache[pos];
+   if (ce_namelen(ce) == len &&
+   !memcmp(ce->name, ent->name, len))
+   continue; /* Yup, this one exists unmerged */
+   }
+
+   /*
+* we might have removed this as part of earlier
+* recursive directory removal, so lstat() here could
+* fail with ENOENT.
+*/
+   if (lstat(ent->name, &st))
+   continue;
+
+   if (pathspec) {
+   memset(seen, 0, pathspec_nr > 0 ? pathspec_nr : 1);
+   matches = match_pathspec(pathspec, ent->name, len,
+0, seen);
+   }
+
+   if (S_ISDIR(st.st_mode)) {
+   if ((clean_flags & CLEAN_OPTS_REMOVE_DIRECTORIES) ||
+   (matches == MATCHED_EXACTLY))
+   string_list_append(&del_list, ent->name);
+   } else {
+   if (pathspec && !matches)
+   continue;
+   string_list_append(&del_list, ent->name);
+   }
+   }
+
+   free(seen);
+}
+
 static void pretty_print_dels()
 {
struct string_list list = STRING_LIST_INIT_DUP;
@@ -846,18 +935,15 @@ static void interactive_main_loop()
 
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
-   int i, res;
+   int res;
int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, config_set = 0, errors = 0, gone = 1;
struct strbuf directory = STRBUF_INIT;
-   struct dir_struct dir;
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
-   struct string_list exclude_list = STRING_LIST_INIT_NODUP;
-   struct exclude_list *el;
struct string_list_item *item;
+   struct string_list exclude_list = STRING_LIST_INIT_NODUP;
const char *qname;
-   char *seen = NULL;
struct option options[] = {
OPT__QUIET(&quiet, N_("do not print names of files removed")),
OPT__DRY_RUN(&dry_run, N_("dry run")),
@@ -909,79 +995,9 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
if (remove_directories)
clean_flags |= CLEAN_OPTS_REMOVE_DIRECTORIES

[PATCH v7 07/10] git-clean: update document for interactive git-clean

[Jiang Xin]

Signed-off-by: Jiang Xin 
---
 Documentation/git-clean.txt | 70 -
 1 file changed, 63 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index f5572..47e8e 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -39,13 +39,8 @@ OPTIONS
 
 -i::
 --interactive::
-   Show what would be done and the user must confirm before actually
-   cleaning. In the confirmation dialog, the user can choose to abort
-   the cleaning, or enter into an edit mode. In the edit mode, the
-   user can input space-separated patterns (the same syntax as
-   gitignore), and each clean candidate that matches with one of the
-   patterns will be excluded from cleaning. When the user feels it's
-   OK, presses ENTER and back to the confirmation dialog.
+   Show what would be done and clean files interactively. See
+   ``Interactive mode'' for details.
 
 -n::
 --dry-run::
@@ -74,6 +69,67 @@ OPTIONS
Remove only files ignored by Git.  This may be useful to rebuild
everything from scratch, but keep manually created files.
 
+Interactive mode
+
+When the command enters the interactive mode, it shows the
+files and directories to be cleaned, and goes into its
+interactive command loop.
+
+The command loop shows the list of subcommands available, and
+gives a prompt "What now> ".  In general, when the prompt ends
+with a single '>', you can pick only one of the choices given
+and type return, like this:
+
+
+*** Commands ***
+  1: clean 2: edit by patterns   3: edit by numbers
+  4. rm -i 5. quit   6. help
+What now> 2
+
+
+You also could say `c` or `clean` above as long as the choice is unique.
+
+The main command loop has 6 subcommands.
+
+clean::
+
+   Start cleaning files and directories, and then quit.
+
+edit by patterns::
+
+   This shows the files and directories to be deleted and issues an
+   "Input ignore patterns>>" prompt. You can input a space-seperated
+   patterns to exclude files and directories from deletion.
+   E.g. "*.c *.h" will excludes files end with ".c" and ".h" from
+   deletion. When you are satisfied with the filtered result, press
+   ENTER (empty) back to the main menu.
+
+edit by numbers::
+
+   This shows the files and directories to be deleted and issues an
+   "Select items to delete>>" prompt. When the prompt ends with double
+   '>>' like this, you can make more than one selection, concatenated
+   with whitespace or comma.  Also you can say ranges.  E.g. "2-5 7,9"
+   to choose 2,3,4,5,7,9 from the list.  If the second number in a
+   range is omitted, all remaining patches are taken.  E.g. "7-" to
+   choose 7,8,9 from the list.  You can say '*' to choose everything.
+   Also when you are satisfied with the filtered result, press ENTER
+   (empty) back to the main menu.
+
+rm -i::
+
+  This will show a "rm -i" style cleaning, that you must confirm one
+  by one in order to delete items. This action is not as efficient
+  as the above two actions.
+
+quit::
+
+  This lets you quit without do cleaning.
+
+help::
+
+  Show brief usage of interactive git-clean.
+
 SEE ALSO
 
 linkgit:gitignore[5]
-- 
1.8.3.rc1.341.g1c24ab7

--
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 v7 06/10] git-clean: rm -i style interactive cleaning

[Jiang Xin]

Add a "rm -i" style interactive cleaning method. User must confirm one
by one before starting to delete.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 75e37..5bb36 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -721,6 +721,40 @@ static int edit_by_numbers_cmd()
return 0;
 }
 
+static int rm_i_cmd()
+{
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf buf = STRBUF_INIT;
+   struct string_list_item *item;
+   const char *qname;
+   int changed = 0, eof = 0;
+
+   for_each_string_list_item(item, &del_list) {
+   /* Ctrl-D should stop removing files */
+   if (!eof) {
+   qname = quote_path_relative(item->string, -1, &buf, 
*the_prefix);
+   printf(_("remove %s ? "), qname);
+   if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
+   strbuf_trim(&confirm);
+   } else {
+   putchar('\n');
+   eof = 1;
+   }
+   }
+   if (!confirm.len || !strncasecmp(confirm.buf, "no", 
confirm.len)) {
+   *item->string = '\0';
+   changed++;
+   }
+   }
+
+   if (changed)
+   string_list_remove_empty_items(&del_list, 0);
+
+   strbuf_release(&buf);
+   strbuf_release(&confirm);
+   return MENU_RETURN_NO_LOOP;
+}
+
 static int quit_cmd()
 {
string_list_clear(&del_list, 0);
@@ -735,6 +769,7 @@ static int help_cmd(int x)
"clean- start cleaning\n"
"edit by patterns - exclude items from deletion\n"
"edit by numbers  - select items to be deleted by numbers\n"
+   "rm -i- delete items one by one, like \"rm 
-i\"\n"
"quit - stop cleaning\n"
"help - this screen\n"
"?- help for prompt selection"
@@ -753,6 +788,7 @@ static void interactive_main_loop()
{'c', "clean",  0, clean_cmd},
{'p', "edit by patterns",   0, 
edit_by_patterns_cmd},
{'n', "edit by numbers",0, edit_by_numbers_cmd},
+   {'i', "rm -i",  0, rm_i_cmd},
{'q', "quit",   0, quit_cmd},
{'h', "help",   0, help_cmd},
};
-- 
1.8.3.rc1.341.g1c24ab7

--
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 v7 04/10] git-clean: use a git-add-interactive compatible UI

[Jiang Xin]

Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We can reused this method later for
more actions.

Please NOTE:

 * Method `list_and_choose` return an array of integers, and
 * it is up to you to free the allocated memory of the array.
 * The array ends with EOF.
 * If user pressed CTRL-D (i.e. EOF), no selection returned.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 469 +++-
 1 file changed, 428 insertions(+), 41 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 9b029..10f3 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -51,6 +51,36 @@ enum color_clean {
CLEAN_COLOR_ERROR = 5,
 };
 
+#define MENU_OPTS_SINGLETON01
+#define MENU_OPTS_IMMEDIATE02
+#define MENU_OPTS_LIST_ONLY04
+
+struct menu_opts {
+   const char *header;
+   const char *prompt;
+   int flag;
+};
+
+#define MENU_RETURN_NO_LOOP10
+
+struct menu_item {
+   char hotkey;
+   char *title;
+   int selected;
+   int (*fn)();
+};
+
+enum menu_stuff_type {
+   MENU_STUFF_TYPE_STRING_LIST = 1,
+   MENU_STUFF_TYPE_MENU_ITEM
+};
+
+struct menu_stuff {
+   enum menu_stuff_type type;
+   int nr;
+   void *stuff;
+};
+
 static int parse_clean_color_slot(const char *var, int ofs)
 {
if (!strcasecmp(var+ofs, "reset"))
@@ -240,12 +270,345 @@ static void pretty_print_dels()
copts.indent = "  ";
copts.padding = 2;
print_columns(&list, colopts, &copts);
-   putchar('\n');
strbuf_release(&buf);
string_list_clear(&list, 0);
 }
 
-static void edit_by_patterns_cmd()
+static void pretty_print_menus(struct string_list *menu_list)
+{
+   unsigned int local_colopts = 0;
+   struct column_options copts;
+
+   local_colopts = COL_ENABLED | COL_ROW;
+   memset(&copts, 0, sizeof(copts));
+   copts.indent = "  ";
+   copts.padding = 2;
+   print_columns(menu_list, local_colopts, &copts);
+}
+
+static void prompt_help_cmd(int singleton)
+{
+   clean_print_color(CLEAN_COLOR_HELP);
+   printf_ln(singleton ?
+ _("Prompt help:\n"
+   "1  - select a numbered item\n"
+   "foo- select item based on unique prefix\n"
+   "   - (empty) select nothing") :
+ _("Prompt help:\n"
+   "1  - select a single item\n"
+   "3-5- select a range of items\n"
+   "2-3,6-9- select multiple ranges\n"
+   "foo- select item based on unique prefix\n"
+   "-...   - unselect specified items\n"
+   "*  - choose all items\n"
+   "   - (empty) finish selecting"));
+   clean_print_color(CLEAN_COLOR_RESET);
+}
+
+/*
+ * display menu stuff with number prefix and hotkey highlight
+ */
+static void print_highlight_menu_stuff(struct menu_stuff *stuff, int **chosen)
+{
+   static struct string_list menu_list = STRING_LIST_INIT_DUP;
+   struct strbuf menu = STRBUF_INIT;
+   int i;
+
+   /* highlight hotkey in menu */
+   if (MENU_STUFF_TYPE_MENU_ITEM == stuff->type) {
+   struct menu_item *item;
+
+   item = (struct menu_item *)stuff->stuff;
+   for (i = 0; i < stuff->nr; i++, item++) {
+   char *p;
+   int highlighted = 0;
+
+   p = item->title;
+   if ((*chosen)[i] < 0)
+   (*chosen)[i] = item->selected ? 1 : 0;
+   strbuf_addf(&menu, "%s%2d: ", (*chosen)[i] ? "*" : " ", 
i+1);
+   for (; *p; p++) {
+   if (!highlighted && *p == item->hotkey) {
+   strbuf_addstr(&menu, 
clean_get_color(CLEAN_COLOR_PROMPT));
+   strbuf_addch(&menu, *p);
+   strbuf_addstr(&menu, 
clean_get_color(CLEAN_COLOR_RESET));
+   highlighted = 1;
+   } else {
+   strbuf_addch(&menu, *p);
+   }
+   }
+   string_list_append(&menu_list, menu.buf);
+   strbuf_reset(&menu);
+   }
+   } else if (MENU_STUFF_TYPE_STRING_LIST == stuff->type) {
+   struct string_list_item *item;
+   struct strbuf buf = STRBUF_INIT;
+   i = 0;
+
+   for_each_string_list_item(item, (struct string_list 
*)stuff->stuff) {
+   const char *qname;
+
+   if ((*chosen)[i] < 0)
+   (*chosen)[i] = 0;
+   qname = quote_path_relativ

[PATCH v7 05/10] git-clean: interactive cleaning by select numbers

[Jiang Xin]

Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.

User can input:

 *  1,5-7 : select 1,5,6,7 items to be deleted
 *  * : select all items to be deleted
 *  -*: unselect all, nothing will be deleted
 *: (empty) finish selecting, and return back to main menu

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 10f3..75e37 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -684,6 +684,43 @@ static int edit_by_patterns_cmd()
return 0;
 }
 
+static int edit_by_numbers_cmd()
+{
+   struct menu_opts menu_opts;
+   struct menu_stuff menu_stuff;
+   struct string_list_item *items;
+   int *chosen;
+   int i, j;
+
+   menu_opts.header = NULL;
+   menu_opts.prompt = "Select items to delete";
+   menu_opts.flag = 0;
+
+   menu_stuff.type = MENU_STUFF_TYPE_STRING_LIST;
+   menu_stuff.stuff = &del_list;
+   menu_stuff.nr = del_list.nr;
+
+   chosen = list_and_choose(&menu_opts, &menu_stuff);
+   items = del_list.items;
+   for(i = 0, j = 0; i < del_list.nr; i++) {
+   if (i < chosen[j]) {
+   *(items[i].string) = '\0';
+   } else if (i == chosen[j]) {
+   /* delete selected item */
+   j++;
+   continue;
+   } else {
+   /* end of chosen (EOF), won't delete */
+   *(items[i].string) = '\0';
+   }
+   }
+
+   string_list_remove_empty_items(&del_list, 0);
+
+   free(chosen);
+   return 0;
+}
+
 static int quit_cmd()
 {
string_list_clear(&del_list, 0);
@@ -697,6 +734,7 @@ static int help_cmd(int x)
printf_ln(_(
"clean- start cleaning\n"
"edit by patterns - exclude items from deletion\n"
+   "edit by numbers  - select items to be deleted by numbers\n"
"quit - stop cleaning\n"
"help - this screen\n"
"?- help for prompt selection"
@@ -714,6 +752,7 @@ static void interactive_main_loop()
struct menu_item menus[] = {
{'c', "clean",  0, clean_cmd},
{'p', "edit by patterns",   0, 
edit_by_patterns_cmd},
+   {'n', "edit by numbers",0, edit_by_numbers_cmd},
{'q', "quit",   0, quit_cmd},
{'h', "help",   0, help_cmd},
};
-- 
1.8.3.rc1.341.g1c24ab7

--
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 v7 03/10] Add colors to interactive git-clean

[Jiang Xin]

Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables for other git commands, such as
git-add--interactive and git-stash:

 * color.interactive: When set to always, always use colors for
   interactive prompts and displays. When false (or never),
   never. When set to true or auto, use colors only when the
   output is to the terminal.

 * color.interactive.: Use customized color for interactive
   git-clean output (like git add --interactive).  may be
   prompt, header, help or error.

Signed-off-by: Jiang Xin 
Comments-by: Matthieu Moy 
---
 builtin/clean.c | 78 -
 1 file changed, 77 insertions(+), 1 deletion(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 38ed0..9b029 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -14,6 +14,7 @@
 #include "string-list.h"
 #include "quote.h"
 #include "column.h"
+#include "color.h"
 
 static int force = -1; /* unset */
 static int interactive;
@@ -32,16 +33,81 @@ static const char *msg_skip_git_dir = N_("Skipping 
repository %s\n");
 static const char *msg_would_skip_git_dir = N_("Would skip repository %s\n");
 static const char *msg_warn_remove_failed = N_("failed to remove %s");
 
+static int clean_use_color = -1;
+static char clean_colors[][COLOR_MAXLEN] = {
+   GIT_COLOR_RESET,
+   GIT_COLOR_NORMAL,   /* PLAIN */
+   GIT_COLOR_BOLD_BLUE,/* PROMPT */
+   GIT_COLOR_BOLD, /* HEADER */
+   GIT_COLOR_BOLD_RED, /* HELP */
+   GIT_COLOR_BOLD_RED, /* ERROR */
+};
+enum color_clean {
+   CLEAN_COLOR_RESET = 0,
+   CLEAN_COLOR_PLAIN = 1,
+   CLEAN_COLOR_PROMPT = 2,
+   CLEAN_COLOR_HEADER = 3,
+   CLEAN_COLOR_HELP = 4,
+   CLEAN_COLOR_ERROR = 5,
+};
+
+static int parse_clean_color_slot(const char *var, int ofs)
+{
+   if (!strcasecmp(var+ofs, "reset"))
+   return CLEAN_COLOR_RESET;
+   if (!strcasecmp(var+ofs, "plain"))
+   return CLEAN_COLOR_PLAIN;
+   if (!strcasecmp(var+ofs, "prompt"))
+   return CLEAN_COLOR_PROMPT;
+   if (!strcasecmp(var+ofs, "header"))
+   return CLEAN_COLOR_HEADER;
+   if (!strcasecmp(var+ofs, "help"))
+   return CLEAN_COLOR_HELP;
+   if (!strcasecmp(var+ofs, "error"))
+   return CLEAN_COLOR_ERROR;
+   return -1;
+}
+
 static int git_clean_config(const char *var, const char *value, void *cb)
 {
if (!prefixcmp(var, "column."))
return git_column_config(var, value, "clean", &colopts);
 
+   /* honors the color.interactive* config variables which also
+  applied in git-add--interactive and git-stash */
+   if (!strcmp(var, "color.interactive")) {
+   clean_use_color = git_config_colorbool(var, value);
+   return 0;
+   }
+   if (!prefixcmp(var, "color.interactive.")) {
+   int slot = parse_clean_color_slot(var, 18);
+   if (slot < 0)
+   return 0;
+   if (!value)
+   return config_error_nonbool(var);
+   color_parse(value, var, clean_colors[slot]);
+   return 0;
+   }
+
if (!strcmp(var, "clean.requireforce")) {
force = !git_config_bool(var, value);
return 0;
}
-   return git_default_config(var, value, cb);
+
+   /* inspect the color.ui config variable and others */
+   return git_color_default_config(var, value, cb);
+}
+
+static const char *clean_get_color(enum color_clean ix)
+{
+   if (want_color(clean_use_color))
+   return clean_colors[ix];
+   return "";
+}
+
+static void clean_print_color(enum color_clean ix)
+{
+   printf("%s", clean_get_color(ix));
 }
 
 static int exclude_cb(const struct option *opt, const char *arg, int unset)
@@ -192,7 +258,9 @@ static void edit_by_patterns_cmd()
while (1) {
/* dels list may become empty when we run 
string_list_remove_empty_items later */
if (!del_list.nr) {
+   clean_print_color(CLEAN_COLOR_ERROR);
printf_ln(_("No more files to clean, exiting."));
+   clean_print_color(CLEAN_COLOR_RESET);
break;
}
 
@@ -203,7 +271,9 @@ static void edit_by_patterns_cmd()
pretty_print_dels();
}
 
+   clean_print_color(CLEAN_COLOR_PROMPT);
printf(_("Input ignore patterns>> "));
+   clean_print_color(CLEAN_COLOR_RESET);
if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
strbuf_trim(&confirm);
} else {
@@ -243,7 +313,9 @@ static void edit_by_patterns_cmd()
if (changed) {
string_list_remove_empty_items(&del_list, 0);
} else {
+   clean_p

[PATCH v7 02/10] Show items of interactive git-clean in columns

[Jiang Xin]

When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns instead of in one column will solve
this problem.

Since no longer show items to be cleaned using the "Would remove ..."
format (only plain filenames) in interactive mode, we add instructions
and warnings as header before them.

Signed-off-by: Jiang Xin 
Comments-by: Matthieu Moy 
---
 Documentation/config.txt |  4 
 builtin/clean.c  | 58 +---
 2 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53f..98bfa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -955,6 +955,10 @@ column.branch::
Specify whether to output branch listing in `git branch` in columns.
See `column.ui` for details.
 
+column.clean::
+   Specify whether to output cleaning files in `git clean -i` in columns.
+   See `column.ui` for details.
+
 column.status::
Specify whether to output untracked files in `git status` in columns.
See `column.ui` for details.
diff --git a/builtin/clean.c b/builtin/clean.c
index 49aab..38ed0 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -13,11 +13,13 @@
 #include "refs.h"
 #include "string-list.h"
 #include "quote.h"
+#include "column.h"
 
 static int force = -1; /* unset */
 static int interactive;
 static struct string_list del_list = STRING_LIST_INIT_DUP;
 static const char **the_prefix;
+static unsigned int colopts;
 
 static const char *const builtin_clean_usage[] = {
N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
@@ -32,8 +34,13 @@ static const char *msg_warn_remove_failed = N_("failed to 
remove %s");
 
 static int git_clean_config(const char *var, const char *value, void *cb)
 {
-   if (!strcmp(var, "clean.requireforce"))
+   if (!prefixcmp(var, "column."))
+   return git_column_config(var, value, "clean", &colopts);
+
+   if (!strcmp(var, "clean.requireforce")) {
force = !git_config_bool(var, value);
+   return 0;
+   }
return git_default_config(var, value, cb);
 }
 
@@ -145,6 +152,33 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
return ret;
 }
 
+static void pretty_print_dels()
+{
+   struct string_list list = STRING_LIST_INIT_DUP;
+   struct string_list_item *item;
+   struct strbuf buf = STRBUF_INIT;
+   const char *qname;
+   struct column_options copts;
+
+   for_each_string_list_item(item, &del_list) {
+   qname = quote_path_relative(item->string, -1, &buf, 
*the_prefix);
+   string_list_append(&list, qname);
+   }
+
+   /*
+* always enable column display, we only consult column.*
+* about layout strategy and stuff
+*/
+   colopts = (colopts & ~COL_ENABLE_MASK) | COL_ENABLED;
+   memset(&copts, 0, sizeof(copts));
+   copts.indent = "  ";
+   copts.padding = 2;
+   print_columns(&list, colopts, &copts);
+   putchar('\n');
+   strbuf_release(&buf);
+   string_list_clear(&list, 0);
+}
+
 static void edit_by_patterns_cmd()
 {
struct dir_struct dir;
@@ -153,7 +187,6 @@ static void edit_by_patterns_cmd()
struct strbuf **ignore_list;
struct string_list_item *item;
struct exclude_list *el;
-   const char *qname;
int changed = -1, i;
 
while (1) {
@@ -166,12 +199,8 @@ static void edit_by_patterns_cmd()
if (changed) {
putchar('\n');
 
-   /* Display dels in "Would remove ..." format */
-   for_each_string_list_item(item, &del_list) {
-   qname = quote_path_relative(item->string, -1, 
&buf, *the_prefix);
-   printf(_(msg_would_remove), qname);
-   }
-   putchar('\n');
+   /* Display dels in columns */
+   pretty_print_dels();
}
 
printf(_("Input ignore patterns>> "));
@@ -228,23 +257,17 @@ static void edit_by_patterns_cmd()
 static void interactive_main_loop()
 {
struct strbuf confirm = STRBUF_INIT;
-   struct strbuf buf = STRBUF_INIT;
-   struct string_list_item *item;
-   const char *qname;
 
/* dels list may become empty after return back from edit mode */
while (del_list.nr) {
+   putchar('\n');
printf_ln(Q_("Would remove the following item:",
 "Would remove the following items:",
 del_list.nr));
putchar('\n');
 
-   /* Display dels in "Would remove ..." format */
-   for_each_string_list_item(item, &del_list) {
-   qname = quote_path_relative(item->string, -1, &buf, 
*the_prefix);
- 

[PATCH v7 01/10] Add support for -i/--interactive to git-clean

[Jiang Xin]

Show what would be done and the user must confirm before actually
cleaning. In the confirmation dialog, the user has three choices:

 * y/yes:  Start to do cleaning.
 * n/no:   Nothing will be deleted.
 * e/edit: Exclude items from deletion using ignore patterns.

When the user chooses the edit mode, the user can input space-
separated patterns (the same syntax as gitignore), and each clean
candidate that matches with one of the patterns will be excluded
from cleaning. When the user feels it's OK, presses ENTER and back
to the confirmation dialog.

Signed-off-by: Jiang Xin 
Suggested-by: Junio C Hamano 
Spelling-checked-by: Eric Sunshine 
Comments-by: Matthieu Moy 
Suggested-by: Eric Sunshine 
---
 Documentation/git-clean.txt |  15 +++-
 builtin/clean.c | 198 +++-
 2 files changed, 192 insertions(+), 21 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index bdc3a..f5572 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 
 [verse]
-'git clean' [-d] [-f] [-n] [-q] [-e ] [-x | -X] [--] ...
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ...
 
 DESCRIPTION
 ---
@@ -34,7 +34,18 @@ OPTIONS
 -f::
 --force::
If the Git configuration variable clean.requireForce is not set
-   to false, 'git clean' will refuse to run unless given -f or -n.
+   to false, 'git clean' will refuse to run unless given -f, -n or
+   -i.
+
+-i::
+--interactive::
+   Show what would be done and the user must confirm before actually
+   cleaning. In the confirmation dialog, the user can choose to abort
+   the cleaning, or enter into an edit mode. In the edit mode, the
+   user can input space-separated patterns (the same syntax as
+   gitignore), and each clean candidate that matches with one of the
+   patterns will be excluded from cleaning. When the user feels it's
+   OK, presses ENTER and back to the confirmation dialog.
 
 -n::
 --dry-run::
diff --git a/builtin/clean.c b/builtin/clean.c
index 04e39..49aab 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -15,9 +15,12 @@
 #include "quote.h"
 
 static int force = -1; /* unset */
+static int interactive;
+static struct string_list del_list = STRING_LIST_INIT_DUP;
+static const char **the_prefix;
 
 static const char *const builtin_clean_usage[] = {
-   N_("git clean [-d] [-f] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
+   N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
NULL
 };
 
@@ -142,6 +145,139 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
return ret;
 }
 
+static void edit_by_patterns_cmd()
+{
+   struct dir_struct dir;
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf buf = STRBUF_INIT;
+   struct strbuf **ignore_list;
+   struct string_list_item *item;
+   struct exclude_list *el;
+   const char *qname;
+   int changed = -1, i;
+
+   while (1) {
+   /* dels list may become empty when we run 
string_list_remove_empty_items later */
+   if (!del_list.nr) {
+   printf_ln(_("No more files to clean, exiting."));
+   break;
+   }
+
+   if (changed) {
+   putchar('\n');
+
+   /* Display dels in "Would remove ..." format */
+   for_each_string_list_item(item, &del_list) {
+   qname = quote_path_relative(item->string, -1, 
&buf, *the_prefix);
+   printf(_(msg_would_remove), qname);
+   }
+   putchar('\n');
+   }
+
+   printf(_("Input ignore patterns>> "));
+   if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
+   strbuf_trim(&confirm);
+   } else {
+   putchar('\n');
+   break;
+   }
+
+   /* Quit edit mode */
+   if (!confirm.len)
+   break;
+
+   memset(&dir, 0, sizeof(dir));
+   el = add_exclude_list(&dir, EXC_CMDL, "manual exclude");
+   ignore_list = strbuf_split_max(&confirm, ' ', 0);
+
+   for (i = 0; ignore_list[i]; i++) {
+   strbuf_trim(ignore_list[i]);
+   if (!ignore_list[i]->len)
+   continue;
+
+   add_exclude(ignore_list[i]->buf, "", 0, el, -(i+1));
+   }
+
+   changed = 0;
+   for_each_string_list_item(item, &del_list) {
+   int dtype = DT_UNKNOWN;
+   const char *qname;
+
+   qname = quote_path_relative(item->string, -1, &buf, 
*the_prefix);
+
+

[PATCH v7 00/10] interactive git clean

[Jiang Xin]

Significant updates since patch v6 series:

 * Refactor on patch 4/10: split `list_and_choose` into 3 functions,
   to make it easy to read.

 * Mark no public functions as static for patch 1-10.

 * If set 'pager.clean' to true (i.e. isatty(1) is false), die
   instead of do cleaning.

 * New action: flags. The user can update flags for git-clean,
   such as -x/-d/-X/-ff.

 * Alway show interactive menu, even there are no files to clean.
   Because the use can update flags for git-clean.
 
Usage:

When the command enters the interactive mode, it shows the
files and directories to be cleaned, and goes into its
interactive command loop.

The command loop shows the list of subcommands available, and
gives a prompt "What now> ".  In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:

*** Commands ***
  1: clean   2: edit by patterns3: edit by numbers 4: 
rm -i
  5: flags: none 6: quit7: help
What now> 2

You also could say `c` or `clean` above as long as the choice is unique.

The main command loop has 7 subcommands.

clean::

   Start cleaning files and directories, and then quit.

edit by patterns::

   This shows the files and directories to be deleted and issues an
   "Input ignore patterns>>" prompt. You can input a space-seperated
   patterns to exclude files and directories from deletion.
   E.g. "*.c *.h" will excludes files end with ".c" and ".h" from
   deletion. When you are satisfied with the filtered result, press
   ENTER (empty) back to the main menu.

edit by numbers::

   This shows the files and directories to be deleted and issues an
   "Select items to delete>>" prompt. When the prompt ends with double
   '>>' like this, you can make more than one selection, concatenated
   with whitespace or comma.  Also you can say ranges.  E.g. "2-5 7,9"
   to choose 2,3,4,5,7,9 from the list.  If the second number in a
   range is omitted, all remaining patches are taken.  E.g. "7-" to
   choose 7,8,9 from the list.  You can say '*' to choose everything.
   Also when you are satisfied with the filtered result, press ENTER
   (empty) back to the main menu.

rm -i::

  This will show a "rm -i" style cleaning, that you must confirm one
  by one in order to delete items. This action is not as efficient
  as the above two actions.

flags::

  This lets you change the flags for git-clean, such as -x/-X/-d/-ff,
  and refresh the cleaning candidates list automatically.

quit::

  This lets you quit without do cleaning.

help::

  Show brief usage of interactive git-clean.


Jiang Xin (10):
  Add support for -i/--interactive to git-clean
  Show items of interactive git-clean in columns
  Add colors to interactive git-clean
  git-clean: use a git-add-interactive compatible UI
  git-clean: interactive cleaning by select numbers
  git-clean: rm -i style interactive cleaning
  git-clean: update document for interactive git-clean
  git-clean refactor: save some options in clean_flags
  git-clean refactor: wrap in scan_clean_candidates
  git-clean: change clean flags in interactive mode

 Documentation/config.txt|   4 +
 Documentation/git-clean.txt |  76 +++-
 builtin/clean.c | 972 
 3 files changed, 981 insertions(+), 71 deletions(-)

-- 
1.8.3.rc1.341.g1c24ab7

--
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: Minor correction to Git book

[John Keeping]

On Wed, May 08, 2013 at 12:01:00PM +0100, Robin Messer wrote:
> > I think the text is correct as it stands.  "git status" shows you that
> > there are changes that are staged and unstaged, "git diff" (and "git
> > diff --cached") shows you what those changes are.
> 
> Thanks, but the command line which follows that text does actually use
> "git status" to show which files (staged and unstaged) have changes.
> The text I quoted is introducing that command.
> 
> Then the next example shows you how to use "git diff" to see what the
> actual unstaged changes to those files are.

Ah, OK.  I read your email without looking at the context.

> If this is not the appropriate place to report such things, please point
> me at the correct one.

The ProGit book is maintained at https://github.com/progit/progit
--
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: Minor correction to Git book

[Robin Messer]

> I think the text is correct as it stands.  "git status" shows you that
> there are changes that are staged and unstaged, "git diff" (and "git
> diff --cached") shows you what those changes are.

Thanks, but the command line which follows that text does actually use
"git status" to show which files (staged and unstaged) have changes.
The text I quoted is introducing that command.

Then the next example shows you how to use "git diff" to see what the
actual unstaged changes to those files are.

If this is not the appropriate place to report such things, please point
me at the correct one.

Thanks,

Robin.

This email is confidential and intended solely for the use of the individual to 
whom it is addressed. If you are not the intended recipient, be advised that 
you have received this email in error and that any use, disclosure, copying or 
distribution or any action taken or omitted to be taken in reliance on it is 
strictly prohibited. If you have received this email in error please contact 
the sender. Any views or opinions presented in this email are solely those of 
the author and do not necessarily represent those of Altran.

Although this email and any attachments are believed to be free of any virus or 
other defect, no responsibility is accepted by Altran or any of its associated 
companies for any loss or damage arising in any way from the receipt or use 
thereof.

Altran UK Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 22 St. Lawrence Street, Bath, BA1 1AN

VAT Registered in Great Britain: 682635707

--
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: Minor correction to Git book

[John Keeping]

On Wed, May 08, 2013 at 11:24:56AM +0100, Robin Messer wrote:
> I'm just learning Git so I don't yet know how to submit this
> as a patch, but I'm reading the Git Book to get myself started
> and I think there is a mistake on the page at:
> 
> http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository
> 
> It says: "For another example, if you stage the benchmarks.rb file and
> then edit it, you can use git diff to see the changes in the file that
> are staged and the changes that are unstaged:"
> 
> I believe this should say "git status" rather than "git diff".

I think the text is correct as it stands.  "git status" shows you that
there are changes that are staged and unstaged, "git diff" (and "git
diff --cached") shows you what those changes are.
--
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 00/11] sha1_name: improvements

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Will queue.  Thanks.

Nit: you might want to add my s-o-b on patches 73027d and b018e8 queued in pu.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Minor correction to Git book

[Robin Messer]

I'm just learning Git so I don't yet know how to submit this
as a patch, but I'm reading the Git Book to get myself started
and I think there is a mistake on the page at:

http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository

It says: "For another example, if you stage the benchmarks.rb file and
then edit it, you can use git diff to see the changes in the file that
are staged and the changes that are unstaged:"

I believe this should say "git status" rather than "git diff".

--
Robin

This email is confidential and intended solely for the use of the individual to 
whom it is addressed. If you are not the intended recipient, be advised that 
you have received this email in error and that any use, disclosure, copying or 
distribution or any action taken or omitted to be taken in reliance on it is 
strictly prohibited. If you have received this email in error please contact 
the sender. Any views or opinions presented in this email are solely those of 
the author and do not necessarily represent those of Altran.

Although this email and any attachments are believed to be free of any virus or 
other defect, no responsibility is accepted by Altran or any of its associated 
companies for any loss or damage arising in any way from the receipt or use 
thereof.

Altran UK Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 22 St. Lawrence Street, Bath, BA1 1AN

VAT Registered in Great Britain: 682635707

--
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: trouble on windows network share

[David Goldfarb]

Here's one more data point. It suggests that the problem is due to either 
Cygwin or possibly Git 1.7.9.


My Ubuntu box is actually a VM, hosted by my windows box in VMWare Player.

So, I tried using the VMWare shared folder feature, to mount the Windows U: 
drive (which is physically on the WD NAS box) as /mnt/hgfs/Host-U on Ubuntu.
Then, I tried linux on the Ubuntu box, fully expecting it to fail as it 
trampolined through Windows connection to the NAS box).

But, it worked fine.

So, at this point, it became likely that the problem is tied to the different 
version of Git that I have on the two machines:
- On Ubuntu, git version 1.7.10.4
- On Windows, Cygwin's git version 1.7.9 (which appears to be the latest 
version for Cygwin).

So, I installed Git on Windows from http://git-scm.com/download/win. Git 
version 1.8.1.msysgit.1

Triumph: Git on windows works with this git but, on the same file and repo, 
fails with Cygwin git.

So, either something relevant changed in Git 1.7.10, or (more likely) this is a 
Cygwin issue.


Jason, are you also using Cygwin git?  Are you also using a WD NAS?

David

-Original Message-
From: Pyeron, Jason J CTR (US) [mailto:jason.j.pyeron@mail.mil] 
Sent: Monday, May 06, 2013 4:11 PM
To: Thomas Rast; David Goldfarb
Cc: git@vger.kernel.org
Subject: RE: trouble on windows network share

> -Original Message-
> From: Thomas Rast
> Sent: Monday, May 06, 2013 5:42 AM
> 
> David Goldfarb  writes:
> 
> > Git works correctly under Linux (Ubuntu 12.04; git 1.7.9.5).  I've
> attached the strace outputs. (Note: for reasons that are probably
> irrelevant, I needed to run the commands sudo'd. Shout back if this is
> an issue).
> >
> > Under Windows 7, Cygwin git 1.7.9, commit fails:
> >   U:\foo>git commit -m "added foo2"
> >   error: unable to find 0b89efdeef245ed6a0a7eacc5c578629a141f856
> >   fatal: 0b89efdeef245ed6a0a7eacc5c578629a141f856 is not a valid
> object
> >
> > For what it's worth, note that the file does exist.
> >   U:\foo>ls -l .git/objects/0b
> >   total 1024
> >   -rwxrw-r-- 1   74 May  5 01:15
> 89efdeef245ed6a0a7eacc5c578629a141f856
> >
> > (I'm not sure why the permissions are trashed. Seems to be a Cygwin
> thing, or maybe my Cygwin config. The "??" also  appears on local
> files, and I believe also with files on the old Buffalo drive, so I
> don't think it is relevant to the problem).  Just in case, here's the
> same dir, as seen from the Ubuntu VM:
> >
> >   deg@ubuntu:/mnt/users/foo$ ls -l .git/objects/0b
> >   total 64
> >   -rwxr-xr-x 0 root root 74 May  5 01:15
> 89efdeef245ed6a0a7eacc5c578629a141f856
> >
> > Again, note that there is some user permissions lossage here. I don't
> know enough about Linux mount or CIFS, and apparently did the mount in
> a way that everything seems to appear to be stuck owned by root. (same
> problem I hinted at above). Hope this is not relevant to the problem.
> >
> > Here's how the same directory looks, when I'm ssh'd into the NAS box
> itself:
> >
> >CentralPark:/shares/Users/foo# ls -l .git/objects/0b
> >   total 64
> >   -rwxrw-r-- 1 deg share 74 May  5 01:15
> 89efdeef245ed6a0a7eacc5c578629a141f856
> >
> > In any event, the symptoms don't seem to be a permissions problem, so
> all this extra info is probably just a red herring, I hope.
> 
> Hrm.  What about what Jeff already asked of the OP (and AFAICS never
> got
> a reply)?

If referring to me, then yes but it was too big for the list.

> 
> } If it's a race condition between the write and the subsequent read in
> } the same process, then it would be solved by looking at the object
> } later. Does "git cat-file -p
> 6838761d549cf76033d2e9faf5954e62839eb25d"
> } work, or is the object forever inaccessible?
> 
> In your case: git cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856


--
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 10/11] sha1_name: reorganize get_sha1_basic()

[Felipe Contreras]

On Wed, May 8, 2013 at 2:39 AM, Ramkumar Ramachandra  wrote:
> Felipe Contreras wrote:
>> ---
>>  sha1_name.c | 30 +++---
>>  1 file changed, 19 insertions(+), 11 deletions(-)
>
> How has this changed since my eyeballing of the previous version?  An
> inter-diff would be nice: having spent a significant amount of time
> looking at this area, I can confirm that the patch is Correct.

You mean this compared to v4? It hasn't changed.

-- 
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

Re: [PATCH v2 10/11] sha1_name: reorganize get_sha1_basic()

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> ---
>  sha1_name.c | 30 +++---
>  1 file changed, 19 insertions(+), 11 deletions(-)

How has this changed since my eyeballing of the previous version?  An
inter-diff would be nice: having spent a significant amount of time
looking at this area, I can confirm that the patch is Correct.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] completion: synchronize zsh wrapper

[Felipe Contreras]

So it's closer to the full zsh wrapper.

Signed-off-by: Felipe Contreras 
---
 contrib/completion/git-completion.bash | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 84dbf19..b61f6c2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2663,7 +2663,7 @@ if [[ -n ${ZSH_VERSION-} ]]; then
--*=*|*.) ;;
*) c="$c " ;;
esac
-   array[$#array+1]="$c"
+   array+=("$c")
done
compset -P '*[=:]'
compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
@@ -2696,7 +2696,7 @@ if [[ -n ${ZSH_VERSION-} ]]; then
prev=${words[CURRENT-1]}
let cword=CURRENT-1
emulate ksh -c __${service}_main
-   let _ret && _default -S '' && _ret=0
+   let _ret && _default && _ret=0
return _ret
}
 
-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] completion: zsh wrapper cleanups

[Felipe Contreras]

Hi,

Nothing fancy, just some cleanups for the minimal zsh backup wrapper in bash's
completion code.

Felipe Contreras (2):
  completion: cleanup zsh wrapper
  completion: synchronize zsh wrapper

 contrib/completion/git-completion.bash | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

-- 
1.8.3.rc1.553.gac13664

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] completion: cleanup zsh wrapper

[Felipe Contreras]

There's no need for a separate function; we can call
'emulate -k ksh func'.

Signed-off-by: Felipe Contreras 
---
 contrib/completion/git-completion.bash | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index b97162f..84dbf19 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2689,21 +2689,13 @@ if [[ -n ${ZSH_VERSION-} ]]; then
compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
}
 
-   __git_zsh_helper ()
-   {
-   emulate -L ksh
-   local cur cword prev
-   cur=${words[CURRENT-1]}
-   prev=${words[CURRENT-2]}
-   let cword=CURRENT-1
-   __${service}_main
-   }
-
_git ()
{
-   emulate -L zsh
-   local _ret=1
-   __git_zsh_helper
+   local _ret=1 cur cword prev
+   cur=${words[CURRENT]}
+   prev=${words[CURRENT-1]}
+   let cword=CURRENT-1
+   emulate ksh -c __${service}_main
let _ret && _default -S '' && _ret=0
return _ret
}
-- 
1.8.3.rc1.553.gac13664

--
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: What's cooking in git.git (May 2013, #02; Mon, 6)

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> This series has cleanups and features that are good as they are.
> Ramkumar said he was going to resend his cleanup series, but he
> didn't. I'll try to gather all the patches and split them into
> cleanups, and features.

Thanks for picking up the pieces.  I was out of town these last few days.
--
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