* [PATCH 3/5] verify-pack: add --quick
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <1233313517-24208-3-git-send-email-gitster@pobox.com>
This teaches "git verify-pack" a new option --quick, to trigger the
VERIFY_PACK_QUICK option.
"git fsck" is a more familiar command, and it checks more things at once
than "git verify-pack", and the case you do want to use the latter is when
really want a deep verification of a single pack. For this reason, I do
not think anybody would want to actually use this option, but it was an
easy way to benchmark the change.
For a 32M packfile from the git repository on my AMD64X2:
$ /usr/bin/time ./git-verify-pack $THE_PACKFILE
22.16user 0.18system 0:22.35elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+44166minor)pagefaults 0swaps
$ /usr/bin/time ./git-verify-pack --quick $THE_PACKFILE
0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+11569minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-verify-pack.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index 42ae406..fdc04d1 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -54,12 +54,13 @@ static void show_pack_info(struct packed_git *p)
chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
}
-static int verify_one_pack(const char *path, int verbose)
+static int verify_one_pack(const char *path, int verbose, int quick)
{
char arg[PATH_MAX];
int len;
struct packed_git *pack;
int err;
+ unsigned flag = (quick ? VERIFY_PACK_QUICK : 0);
len = strlcpy(arg, path, PATH_MAX);
if (len >= PATH_MAX)
@@ -93,7 +94,7 @@ static int verify_one_pack(const char *path, int verbose)
return error("packfile %s not found.", arg);
install_packed_git(pack);
- err = verify_pack(pack, 0);
+ err = verify_pack(pack, flag);
if (verbose) {
if (err)
@@ -112,6 +113,7 @@ static const char verify_pack_usage[] = "git-verify-pack [-v] <pack>...";
int cmd_verify_pack(int argc, const char **argv, const char *prefix)
{
int err = 0;
+ int quick = 0;
int verbose = 0;
int no_more_options = 0;
int nothing_done = 1;
@@ -121,13 +123,15 @@ int cmd_verify_pack(int argc, const char **argv, const char *prefix)
if (!no_more_options && argv[1][0] == '-') {
if (!strcmp("-v", argv[1]))
verbose = 1;
+ else if (!strcmp("--quick", argv[1]))
+ quick = 1;
else if (!strcmp("--", argv[1]))
no_more_options = 1;
else
usage(verify_pack_usage);
}
else {
- if (verify_one_pack(argv[1], verbose))
+ if (verify_one_pack(argv[1], verbose, quick))
err = 1;
discard_revindex();
nothing_done = 0;
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* [PATCH 4/5] fsck: three levels of validation
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <1233313517-24208-4-git-send-email-gitster@pobox.com>
Traditionally, "git fsck" only checked loose objects and "git fsck --full"
checked both loose and packed objects fully.
This introduces a new medium level of validation that checks loose objects
and runs the quicker packfile validation introduced earlier (in other
words, the individual objects in packfiles are not validated, but we still
make sure that the packfiles themselves are sound and individual objects
pass their own CRC checks when the pack has version 2 idx file), and makes
this new mode the default. The original "loose objects only" mode can be
asked with --quick option.
In my private git project repository (almost fully packed but with may
dangling objects) on my AMD 64X2:
$ /usr/bin/time ./git-fsck --quick
0.18user 0.02system 0:00.20elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3205minor)pagefaults 0swaps
$ /usr/bin/time ./git-fsck
68.61user 0.43system 1:09.06elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+116707minor)pagefaults 0swaps
$ /usr/bin/time ./git-fsck --full
90.36user 0.61system 1:31.00elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+169641minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-fsck.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 8dc7881..72bf33b 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -20,6 +20,7 @@ static int show_tags;
static int show_unreachable;
static int include_reflogs = 1;
static int check_full;
+static int check_quick;
static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
@@ -576,7 +577,8 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "root", &show_root, "report root nodes"),
OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
- OPT_BOOLEAN(0, "full", &check_full, "also consider alternate objects"),
+ OPT_BOOLEAN(0, "full", &check_full, "fully check packs"),
+ OPT_BOOLEAN(0, "quick", &check_quick, "only check loose objects"),
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
@@ -587,10 +589,14 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
{
int i, heads;
struct alternate_object_database *alt;
+ unsigned verify_pack_flag;
errors_found = 0;
argc = parse_options(argc, argv, fsck_opts, fsck_usage, 0);
+ if (check_full && check_quick)
+ die("--full and --quick? which one do you want?");
+
if (write_lost_and_found) {
check_full = 1;
include_reflogs = 0;
@@ -608,13 +614,14 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
fsck_object_dir(namebuf);
}
- if (check_full) {
+ if (!check_quick) {
struct packed_git *p;
+ verify_pack_flag = check_full ? 0 : VERIFY_PACK_QUICK;
prepare_packed_git();
for (p = packed_git; p; p = p->next)
/* verify gives error messages itself */
- verify_pack(p, 0);
+ verify_pack(p, verify_pack_flag);
for (p = packed_git; p; p = p->next) {
uint32_t j, num;
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* [PATCH 5/5] [squash] fsck: revert --quick to the default and introduce --medium
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <1233313517-24208-5-git-send-email-gitster@pobox.com>
(This commit log message is designed to replace the previous one when
patch text is squashed into the previous one).
Traditionally, "git fsck" only checked loose objects and "git fsck --full"
checked both loose and packed objects fully.
This introduces a new medium level of validation that checks loose objects
and runs the quicker packfile validation introduced earlier (in other
words, the individual objects in packfiles are not validated, but we still
make sure that the packfiles themselves are sound and individual objects
pass their own CRC checks when the pack has version 2 idx file).
I hoped that the new "medium" level to give a cursory look at the pack
data would be acceptable as the default, but given the benchmark data,
I think it is a bit too slow to be the default. So you pass --medium
to trigger this new mode, instead of --full.
In my private git project repository (almost fully packed but with may
dangling objects) on my AMD 64X2:
$ /usr/bin/time ./git-fsck
0.18user 0.02system 0:00.20elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3205minor)pagefaults 0swaps
$ /usr/bin/time ./git-fsck --medium
68.61user 0.43system 1:09.06elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+116707minor)pagefaults 0swaps
$ /usr/bin/time ./git-fsck --full
90.36user 0.61system 1:31.00elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+169641minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-fsck.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 72bf33b..83faa98 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -20,7 +20,7 @@ static int show_tags;
static int show_unreachable;
static int include_reflogs = 1;
static int check_full;
-static int check_quick;
+static int check_medium;
static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
@@ -578,7 +578,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
OPT_BOOLEAN(0, "full", &check_full, "fully check packs"),
- OPT_BOOLEAN(0, "quick", &check_quick, "only check loose objects"),
+ OPT_BOOLEAN(0, "medium", &check_medium, "also check packs"),
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
@@ -594,8 +594,8 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
errors_found = 0;
argc = parse_options(argc, argv, fsck_opts, fsck_usage, 0);
- if (check_full && check_quick)
- die("--full and --quick? which one do you want?");
+ if (check_full && check_medium)
+ die("--full and --medium? which one do you want?");
if (write_lost_and_found) {
check_full = 1;
@@ -614,7 +614,7 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
fsck_object_dir(namebuf);
}
- if (!check_quick) {
+ if (check_full || check_medium) {
struct packed_git *p;
verify_pack_flag = check_full ? 0 : VERIFY_PACK_QUICK;
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* Re: Finding the name of the parent branch?
From: Santi Béjar @ 2009-01-30 11:18 UTC (permalink / raw)
To: Pascal Obry; +Cc: Git Mailing List
In-Reply-To: <a2633edd0901300256k2ad7530elcaca5cdc30c17534@mail.gmail.com>
2009/1/30 Pascal Obry <pascal@obry.net>:
> I want to find the name of the parent branch in a script. What is the best way?
>
> o---o---o---C
> /
> o---o---o---B
> /
> ---o---o---o---o---o---A
>
> For B I want to get A and for C I want to get B.
I think your definition is not well defined. A, B and C are just
branches of you project, technically they are equivalent. Maybe you
are thinking that the common commits of, say A and B, really belongs
to A, but this is not the case they belong to both branches. In git a
branch is really just a pointer to a commit and by extension the
history, it is not a series of commits.
Just a counterexample, just rearranging you graph:
o---B
/
o---o---o---o---o---C
/
---o---o---o---o---o---A
>From you description: For B I would get C and for C I would get A.
HTH,
Santi
^ permalink raw reply
* Git log can not show history before rename
From: Frank Li @ 2009-01-30 11:23 UTC (permalink / raw)
To: git
mkdir tt3
cd tt3
git init-db
touch a.c
git add a.c
git commit -a -m "test1"
git mv a.c b.c
git commit -a -m "rename"
modify b.c
git commit -a -m "test2"
git log -C -M -- b.c
========================================
commit 8d55ed63d2048d41bde8c34dafc52c6a965d61ed
Author: Frank Li <lznuaa@gmail.com>
Date: Fri Jan 30 19:20:10 2009 +0800
test2
commit af0214f7d32cf97fda2743e7d906305e6de2e9a2
Author: Frank Li <lznuaa@gmail.com>
Date: Fri Jan 30 19:19:15 2009 +0800
rename
=========================================
I can't get history before rename.
^ permalink raw reply
* Re: Git log can not show history before rename
From: Santi Béjar @ 2009-01-30 11:29 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901300323n384d3650s3bb5a575accb65d1@mail.gmail.com>
2009/1/30 Frank Li <lznuaa@gmail.com>:
> mkdir tt3
> cd tt3
> git init-db
"git init"
> touch a.c
> git add a.c
> git commit -a -m "test1"
>
> git mv a.c b.c
> git commit -a -m "rename"
>
> modify b.c
> git commit -a -m "test2"
>
> git log -C -M -- b.c
[...]
> I can't get history before rename.
You asked to restrict the search to the b.c path.
You want:
git log --follow -- b.c
Man git-log:
--follow
Continue listing the history of a file beyond renames.
HTH,
Santi
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Raimund Berger @ 2009-01-30 11:37 UTC (permalink / raw)
To: git
In-Reply-To: <871vulda2r.fsf@gigli.quasi.internal>
> The question is whether a (3way) merge is commutative, purely in terms
> of content
Yes / No / Unknown ?
^ permalink raw reply
* Re: [PATCH 5/5] [squash] fsck: revert --quick to the default and introduce --medium
From: Kjetil Barvik @ 2009-01-30 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1233313517-24208-6-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
<snipp>
> diff --git a/builtin-fsck.c b/builtin-fsck.c
> index 72bf33b..83faa98 100644
> --- a/builtin-fsck.c
> +++ b/builtin-fsck.c
> @@ -20,7 +20,7 @@ static int show_tags;
> static int show_unreachable;
> static int include_reflogs = 1;
> static int check_full;
> -static int check_quick;
> +static int check_medium;
> static int check_strict;
> static int keep_cache_objects;
> static unsigned char head_sha1[20];
> @@ -578,7 +578,7 @@ static struct option fsck_opts[] = {
> OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
> OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
> OPT_BOOLEAN(0, "full", &check_full, "fully check packs"),
> - OPT_BOOLEAN(0, "quick", &check_quick, "only check loose objects"),
> + OPT_BOOLEAN(0, "medium", &check_medium, "also check packs"),
> OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
> OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
> "write dangling objects in .git/lost-found"),
> @@ -594,8 +594,8 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
> errors_found = 0;
>
> argc = parse_options(argc, argv, fsck_opts, fsck_usage, 0);
> - if (check_full && check_quick)
> - die("--full and --quick? which one do you want?");
> + if (check_full && check_medium)
> + die("--full and --medium? which one do you want?");
>
Would it not be better to have an "OPT_INT" argument named
"check_level" or similar?
Then you do not need those error checks, and people would maybe
better understand the differences between the different check's?
The documentation could then say that (for example) "level 2
includes all check's that level 1 includes, in addition to ...".
-- kjetil
^ permalink raw reply
* Re: Git log can not show history before rename
From: Jakub Narebski @ 2009-01-30 12:25 UTC (permalink / raw)
To: Santi Béjar; +Cc: Frank Li, git
In-Reply-To: <adf1fd3d0901300329y53e46d91xda75799ce1244ddd@mail.gmail.com>
Santi Béjar <santi@agolina.net> writes:
> 2009/1/30 Frank Li <lznuaa@gmail.com>:
> > mkdir tt3
> > cd tt3
> > git init-db
>
> "git init"
>
> > touch a.c
> > git add a.c
> > git commit -a -m "test1"
> >
> > git mv a.c b.c
> > git commit -a -m "rename"
> >
> > modify b.c
> > git commit -a -m "test2"
> >
> > git log -C -M -- b.c
> [...]
> > I can't get history before rename.
>
> You asked to restrict the search to the b.c path.
>
> You want:
>
> git log --follow -- b.c
>
> Man git-log:
> --follow
> Continue listing the history of a file beyond renames.
Or use
$ git log -C -- b.c a.c
(you don't need '-M' option, as '-C' is superset of it).
Note that '--follow' works for simple histories, but (as it is quite
new invention) doesn't work yet for all cases, like for example
subtree merge or equivalent.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git log can not show history before rename
From: Frank Li @ 2009-01-30 12:29 UTC (permalink / raw)
To: git
In-Reply-To: <adf1fd3d0901300329y53e46d91xda75799ce1244ddd@mail.gmail.com>
Does it conflict with --parents?
When I use --follow and --parents together, parents can't rewrite.
without --follow, parent can rewrite.
2009/1/30 Santi Béjar <santi@agolina.net>:
> 2009/1/30 Frank Li <lznuaa@gmail.com>:
>> mkdir tt3
>> cd tt3
>> git init-db
>
> "git init"
>
>> touch a.c
>> git add a.c
>> git commit -a -m "test1"
>>
>> git mv a.c b.c
>> git commit -a -m "rename"
>>
>> modify b.c
>> git commit -a -m "test2"
>>
>> git log -C -M -- b.c
> [...]
>> I can't get history before rename.
>
> You asked to restrict the search to the b.c path.
>
> You want:
>
> git log --follow -- b.c
>
> Man git-log:
> --follow
> Continue listing the history of a file beyond renames.
>
> HTH,
> Santi
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Jakub Narebski @ 2009-01-30 12:46 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: git
In-Reply-To: <d30068860901281725t14d19c1vc0557182bca3eb8d@mail.gmail.com>
Greg Hauptmann <greg.hauptmann.ruby@gmail.com> writes:
> Do you recommend "git" (over svn) for a 1-person team??? (the
> ability to commit while offline on my laptop sounds potentially
> enough reason)
Beside much easier (I think) sync between desktop and offline laptop?
You don't need to setup Subversion server (even if it is setting up
place for repositories): "git init" is enough (and you can use
filesystem, or bundles, or ssh for sync).
You don't have '.svn' in each directory, but one '.git' at the top
directory of your project (module).
You have (from what I have read) better support for file renames,
better support for binary files, and much easier merging branches
(before Subversion 1.5 you had to use third party tools (SVK or
svnmerge) to not have to do merges "manually", and even now the
support for easy merging is IMHO worse in SVN).
You have all those nifty tools like git-bisect, git-log with --grep
and -S (pickaxe), git-mergetool, git-blame which follows code movement
at request (see e.g. "git gui blame"), git-stash, incremental
comitting, comitting part of changes, etc.
What Subversion has over Git (becuase it is longer) is better tools...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git log can not show history before rename
From: Santi Béjar @ 2009-01-30 12:49 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901300429i6d9b3594m91222314c284d184@mail.gmail.com>
[Please, don't top post, and quote only what you are replying to]
2009/1/30 Frank Li <lznuaa@gmail.com>:
> Does it conflict with --parents?
> When I use --follow and --parents together, parents can't rewrite.
> without --follow, parent can rewrite.
I think there are no obvious reasons to conflict and they could work
together, but as Jakub just said, --follow is quite new and only works
well with simple history and simple cases.
Santi
^ permalink raw reply
* Re: Finding the name of the parent branch?
From: Pascal Obry @ 2009-01-30 12:56 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0901300318s5a0e4c94gab5f31342643ea52@mail.gmail.com>
Santi,
Thanks for you reply.
> I think your definition is not well defined. A, B and C are just
> branches of you project, technically they are equivalent. Maybe you
Right. Yet I want to know from which branch a branch as been started.
You need this to get the proper merge-base for example:
$ git merge-base C A
1
$ git merge-base B C
2
$ git merge-base B A
1
I always know on which topic branch I'm but, as shown above, depending on the
parent branch passed to merge-base you do not get the same branch-point. This
is fine.
So, when I'm in a topic branch I want to find the name of the parent
branch. The one given
when creating the branch:
$ git branch B C
A "stupid" solution whould be to iterate over all branches. Looking
for the merge-base and
at the end output the branch having the youngest merge-base. I'm
looking for something
more efficient...
> are thinking that the common commits of, say A and B, really belongs
> to A, but this is not the case they belong to both branches. In git a
> branch is really just a pointer to a commit and by extension the
> history, it is not a series of commits.
>
> Just a counterexample, just rearranging you graph:
>
> o---B
> /
> o---2---o---o---o---C
> /
> ---o---1---o---o---o---A
>
> From you description: For B I would get C and for C I would get A.
Don't see this as a counter-example as it is exactly my example.
Did I missed something?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* [PATCH] Add a test for checking whether gitattributes is honored by checkout.
From: Kristian Amlie @ 2009-01-30 13:00 UTC (permalink / raw)
To: git; +Cc: Kristian Amlie
In-Reply-To: <1233320413-28069-1-git-send-email-kristian.amlie@trolltech.com>
The original bug will not honor new entries in gitattributes if they
are changed in the same checkout as the files they affect.
---
t/t2012-checkout-crlf.sh | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100755 t/t2012-checkout-crlf.sh
diff --git a/t/t2012-checkout-crlf.sh b/t/t2012-checkout-crlf.sh
new file mode 100755
index 0000000..cb997a8
--- /dev/null
+++ b/t/t2012-checkout-crlf.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='checkout should honor .gitattributes'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ git config core.autocrlf true &&
+ printf "dummy dummy=true\r\n" > .gitattributes &&
+ git add .gitattributes &&
+ git commit -m initial &&
+ printf "file -crlf\n" >> .gitattributes &&
+ printf "contents\n" > file &&
+ git add .gitattributes file &&
+ git commit -m second
+
+'
+
+test_expect_success 'checkout with existing .gitattributes' '
+
+ git checkout master~1 &&
+ git checkout master &&
+ test "$(git diff-files --raw)" = ""
+
+'
+
+test_done
+
--
1.6.0.3
^ permalink raw reply related
* Re: Honoring a checked out gitattributes file
From: Kristian Amlie @ 2009-01-30 13:00 UTC (permalink / raw)
To: git
In-Reply-To: <498094F9.5070201@trolltech.com>
I have now created a test case which demonstrates the problem.
I want to create a patch for it too, but I am unfortunately not so
familiar with the Git source code.
To put it short, I want to make sure that when checking out a tree,
.gitattributes will be checked out before all other files, so that
files that are affected by it will be guaranteed to get the correct
attributes. Maybe someone from this list could point me in the right
direction in the source code for something like this?
--
Kristian Amlie
^ permalink raw reply
* git mergetool from next not working in subdirectory
From: Jonas Flodén @ 2009-01-30 13:05 UTC (permalink / raw)
To: git
Hi,
I just upgraded to the current 'next' version of git
(v1.6.1.2-418-gd79e69c). When I run git mergetool from
a subdirectory in my workspace I get the following output:
(with obfuscated output..)
~/src/rep/subdir $ git mergetool
Merging the files: a/b/file.c
git checkout-index: subdir/subdir/a/b/file.c is not in the cache
git checkout-index: subdir/subdir/a/b/file.c is not in the cache
git checkout-index: subdir/subdir/a/b/file.c is not in the cache
Normal merge conflict for 'a/b/file.c':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (kdiff3):
When I hit enter the merge resolution finishes right away
and the file ends up empty.
Note how subdir is duplicated in the output above.
This works perfectly fine with the 'master' version (1.6.1.2-253-ga34a).
Regards,
Jonas
^ permalink raw reply
* git log --follow --parents can't rewrite history
From: Frank Li @ 2009-01-30 13:16 UTC (permalink / raw)
To: git
use git.git repository.
git log --pretty=format:Commit:%H%nParent:%P%n%n --parents -- alloc.c
Commit:100c5f3b0b27ec6617de1a785c4ff481e92636c1
Parent:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3
Commit:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3
Parent:579d1fbfaf25550254014fa472faac95f88eb779
Commit:579d1fbfaf25550254014fa472faac95f88eb779
Parent:855419f764a65e92f1d5dd1b3d50ee987db1d9de
Commit:855419f764a65e92f1d5dd1b3d50ee987db1d9de
Parent:
Parent will be rewritten correctly.
But When I add --follow, it will be
git log --pretty=format:Commit:%H%nParent:%P%n%n --parents --follow -- alloc.c
Commit:100c5f3b0b27ec6617de1a785c4ff481e92636c1
Parent:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3
Commit:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3
Parent:f948792990f82a35bf0c98510e7511ef8acb9cd3
Commit:579d1fbfaf25550254014fa472faac95f88eb779
Parent:446c6faec69f7ac521b8b9fc2b1874731729032f
Commit:855419f764a65e92f1d5dd1b3d50ee987db1d9de
Parent:64e86c57867593ba0ee77a7b0ff0eb8e9d4d8ed5
parent will be not rewritten.
^ permalink raw reply
* Re: Finding the name of the parent branch?
From: Santi Béjar @ 2009-01-30 13:16 UTC (permalink / raw)
To: Pascal Obry; +Cc: Git Mailing List
In-Reply-To: <a2633edd0901300456y48e8d78fn199675f2ae105c8@mail.gmail.com>
2009/1/30 Pascal Obry <pascal@obry.net>:
> Santi,
>
> Thanks for you reply.
>
>> I think your definition is not well defined. A, B and C are just
>> branches of you project, technically they are equivalent. Maybe you
>
> Right. Yet I want to know from which branch a branch as been started.
You can set it when you create the branch:
git branch --track newbranch startpointbranch
(maybe --track is the default these days for remote branches)
And then the config keys:
branch.newbranch.remote
branch.newbranch.merge
will tell you from which branch a branch was started. And it is used
in "git pull" to merge from the tracking branch.
> You need this to get the proper merge-base for example:
>
> $ git merge-base C A
> 1
>
> $ git merge-base B C
> 2
>
> $ git merge-base B A
> 1
1 and 2 are defined in the graph below...
> I always know on which topic branch I'm but, as shown above, depending on the
> parent branch passed to merge-base you do not get the same branch-point. This
> is fine.
>
> So, when I'm in a topic branch I want to find the name of the parent
> branch. The one given
> when creating the branch:
>
> $ git branch B C
See above.
>
> A "stupid" solution whould be to iterate over all branches. Looking
> for the merge-base and
> at the end output the branch having the youngest merge-base. I'm
> looking for something
> more efficient...
>
Maybe if you explain why you want it (a use case) instead of just this
specific problem...
>> are thinking that the common commits of, say A and B, really belongs
>> to A, but this is not the case they belong to both branches. In git a
>> branch is really just a pointer to a commit and by extension the
>> history, it is not a series of commits.
>>
>> Just a counterexample, just rearranging you graph:
>>
>> o---B
>> /
>> o---2---o---o---o---C
>> /
>> ---o---1---o---o---o---A
>>
>> From you description: For B I would get C and for C I would get A.
Please, if you quote text do not edit it (the 1 and the 2 in this case).
> Don't see this as a counter-example as it is exactly my example.
>
> Did I missed something?
Yes. Compare your sentence and mine:
For B I want to get A and for C I want to get B.
For B I would get C and for C I would get A.
So for B you get A while I get C, and the equivalent for C.
Santi
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Johannes Schindelin @ 2009-01-30 13:18 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Pieter de Bie, Junio C Hamano, git
In-Reply-To: <20090130045131.GB18655@coredump.intra.peff.net>
Hi,
On Thu, 29 Jan 2009, Jeff King wrote:
> On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:
>
> > > It wouldn't help the case of "somebody
> > > else pushed some content that you want to pull", but like you said, I
> > > think the primary workflow is that you immediately push after cloning
> > > the empty repo.
> >
> > Also, the only way to support the "somebody else pushed already"
> > workflow would be to assume the user wants to name the branch
> > 'master', which might not be the case at all.
>
> You could make a guess that they will use "master", and if you are
> wrong, it behaves as now. But if you are right, "git pull" pulls down
> master automatically.
>
> But that is getting a little confusing. So let's push this "git push
> --track" idea to completion and see how people like it.
How about installing
[branch "master"]
remote = origin
merge = refs/heads/master
by default? It is a safe bet that this will be the case for 99% of all
users that want to clone an empty repository (especially if they are
putting their public repositories on something like repo.or.cz, where you
cannot change the default branch from "master" to something else).
And if somebody wants to track another branch, tough, she has to call
this:
$ git checkout -t origin/blablabla
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-01-30 13:23 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git, gitster
In-Reply-To: <20090130073415.GA27224@coredump.intra.peff.net>
Hi,
On Fri, 30 Jan 2009, Jeff King wrote:
> On Fri, Jan 30, 2009 at 08:17:48AM +0100, Johannes Sixt wrote:
>
> > Johannes Schindelin schrieb:
> > > + error("refusing to update checked out branch: %s\n"
> > > + "if you know what you are doing, you can allow it by "
> > > + "setting\n\n"
> > > + "\tgit config receive.denyCurrentBranch true\n", name);
> >
> > Oh, fscking hell, I should have screamed out loudly when Jeff named this
> > option "denyCurrentBranch" instead of "allowCurrentBranch". It's all too
> > easy to fall into the trap, like you here.
>
> Sorry. ;P
>
> On the other hand, you also missed the boat on receive.denyDeletes and
> receive.denyNonFastForwards.
The idea with these is that they are _booleans_, and therefore
[receive]
denyDeletes
is something natural to write, because "denyDeletes" is _not_ the default.
However, with denyCurrentBranch we wanted to change the default in the
long run, so I agree it was a not-so-brilliant choice.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-01-30 13:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwscdbkpd.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 29 Jan 2009, Junio C Hamano wrote:
> @@ -239,9 +239,12 @@ static const char *update(struct command *cmd)
> " that are now in HEAD.");
> break;
> case DENY_REFUSE:
> - if (!is_ref_checked_out(name))
> + if (is_bare_repository() || !is_ref_checked_out(name))
> break;
> - error("refusing to update checked out branch: %s", name);
> + error("refusing to update checked out branch: %s\n"
> + "if you know what you are doing, you can allow it by "
> + "setting\n\n"
> + "\tgit config receive.denyCurrentBranch true\n", name);
> return "branch is currently checked out";
> }
>
> As the message I am currently getting from such a push is:
>
> $ git push ../victim-010 next:master
> Total 0 (delta 0), reused 0 (delta 0)
> warning: updating the currently checked out branch; this may cause confusion,
> as the index and working tree do not reflect changes that are now in HEAD.
> To ../victim-010
> a34a9db..d79e69c next -> master
>
> which is much better than what you did. It at least tries to explain why
> it is warning, even though I think it has a huge room for improvement.
I do not really care about the output. You are probably right, it should
be different from what I proposed.
> You alluded that we wanted to make grace period much longer, but you
> want to cut it short. I think it is a huge mistake. The warning has
> only been there for the last two months, and only can be seen from
> v1.6.1-rc1 or newer software. These new people even haven't a chance to
> learn from the existing warning.
In reality, people will not learn from the warning. Those that are
old-timers (and who should be warned in the first place, instead of
refuses) will just happily ignore that there was a warning: the command
they used so often and the worked all the time just happened to work --
again -- no matter what the output is.
But we are really hurting new users, and let's face it, the balance of
time cost currently is in a huge favor of the old-timers there.
Not only are there many more newbies these days than old timers.
No, the _time_ spent by an old-timer to read an appropriate message and
fix the setup would be _substantially_ shorter than the _hours_ of
frustration a newbie spends on the issue.
And we claim to make decentralized repositories easy.
> I think what would work much better would be a patch that keeps the
> warn-but-allow as the default, but clarifies the warning message.
As I said, I am _convinced_ that a warning will do nothing at all. Just
like the warning about the dashed commands, nobody who should be concerned
will notice it.
> (1) what symptoms, that are easily observable by the most novice users,
> are caused by "index and work tree going out of sync" the warning
> talks about, and why that would not be what they want;
>
> (2) if the user did not mean to do it (and the user can tell by observing
> the symptom described in the previous point), describe what needs to
> be done to recover from the fallout this push has caused (we do not
> need a recipe; pointing at a URL or manpage is fine), and what switch
> to flip to prevent herself from doing it again in the future;
>
> (3) if the user did mean it, and finds the above two big warning
> annoying, what switch to flip to squelch the warning for future
> pushes.
>
> The goal of the warning should be to *force* people *choose*, either to
> silently-allow (aka DENY_IGNORE) or refuse (DENY_REFUSE), and give enough
> information for them to make an informed decision. We can afford to be
> annoyingly long, loud and verbose there.
>
> On the other hand, you cannot make the message for DENY_REFUSE annoyingly
> long, as people may have already chosen to say "please refuse my push into
> a live branch".
>
> If you are making "refuse" the default, an annoyingly long message is even
> worse. "Yeah, thanks for stopping me, but you do not have to remind me
> every time that I made a mistake in large red letters. I perfectly well
> know what I am doing, I perfectly well know that I did not want to push
> into that branch, I just made a mistake---you do not have to be so loud".
>
> I suspect that you cannot even be long enough to be informative, not to
> annoy people.
Let's reap all the opinions about this issue, and then I'll do the wrap-up
patch.
But this is a serious issue that seriously needs to be coped with. We are
getting another generation of "Git is difficult" users that way.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-01-30 13:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, gitster
In-Reply-To: <20090130023040.GR21473@genesis.frugalware.org>
Hi,
On Fri, 30 Jan 2009, Miklos Vajna wrote:
> On Fri, Jan 30, 2009 at 01:34:28AM +0100, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
> > - error("refusing to update checked out branch: %s", name);
> > + error("refusing to update checked out branch: %s\n"
> > + "if you know what you are doing, you can allow it by "
> > + "setting\n\n"
> > + "\tgit config receive.denyCurrentBranch true\n", name);
>
> Shouldn't this be
>
> git config receive.denyCurrentBranch ignore
>
> instead of "true"?
Right.
However, as Junio pointed out, we do not want to give this resolution in
the error message. I am now leaning more to something like
refusing to update checked out branch '%s' in non-bare repository
Hmm?
Old-timers will know "oh, what the hell, I did not mark my repository as
bare!", and new-timers will no longer be confused.
Ciao,
Dscho
^ permalink raw reply
* Re: Finding the name of the parent branch?
From: Michael J Gruber @ 2009-01-30 13:35 UTC (permalink / raw)
To: Pascal Obry; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <a2633edd0901300456y48e8d78fn199675f2ae105c8@mail.gmail.com>
Pascal Obry venit, vidit, dixit 30.01.2009 13:56:
> Santi,
>
> Thanks for you reply.
>
>> I think your definition is not well defined. A, B and C are just
>> branches of you project, technically they are equivalent. Maybe you
>
> Right. Yet I want to know from which branch a branch as been started.
>
> You need this to get the proper merge-base for example:
>
> $ git merge-base C A
> 1
>
> $ git merge-base B C
> 2
>
> $ git merge-base B A
> 1
>
> I always know on which topic branch I'm but, as shown above, depending on the
> parent branch passed to merge-base you do not get the same branch-point. This
> is fine.
>
> So, when I'm in a topic branch I want to find the name of the parent
> branch. The one given
> when creating the branch:
>
> $ git branch B C
>
> A "stupid" solution whould be to iterate over all branches. Looking
> for the merge-base and
> at the end output the branch having the youngest merge-base. I'm
> looking for something
> more efficient...
>
>> are thinking that the common commits of, say A and B, really belongs
>> to A, but this is not the case they belong to both branches. In git a
>> branch is really just a pointer to a commit and by extension the
>> history, it is not a series of commits.
>>
>> Just a counterexample, just rearranging you graph:
>>
>> o---B
>> /
>> o---2---o---o---o---C
>> /
>> ---o---1---o---o---o---A
>>
>> From you description: For B I would get C and for C I would get A.
>
> Don't see this as a counter-example as it is exactly my example.
>
> Did I missed something?
I think you still haven't *defined* what you mean by "parent branch".
Your example alone doesn't define it, and whenever you have merge
commits things are not clear:
o---o---o---A
/ \
---o o---o---C
\ /
o---o---o---B
Now, which one is the "parent branch" of C? A+B? Similarly:
o---A
/
---o---C
\
o---B
Here it's clear which commit you want, but which branch does it belong
to? A or B?
I really think this is impossible to define unambiguously in git, due to
the nature of git branches, being movable tags, much different from say
hg's hardwired branches (embedded in the commit object).
What you see in gitk is which branch contains a certain commit ("git
branch --contains").
What you want may be the branch which differs from C by the least number
of commits.
Cheers,
Michael
^ permalink raw reply
* Re: gitk run from subdir and "find commit touching paths"
From: Sitaram Chamarty @ 2009-01-30 13:39 UTC (permalink / raw)
To: git
In-Reply-To: <1c5969370901292156k2456b585r8e79889db516bc59@mail.gmail.com>
On 2009-01-30, Matt Graham <mdg149@gmail.com> wrote:
> On Tue, Jan 27, 2009 at 12:14, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> I get this too. My repos are small enough that I'm usually able to
> just cd to the root dir and rerun gitk.
Mine are too; and if they weren't I'd alias it in bash, no
sweat. It was just a question to see if it was a known
problem, and really all I wanted was to confirm what I am
seeing.
I'm not even saying it needs to be fixed :-)
^ permalink raw reply
* Re: Finding the name of the parent branch?
From: Pascal Obry @ 2009-01-30 13:35 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0901300516y3d1bf58dmda9c5172586d828@mail.gmail.com>
Santi,
> Maybe if you explain why you want it (a use case) instead of just this
> specific problem...
To know the proper merge base to display all commits done on a specific
topic branch.
>>> Just a counterexample, just rearranging you graph:
>>>
>>> o---B
>>> /
>>> o---2---o---o---o---C
>>> /
>>> ---o---1---o---o---o---A
>>>
>>> From you description: For B I would get C and for C I would get A.
>
> Please, if you quote text do not edit it (the 1 and the 2 in this case).
Well I've just added 1 and 2, nothing changed in the semantic!
> Yes. Compare your sentence and mine:
>
> For B I want to get A and for C I want to get B.
> For B I would get C and for C I would get A.
>
> So for B you get A while I get C, and the equivalent for C.
Ok, that's expected since you have renamed B to C and C to B.
My tree was:
o---o---o---C
/
o---o---o---B
/
---o---o---o---o---o---A
Your's was:
o---B
/
o---o---o---o---o---C
/
---o---o---o---o---o---A
So when I said:
For B I want to get A and for C I want to get B.
It is equivalent to your (just rename B and C).:
For B I would get C and for C I would get A.
Frankly I do not see your point... That's maybe the cause of the
problem I'm having....
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox