[PATCH/RFC] add: support saving the last versions of the index

2013-08-03 Thread Nguyễn Thái Ngọc Duy
When you do "git add foo", change "foo" and "git add foo" again, the
previous foo version is still in the repository, but its SHA-1 may be
lost. "git fsck --lost-found" may help, but it may take more time to
find out which blob is the old "foo".

This patch adds support for saving old index files, so that people
could look back more easily. In the case of "old foo", the user could
use ls-files with the previous of the index to determine SHA-1 of "old
foo".

When core.indexlogsize is defined to , every time the index
changes(**), the old version is stored as $GIT_DIR/index-, where
 is from 0..-1.  increased after every change and wrapped
around at -1. The current  is stored in $GIT_DIR/index as new
ILOG extension. ILOG extension also contains HEAD's tree SHA-1 and a
line describing the change.

(**) The index can change in many ways, but only changes by "git add"
(and maybe "git update-index" as well) are backed up. Non-SHA1 updates
are not worth watching. SHA-1 changes that end up in a commit
are tracked by reflog already. "git mv" and "git rm" may be worth
watching too.
---
 http://thread.gmane.org/gmane.comp.version-control.git/231594 reminds
 me that I have had something like this for a long time but never
 finished it. So here we go again.

 I think the basic idea is ok (new index versions like v5 may have
 problems though). The UI is harder. We need something like "git
 reflog" and perhaps something like @{N} syntax to access old indexes.
 Being able to diff between two indexes are even better but that might
 be a lot of work, diff-ing "git ls-files --stage" output should be
 ok. Hmm?

 builtin/add.c |  9 -
 cache.h   |  5 +
 config.c  |  5 +
 environment.c |  1 +
 lockfile.c| 12 +++-
 read-cache.c  | 56 +++-
 6 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index 8266a9c..90e580c 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -15,6 +15,7 @@
 #include "diffcore.h"
 #include "revision.h"
 #include "bulk-checkin.h"
+#include "quote.h"
 
 static const char * const builtin_add_usage[] = {
N_("git add [options] [--] ..."),
@@ -454,9 +455,15 @@ int cmd_add(int argc, const char **argv, const char 
*prefix)
char *seen = NULL;
int implicit_dot = 0;
struct update_callback_data update_data;
+   struct strbuf log = STRBUF_INIT;
 
git_config(add_config, NULL);
 
+   if (index_log_size) {
+   strbuf_addf(&log, "[%s] add ", prefix ? prefix : "");
+   sq_quote_argv(&log, argv, 0);
+   }
+
argc = parse_options(argc, argv, prefix, builtin_add_options,
  builtin_add_usage, PARSE_OPT_KEEP_ARGV0);
if (patch_interactive)
@@ -600,7 +607,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 
  finish:
if (active_cache_changed) {
-   if (write_cache(newfd, active_cache, active_nr) ||
+   if (write_index_with_log(&the_index, newfd, log.buf) ||
commit_locked_index(&lock_file))
die(_("Unable to write new index file"));
}
diff --git a/cache.h b/cache.h
index 85b544f..7655c4b 100644
--- a/cache.h
+++ b/cache.h
@@ -274,9 +274,12 @@ struct index_state {
struct cache_tree *cache_tree;
struct cache_time timestamp;
unsigned name_hash_initialized : 1,
+log_updated : 1,
 initialized : 1;
struct hash_table name_hash;
struct hash_table dir_hash;
+   unsigned int log_index;
+   struct strbuf *log;
 };
 
 extern struct index_state the_index;
@@ -454,6 +457,7 @@ extern int read_index_from(struct index_state *, const char 
*path);
 extern int is_index_unborn(struct index_state *);
 extern int read_index_unmerged(struct index_state *);
 extern int write_index(struct index_state *, int newfd);
+extern int write_index_with_log(struct index_state *, int newfd, const char 
*log);
 extern int discard_index(struct index_state *);
 extern int unmerged_index(const struct index_state *);
 extern int verify_path(const char *path);
@@ -595,6 +599,7 @@ extern int fsync_object_files;
 extern int core_preload_index;
 extern int core_apply_sparse_checkout;
 extern int precomposed_unicode;
+extern unsigned long index_log_size;
 
 /*
  * The character that begins a commented line in user-editable file
diff --git a/config.c b/config.c
index e13a7b6..f5e40fb 100644
--- a/config.c
+++ b/config.c
@@ -831,6 +831,11 @@ static int git_default_core_config(const char *var, const 
char *value)
return 0;
}
 
+   if (!strcmp(var, "core.indexlogsize")) {
+   index_log_size = git_config_ulong(var, value);
+   return 0;
+   }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
 }
diff --git a/environment.c b/environment.c
index 5398c36..12f01f7 100644
--

Re: [PATCH] Add missing test file for UTF-16.

2013-08-03 Thread Duy Nguyen
On Sun, Aug 4, 2013 at 12:26 AM, brian m. carlson
 wrote:
> The test file that the UTF-16 rejection test looks for is missing, but this 
> went
> unnoticed because the test is expected to fail anyway; as a consequence, the
> test fails because the file containing the commit message is missing, and not
> because the test file contains a NUL byte.  Fix this by including a sample 
> text
> file containing a commit message encoded in UTF-16.

Tested-by: Duy Nguyen 

and sorry, my bad. I think we need your sign-off in this patch.

> ---
>  t/t3900/UTF-16.txt | Bin 0 -> 146 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 t/t3900/UTF-16.txt
>
> diff --git a/t/t3900/UTF-16.txt b/t/t3900/UTF-16.txt
> new file mode 100644
> index 
> ..2257f05a992a4b9500f6ff33752cbdf8fb58c99d
> GIT binary patch
> literal 146
> zcmW-aJqmbjKEzFY?FCi}po-doQaNvlX
> zuj<&j$Vh~SS#Fd&>8^}o3xQtzWRNy5zCGpzu|P`62Tv_HZgu?B*(r7K7qg7DI9e@K
> J`p+qB@d1eo8QA~;
>
> literal 0
> HcmV?d1
>
> --
> 1.8.4.rc1
>
-- 
Duy
--
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] remotes-hg: timezones are transformed

2013-08-03 Thread Felipe Contreras
Hi,

On Sat, Aug 3, 2013 at 11:36 AM, Jörn Hees  wrote:

> it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a 
> mercurial repo the timezone information of commits gets transformed into your 
> current timezone.
> (command: git clone hg::…)
>
> I noticed this when a colleague in another timezone used Kiln to also export 
> the same mercurial repo that i had cloned from git before.
> Fetching from his git repo gives me a "second root tree" with all commits 
> duplicated.
> A git show of two equivalent commit reveals that the Date: line of the 
> commits changed.
> Tracking this back into the original mercurial repo reveals that _his_ times 
> are correct.
>
> This will also make two or more clones from different timezones all using the 
> same hg remote repo incompatible!
>
>
> Example:
> Original mercurial commit (timezone: -7200 = -4h)
> https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/
>
> Lipis git export via Kiln: (-4h)
> https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c
>
> My export via git clone hg::ssh://h...@bitbucket.org/lipis/gae-init (+2h)
> https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae

Actually our version is the correct one:

% hg commit -m one -d "2012-04-28 11:28 +0200"
% hg export
# HG changeset patch
# User Felipe Contreras 
# Date 1335605280 -7200
#  Sat Apr 28 11:28:00 2012 +0200

-- 
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: Bug: Pulling remotes into an empty repo deletes the index

2013-08-03 Thread Adam A
On Sun, Aug 4, 2013 at 2:57 AM, Jonathan Nieder  wrote:
> Daniel Convissor wrote:
>
>> All is not lost.  Your local files should be stored in the repository's
>> reflog.  Examine the output of "git reflog".  You can then reset your
>> working directory to obtain those files by doing something _like_
>> "git reset --hard HEAD@{1}".
>
> Adam hadn't made a commit, so that wouldn't work in this case.
>
> "git fsck --lost-found" should be helpful, but yeah, this is a bug.
> See for example [1] for the start of a patch to play with (needs
> tests).

Ah I didn't realize the objects would still be there! `git fsck` +
`git show` is a wonderful workaround until the bug is fixed.

>
> Thanks and hope that helps,
> Jonathan
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/196502/focus=196503


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


Re: [PATCH 3/4] gitweb: omit the repository owner when it is unset

2013-08-03 Thread Jakub Narębski
On Tue, Jul 2, 2013 at 6:24 PM, Tony Finch  wrote:

> On the repository summary page, leave the whole owner line out if
> the repo does not have an owner, rather than displaying a labelled
> empty field..

Note that if $omit_owner is true, whole _column_ is skipped.

Is removing cell (instead of leaving it empty) and relying on browser
treating nonexistent cell correctly a good idea, that I do not know.
Does it looks better?  Does it looks better in all web browsers?

> Signed-off-by: Tony Finch 
> ---
>  gitweb/gitweb.perl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 8d69ada..c029b98 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -6463,7 +6463,7 @@ sub git_summary {
> print " \n";
> print "\n" .
>   "description" . 
> esc_html($descr) . "\n";
> -unless ($omit_owner) {
> +if ($owner and not $omit_owner) {
> print  "owner" . 
> esc_html($owner) . "\n";
>  }
> if (defined $cd{'rfc2822'}) {
> --
> 1.8.3.1.605.g85318f5
>



-- 
Jakub Narebski
--
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/4] gitweb: make search help link less ugly

2013-08-03 Thread Jakub Narębski
On Tue, Jul 9, 2013 at 7:15 PM, Tony Finch  wrote:

> The search help link was a superscript question mark right next to
> a drop-down menu, which looks misaligned

I think the idea was to simulate footnote explaining search terms
(I think, I am not the author of this feature)...

>and is a 
> cramped and
> awkward click target. Remove the superscript tags and add some
> spacing to fix these nits. Add a title attribute to provide an
> explanatory mouseover.

... but I agree that it makes for poor UI.

>
> Signed-off-by: Tony Finch 
> ---
>  gitweb/gitweb.perl | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c029b98..874c948 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4029,9 +4029,9 @@ sub print_search_form {
>   $cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . 
> "\n" .
>   $cgi->input({-name=>"h", -value=>$search_hash, 
> -type=>"hidden"}) . "\n" .
>   $cgi->popup_menu(-name => 'st', -default => 'commit',
> -  -values => ['commit', 'grep', 'author', 
> 'committer', 'pickaxe']) .
> - $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) 
> .
> - " search:\n",
> +  -values => ['commit', 'grep', 'author', 
> 'committer', 'pickaxe']) .

Nb. what changed here (in line above)?

> + " " . $cgi->a({-href => href(action=>"search_help"),
> +-title => "search help" }, "?") . " search:\n",
>   $cgi->textfield(-name => "s", -value => $searchtext, -override 
> => 1) . "\n" .
>   "" .
>   $cgi->checkbox(-name => 'sr', -value => 1, -label => 're',
> --
> 1.8.3.1.605.g85318f5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] howto: Eliminate all tabs

2013-08-03 Thread Piotr Krukowiecki
Junio C Hamano  napisał:
>Besides, the tab width of our source is 8, period.  Get over it.

Isn't the howto documentation intended (mainly/also) for the users of git, not 
the developers?


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


Re: [PATCH 2/2] submodule: don't print status output with ignore=all

2013-08-03 Thread Jonathan Nieder
brian m. carlson wrote:

> git status prints information for submodules, but it should ignore the status 
> of
> those which have submodule..ignore set to all.  Fix it so that it does
> properly ignore those which have that setting either in .git/config or in
> .gitmodules.
>
> Signed-off-by: brian m. carlson 
> ---
>  git-submodule.sh  | 2 ++
>  t/t7508-status.sh | 4 ++--
>  2 files changed, 4 insertions(+), 2 deletions(-)

Thanks.  Cc-ing Jens, who wrote that test and knows this code much
better than I do. :)

[...]
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -1034,6 +1034,8 @@ cmd_summary() {
>   sane_egrep '^:([0-7]* )?16' |
>   while read mod_src mod_dst sha1_src sha1_dst status path
>   do
> + name=$(module_name "$path")
> + test $(get_submodule_config "$name" ignore none) = all 
> && continue
>   # Always show modules deleted or type-changed 
> (blob<->module)
>   test $status = D -o $status = T && echo "$path" && 
> continue

I'm not sure what the exact semantics should be here, though that's
mostly because of my unfamiliarity with submodules in general.

If I have '[submodule "favorite"] ignore = all' and I then replace
that submodule with a blob, should "git submodule status" not mention
that path?

If I just renamed a submodule, will 'module_name "$path"' do the right
thing with the old path?

(rest of the patch kept unsnipped for reference)
>   # Also show added or modified modules which are checked 
> out
> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
> index ac3d0fe..fb89fb9 100755
> --- a/t/t7508-status.sh
> +++ b/t/t7508-status.sh
> @@ -1316,7 +1316,7 @@ test_expect_success "--ignore-submodules=all suppresses 
> submodule summary" '
>   test_i18ncmp expect output
>  '
>  
> -test_expect_failure '.gitmodules ignore=all suppresses submodule summary' '
> +test_expect_success '.gitmodules ignore=all suppresses submodule summary' '
>   git config --add -f .gitmodules submodule.subname.ignore all &&
>   git config --add -f .gitmodules submodule.subname.path sm &&
>   git status > output &&
> @@ -1324,7 +1324,7 @@ test_expect_failure '.gitmodules ignore=all suppresses 
> submodule summary' '
>   git config -f .gitmodules  --remove-section submodule.subname
>  '
>  
> -test_expect_failure '.git/config ignore=all suppresses submodule summary' '
> +test_expect_success '.git/config ignore=all suppresses submodule summary' '
>   git config --add -f .gitmodules submodule.subname.ignore none &&
>   git config --add -f .gitmodules submodule.subname.path sm &&
>   git config --add submodule.subname.ignore all &&
> -- 
> 1.8.4.rc1
--
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] submodule: fix confusing variable name

2013-08-03 Thread Jonathan Nieder
brian m. carlson wrote:

> cmd_summary reads the output of git diff, but reads in the submodule
> path into a variable called name.  Since this variable does not
> contain the name of the submodule, but the path, rename it to be
> clearer what data it actually holds.

Nice.

Reviewed-by: Jonathan Nieder 
--
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] Add missing test file for UTF-16.

2013-08-03 Thread brian m. carlson
The test file that the UTF-16 rejection test looks for is missing, but this went
unnoticed because the test is expected to fail anyway; as a consequence, the
test fails because the file containing the commit message is missing, and not
because the test file contains a NUL byte.  Fix this by including a sample text
file containing a commit message encoded in UTF-16.
---
 t/t3900/UTF-16.txt | Bin 0 -> 146 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 t/t3900/UTF-16.txt

diff --git a/t/t3900/UTF-16.txt b/t/t3900/UTF-16.txt
new file mode 100644
index 
..2257f05a992a4b9500f6ff33752cbdf8fb58c99d
GIT binary patch
literal 146
zcmW-aJqmbjKEzFY?FCi}po-doQaNvlX
zuj<&j$Vh~SS#Fd&>8^}o3xQtzWRNy5zCGpzu|P`62Tv_HZgu?B*(r7K7qg7DI9e@K
J`p+qB@d1eo8QA~;

literal 0
HcmV?d1

-- 
1.8.4.rc1

--
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] submodule: don't print status output with ignore=all

2013-08-03 Thread brian m. carlson
git status prints information for submodules, but it should ignore the status of
those which have submodule..ignore set to all.  Fix it so that it does
properly ignore those which have that setting either in .git/config or in
.gitmodules.

Signed-off-by: brian m. carlson 
---
 git-submodule.sh  | 2 ++
 t/t7508-status.sh | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 30b7fc1..5694ae6 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1034,6 +1034,8 @@ cmd_summary() {
sane_egrep '^:([0-7]* )?16' |
while read mod_src mod_dst sha1_src sha1_dst status path
do
+   name=$(module_name "$path")
+   test $(get_submodule_config "$name" ignore none) = all 
&& continue
# Always show modules deleted or type-changed 
(blob<->module)
test $status = D -o $status = T && echo "$path" && 
continue
# Also show added or modified modules which are checked 
out
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index ac3d0fe..fb89fb9 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1316,7 +1316,7 @@ test_expect_success "--ignore-submodules=all suppresses 
submodule summary" '
test_i18ncmp expect output
 '
 
-test_expect_failure '.gitmodules ignore=all suppresses submodule summary' '
+test_expect_success '.gitmodules ignore=all suppresses submodule summary' '
git config --add -f .gitmodules submodule.subname.ignore all &&
git config --add -f .gitmodules submodule.subname.path sm &&
git status > output &&
@@ -1324,7 +1324,7 @@ test_expect_failure '.gitmodules ignore=all suppresses 
submodule summary' '
git config -f .gitmodules  --remove-section submodule.subname
 '
 
-test_expect_failure '.git/config ignore=all suppresses submodule summary' '
+test_expect_success '.git/config ignore=all suppresses submodule summary' '
git config --add -f .gitmodules submodule.subname.ignore none &&
git config --add -f .gitmodules submodule.subname.path sm &&
git config --add submodule.subname.ignore all &&
-- 
1.8.4.rc1

--
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] submodule: fix confusing variable name

2013-08-03 Thread brian m. carlson
cmd_summary reads the output of git diff, but reads in the submodule path into a
variable called name.  Since this variable does not contain the name of the
submodule, but the path, rename it to be clearer what data it actually holds.

Signed-off-by: brian m. carlson 
---
 git-submodule.sh | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..30b7fc1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1032,13 +1032,13 @@ cmd_summary() {
# Get modified modules cared by user
modules=$(git $diff_cmd $cached --ignore-submodules=dirty --raw $head 
-- "$@" |
sane_egrep '^:([0-7]* )?16' |
-   while read mod_src mod_dst sha1_src sha1_dst status name
+   while read mod_src mod_dst sha1_src sha1_dst status path
do
# Always show modules deleted or type-changed 
(blob<->module)
-   test $status = D -o $status = T && echo "$name" && 
continue
+   test $status = D -o $status = T && echo "$path" && 
continue
# Also show added or modified modules which are checked 
out
-   GIT_DIR="$name/.git" git-rev-parse --git-dir >/dev/null 
2>&1 &&
-   echo "$name"
+   GIT_DIR="$path/.git" git-rev-parse --git-dir >/dev/null 
2>&1 &&
+   echo "$path"
done
)
 
-- 
1.8.4.rc1

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


Don't print status output with submodule..ignore=all

2013-08-03 Thread brian m. carlson
There are configuration options for each submodule that specify under what
circumstances git status should display output for that submodule.
Unfortunately, these settings were not being respected, and as such the tests
were marked TODO.

This patch series consists of two patches: the first is a fix for a confusing
variable name, and the latter actually makes git status not output the submodule
information.  The tests have been updated accordingly.

 git-submodule.sh  | 10 ++
 t/t7508-status.sh |  4 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)
--
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: change remote to track new branch

2013-08-03 Thread Jonathan Nieder
Daniel Convissor wrote:
> On Sat, Aug 03, 2013 at 09:14:59AM +0200, Andreas Schwab wrote:

>> Use "git remote set-branches" to change the tracked branches of a
>> remote.  Use "git branch --set-upstream-to" to change the upstream of a
>> branch (or create a new branch from the new upstream).
>
> Thanks.  Those commands were introduced in 1.8.  Is there a way to do it
> in 1.7, please?

"git remote set-branches" was introduced by v1.7.8-rc2~4^2~1.  Are you
stuck on 1.7.2.5, perhaps?  In older (and current) versions of git,
you can control the list of branches tracked by a remote by modifying
its "fetch" refspec in .git/config:

[remote "origin"]
url = ...
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/next:refs/remotes/origin/next

"git branch --set-upstream-to" is from v1.8.0-rc0~50^2~4.  In older
versions of git,

git branch --set-upstream-to=origin/master master

was spelled as

git branch --set-upstream master origin/master

or the branch's upstream can be set directly in .git/config by
modifying the "remote" and "merge" values in the [branch "foo"]
paragraph.

Hope that helps,
Jonathan
--
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: Pulling remotes into an empty repo deletes the index

2013-08-03 Thread Daniel Convissor
Heya:

On Sat, Aug 03, 2013 at 09:57:28AM -0700, Jonathan Nieder wrote:
> 
> Adam hadn't made a commit, so that wouldn't work in this case.

Oh, good catch.  I saw the add and assumed there was a commit there.

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335
--
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: Pulling remotes into an empty repo deletes the index

2013-08-03 Thread Daniel Convissor
Hey Again Adam:

On Sat, Aug 03, 2013 at 12:39:15PM -0400, Daniel Convissor wrote:
> 
> All is not lost.  Your local files should be stored in the repository's
> reflog.  Examine the output of "git reflog".  You can then reset your
> working directory to obtain those files by doing something _like_
> "git reset --hard HEAD@{1}".

A further thought.  The most useful thing to do would probably be along
these lines...

git reflog  # as mentioned before
git checkout -b myinitialstuff HEAD@{}
git log
git checkout master
git cherry-pick 

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335
--
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: Pulling remotes into an empty repo deletes the index

2013-08-03 Thread Jonathan Nieder
Daniel Convissor wrote:

> All is not lost.  Your local files should be stored in the repository's
> reflog.  Examine the output of "git reflog".  You can then reset your
> working directory to obtain those files by doing something _like_
> "git reset --hard HEAD@{1}".

Adam hadn't made a commit, so that wouldn't work in this case.

"git fsck --lost-found" should be helpful, but yeah, this is a bug.
See for example [1] for the start of a patch to play with (needs
tests).

Thanks and hope that helps,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/196502/focus=196503
--
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: change remote to track new branch

2013-08-03 Thread Daniel Convissor
Hi Andreas:

On Sat, Aug 03, 2013 at 06:41:46PM +0200, Andreas Schwab wrote:
> Daniel Convissor  writes:
> 
> Use git config.

Yeah.  I had contemplated using the following commands:

git config remote.wp.fetch \
"+refs/heads/3.6-branch:refs/remotes/wp/3.6-branch"
git config branch.wp.merge "refs/heads/3.6-branch"

So is "git remote set-branches" and "git branch --set-upstream-to" just
another syntax for making those same changes to git config?  Or do the
new commands do some additional work on the repository (to better keep
track of things, or whatever)?

Thanks,

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335
--
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: change remote to track new branch

2013-08-03 Thread Andreas Schwab
Daniel Convissor  writes:

> Thanks.  Those commands were introduced in 1.8.  Is there a way to do it
> in 1.7, please?

Use git config.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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: Pulling remotes into an empty repo deletes the index

2013-08-03 Thread Daniel Convissor
Hi Adam:

On Sat, Aug 03, 2013 at 10:01:30PM +1000, Adam A wrote:
> - create a remote repository at URL with commit(s) in it
>   - e.g., a new github repo with README and LICENSE files auto-added
> - write some files in a local directory
> - git init
> - git add .
>   - the contents of the directory are now in the index
> - git remote add origin URL
> - git pull origin master
> 
> The local files added to the index are now completely wiped out and
> replaced with the remote content. I lose all my previous work. :/

All is not lost.  Your local files should be stored in the repository's
reflog.  Examine the output of "git reflog".  You can then reset your
working directory to obtain those files by doing something _like_
"git reset --hard HEAD@{1}".

All hail reflog.

Good luck,

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335
--
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


[bug] remotes-hg: timezones are transformed

2013-08-03 Thread Jörn Hees
Hi,

it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a 
mercurial repo the timezone information of commits gets transformed into your 
current timezone.
(command: git clone hg::…)

I noticed this when a colleague in another timezone used Kiln to also export 
the same mercurial repo that i had cloned from git before.
Fetching from his git repo gives me a "second root tree" with all commits 
duplicated.
A git show of two equivalent commit reveals that the Date: line of the commits 
changed.
Tracking this back into the original mercurial repo reveals that _his_ times 
are correct.

This will also make two or more clones from different timezones all using the 
same hg remote repo incompatible!


Example:
Original mercurial commit (timezone: -7200 = -4h)
https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/

Lipis git export via Kiln: (-4h)
https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c

My export via git clone hg::ssh://h...@bitbucket.org/lipis/gae-init (+2h)
https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae

Expected would be that the hashes of both git exports are the same. His are 
correct as far as i can tell.


Cheers,
Jörn

--
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: change remote to track new branch

2013-08-03 Thread Daniel Convissor
Hi Andreas:

On Sat, Aug 03, 2013 at 09:14:59AM +0200, Andreas Schwab wrote:
> Daniel Convissor  writes:
> 
> > Long ago I added a remote to my repo.  It is set to track what was then
> > WordPress' main release branch (3.4-branch) and created a local branch
> > to use it.  Well, time marches on.  I want to update my remote and
> > branch to track the new main release branch (3.6-branch).
> >
> > Here's how I set things up at the time:
> >
> > git remote add -t 3.4-branch -f wp https://github.com/WordPress/WordPress
> > git checkout -b wp wp/3.4-branch
> 
> Use "git remote set-branches" to change the tracked branches of a
> remote.  Use "git branch --set-upstream-to" to change the upstream of a
> branch (or create a new branch from the new upstream).

Thanks.  Those commands were introduced in 1.8.  Is there a way to do it
in 1.7, please?

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335
--
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 replace: should it check for object type, and can it replace merges?

2013-08-03 Thread Thomas Rast
"Philip Oakley"  writes:

> A recent comment http://stackoverflow.com/a/18027030/717355 on a
> question I asked two years ago about 'grafts' and 'replace' indicates
> that users think that 'git replace' can't replace a merge commit. The
> documentation doesn't have any examples and gives the naive impression
> that one should only replace a simple commit with another simple
> commit.
>
> Having looked at the code, I realised that anything can be replaced
> with anything, which is perhaps not what was intended. A simple
> thought is that the replace should be like-for-like with regard to
> object type, though that would not include replacing a sub-module for
> a tree (and vice versa).

Off hand I cannot come up with any case where you can replace one object
with one of a different type, keeping the history valid.

To back that up:

* Refs can be "replaced" simply by changing the ref itself.

* Annotated tags contain the type of the tagged object.

* The tree/parent lines in commits must be a tree and commits, resp.

* The object types referred to by trees are specified in the 'mode'
  field:
100644 and 100755blob
16   commit
04   tree
  (these are the only valid modes)

* Blobs don't point at anything.

So yes:

> Should 'git replace' check the object types to ensure they are sensible?

I think that would be a very good thing to check.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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


git replace: should it check for object type, and can it replace merges?

2013-08-03 Thread Philip Oakley
A recent comment http://stackoverflow.com/a/18027030/717355 on a 
question I asked two years ago about 'grafts' and 'replace' indicates 
that users think that 'git replace' can't replace a merge commit. The 
documentation doesn't have any examples and gives the naive impression 
that one should only replace a simple commit with another simple commit.


Having looked at the code, I realised that anything can be replaced with 
anything, which is perhaps not what was intended. A simple thought is 
that the replace should be like-for-like with regard to object type, 
though that would not include replacing a sub-module for a tree (and 
vice versa).


Should 'git replace' check the object types to ensure they are sensible?

Would it be reasonable to add examples to indicate the range of 
replacements, and how to prepare alternative merge commits, or is that a 
hostage to fortune?



Philip Oakley

--
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 00/11] blame/log -L: additional tests and bug fixes

2013-08-03 Thread Thomas Rast
Eric Sunshine  writes:

> While working on multiple -L support for git-blame, I encountered more
> issues with the existing -L facility in git-blame and git-log. This
> series fixes these problems and adds a slew of new tests.
>
> Patch 6/11 (t4211: retire soon-to-be unimplementable tests) may be
> controversial. Removal of these tests was effectively a decision made in
> isolation since my request for input [1] regarding the issue generated
> only a single response (from j6t).

I agree with that decision.  It's better to not leave any user-facing
quirks just for internal's sake.

The right thing would be to either expose enough of the range_set api
through a test-range-set command, or just write all the tests in C.
Both seem a bit excessive since the API doesn't have any users outside
of log -L, which probably approaches "reasonable quality" now that you
shaked it down quite a bit.

As for the series, my tuits don't go further than a cursory read today,
but from that it seems good.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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] fix typo in documentation of git-svn

2013-08-03 Thread Felix Gruber
Signed-off-by: Felix Gruber 
---
 Documentation/git-svn.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index aad452f..8845e10 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -256,7 +256,7 @@ first have already been pushed into SVN.
For each patch, one may answer "yes" (accept this patch), "no" (discard 
this
patch), "all" (accept all patches), or "quit".
+
-   'git svn dcommit' returns immediately if answer if "no" or "quit", 
without
+   'git svn dcommit' returns immediately if answer is "no" or "quit", 
without
committing anything to SVN.
 
 'branch'::
-- 
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What's cooking in git.git (Jul 2013, #09; Mon, 29)

2013-08-03 Thread Mark Levedahl

On 08/01/2013 05:12 PM, Junio C Hamano wrote:

Ramsay Jones  writes:


Junio C Hamano wrote:

Ramsay Jones  writes:


  I am personally in favor of this simpler solution.  Comments?

I had expected this to me marked for 'master'.

Has this simply been overlooked, or do you have reservations about
applying this patch?

I am just being careful and do want to keep it cooking in 'next'
during the feature freeze.  The more users work with 'next' (not
"work *on* 'next'"), the more confidence we would be with, and
hopefully this can be one of the topis that graduate early after
the 1.8.4 release.

Hmm, this patch is a bug-fix for a bug that (currently) will be
_introduced_ by v1.8.4.

OK, let's merge it then.  Thanks for being patient with me.


Do you want me to try and find a different bug-fix for v1.8.4?
(Although that would most likely be more risky than simply taking
this patch! ;-) ).

Absolutely not, and I 100% agree with you.

I have been using this patch since Ramsey first sent it, have noticed no 
trouble over that time but all of my work is with filemode=true (has 
been since I started using git as Cygwin is a secondary platform for me 
and interoperability with repos on Linux is an absolute requirement).


Mark
--
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: Pulling remotes into an empty repo deletes the index

2013-08-03 Thread Adam A
Hello, the project readme on github points here for submitting bug
reports, but please let me know if I'm in the wrong place.

Steps to reproduce:

- create a remote repository at URL with commit(s) in it
  - e.g., a new github repo with README and LICENSE files auto-added
- write some files in a local directory
- git init
- git add .
  - the contents of the directory are now in the index
- git remote add origin URL
- git pull origin master

The local files added to the index are now completely wiped out and
replaced with the remote content. I lose all my previous work. :/

This was pretty painful for me to lose a few days of work. I also
couldn't stash my changes which I tried first, but git refused without
an initial commit.

Would have been nice if git warning me about the destructive operation.

Cheers,
Adam

On Sat, Aug 3, 2013 at 9:57 PM, Adam A  wrote:
> Hello, the project readme on github points here for submitting bug reports,
> but please let me know if I'm in the wrong place.
>
> Steps to reproduce:
>
> - create a remote repository at URL with commit(s) in it
>   - e.g., a new github repo with README and LICENSE files auto-added
> - write some files in a local directory
> - git init
> - git add .
>   - the contents of the directory are now in the index
> - git remote add origin URL
> - git pull origin master
>
> The local files added to the index are now completely wiped out and replaced
> with the remote content. I lose all my previous work. :/
>
> This was pretty painful for me to lose a few days of work. I also couldn't
> stash my changes which I tried first, but git refused without an initial
> commit.
>
> Would have been nice if git warning me about the destructive operation.
>
> Cheers,
> Adam
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 0/9] Removing deprecated parsing macros

2013-08-03 Thread Stefan Beller
On 08/03/2013 01:51 PM, Stefan Beller wrote:
> Suggested changes by Eric Sunshine included.
> 

The patches still apply on top of origin/jc/parseopt-command-modes




signature.asc
Description: OpenPGP digital signature


[PATCH] .mailmap: Multiple addresses of Michael S. Tsirkin

2013-08-03 Thread Stefan Beller
Acked-by: Michael S. Tsirkin 
Signed-off-by: Stefan Beller 
---
 .mailmap | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.mailmap b/.mailmap
index 57551b0..dfa2e65 100644
--- a/.mailmap
+++ b/.mailmap
@@ -130,6 +130,9 @@ Matthias Urlichs  
 Matthias Urlichs  
 Michael Coleman 
 Michael J Gruber  
+Michael S. Tsirkin  
+Michael S. Tsirkin  
+Michael S. Tsirkin  
 Michael W. Olson 
 Michael Witten  
 Michael Witten  
-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 1/9] Remove deprecated OPTION_BOOLEAN for parsing arguments

2013-08-03 Thread Stefan Beller
As of b04ba2bb4 OPTION_BOOLEAN was deprecated.
This commit removes all occurrences of OPTION_BOOLEAN.
In b04ba2bb4 Junio suggested to replace it with either
OPTION_SET_INT or OPTION_COUNTUP instead. However a pattern, which
occurred often with the OPTION_BOOLEAN was a hidden boolean parameter.
So I defined OPT_HIDDEN_BOOL as an additional possible parse option
in parse-options.h to make life easy.

The OPT_HIDDEN_BOOL was used in checkout, clone, commit, show-ref.
The only exception, where there was need to fiddle with OPTION_SET_INT
was log and notes. However in these two files there is also a pattern,
so we could think of introducing OPT_NONEG_BOOL.

Signed-off-by: Stefan Beller 
---
 builtin/checkout.c |  5 ++---
 builtin/clone.c|  7 +++
 builtin/commit.c   | 10 --
 builtin/log.c  |  4 ++--
 builtin/notes.c|  8 
 builtin/show-ref.c |  5 ++---
 parse-options.h|  5 ++---
 7 files changed, 19 insertions(+), 25 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 7025938..646a475 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1073,9 +1073,8 @@ int cmd_checkout(int argc, const char **argv, const char 
*prefix)
OPT_BOOLEAN('p', "patch", &opts.patch_mode, N_("select hunks 
interactively")),
OPT_BOOL(0, "ignore-skip-worktree-bits", 
&opts.ignore_skipworktree,
 N_("do not limit pathspecs to sparse entries only")),
-   { OPTION_BOOLEAN, 0, "guess", &dwim_new_local_branch, NULL,
- N_("second guess 'git checkout no-such-branch'"),
- PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+   OPT_HIDDEN_BOOL(0, "guess", &dwim_new_local_branch,
+   N_("second guess 'git checkout 
no-such-branch'")),
OPT_END(),
};
 
diff --git a/builtin/clone.c b/builtin/clone.c
index 430307b..e7b0b13 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -64,10 +64,9 @@ static struct option builtin_clone_options[] = {
 N_("force progress reporting")),
OPT_BOOLEAN('n', "no-checkout", &option_no_checkout,
N_("don't create a checkout")),
-   OPT_BOOLEAN(0, "bare", &option_bare, N_("create a bare repository")),
-   { OPTION_BOOLEAN, 0, "naked", &option_bare, NULL,
-   N_("create a bare repository"),
-   PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+   OPT_BOOL(0, "bare", &option_bare, N_("create a bare repository")),
+   OPT_HIDDEN_BOOL(0, "naked", &option_bare,
+   N_("create a bare repository")),
OPT_BOOLEAN(0, "mirror", &option_mirror,
N_("create a mirror repository (implies bare)")),
OPT_BOOL('l', "local", &option_local,
diff --git a/builtin/commit.c b/builtin/commit.c
index 003bd7d..b64a083 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1448,12 +1448,10 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, 
N_("mode"), N_("show untracked files, optional modes: all, normal, no. 
(Default: all)"), PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
/* end commit contents options */
 
-   { OPTION_BOOLEAN, 0, "allow-empty", &allow_empty, NULL,
- N_("ok to record an empty change"),
- PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
-   { OPTION_BOOLEAN, 0, "allow-empty-message", 
&allow_empty_message, NULL,
- N_("ok to record a change with an empty message"),
- PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+   OPT_HIDDEN_BOOL(0, "allow-empty", &allow_empty,
+   N_("ok to record an empty change")),
+   OPT_HIDDEN_BOOL(0, "allow-empty-message", &allow_empty_message,
+   N_("ok to record a change with an empty 
message")),
 
OPT_END()
};
diff --git a/builtin/log.c b/builtin/log.c
index 2625f98..05e374d 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1183,9 +1183,9 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
N_("don't output binary diffs")),
OPT_BOOLEAN(0, "ignore-if-in-upstream", &ignore_if_in_upstream,
N_("don't include a patch matching a commit 
upstream")),
-   { OPTION_BOOLEAN, 'p', "no-stat", &use_patch_format, NULL,
+   { OPTION_SET_INT, 'p', "no-stat", &use_patch_format, NULL,
  N_("show patch format instead of default (patch + stat)"),
- PARSE_OPT_NONEG | PARSE_OPT_NOARG },
+ PARSE_OPT_NONEG | PARSE_OPT_NOARG, NULL, 1},
OPT_GROUP(N_("Messaging")),
{ OPTION_CALLBACK, 0, "add-header", NULL, N_("header"),
N_("add email header"), 0, header_callback },
diff --git a/builtin/notes.c b/bu

[PATCHv3 9/9] revert: use the OPT_CMDMODE for parsing, reducing code

2013-08-03 Thread Stefan Beller
The revert command comes with their own implementation of checking
for exclusiveness of parameters.
Now that the OPT_CMDMODE is in place, we can also rely on that macro
instead of cooking that solution for each command itself.

This commit also replaces OPT_BOOLEAN, which was deprecated by b04ba2bb
(parse-options: deprecate OPT_BOOLEAN, 2011-09-27). Instead OPT_BOOL is
used.

Signed-off-by: Stefan Beller 
---
 builtin/revert.c | 62 ++--
 1 file changed, 15 insertions(+), 47 deletions(-)

diff --git a/builtin/revert.c b/builtin/revert.c
index 1d2648b..8e87acd 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -71,44 +71,19 @@ static void verify_opt_compatible(const char *me, const 
char *base_opt, ...)
die(_("%s: %s cannot be used with %s"), me, this_opt, base_opt);
 }
 
-LAST_ARG_MUST_BE_NULL
-static void verify_opt_mutually_compatible(const char *me, ...)
-{
-   const char *opt1, *opt2 = NULL;
-   va_list ap;
-
-   va_start(ap, me);
-   while ((opt1 = va_arg(ap, const char *))) {
-   if (va_arg(ap, int))
-   break;
-   }
-   if (opt1) {
-   while ((opt2 = va_arg(ap, const char *))) {
-   if (va_arg(ap, int))
-   break;
-   }
-   }
-   va_end(ap);
-
-   if (opt1 && opt2)
-   die(_("%s: %s cannot be used with %s"), me, opt1, opt2);
-}
-
 static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 {
const char * const * usage_str = revert_or_cherry_pick_usage(opts);
const char *me = action_name(opts);
-   int remove_state = 0;
-   int contin = 0;
-   int rollback = 0;
+   int cmd = 0;
struct option options[] = {
-   OPT_BOOLEAN(0, "quit", &remove_state, N_("end revert or 
cherry-pick sequence")),
-   OPT_BOOLEAN(0, "continue", &contin, N_("resume revert or 
cherry-pick sequence")),
-   OPT_BOOLEAN(0, "abort", &rollback, N_("cancel revert or 
cherry-pick sequence")),
-   OPT_BOOLEAN('n', "no-commit", &opts->no_commit, N_("don't 
automatically commit")),
-   OPT_BOOLEAN('e', "edit", &opts->edit, N_("edit the commit 
message")),
+   OPT_CMDMODE(0, "quit", &cmd, N_("end revert or cherry-pick 
sequence"), 'q'),
+   OPT_CMDMODE(0, "continue", &cmd, N_("resume revert or 
cherry-pick sequence"), 'c'),
+   OPT_CMDMODE(0, "abort", &cmd, N_("cancel revert or cherry-pick 
sequence"), 'a'),
+   OPT_BOOL('n', "no-commit", &opts->no_commit, N_("don't 
automatically commit")),
+   OPT_BOOL('e', "edit", &opts->edit, N_("edit the commit 
message")),
OPT_NOOP_NOARG('r', NULL),
-   OPT_BOOLEAN('s', "signoff", &opts->signoff, N_("add 
Signed-off-by:")),
+   OPT_BOOL('s', "signoff", &opts->signoff, N_("add 
Signed-off-by:")),
OPT_INTEGER('m', "mainline", &opts->mainline, N_("parent 
number")),
OPT_RERERE_AUTOUPDATE(&opts->allow_rerere_auto),
OPT_STRING(0, "strategy", &opts->strategy, N_("strategy"), 
N_("merge strategy")),
@@ -124,11 +99,11 @@ static void parse_args(int argc, const char **argv, struct 
replay_opts *opts)
 
if (opts->action == REPLAY_PICK) {
struct option cp_extra[] = {
-   OPT_BOOLEAN('x', NULL, &opts->record_origin, N_("append 
commit name")),
-   OPT_BOOLEAN(0, "ff", &opts->allow_ff, N_("allow 
fast-forward")),
-   OPT_BOOLEAN(0, "allow-empty", &opts->allow_empty, 
N_("preserve initially empty commits")),
-   OPT_BOOLEAN(0, "allow-empty-message", 
&opts->allow_empty_message, N_("allow commits with empty messages")),
-   OPT_BOOLEAN(0, "keep-redundant-commits", 
&opts->keep_redundant_commits, N_("keep redundant, empty commits")),
+   OPT_BOOL('x', NULL, &opts->record_origin, N_("append 
commit name")),
+   OPT_BOOL(0, "ff", &opts->allow_ff, N_("allow 
fast-forward")),
+   OPT_BOOL(0, "allow-empty", &opts->allow_empty, 
N_("preserve initially empty commits")),
+   OPT_BOOL(0, "allow-empty-message", 
&opts->allow_empty_message, N_("allow commits with empty messages")),
+   OPT_BOOL(0, "keep-redundant-commits", 
&opts->keep_redundant_commits, N_("keep redundant, empty commits")),
OPT_END(),
};
if (parse_options_concat(options, ARRAY_SIZE(options), 
cp_extra))
@@ -139,23 +114,16 @@ static void parse_args(int argc, const char **argv, 
struct replay_opts *opts)
PARSE_OPT_KEEP_ARGV0 |
PARSE_OPT_KEEP_UNKNOWN);
 
-   /* Check for incompatible subcommands */
-   verify_opt_mutually_compatible(me,
-

[PATCHv3 4/9] checkout: remove superfluous local variable

2013-08-03 Thread Stefan Beller
Signed-off-by: Stefan Beller 
---
 builtin/checkout.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8b48f4a..ed39cec 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -228,8 +228,6 @@ static int checkout_paths(const struct checkout_opts *opts,
int flag;
struct commit *head;
int errs = 0;
-   int stage = opts->writeout_stage;
-   int merge = opts->merge;
int newfd;
struct lock_file *lock_file;
 
@@ -327,8 +325,8 @@ static int checkout_paths(const struct checkout_opts *opts,
continue;
if (opts->force) {
warning(_("path '%s' is unmerged"), ce->name);
-   } else if (stage) {
-   errs |= check_stage(stage, ce, pos);
+   } else if (opts->writeout_stage) {
+   errs |= check_stage(opts->writeout_stage, ce, 
pos);
} else if (opts->merge) {
errs |= check_stages((1<<2) | (1<<3), ce, pos);
} else {
@@ -352,9 +350,9 @@ static int checkout_paths(const struct checkout_opts *opts,
errs |= checkout_entry(ce, &state, NULL);
continue;
}
-   if (stage)
-   errs |= checkout_stage(stage, ce, pos, &state);
-   else if (merge)
+   if (opts->writeout_stage)
+   errs |= checkout_stage(opts->writeout_stage, 
ce, pos, &state);
+   else if (opts->merge)
errs |= checkout_merged(pos, &state);
pos = skip_same_name(ce, pos) - 1;
}
-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 6/9] hash-object: Replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP

2013-08-03 Thread Stefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
2011-09-27). hash-object is a plumbing layer command, so better
not change the input/output behavior for now.

Unfortunately we have these lines relying on the count up mechanism of
OPT_BOOLEAN:

if (hashstdin > 1)
errstr = "Multiple --stdin arguments are not supported";

Maybe later, when the plumbing is refined (git 2.0?), we can drop that
error message and replace the OPT_COUNTUP by OPT_BOOL.

Signed-off-by: Stefan Beller 
---
 builtin/hash-object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/hash-object.c b/builtin/hash-object.c
index 4aea5bb..d7fcf4c 100644
--- a/builtin/hash-object.c
+++ b/builtin/hash-object.c
@@ -71,7 +71,7 @@ static const char *vpath;
 static const struct option hash_object_options[] = {
OPT_STRING('t', NULL, &type, N_("type"), N_("object type")),
OPT_BOOL('w', NULL, &write_object, N_("write the object into the object 
database")),
-   OPT_BOOLEAN( 0 , "stdin", &hashstdin, N_("read the object from stdin")),
+   OPT_COUNTUP( 0 , "stdin", &hashstdin, N_("read the object from stdin")),
OPT_BOOL( 0 , "stdin-paths", &stdin_paths, N_("read file names from 
stdin")),
OPT_BOOL( 0 , "no-filters", &no_filters, N_("store file as is without 
filters")),
OPT_STRING( 0 , "path", &vpath, N_("file"), N_("process file as it were 
from this path")),
-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 8/9] checkout-index: Fix negations of even numbers of -n

2013-08-03 Thread Stefan Beller
The --no-create was parsed with OPT_BOOLEAN, which has a counting up
logic implemented. Since b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
2011-09-27) the OPT_BOOLEAN is deprecated and is only a define:
/* Deprecated synonym */
#define OPTION_BOOLEAN OPTION_COUNTUP

However the variable not_new, which can be counted up by giving
--no-create multiple times, is used to set a bit in the struct checkout
bitfield (defined in cache.h:969, declared at builtin/checkout-index.c:19):

state.not_new = not_new;

When assigning a value other than 0 or 1 to a bit, all leading digits but
the last are ignored and only the last bit is used for setting the bit
variable.

Hence the following:
# in git.git:
$ git status
# working directory clean
rm COPYING
$ git status
# deleted:COPYING
$ git checkout-index -a -n
$ git status
# deleted:COPYING
# which is expected as we're telling git to not restore or create
# files, however:
$ git checkout-index -a -n -n
$ git status
# working directory clean, COPYING is restored again!
# That's the bug, we're fixing here.

By restraining the variable not_new to a value being definitely 0 or 1
by the macro OPT_BOOL the bug is fixed.

Signed-off-by: Stefan Beller 
---
 builtin/checkout-index.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/checkout-index.c b/builtin/checkout-index.c
index aa922ed..69e167b 100644
--- a/builtin/checkout-index.c
+++ b/builtin/checkout-index.c
@@ -188,7 +188,7 @@ int cmd_checkout_index(int argc, const char **argv, const 
char *prefix)
OPT__FORCE(&force, N_("force overwrite of existing files")),
OPT__QUIET(&quiet,
N_("no warning for existing files and files not in 
index")),
-   OPT_BOOLEAN('n', "no-create", ¬_new,
+   OPT_BOOL('n', "no-create", ¬_new,
N_("don't checkout new files")),
{ OPTION_CALLBACK, 'u', "index", &newfd, NULL,
N_("update stat information in the index file"),
-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 5/9] branch, commit, name-rev: ease up boolean conditions

2013-08-03 Thread Stefan Beller
Now that the variables are readin by OPT_BOOL, which makes sure
to have the values being 0 or 1 after reading, we do not need
the double negation to map any other value to 1 for integer
variables.

Signed-off-by: Stefan Beller 
---
 builtin/branch.c   | 3 ++-
 builtin/commit.c   | 2 +-
 builtin/name-rev.c | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index 4daed0b..33ba1fb 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -872,7 +872,8 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
if (with_commit || merge_filter != NO_FILTER)
list = 1;
 
-   if (!!delete + !!rename + !!force_create + !!list + !!new_upstream + 
!!unset_upstream > 1)
+   if (delete + rename + force_create + list + unset_upstream +
+   !!new_upstream > 1)
usage_with_options(builtin_branch_usage, options);
 
if (abbrev == -1)
diff --git a/builtin/commit.c b/builtin/commit.c
index c20426b..b0f86c8 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1072,7 +1072,7 @@ static int parse_and_validate_options(int argc, const 
char *argv[],
if (patch_interactive)
interactive = 1;
 
-   if (!!also + !!only + !!all + !!interactive > 1)
+   if (also + only + all + interactive > 1)
die(_("Only one of --include/--only/--all/--interactive/--patch 
can be used."));
if (argc == 0 && (also || (only && !amend)))
die(_("No paths with --include/--only does not make sense."));
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index a908a34..20fcf8c 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -331,7 +331,7 @@ int cmd_name_rev(int argc, const char **argv, const char 
*prefix)
 
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, prefix, opts, name_rev_usage, 0);
-   if (!!all + !!transform_stdin + !!argc > 1) {
+   if (all + transform_stdin + !!argc > 1) {
error("Specify either a list, or --all, not both!");
usage_with_options(name_rev_usage, opts);
}
-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 3/9] log, format-patch: parsing uses OPT__QUIET

2013-08-03 Thread Stefan Beller
This patch allows users to use the short form -q on
log and format-patch, which was non possible before.

Also the documentation of format-patch mentions -q now.

The documentation of log doesn't even talk about --quiet, so I'll leave
that for more experienced git contributors. ;)
It doesn't seem to change the default behavior, but in combination
with --stat for example it suppresses the actual stats.
however the only relevant code in log is
if (quiet)
rev->diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;

Signed-off-by: Stefan Beller 
---
 Documentation/git-format-patch.txt | 1 +
 builtin/log.c  | 5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-format-patch.txt 
b/Documentation/git-format-patch.txt
index e394276..9e0ef0e 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -242,6 +242,7 @@ configuration options in linkgit:git-notes[1] to use this 
workflow).
 Note that the leading character does not have to be a dot; for example,
 you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
 
+-q::
 --quiet::
Do not print the names of the generated files to standard output.
 
diff --git a/builtin/log.c b/builtin/log.c
index 1dafbd0..ed4dec4 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -121,7 +121,7 @@ static void cmd_log_init_finish(int argc, const char 
**argv, const char *prefix,
static struct line_opt_callback_data line_cb = {NULL, NULL, 
STRING_LIST_INIT_DUP};
 
const struct option builtin_log_options[] = {
-   OPT_BOOL(0, "quiet", &quiet, N_("suppress diff output")),
+   OPT__QUIET(&quiet, N_("suppress diff output")),
OPT_BOOL(0, "source", &source, N_("show source")),
OPT_BOOL(0, "use-mailmap", &mailmap, N_("Use mail map file")),
{ OPTION_CALLBACK, 0, "decorate", NULL, NULL, N_("decorate 
options"),
@@ -1210,8 +1210,7 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
PARSE_OPT_OPTARG, thread_callback },
OPT_STRING(0, "signature", &signature, N_("signature"),
N_("add a signature")),
-   OPT_BOOLEAN(0, "quiet", &quiet,
-   N_("don't print the patch filenames")),
+   OPT__QUIET(&quiet, N_("don't print the patch filenames")),
OPT_END()
};
 
-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 0/9] Removing deprecated parsing macros

2013-08-03 Thread Stefan Beller
Suggested changes by Eric Sunshine included.

Within the builtin/ folder all occurrences of OPT_BOOLEAN have been removed.
Now we only need to review the usage of it in parse-options as used in
OPT__VERBOSE, OPT__QUIET, OPT__DRY_RUN and OPT__FORCE.
Most likely we could just use OPT_SET_INT there and then OPT_BOOLEAN is 
gone.

The patch 1 and 2 are not intended to change any semantics,
but were the most work, because of the checking for each place not
changing the semantics.

Patch 3 introduces -q the shortform of --quiet for log and format-patch 

Patch 4,5 are unspectacular, just improving readability.

Patch 6 is indeed the only occurence, where I needed to use OPT_COUNTUP
for OPT_BOOLEAN. Personally I'd change it there as well, but it's plumbing.

Patch 7 makes git config a little more flexible (allowing --global 
multiple times).

Patch 8 is a change in the plumbing layer, what I'd call a bugfix,
not urgent, but still.

Patch 9 introduces the new OPT_CMDMODE to revert. Junio suggested to 
change the OPT_CMDMODE a little and use the short parameter as the value
assigned to the command variable. This patch shows, why it might not be a
good idea, as the options there do not have short parameters.


Stefan Beller (9):
  Remove deprecated OPTION_BOOLEAN for parsing arguments
  Replace deprecated OPT_BOOLEAN by OPT_BOOL
  log, format-patch: parsing uses OPT__QUIET
  checkout: remove superfluous local variable
  branch, commit, name-rev: ease up boolean conditions
  hash-object: Replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP
  config parsing options: allow one flag multiple times
  checkout-index: Fix negations of even numbers of -n
  revert: use the OPT_CMDMODE for parsing, reducing code

 Documentation/git-format-patch.txt |  1 +
 builtin/apply.c| 24 +++
 builtin/bisect--helper.c   |  8 ++---
 builtin/blame.c|  8 ++---
 builtin/branch.c   | 13 
 builtin/check-attr.c   |  8 ++---
 builtin/check-ignore.c | 12 
 builtin/checkout-index.c   |  8 ++---
 builtin/checkout.c | 27 -
 builtin/clean.c|  6 ++--
 builtin/clone.c| 23 +++---
 builtin/commit.c   | 48 ++---
 builtin/config.c   |  8 ++---
 builtin/describe.c | 20 ++--
 builtin/fast-export.c  | 10 +++---
 builtin/fetch.c| 24 +++
 builtin/fsck.c | 16 +-
 builtin/gc.c   |  4 +--
 builtin/grep.c | 38 +++
 builtin/hash-object.c  |  8 ++---
 builtin/log.c  | 17 +--
 builtin/ls-files.c | 24 +++
 builtin/ls-tree.c  |  6 ++--
 builtin/merge-base.c   | 10 +++---
 builtin/merge-file.c   |  2 +-
 builtin/merge.c| 12 
 builtin/mv.c   |  2 +-
 builtin/name-rev.c | 14 -
 builtin/notes.c| 12 
 builtin/push.c |  6 ++--
 builtin/remote.c   | 28 -
 builtin/replace.c  |  6 ++--
 builtin/reset.c|  2 +-
 builtin/rev-parse.c|  4 +--
 builtin/revert.c   | 62 +-
 builtin/rm.c   |  6 ++--
 builtin/shortlog.c | 12 
 builtin/show-branch.c  | 28 -
 builtin/show-ref.c | 15 +
 builtin/tag.c  |  4 +--
 builtin/update-ref.c   |  4 +--
 parse-options.h|  5 ++-
 42 files changed, 278 insertions(+), 317 deletions(-)

-- 
1.8.4.rc0.16.g7fca822.dirty

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


[PATCHv3 7/9] config parsing options: allow one flag multiple times

2013-08-03 Thread Stefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
2011-09-27).

This commit introduces a change for the users, after this patch
you can pass one of the config level flags multiple times:
Before:
$ git config --global --global --list
error: only one config file at a time.
usage: ...

Afterwards this will work. This is due to the following check in the code:
if (use_global_config + use_system_config + use_local_config +
!!given_config_file + !!given_config_blob > 1) {
error("only one config file at a time.");
usage_with_options(builtin_config_usage, 
builtin_config_options);
}

With OPT_BOOL instead of OPT_BOOLEAN the variables use_global_config,
use_system_config, use_local_config will only have the value 0 if the
command line option was not passed or 1 no matter how often the
respective command line option was passed.

Signed-off-by: Stefan Beller 
---
 builtin/config.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index da12fdb..4ab9e9a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -50,9 +50,9 @@ static int respect_includes = -1;
 
 static struct option builtin_config_options[] = {
OPT_GROUP(N_("Config file location")),
-   OPT_BOOLEAN(0, "global", &use_global_config, N_("use global config 
file")),
-   OPT_BOOLEAN(0, "system", &use_system_config, N_("use system config 
file")),
-   OPT_BOOLEAN(0, "local", &use_local_config, N_("use repository config 
file")),
+   OPT_BOOL(0, "global", &use_global_config, N_("use global config file")),
+   OPT_BOOL(0, "system", &use_system_config, N_("use system config file")),
+   OPT_BOOL(0, "local", &use_local_config, N_("use repository config 
file")),
OPT_STRING('f', "file", &given_config_file, N_("file"), N_("use given 
config file")),
OPT_STRING(0, "blob", &given_config_blob, N_("blob-id"), N_("read 
config from given blob object")),
OPT_GROUP(N_("Action")),
-- 
1.8.4.rc0.16.g7fca822.dirty

--
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] l10n: de.po: translate 99 new messages

2013-08-03 Thread Thomas Rast
Ralf Thielow  writes:

> Translate 99 new messages came from git.pot update in
> 28b3cff (l10n: git.pot: v1.8.4 round 1 (99 new, 46 removed)).
>
> Signed-off-by: Ralf Thielow 

Acked-by: Thomas Rast 

Thanks for your work!

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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 (Aug 2013, #01; Thu, 1)

2013-08-03 Thread Thomas Rast
Junio C Hamano  writes:

> * tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
>  - log: use true parents for diff even when rewriting
>
>  Output from "git log --full-diff -- " looked strange,
>  because comparison was done with the previous ancestor that touched
>  the specified , causing the patches for paths outside the
>  pathspec to show more than the single commit has changed.
>
>  I am not sure if that is necessarily a problem, though.  Output
>  from "git log --full-diff -2 -- " without this change
>  will be applicable to some codebase, but after this change that
>  will no longer be true (you will get only tiny parts of the change
>  that were made by the two commits in question, while missing all
>  the other changes).

Hmm.  Uwe's original complaint was that --stat -- as in "what other
things are touched when we modify foo" -- is nonsensical.

In addition, applying what you describe above would be a very strange
form of rebase: one that squashes everything into the commits that
affect the given files.  When would it ever make sense to do such
squashing?  After all, you'd lose all the commit splits&messages in
between.

If you care about it, I can introduce a new flag that lets the user
pick; it's pretty trivial.  But it seems very strange to me.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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] cherry-pick: allow "-" as abbreviation of '@{-1}'

2013-08-03 Thread Thomas Rast
Hiroshige Umino  writes:

> As "git cherry-pick -" or "git merge -" is convenient to
> switch back to or merge the previous branch,
> "git cherry-pick -" is abbreviation of "git cherry-pick @{-1}"
> to pick up a commit from the previous branch conveniently.

The first line is confusing.  Did you mean to invoke the existing 'git
*checkout* -' and 'git merge -' functionality as a reason why 'git
cherry-pick -' should exist?

What other commands could reasonably use the '-' shorthand?

[...]
> diff --git a/t/t3512-cherry-pick-last.sh b/t/t3512-cherry-pick-last.sh

Do you have to use a new test file for this?

[...]
> +test_expect_success 'setup' '
> + echo hello >world &&
> + git add world &&
(*)
> + git commit -m initial &&
> + git branch other &&
> + echo "hello again" >>world &&
> + git add world &&
(*)
> + git commit -m second
> +'

Our style is to indent the test snippets with a hard tab, not a single
(or eight, for that matter) space.

[...]
> +test_expect_success 'cherry-pick the commit in the previous branch' '
> + prev=$(git rev-parse HEAD) &&
> + git checkout other &&
(*)
> + git cherry-pick - &&
> + test "z$(git rev-parse HEAD)" = "z$prev"
> +'

If you insert 'test_tick' in the places marked with (*), the test fails.

The tests run under a fake clock to ensure that everything, including
the SHA1s produced, are deterministic.  You never advance the clock, so
all commits generated in this script share the same timestamp.

This means that the cherry-pick of 'second' has the same SHA1 as the
original: its tree, parents, author, timestamp etc. all agree.  If you
advance the clock at the last (*), this fails.  You should find some
other way of checking what was picked, e.g., by looking at the file
contents.

That said, please use test_commit in the 'setup' snippet instead of
manually rolling the commits.  It will lead to shorter code, and it
handles test_tick for you.  It is documented in t/README and in a
comment in t/test-lib-functions.sh.  (You still need test_tick
immediately before the cherry-pick!)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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] gc: reject if another gc is running, unless --force is given

2013-08-03 Thread Johannes Sixt
Am 03.08.2013 12:01, schrieb Duy Nguyen:
> On Sat, Aug 03, 2013 at 11:49:02AM +0200, Johannes Sixt wrote:
>> Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
>>>  I changed mingw.h to add a stub uname() because I don't think MinGW
>>>  port has that function, but that's totally untested.
>>
>> Thanks, but we don't have kill(pid, 0), either :-(
> 
> Yeah, I should have checked. Will this work?
> 
> -- 8< --
> diff --git a/compat/mingw.c b/compat/mingw.c
> index bb92c43..14d92df 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1086,6 +1086,12 @@ int mingw_kill(pid_t pid, int sig)
>   errno = err_win_to_posix(GetLastError());
>   CloseHandle(h);
>   return -1;
> + } else if (pid > 0 && sig == 0) {
> + HANDLE h = OpenProcess(PROCESS_TERMINATE, FALSE, pid);
> + if (h) {
> + CloseHandle(h);
> + return 0;
> + }
>   }
>  
>   errno = EINVAL;
> -- 8< --
> 

Looks reasonable. PROCESS_QUERY_INFORMATION instead of PROCESS_TERMINATE
should be sufficient, and errno = ESRCH; return -1; is missing.

-- 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: [PATCH] log: use true parents for diff when walking reflogs

2013-08-03 Thread Thomas Rast
Doh, once again I forgot the in-reply-to.  This patch continues the
thread after <20130731225520.gb25...@sigill.intra.peff.net>.  This is --
strangely enough -- missing from gmane; its immediate predecessor is
this:

  http://thread.gmane.org/gmane.comp.version-control.git/230968/focus=231453

Sorry for the noise.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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] log: use true parents for diff when walking reflogs

2013-08-03 Thread Thomas Rast
The reflog walking logic (git log -g) replaces the true parent list
with the preceding commit in the reflog.  This results in bogus commit
diffs when combined with options such as -p; the diff is against the
reflog predecessor, not the parent of the commit.

Save the true parents on the side, extending the functions from the
previous commit.  The diff logic picks them up and uses them to show
the correct diffs.

We do have to be somewhat careful about repeated calling of
save_parents(), since the reflog may list a commit more than once.  We
now store (commit_list*)-1 to distinguish the "not saved yet" and
"root commit" cases.  This lets us preserve an empty parent list even
if save_parents() is repeatedly called.

Suggested-by: Jeff King 
Signed-off-by: Thomas Rast 
---

Jeff King  wrote:
> 
> Your description (and solution) make a lot of sense to me. Another code
> path that has a similar problem is the "-g" reflog walker. It rewrites
> the parents based on the reflog, and the diffs it produces are mostly
> useless (e.g., try "git stash list -p").
> 
> Should we be applying the same technique there?

Good point.  This is how.  It applies on top of the other patch.

It doesn't really help for 'git stash list -p', though, because
stashes are merge commits.  Now they just don't show anything.  You
could try 'git stash list -p -m', though.


 revision.c | 28 +---
 t/t1411-reflog-show.sh | 22 ++
 2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/revision.c b/revision.c
index e3ca936..ac20d1a 100644
--- a/revision.c
+++ b/revision.c
@@ -2848,6 +2848,7 @@ static struct commit *get_revision_1(struct rev_info 
*revs)
free(entry);
 
if (revs->reflog_info) {
+   save_parents(revs, commit);
fake_reflog_parent(revs->reflog_info, commit);
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
}
@@ -3083,6 +3084,8 @@ void put_revision_mark(const struct rev_info *revs, const 
struct commit *commit)
 
 define_commit_slab(saved_parents, struct commit_list *);
 
+#define EMPTY_PARENT_LIST ((struct commit_list *)-1)
+
 void save_parents(struct rev_info *revs, struct commit *commit)
 {
struct commit_list **pp;
@@ -3093,16 +3096,35 @@ void save_parents(struct rev_info *revs, struct commit 
*commit)
}
 
pp = saved_parents_at(revs->saved_parents_slab, commit);
-   assert(*pp == NULL);
-   *pp = copy_commit_list(commit->parents);
+
+   /*
+* When walking with reflogs, we may visit the same commit
+* several times: once for each appearance in the reflog.
+*
+* In this case, save_parents() will be called multiple times.
+* We want to keep only the first set of parents.  We need to
+* store a sentinel value for an empty (i.e., NULL) parent
+* list to distinguish it from a not-yet-saved list, however.
+*/
+   if (*pp)
+   return;
+   if (commit->parents)
+   *pp = copy_commit_list(commit->parents);
+   else
+   *pp = EMPTY_PARENT_LIST;
 }
 
 struct commit_list *get_saved_parents(struct rev_info *revs, const struct 
commit *commit)
 {
+   struct commit_list *parents;
+
if (!revs->saved_parents_slab)
return commit->parents;
 
-   return *saved_parents_at(revs->saved_parents_slab, commit);
+   parents = *saved_parents_at(revs->saved_parents_slab, commit);
+   if (parents == EMPTY_PARENT_LIST)
+   return NULL;
+   return parents;
 }
 
 void free_saved_parents(struct rev_info *revs)
diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
index 9a105fe..6f47c0d 100755
--- a/t/t1411-reflog-show.sh
+++ b/t/t1411-reflog-show.sh
@@ -144,4 +144,26 @@ test_expect_success 'empty reflog file' '
test_cmp expect actual
 '
 
+# This guards against the alternative of showing the diffs vs. the
+# reflog ancestor.  The reflog used is designed to list the commits
+# more than once, so as to exercise the corresponding logic.
+test_expect_success 'git log -g -p shows diffs vs. parents' '
+   test_commit two &&
+   git branch flipflop &&
+   git update-ref refs/heads/flipflop -m flip1 HEAD^ &&
+   git update-ref refs/heads/flipflop -m flop1 HEAD &&
+   git update-ref refs/heads/flipflop -m flip2 HEAD^ &&
+   git log -g -p flipflop >reflog &&
+   grep -v ^Reflog reflog >actual &&
+   git log -1 -p HEAD^ >log.one &&
+   git log -1 -p HEAD >log.two &&
+   (
+   cat log.one; echo
+   cat log.two; echo
+   cat log.one; echo
+   cat log.two
+   ) >expect &&
+   test_cmp expect actual
+'
+
 test_done
-- 
1.8.4.rc1.414.g34bc5b2

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

Re: Rewriting git-repack.sh in C

2013-08-03 Thread Duy Nguyen
On Sat, Aug 3, 2013 at 1:33 PM, Fredrik Gustafsson  wrote:
> On Fri, Aug 02, 2013 at 09:10:59PM +0700, Duy Nguyen wrote:
>> > So my question is, how you'd generally approach rewriting a
>> > shell script in C.
>>
>> Start a new process via start_command/run_command interface. It's
>> safer to retain the process boundary at this stage. You can try to
>> integrate further later.
>
> Is it really the right approach to just replace sh with C? IMHO forking
> and wait for the result should not be done if it can be avoided. It just
> adds overhead.

Agreed. As I said in another post, I misread this as rewriting
git-rebase.sh, which is a lot more complicated.

> Of course you can argue that just replace sh with C is a good first step
> towards to actually do the command in "full C". Altough I'm afraid that
> that will get such low priority that it won't be done.

One of the reasons I started porting git-repack.sh since 2011 and
never finished it.
-- 
Duy
--
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] gc: reject if another gc is running, unless --force is given

2013-08-03 Thread Duy Nguyen
On Sat, Aug 3, 2013 at 2:52 PM, Ramkumar Ramachandra  wrote:
>> +   time(NULL) - st.st_mtime <= 12 * 3600) {
>
> Quick question: is this kind of file-lifetime used anywhere else in git.git?

I don't think so.
-- 
Duy
--
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] gc: reject if another gc is running, unless --force is given

2013-08-03 Thread Duy Nguyen
On Sat, Aug 03, 2013 at 11:49:02AM +0200, Johannes Sixt wrote:
> Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
> >  I changed mingw.h to add a stub uname() because I don't think MinGW
> >  port has that function, but that's totally untested.
> 
> Thanks, but we don't have kill(pid, 0), either :-(

Yeah, I should have checked. Will this work?

-- 8< --
diff --git a/compat/mingw.c b/compat/mingw.c
index bb92c43..14d92df 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1086,6 +1086,12 @@ int mingw_kill(pid_t pid, int sig)
errno = err_win_to_posix(GetLastError());
CloseHandle(h);
return -1;
+   } else if (pid > 0 && sig == 0) {
+   HANDLE h = OpenProcess(PROCESS_TERMINATE, FALSE, pid);
+   if (h) {
+   CloseHandle(h);
+   return 0;
+   }
}
 
errno = EINVAL;
-- 8< --
--
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] gc: reject if another gc is running, unless --force is given

2013-08-03 Thread Johannes Sixt
Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
>  I changed mingw.h to add a stub uname() because I don't think MinGW
>  port has that function, but that's totally untested.

Thanks, but we don't have kill(pid, 0), either :-(

-- 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: [PATCH v2] gc: reject if another gc is running, unless --force is given

2013-08-03 Thread Ramkumar Ramachandra
Nguyễn Thái Ngọc Duy wrote:
> This may happen when `git gc --auto` is run automatically, then the
> user, to avoid wait time, switches to a new terminal, keeps working
> and `git gc --auto` is started again because the first gc instance has
> not clean up the repository.
>
> This patch tries to avoid multiple gc running, especially in --auto
> mode. In the worst case, gc may be delayed 12 hours if a daemon reuses
> the pid stored in gc-%s.pid.

Definitely looks like a good solution. Thanks for this.

I'm currently on vacation, so can't apply and test: sorry.

> +   if (!force &&
> +   (fp = fopen(git_path("gc-%s.pid", utsname.nodename), "r")) != 
> NULL &&
> +   !fstat(fileno(fp), &st) &&

It's open for a very short period of time, so lockfile (which we'd
normally use) would probably be an overkill.

> +   time(NULL) - st.st_mtime <= 12 * 3600) {

Quick question: is this kind of file-lifetime used anywhere else in git.git?

> +   if (auto_gc)
> +   return 0; /* be quiet on --auto */
> +   die(_("gc is already running"));

Nice.
--
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: Please pull l10n updates for 1.8.4 round 1

2013-08-03 Thread Jiang Xin
2013/8/3 Jiang Xin :
>>> are available in the git repository at:
>>>
>>>git://github.com/gotgit/git-po
>>
>>
>> git://github.com/git-l10n/git-po
>>
>
> Thanks Trần. Should be git-l10n/got-po, and gotgit/git-po does not exist.
>

In order to prevent this, next time when I generate this pull request text,
I will use the following command:

$ git request-pull kernel/master origin

"kernel" is a remote points to git://git.kernel.org/pub/scm/git/git.git,
while "origin" should have two urls, one for fetch and one for push.

$ git config --get-regexp remote.origin..*url
remote.origin.url git://github.com/git-l10n/git-po
remote.origin.pushurl jiangxin.github.com:git-l10n/git-po  # ssh protocol

The url for fetch will be used when generate pull request.

--
Jiang Xin
--
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: [regression] Re: git-cat-file --batch reversion; cannot query filenames with spaces

2013-08-03 Thread Jeff King
On Fri, Aug 02, 2013 at 11:30:03AM -0700, Junio C Hamano wrote:

> > I didn't see the result of your wrangling in pu, but I will keep an eye
> > out to double-check it (unless you did not finish, in which case I am
> > happy to do the wrangling myself).
> 
> Here is what is on top of the revert that has been pushed out on
> 'pu'.

Thanks, that looks good to me.

We may want to also squash in the patch below, which puts the pointer
variable in the most-local block and re-wraps the newly indented comment
for line length. Neither introduced by your adaptation, but they became
more obvious to me when seen on top of the revert.

-Peff

---
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 07b4818..41afaa5 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -286,15 +286,15 @@ static int batch_objects(struct batch_options *opt)
warn_on_object_refname_ambiguity = 0;
 
while (strbuf_getline(&buf, stdin, '\n') != EOF) {
-   char *p;
int error;
 
if (data.split_on_whitespace) {
/*
-* Split at first whitespace, tying off the beginning 
of the
-* string and saving the remainder (or NULL) in 
data.rest.
+* Split at first whitespace, tying off the beginning
+* of the string and saving the remainder (or NULL) in
+* data.rest.
 */
-   p = strpbrk(buf.buf, " \t");
+   char *p = strpbrk(buf.buf, " \t");
if (p) {
while (*p && strchr(" \t", *p))
*p++ = '\0';

--
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: Please pull l10n updates for 1.8.4 round 1

2013-08-03 Thread Jiang Xin
2013/8/3 Trần Ngọc Quân :
> On 03/08/2013 13:39, Jiang Xin wrote:
>>
>> Hi, Junio
>>
>> Please pull these updates for git l10n.
>>
>> BTW, Ralf's updates for de.po are still in the review process in this
>> list,
>> but I want to send this pull request earlier, because I find there are
>> some
>> new l10n changes (5 new/modified messages) in v1.8.4-rc1. I will start
>> git 1.8,4 l10n rnd 2 right after gitster closes this pull request.
>>
>> The following changes since commit
>> c490a6079021a3343ca5b042b37258858fdefbfc:
>>
>>Git 1.8.4-rc0 (2013-07-24 19:29:07 -0700)
>>
>> are available in the git repository at:
>>
>>git://github.com/gotgit/git-po
>
>
> git://github.com/git-l10n/git-po
>

Thanks Trần. Should be git-l10n/got-po, and gotgit/git-po does not exist.

>
>>
>> for you to fetch changes up to 2e8451e8602380a8a129f21da6364f3ea879e6a9:
>>
>>l10n: zh_CN.po: translate 99 messages (2133t0f0u) (2013-08-03 14:14:07
>> +0800)
>>
>> 
>> Jiang Xin (2):
>>l10n: git.pot: v1.8.4 round 1 (99 new, 46 removed)
>>l10n: zh_CN.po: translate 99 messages (2133t0f0u)
>>
>> Tran Ngoc Quan (1):
>>l10n: vi.po (2133t)
>>
>>   po/git.pot  | 3072 +
>>   po/vi.po| 3383
>> +--
>>   po/zh_CN.po | 3300
>> -
>>   3 files changed, 5403 insertions(+), 4352 deletions(-)
>>
>> --
>> Jiang Xin
>
>
>
> --
> Thanks,
> Trần Ngọc Quân
>



-- 
蒋鑫

北京群英汇信息技术有限公司
邮件: worldhello@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 18601196889
--
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: change remote to track new branch

2013-08-03 Thread Andreas Schwab
Daniel Convissor  writes:

> Long ago I added a remote to my repo.  It is set to track what was then
> WordPress' main release branch (3.4-branch) and created a local branch
> to use it.  Well, time marches on.  I want to update my remote and
> branch to track the new main release branch (3.6-branch).
>
> Here's how I set things up at the time:
>
> git remote add -t 3.4-branch -f wp https://github.com/WordPress/WordPress
> git checkout -b wp wp/3.4-branch

Use "git remote set-branches" to change the tracked branches of a
remote.  Use "git branch --set-upstream-to" to change the upstream of a
branch (or create a new branch from the new upstream).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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 (Jul 2013, #09; Mon, 29)

2013-08-03 Thread Torsten Bögershausen
On 2013-08-03 08.50, Torsten Bögershausen wrote:
> On 2013-08-01 22.51, Ramsay Jones wrote:
>> Junio C Hamano wrote:
>>> Ramsay Jones  writes:
>>>
>  I am personally in favor of this simpler solution.  Comments?

 I had expected this to me marked for 'master'.

 Has this simply been overlooked, or do you have reservations about
 applying this patch?
>>>
>>> I am just being careful and do want to keep it cooking in 'next'
>>> during the feature freeze.  The more users work with 'next' (not
>>> "work *on* 'next'"), the more confidence we would be with, and
>>> hopefully this can be one of the topis that graduate early after
>>> the 1.8.4 release.
>>
>> Hmm, this patch is a bug-fix for a bug that (currently) will be
>> _introduced_ by v1.8.4.
>>
>> Do you want me to try and find a different bug-fix for v1.8.4?
>> (Although that would most likely be more risky than simply taking
>> this patch! ;-) ).
>>
>> ATB,
>> Ramsay Jones
> 
> I just managed to run v1.8.4-rc1 under cygwin 1.7, and it all passed.
> Good work, thanks.
> 
> I realized that core.filemode is true by default, which
> by default switches of the stat()/lstat() code in cygwin.c
> 
> Which bug fix are we missing for v1.8.4 ?
> /Torsten

Oh, the problem is of course that users have existing repos
where core.filemode = false.

So I think we can and should remove compat/cygwin.[ch] without further
cooking, to be on the save side.

(Just to be sure: this is what we are talking about ?)
/Torsten
 





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