* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Andreas Ericsson @ 2008-06-26 5:31 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <48620C1A.6000509@panasas.com>
Boaz Harrosh wrote:
> Junio C Hamano wrote:
>> Steven Walter <stevenrwalter@gmail.com> writes:
>>
>>> @@ -225,6 +243,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>>> if (reset_type == HARD && is_bare_repository())
>>> die("hard reset makes no sense in a bare repository");
>>>
>>> + if (reset_type == HARD && !force && index_is_dirty()) {
>>> + die("Uncommitted changes; re-run with -f to trash them");
>>> + }
>>> +
>> Please don't. With your change, does the testsuite even pass?
>>
>> "reset --hard" has *ALWAYS* meant to be destructive --- discarding
>> potential local cruft is the whole point of the operation.
>>
>
> I was under the impression that --hard means working-directory-also
> as opposed to tree-and-index-only. Nothing to do with
> destructive-discarding. If it is then something is missing.
> I need 2 distinct functions. You combine to functions under
> one command.
>
>> Learn the lingo, and get over it.
>>
>
> I did lern the lingo and got bitten. I wanted to do one thing
> also got the other one.
>
> there is:
> git-reset --clean - destructive-discarding any local changes
> git-reset --hard - move tree index and working directory to new head
>
> How can I separate between them, Please
>
There is a "--hard" after one of them. It reads like this:
git reset --hard ;# move current branch to random point in history
# discarding working tree and index state
git reset --mixed ;# move current branch to random point in history
# discard the index but keep the working tree
git reset --soft ;# move current branch to random point in history,
# leaving index and working tree intact
It's under OPTIONS in the man-page. --mixed is default.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Jeff King @ 2008-06-26 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lea Wiemann, Git Mailing List
In-Reply-To: <20080625161433.GA6612@sigill.intra.peff.net>
On Wed, Jun 25, 2008 at 12:14:33PM -0400, Jeff King wrote:
> Hmm. Actually, there is a test in t6300 that runs with each atom name.
> Unfortunately, it doesn't bother actually checking the output for
> sanity, so the fact that these atoms returned the empty string was
> missed.
And here is a two patch series cleaning up the test script and fixing
the bug.
-Peff
^ permalink raw reply
* [PATCH 1/2] improve for-each-ref test script
From: Jeff King @ 2008-06-26 5:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lea Wiemann, git
In-Reply-To: <20080626053551.GA20767@sigill.intra.peff.net>
Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom. This patch checks
the output, and in doing so reveals breakage on a few atoms.
While we're at it, also clean up a few '!' into
test_must_fail.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t6300-for-each-ref.sh | 87 +++++++++++++++++++++++++++++++++++++---------
1 files changed, 70 insertions(+), 17 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 91ea85d..415e1d1 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -26,25 +26,78 @@ test_expect_success 'Create sample commit with known timestamp' '
git tag -a -m "Tagging at $datestamp" testtag
'
-test_expect_success 'Check atom names are valid' '
- bad=
- for token in \
- refname objecttype objectsize objectname tree parent \
- numparent object type author authorname authoremail \
- authordate committer committername committeremail \
- committerdate tag tagger taggername taggeremail \
- taggerdate creator creatordate subject body contents
- do
- git for-each-ref --format="$token=%($token)" refs/heads || {
- bad=$token
- break
- }
- done
- test -z "$bad"
+test_atom() {
+ case "$1" in
+ head) ref=refs/heads/master ;;
+ tag) ref=refs/tags/testtag ;;
+ esac
+ printf '%s\n' "$3" >expected
+ test_expect_${4:-success} "basic atom: $1 $2" "
+ git for-each-ref --format='%($2)' $ref >actual &&
+ test_cmp expected actual
+ "
+}
+
+test_atom head refname refs/heads/master
+test_atom head objecttype commit
+test_atom head objectsize 171
+test_atom head objectname 67a36f10722846e891fbada1ba48ed035de75581
+test_atom head tree 0e51c00fcb93dffc755546f27593d511e1bdb46f
+test_atom head parent ''
+test_atom head numparent 0
+test_atom head object ''
+test_atom head type ''
+test_atom head author 'A U Thor <author@example.com> 1151939924 +0200'
+test_atom head authorname 'A U Thor'
+test_atom head authoremail '<author@example.com>'
+test_atom head authordate 'Mon Jul 3 17:18:44 2006 +0200'
+test_atom head committer 'C O Mitter <committer@example.com> 1151939923 +0200'
+test_atom head committername 'C O Mitter'
+test_atom head committeremail '<committer@example.com>'
+test_atom head committerdate 'Mon Jul 3 17:18:43 2006 +0200'
+test_atom head tag ''
+test_atom head tagger ''
+test_atom head taggername ''
+test_atom head taggeremail ''
+test_atom head taggerdate ''
+test_atom head creator 'C O Mitter <committer@example.com> 1151939923 +0200'
+test_atom head creatordate 'Mon Jul 3 17:18:43 2006 +0200'
+test_atom head subject 'Initial'
+test_atom head body ''
+test_atom head contents 'Initial
+'
+
+test_atom tag refname refs/tags/testtag
+test_atom tag objecttype tag
+test_atom tag objectsize 154
+test_atom tag objectname 98b46b1d36e5b07909de1b3886224e3e81e87322
+test_atom tag tree ''
+test_atom tag parent ''
+test_atom tag numparent ''
+test_atom tag object '67a36f10722846e891fbada1ba48ed035de75581' failure
+test_atom tag type 'commit' failure
+test_atom tag author ''
+test_atom tag authorname ''
+test_atom tag authoremail ''
+test_atom tag authordate ''
+test_atom tag committer ''
+test_atom tag committername ''
+test_atom tag committeremail ''
+test_atom tag committerdate ''
+test_atom tag tag 'testtag'
+test_atom tag tagger 'C O Mitter <committer@example.com> 1151939925 +0200'
+test_atom tag taggername 'C O Mitter'
+test_atom tag taggeremail '<committer@example.com>'
+test_atom tag taggerdate 'Mon Jul 3 17:18:45 2006 +0200'
+test_atom tag creator 'C O Mitter <committer@example.com> 1151939925 +0200'
+test_atom tag creatordate 'Mon Jul 3 17:18:45 2006 +0200'
+test_atom tag subject 'Tagging at 1151939927'
+test_atom tag body ''
+test_atom tag contents 'Tagging at 1151939927
'
test_expect_success 'Check invalid atoms names are errors' '
- ! git-for-each-ref --format="%(INVALID)" refs/heads
+ test_must_fail git-for-each-ref --format="%(INVALID)" refs/heads
'
test_expect_success 'Check format specifiers are ignored in naming date atoms' '
@@ -64,7 +117,7 @@ test_expect_success 'Check valid format specifiers for date fields' '
'
test_expect_success 'Check invalid format specifiers are errors' '
- ! git-for-each-ref --format="%(authordate:INVALID)" refs/heads
+ test_must_fail git-for-each-ref --format="%(authordate:INVALID)" refs/heads
'
cat >expected <<\EOF
--
1.5.6
^ permalink raw reply related
* [PATCH 2/2] for-each-ref: implement missing tag values
From: Jeff King @ 2008-06-26 5:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lea Wiemann, git
In-Reply-To: <20080626053551.GA20767@sigill.intra.peff.net>
The "type" and "object" fields for tags were accepted as
valid atoms, but never implemented. Consequently, they
simply returned the empty string, even for valid tags.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-for-each-ref.c | 7 +++++++
t/t6300-for-each-ref.sh | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 07d9c57..fef93d7 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -234,6 +234,13 @@ static void grab_tag_values(struct atom_value *val, int deref, struct object *ob
name++;
if (!strcmp(name, "tag"))
v->s = tag->tag;
+ else if (!strcmp(name, "type") && tag->tagged)
+ v->s = typename(tag->tagged->type);
+ else if (!strcmp(name, "object") && tag->tagged) {
+ char *s = xmalloc(41);
+ strcpy(s, sha1_to_hex(tag->tagged->sha1));
+ v->s = s;
+ }
}
}
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 415e1d1..a3c8941 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -74,8 +74,8 @@ test_atom tag objectname 98b46b1d36e5b07909de1b3886224e3e81e87322
test_atom tag tree ''
test_atom tag parent ''
test_atom tag numparent ''
-test_atom tag object '67a36f10722846e891fbada1ba48ed035de75581' failure
-test_atom tag type 'commit' failure
+test_atom tag object '67a36f10722846e891fbada1ba48ed035de75581'
+test_atom tag type 'commit'
test_atom tag author ''
test_atom tag authorname ''
test_atom tag authoremail ''
--
1.5.6
^ permalink raw reply related
* [Bug?] git submodule add doesn't respect core.autocrlf
From: Edward Z. Yang @ 2008-06-26 5:43 UTC (permalink / raw)
To: git
It doesn't appear that git-submodule add respects crlf, as evidenced by
this set of commands on Windows:
mkdir test
cd test
git init
git config core.safecrlf true
git config core.autocrlf true
git submodule add http://repo.or.cz/w/htmlpurifier.git htmlpurifier
You get: "fatal: LF would be replaced by CRLF in .gitmodules" and
inspecting .gitmodules reveals that it uses LF, instead of CRLF.
Can anyone reproduce? Thanks.
^ permalink raw reply
* Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Christian Couder @ 2008-06-26 6:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git
In-Reply-To: <7v8wwubh3j.fsf@gitster.siamese.dyndns.org>
Le mercredi 25 juin 2008, Junio C Hamano a écrit :
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Tue, 24 Jun 2008, Michael Haggerty wrote:
> > ...
> >
> >> It seems to me that your problem is that git-bisect requires the
> >> "good" revision to be older than the "bad" one.
Yes, "git bisect" works if the good revisions are ancestors of the bad
revision.
Currently if you mistake good and bad revs (and if one of the rev is
an ancestor of the other) you get something like:
$ git bisect start HEAD~3 HEAD
'git rev-list --bisect-vars' failed:
maybe you mistake good and bad revs?
I also noticed that if the good and bad are siblings for example like:
A-B-C-D
\E-F
and you say:
$ git bisect start D F
(that means D is bad and F is good)
then it will kind of "work" but only C and D will be considered as possible
first bad commits. This is arguably a bug because for example E could have
fixed a bug that always existed, and then the first bad commit is B or A
depending how we define it.
> >> If this requirement
> >> were removed, would there still be a need for "fixed" vs. "unfixed"?
Well this requirement can be "removed" in different ways.
1) We could just allow anything to be called "bad" and "good" as long as
there is either:
- only one bad revision and all good revisions are its ancestor, or
- only one good revision and all bad revisions are its ancestor
2) Another way to remove the requirement is to make it work in the siblings
case above.
> > Nope.
> >
> > The thing that makes "fixed" and "bad" special is that _one_ commit
> > introduced that.
>
> That was my initial reaction, and I actually was about to phrase it more
> bluntly: you do not understand what "bisect" is.
>
> But that was a reaction without thinking things through. It may not be
> what "git bisect" currently is, but the suggestion does not go against
> what the underlying "git rev-list --bisect" is at all.
If we want to make the siblings case (case 2) work, then "git
rev-list --bisect" needs work though.
> I think what
> Michael is speculating is different, and it makes sense in its own way.
>
> Instead of having a set of bisect/good-* refs and a single bisect-bad
> ref, your "fixed and unfixed" mode could work quite differently. By
> noticing that the topology the user specified with initial good and bad
> have ancient bad and recent good --- that is, "it used to be bad but now
> it is good" --- you could instead use a set of bisect/bad-* refs and a
> single bisect-good ref, and feed good and bad swapped to "rev-list
> --bisect" in bisect_next(). That way, the labels given by visualize will
> match what the user is doing automatically.
Yes, that is the case 1 above.
> I said "it makes sense in its own way", because it is _quite_ different
> from how git-bisect currently assumes, and restructuring git-bisect to
> operate naturally in a way Michael describes would be a much larger
> surgery with costs (including risks of bugs) associated with it, which
> needs to be weighed in when judging that approach would actually make
> sense.
Yes it needs work in git-bisect.sh and I don't think the current situation
with the "maybe you mistake good and bad revs?" error message is too bad.
Regards,
Christian.
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Matthieu Moy @ 2008-06-26 6:04 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <g3v3s1$bok$1@ger.gmane.org>
Dan McGee <dpmcgee@gmail.com> writes:
> That became impossible with 1.5.6 out of the box,
Actually, by default it does. It does not for you because you've set
$LESS. That said, I argee that a config option to enable/disable the
pager per-command would have been better that the change we're talking
about.
--
Matthieu
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-26 6:08 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git
In-Reply-To: <20080626052310.GC8610@mit.edu>
-- Theodore Tso wrote:
> If you are going to preserve the workflow of CVS, then you're
> also going to preserve all of the downsides of CVS.
I don't agree with this, and I don't see you proposing any logic that proves it
to be true. Of course I plan to make small changes. However, in my previous
message I proposed 3 same-workflow improvements, and 2 small-workflow-extension
improvements. I have more in mind..
http://marc.info/?l=git&m=121442660332114&w=2
Maybe it was too confusing or too long to read. Just consider the first simple
example.
Currently "cvs up" in a dirty tree is a destructive operation. If you merge
badly, you can't get back to your local working files before the "up". I've
been burned by this in cvs/perforce enough that now when there are complicated
update-conflicts I tar up the tree before trying to fix them. I still can't
really get back to the pre-up state.
I can be better than cvs with the EXACT same workflow, by checking in their
local changes (git checkin;) and then doing the "up" (git pull;). If they
decide they botched their merge, they can get back to where they were before
the UP because I'm using a richer underlying mechanism to implement their
workflow.
Do you think that's not an improvement? or not the same workflow? It sure seems
like a same-workflow improvement to me.
----
git's mechanisms are really great for making a hybrid central/distributed
system which has the simplicity of cvs/perforce and several of the benefits of
git. The git interface is just too complicated to be used for this.
Fortunately, building on git means that power users will still be able to use
git directly and people can distribute the repositories as much as they want.
> how much change are you willing to make them deviate from
> the CVS workflow, and how much smarts are you willing to assume that
> they have?
Good question. I'm working on a command-line wrapper for git that does it.
Digging into the "plumbling" is making it more obvious why I find git's
porcelain operations hard to understand. I think I can make a 2-repository
setup (personal-inaccessible, origin) work like cvs/perforce with local
checkins, and I can make a 3-repository setup (personal-inaccessible,
personal-accessible, origin) work nearly the same as cvs while allowing
distributed collaboration. I think I will need a tiny bit of custom server
support (to create the personal-accessible repositories automatically).
Right now it looks like I'll be a simple hybrid of cvs/perforce, with a couple
git concepts peppered in. (but just a couple) It seems simple so far, it's just
taking me a while to dig through git-plumbing to understand it.
Also remember, this isn't built to handle what linux-kernel folks do with git.
It's designed to provide a familiar environment for cvs/perforce style users
that is just as simple but a whole lot better. Even if it eventually gets lots
of git concepts, they won't HAVE to understand them to use it. They can learn
them as they go. This is obviously something that people want, as cogito and
easy-git show.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-26 6:08 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git
In-Reply-To: <20080626052310.GC8610@mit.edu>
-- Theodore Tso wrote:
> If you are going to preserve the workflow of CVS, then you're
> also going to preserve all of the downsides of CVS.
I don't agree with this, and I don't see you proposing any logic that proves it
to be true. Of course I plan to make small changes. However, in my previous
message I proposed 3 same-workflow improvements, and 2 small-workflow-extension
improvements. I have more in mind..
http://marc.info/?l=git&m=121442660332114&w=2
Maybe it was too confusing or too long to read. Just consider the first simple
example.
Currently "cvs up" in a dirty tree is a destructive operation. If you merge
badly, you can't get back to your local working files before the "up". I've
been burned by this in cvs/perforce enough that now when there are complicated
update-conflicts I tar up the tree before trying to fix them. I still can't
really get back to the pre-up state.
I can be better than cvs with the EXACT same workflow, by checking in their
local changes (git checkin;) and then doing the "up" (git pull;). If they
decide they botched their merge, they can get back to where they were before
the UP because I'm using a richer underlying mechanism to implement their
workflow.
Do you think that's not an improvement? or not the same workflow? It sure seems
like a same-workflow improvement to me.
----
git's mechanisms are really great for making a hybrid central/distributed
system which has the simplicity of cvs/perforce and several of the benefits of
git. The git interface is just too complicated to be used for this.
Fortunately, building on git means that power users will still be able to use
git directly and people can distribute the repositories as much as they want.
> how much change are you willing to make them deviate from
> the CVS workflow, and how much smarts are you willing to assume that
> they have?
Good question. I'm working on a command-line wrapper for git that does it.
Digging into the "plumbling" is making it more obvious why I find git's
porcelain operations hard to understand. I think I can make a 2-repository
setup (personal-inaccessible, origin) work like cvs/perforce with local
checkins, and I can make a 3-repository setup (personal-inaccessible,
personal-accessible, origin) work nearly the same as cvs while allowing
distributed collaboration. I think I will need a tiny bit of custom server
support (to create the personal-accessible repositories automatically).
Right now it looks like I'll be a simple hybrid of cvs/perforce, with a couple
git concepts peppered in. (but just a couple) It seems simple so far, it's just
taking me a while to dig through git-plumbing to understand it.
Also remember, this isn't built to handle what linux-kernel folks do with git.
It's designed to provide a familiar environment for cvs/perforce style users
that is just as simple but a whole lot better. Even if it eventually gets lots
of git concepts, they won't HAVE to understand them to use it. They can learn
them as they go. This is obviously something that people want, as cogito and
easy-git show.
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.6.1
From: Junio C Hamano @ 2008-06-26 6:21 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vmylixr6h.fsf@gitster.siamese.dyndns.org>
The latest maintenance release GIT 1.5.6.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.6.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.6.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.6.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.6.1-1.$arch.rpm (RPM)
GIT v1.5.6.1 Release Notes
==========================
Fixes since v1.5.6
------------------
* Last minute change broke loose object creation on AIX.
* (performance fix) We used to make $GIT_DIR absolute path early in the
programs but keeping it relative to the current directory internally
gives 1-3 per-cent performance boost.
* bash completion knows the new --graph option to git-log family.
* git-diff -c/--cc showed unnecessary "deletion" lines at the context
boundary.
* git-for-each-ref ignored %(object) and %(type) requests for tag
objects.
* git-merge usage had a typo.
* Rebuilding of git-svn metainfo database did not take rewriteRoot
option into account.
* Running "git-rebase --continue/--skip/--abort" before starting a
rebase gave nonsense error messages.
----------------------------------------------------------------
Changes since v1.5.6 are as follows:
Brandon Casey (2):
git-merge.sh: fix typo in usage message: sucesses --> succeeds
t7502-commit.sh: test_must_fail doesn't work with inline environment variables
Dan McGee (1):
completion: add --graph to log command completion
Dmitry Potapov (1):
fix update-hook-example to work with packed tag references
Jan Krüger (2):
Documentation: fix formatting in git-svn
git-svn: make rebuild respect rewriteRoot option
Jeff King (2):
for-each-ref: implement missing tag values
clone: create intermediate directories of destination repo
Junio C Hamano (2):
diff -c/--cc: do not include uninteresting deletion before leading context
GIT 1.5.6.1
Linus Torvalds (1):
Make git_dir a path relative to work_tree in setup_work_tree()
Michele Ballabio (1):
parse-options.c: fix documentation syntax of optional arguments
Patrick Higgins (1):
Workaround for AIX mkstemp()
Stephan Beyer (4):
git-rebase.sh: Add check if rebase is in progress
api-builtin.txt: update and fix typo
api-parse-options.txt: Introduce documentation for parse options API
Extend parse-options test suite
^ permalink raw reply
* Re: Windows symlinks
From: Andreas Ericsson @ 2008-06-26 6:33 UTC (permalink / raw)
To: Patrick.Higgins; +Cc: apenwarr, jnareb, git
In-Reply-To: <911589C97062424796D53B625CEC0025E46196@USCOBRMFA-SE-70.northamerica.cexp.com>
Patrick.Higgins@cexp.com wrote:
>> From: Avery Pennarun [mailto:apenwarr@gmail.com]
>>
>>> Agreed. The first thing we started working on was getting
>> symlinks out of our repositories.
>>> Unfortunately, we chose to use them because we are using
>> broken development tools that
>>> don't support proper modularity. We found the best way to
>> Perhaps git-submodule would do what you're looking for.
>
> We might be able to get by with them, but submodules appear to be
> significantly more complex than symlinks, and we sometimes symlink
> just a file or two if that's all we need. Splitting up submodules to
> that level of granularity would be hard to manage.
>
> My understanding of the submodule workflow is:
>
> Projects A, B, and C (we actually have about 17 of these) all share
> common code in project Common. Then, each of A, B, and C adds Common
> as a submodule. While working on project A, the need arises to modify
> Common, so the developer changes it there, commits, pushes the change
> to Common, then commits and pushes the change to A. To update B and
> C, they would have to change to each of those projects, run a git
> pull, then git submodule update, and compile and test.
>
> Is that correct? If so, it's a lot more work than letting a symlink
> propagate the change to all the other projects. Of course, since
> Windows doesn't have symlinks...
That is correct, but you only need to do the change if the projects
B, C, D, n... actually requires the new feature/bugfix introduced in
Common. Otherwise you can just leave it as-is.
Besides, when an important bugfix is added to Common, you probably
want to cut new releases from B, C, D, n... anyway, so it still
means doing stuff to those repositories.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] gitk: Add basic French translation
From: Christian Couder @ 2008-06-26 6:39 UTC (permalink / raw)
To: Cyril Brulebois; +Cc: paulus, git
In-Reply-To: <1213852083-31418-2-git-send-email-kibi@debian.org>
Le jeudi 19 juin 2008, Cyril Brulebois a écrit :
> Signed-off-by: Cyril Brulebois <kibi@debian.org>
> ---
> po/fr.po | 904
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files
> changed, 904 insertions(+), 0 deletions(-)
> create mode 100644 po/fr.po
>
> diff --git a/po/fr.po b/po/fr.po
> new file mode 100644
> index 0000000..d37b2eb
> --- /dev/null
> +++ b/po/fr.po
> @@ -0,0 +1,904 @@
> +# Translation of gitk
> +# This file is distributed under the same license as the gitk package.
> +# Copyright © 2008 Cyril Brulebois <kibi@debian.org>
> +#
[...]
> +
> +#: gitk:2121 gitk:2136 gitk:7211
> +msgid "Diff this -> selected"
> +msgstr ""
msgstr "Diff ceci -> selection"
> +
> +#: gitk:2123 gitk:2138 gitk:7212
> +msgid "Diff selected -> this"
> +msgstr ""
msgstr "Diff selection -> ceci"
> +
> +#: gitk:2125 gitk:2140 gitk:7213
> +msgid "Make patch"
> +msgstr "Créer patch"
> +
> +#: gitk:2126 gitk:7351
> +msgid "Create tag"
> +msgstr "Créer tag"
> +
> +#: gitk:2127 gitk:7450
> +msgid "Write commit to file"
> +msgstr ""
msgstr "Enregistrer le commit dans un fichier"
> +
> +#: gitk:2128 gitk:7504
> +msgid "Create new branch"
> +msgstr "Créer une nouvelle branch"
msgstr "Créer une nouvelle branche"
> +#: gitk:2129
> +msgid "Cherry-pick this commit"
> +msgstr "Cueillir ce commit"
> +
> +#: gitk:2131
> +msgid "Reset HEAD branch to here"
> +msgstr "Réinitialiser la branche HEAD ici"
> +
> +#: gitk:2147
> +msgid "Check out this branch"
> +msgstr ""
msgstr "Emprunter cette branche"
[...]
> +#: gitk:2438
> +msgid "<PageUp>\tMove up one page in commit list"
> +msgstr ""
msgstr "<PageUp>\tRemonter d'une page dans la liste des commits"
> +
> +#: gitk:2439
> +msgid "<PageDown>\tMove down one page in commit list"
> +msgstr ""
msgstr "<PageDown>\tRedescendre d'une page dans la liste des commits"
> +#: gitk:2440
> +#, tcl-format
> +msgid "<%s-Home>\tScroll to top of commit list"
> +msgstr ""
msgstr "<%s-Home>\tAller en haut de la liste des commits"
> +#: gitk:2441
> +#, tcl-format
> +msgid "<%s-End>\tScroll to bottom of commit list"
> +msgstr ""
msgstr "<%s-End>\tAller en bas de la liste des commits"
> +#: gitk:2442
> +#, tcl-format
> +msgid "<%s-Up>\tScroll commit list up one line"
> +msgstr ""
msgstr "<%s-Up>\tMonter d'une ligne dans la liste des commits"
> +#: gitk:2443
> +#, tcl-format
> +msgid "<%s-Down>\tScroll commit list down one line"
> +msgstr ""
msgstr "<%s-Down>\tDescendre d'une ligne dans la liste des commits"
> +#: gitk:2444
> +#, tcl-format
> +msgid "<%s-PageUp>\tScroll commit list up one page"
> +msgstr ""
msgstr "<%s-PageUp>\tMonter d'une page dans la liste des commits"
> +#: gitk:2445
> +#, tcl-format
> +msgid "<%s-PageDown>\tScroll commit list down one page"
> +msgstr ""
msgstr "<%s-PageDown>\tDescendre d'une page dans la liste des commits"
> +#: gitk:2446
> +msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
> +msgstr ""
msgstr "<Shift-Up>\tRechercher en arrière (plus haut, commits plus récents)"
> +#: gitk:2447
> +msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
> +msgstr ""
msgstr "<Shift-Down>\tRechercher en avant (plus bas, commits plus anciens)"
> +#: gitk:2448
> +msgid "<Delete>, b\tScroll diff view up one page"
> +msgstr ""
msgstr "<Delete>, b\tMonter d'une page dans la vue du diff"
> +#: gitk:2449
> +msgid "<Backspace>\tScroll diff view up one page"
> +msgstr ""
msgstr "<Backspace>\tMonter d'une page dans la vue du diff"
> +#: gitk:2450
> +msgid "<Space>\t\tScroll diff view down one page"
> +msgstr ""
msgstr "<Space>\t\tDescendre d'une page dans la vue du diff"
> +#: gitk:2451
> +msgid "u\t\tScroll diff view up 18 lines"
> +msgstr ""
msgstr "u\t\tMonter de 18 lignes dans la vue du diff"
> +#: gitk:2452
> +msgid "d\t\tScroll diff view down 18 lines"
> +msgstr ""
msgstr "d\t\tDescendre de 18 lignes dans la vue du diff"
> +#: gitk:2453
> +#, tcl-format
> +msgid "<%s-F>\t\tFind"
> +msgstr ""
msgstr "<%s-F>\t\tChercher"
> +#: gitk:2454
> +#, tcl-format
> +msgid "<%s-G>\t\tMove to next find hit"
> +msgstr ""
msgstr "<%s-G>\t\tAller à la prochaine occurence"
> +#: gitk:2455
> +msgid "<Return>\tMove to next find hit"
> +msgstr ""
msgstr "<Return>\tAller à la prochaine occurence"
> +#: gitk:2456
> +msgid "/\t\tMove to next find hit, or redo find"
> +msgstr ""
msgstr "/\t\tAller à la prochaine occurence ou recommencer la recherche"
> +#: gitk:2457
> +msgid "?\t\tMove to previous find hit"
> +msgstr ""
msgstr "?\t\tAller à l'occurence précédente"
Ok, I stopped reviewing/completing here because I am short on time right now
and anyway I think I should have answered before.
By the way for these po file where there are lots of encoding problem,
sending the attached file is ok I think.
Thanks for starting this,
Christian.
^ permalink raw reply
* Re: [PATCH] factorize pack structure allocation
From: Andreas Ericsson @ 2008-06-26 6:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Teemu Likonen
In-Reply-To: <alpine.LFD.1.10.0806241851420.2979@xanadu.home>
Nicolas Pitre wrote:
> New pack structures are currently allocated in 2 different places
> and all members have to be initialized explicitly. This is prone
> to errors leading to segmentation faults as found by Teemu Likonen.
>
> Let's have a common place where this structure is allocated, and have
> all members implicitly initialized to zero.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
> diff --git a/sha1_file.c b/sha1_file.c
> index a92f023..c56f674 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -792,18 +792,28 @@ unsigned char* use_pack(struct packed_git *p,
> return win->base + offset;
> }
>
> +static struct packed_git *alloc_packed_git(int extra)
> +{
> + struct packed_git *p = xmalloc(sizeof(*p) + extra);
> + memset(p, 0, sizeof(*p));
> + p->pack_fd = -1;
> + return p;
> +}
> +
Minor nit; Use xcalloc() instead. It initializes the allocated area
to zero by default, either by the glibc allocator when it re-uses old
memory, or by the kernel when it's handed to userspace. It's a
micro-optimization, but a worthwhile one imo, especially for repos
with lots and lots of packs (git gc --auto runs galore).
The "calloc() returns nulified memory" dogma conforms to C89 and is
thus about as portable as it gets.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Ship sample hooks with .sample suffix
From: Johannes Sixt @ 2008-06-26 7:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod5q8c25.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I'll queue the patch to 'master' and I suspect that this will make 31d6632
> (Windows: Change the name of hook scripts to make them not executable.,
> 2007-11-30) unnecessary.
I've updated
git://repo.or.cz/git/mingw/j6t.git for-junio
and the interdiff to the previous version is merely the reverse of
31d6632. For your convenience I've merged it into current next:
git://repo.or.cz/git/mingw/j6t.git merge-mingw-into-next
-- Hannes
^ permalink raw reply
* Re: [PATCH] Ship sample hooks with .sample suffix
From: Junio C Hamano @ 2008-06-26 7:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <486342F8.2060406@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> I'll queue the patch to 'master' and I suspect that this will make 31d6632
>> (Windows: Change the name of hook scripts to make them not executable.,
>> 2007-11-30) unnecessary.
>
> I've updated
>
> git://repo.or.cz/git/mingw/j6t.git for-junio
>
> and the interdiff to the previous version is merely the reverse of
> 31d6632. For your convenience I've merged it into current next:
>
> git://repo.or.cz/git/mingw/j6t.git merge-mingw-into-next
Thanks. This round I am looking forward to very much being able to merge
this to 'next' for real, not just parking in 'pu', but it is getting late
so it may have to wait til tomorrow.
^ permalink raw reply
* Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
From: Jeff King @ 2008-06-26 7:50 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <20080619151110.GA31654@sigill.intra.peff.net>
On Thu, Jun 19, 2008 at 11:11:10AM -0400, Jeff King wrote:
> > Please please please do :)
> > The exit 1 of git-push is really annoying me these days.
>
> OK, I will try to take a look in the next few days.
I finally got a chance to look at this [distinguishing stale refs from
other non-ff refs]. I was originally planning on doing a multi-patch
series:
1/4 distinguish visually between stale / non-ff refs
2/4 config option to let stale refs not count towards exit code of 1
3/4 disallow "push -f" without explicit refspec or option (like --all)
4/4 config option not to show stale refs unless "-v" is given (which
is now reasonably safe, since invisible refs won't get pushed when
you just repeat your "git push" with a "-f")
But I didn't like how it was turning out. Specifically:
- two config options doesn't really make sense. Either you care about
stale refs, or you don't. If you do, you should see them and have
them impact your exit code.
- I thought 3/4 would introduce a generally useful safety valve. But I
realized I really _like_ the current behavior. Most of the time I
force a push, it is something like "git push", "oops, that is a
non-ff, but I know it is OK", "git push -f". It makes sense to me
that I can repeat my last command and simply say "OK, force this."
But with such a safety valve, I have to realize the shortcut that
"git push" was performing (i.e., "git push --matching"), and then
explicitly retype it. Which is not hard mentally, but it makes the
interface seem very clunky.
Instead of that, I am considering something more like this:
- we always visually distinguish stale and other non-ff refs
- if a config option is set, we treat stale refs as "up to date". That
is, we don't show them (unless -v is set), and they don't affect the
exit code. The option is unset by default, giving the same as
current behavior.
- If the config option is not set, then forcing works as before.
- If the config option is set, then we _do not_ force stale refs, but
only other non-ff. Meaning we are truly treating them like our "up
to date" refs and saying "there is nothing of interest to push".
This leaves one open issue. If you have the "treat stale as up to date"
config option set, how do you force a strict rewind (if the occasion
comes up that in some instance, you do want to treat it differently)?
One solution is for the user to unset the config, do the forced push,
and then reset it. It makes some sense; the user has said, via the
config, that they consider stale refs uninteresting. So to actually
perform such a push, they need to "unsay" that temporarily.
Another solution would be an additional flag for forcing strict rewinds
(or even "-f -f", though I'm not sure that makes sense). This seems a
little hack-ish, since it would _only_ be used if this other config flag
is set.
Yet another solution would be to allow "-f" to force a strict rewind,
but only if the refspec is mentioned explicitly on the command line, and
not part of an automatic match. Reasonably DWIM, but I think it kills
the consistency we have now (that "--all" or "--matching" are really
just shorthands for spelling out all of the respective refspecs).
Does this seem like a good approach overall? Existing behavior should be
identical unless the config option is set, and with it set, I think it
should satisfy Pierre and posters from the original thread. If that is
sensible, which of the solutions for "no, I really want to force this
strict rewind" is the most palatable?
-Peff
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Jeff King @ 2008-06-26 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lea Wiemann, Git Mailing List
In-Reply-To: <20080626053551.GA20767@sigill.intra.peff.net>
On Thu, Jun 26, 2008 at 01:35:51AM -0400, Jeff King wrote:
> > Hmm. Actually, there is a test in t6300 that runs with each atom name.
> > Unfortunately, it doesn't bother actually checking the output for
> > sanity, so the fact that these atoms returned the empty string was
> > missed.
>
> And here is a two patch series cleaning up the test script and fixing
> the bug.
Hmm, looks like I just missed you applying the original fix to maint.
Ignore 2/2, then, as you already have it. I think it is still worth
doing the test script cleanup, though. Here it is, rebased on the
current master (the only difference is we don't have to mark the
breakage as expect_failure).
-- >8 --
improve for-each-ref test script
Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom, which recently let
an obvious bug go undetected for some time.
While we're at it, also clean up a few '!' into
test_must_fail.
---
t/t6300-for-each-ref.sh | 87 +++++++++++++++++++++++++++++++++++++---------
1 files changed, 70 insertions(+), 17 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 91ea85d..a3c8941 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -26,25 +26,78 @@ test_expect_success 'Create sample commit with known timestamp' '
git tag -a -m "Tagging at $datestamp" testtag
'
-test_expect_success 'Check atom names are valid' '
- bad=
- for token in \
- refname objecttype objectsize objectname tree parent \
- numparent object type author authorname authoremail \
- authordate committer committername committeremail \
- committerdate tag tagger taggername taggeremail \
- taggerdate creator creatordate subject body contents
- do
- git for-each-ref --format="$token=%($token)" refs/heads || {
- bad=$token
- break
- }
- done
- test -z "$bad"
+test_atom() {
+ case "$1" in
+ head) ref=refs/heads/master ;;
+ tag) ref=refs/tags/testtag ;;
+ esac
+ printf '%s\n' "$3" >expected
+ test_expect_${4:-success} "basic atom: $1 $2" "
+ git for-each-ref --format='%($2)' $ref >actual &&
+ test_cmp expected actual
+ "
+}
+
+test_atom head refname refs/heads/master
+test_atom head objecttype commit
+test_atom head objectsize 171
+test_atom head objectname 67a36f10722846e891fbada1ba48ed035de75581
+test_atom head tree 0e51c00fcb93dffc755546f27593d511e1bdb46f
+test_atom head parent ''
+test_atom head numparent 0
+test_atom head object ''
+test_atom head type ''
+test_atom head author 'A U Thor <author@example.com> 1151939924 +0200'
+test_atom head authorname 'A U Thor'
+test_atom head authoremail '<author@example.com>'
+test_atom head authordate 'Mon Jul 3 17:18:44 2006 +0200'
+test_atom head committer 'C O Mitter <committer@example.com> 1151939923 +0200'
+test_atom head committername 'C O Mitter'
+test_atom head committeremail '<committer@example.com>'
+test_atom head committerdate 'Mon Jul 3 17:18:43 2006 +0200'
+test_atom head tag ''
+test_atom head tagger ''
+test_atom head taggername ''
+test_atom head taggeremail ''
+test_atom head taggerdate ''
+test_atom head creator 'C O Mitter <committer@example.com> 1151939923 +0200'
+test_atom head creatordate 'Mon Jul 3 17:18:43 2006 +0200'
+test_atom head subject 'Initial'
+test_atom head body ''
+test_atom head contents 'Initial
+'
+
+test_atom tag refname refs/tags/testtag
+test_atom tag objecttype tag
+test_atom tag objectsize 154
+test_atom tag objectname 98b46b1d36e5b07909de1b3886224e3e81e87322
+test_atom tag tree ''
+test_atom tag parent ''
+test_atom tag numparent ''
+test_atom tag object '67a36f10722846e891fbada1ba48ed035de75581'
+test_atom tag type 'commit'
+test_atom tag author ''
+test_atom tag authorname ''
+test_atom tag authoremail ''
+test_atom tag authordate ''
+test_atom tag committer ''
+test_atom tag committername ''
+test_atom tag committeremail ''
+test_atom tag committerdate ''
+test_atom tag tag 'testtag'
+test_atom tag tagger 'C O Mitter <committer@example.com> 1151939925 +0200'
+test_atom tag taggername 'C O Mitter'
+test_atom tag taggeremail '<committer@example.com>'
+test_atom tag taggerdate 'Mon Jul 3 17:18:45 2006 +0200'
+test_atom tag creator 'C O Mitter <committer@example.com> 1151939925 +0200'
+test_atom tag creatordate 'Mon Jul 3 17:18:45 2006 +0200'
+test_atom tag subject 'Tagging at 1151939927'
+test_atom tag body ''
+test_atom tag contents 'Tagging at 1151939927
'
test_expect_success 'Check invalid atoms names are errors' '
- ! git-for-each-ref --format="%(INVALID)" refs/heads
+ test_must_fail git-for-each-ref --format="%(INVALID)" refs/heads
'
test_expect_success 'Check format specifiers are ignored in naming date atoms' '
@@ -64,7 +117,7 @@ test_expect_success 'Check valid format specifiers for date fields' '
'
test_expect_success 'Check invalid format specifiers are errors' '
- ! git-for-each-ref --format="%(authordate:INVALID)" refs/heads
+ test_must_fail git-for-each-ref --format="%(authordate:INVALID)" refs/heads
'
cat >expected <<\EOF
--
1.5.6.129.g8dea5.dirty
^ permalink raw reply related
* [OFF TOPIC] any views about the D programming language
From: Ittay Dror @ 2008-06-26 8:16 UTC (permalink / raw)
To: git
Hello,
I've read the language war thread (C vs C++) and I'm wondering if
someone would like to share their views about using D instead of C.
Thank you,
Ittay
--
--
Ittay Dror <ittay.dror@gmail.com>
^ permalink raw reply
* Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
From: Junio C Hamano @ 2008-06-26 8:19 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, git
In-Reply-To: <20080626075036.GA25770@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Does this seem like a good approach overall? Existing behavior should be
> identical unless the config option is set, and with it set, I think it
> should satisfy Pierre and posters from the original thread. If that is
> sensible, which of the solutions for "no, I really want to force this
> strict rewind" is the most palatable?
That "strict rewind" workaround alone made me so disgusted beyond words.
And then made me step back and think again.
If it is stale, it is stale. A revert is just a different history that
did not have some things that already happened, while a fork has some
other things that did not happen in the original history on top of that.
They are the same thing -- alternate history that drops some things that
already happened. It does not matter if you are strictly stale or if you
built a few (or hundreds of) commits on top of something that is stale.
You are losing history if you tried to push such a thing.
And if you do not want to trigger "what you are pushing is not up to
date", the solution is simple. You do not push them.
I however think what Pierre wanted to do is different, and you do not have
to solve "force this strict rewind" problem to solve it.
What we need is (with a configuration option) to change the meaning of
"matching refs" from the current definition "branches with the same name
between here and there" to "branches with the same name between here and
there, but excluding the ones that do not fast forward (or strictly
behind)". So if you have tons of stale branches you checked out but
haven't touched most of them, your "matching push" won't even try to push
what you haven't touched.
I do not think we would ever want to allow a configuration that disables
the exit status from push upon a push failure when somebody explicitly
says "git push $there $this" and $this is not non-fast-forward. If you
asked $this to be pushed, and if $this cannot be pushed, we _should_ error
out.
So...
(1) when you say "git push" to trigger the "matching refs" push, with the
new configuration, you do not error out nor even try to push out
things that do not fast forward. Pretend that you did not even
attempt to push them, and do not error out. This may result in not
pushing anything out, but that is what the people who have such a
configuration is asking for.
If you have configured which branches are pushed when you are on your
current branch, and that branch --- most likely it is that current
branch --- does not fast forward, it is your problem.
(2) even with such a configuration, you can "git push $there $this" and
"git push $there +$this" to explicitly ask refs to be pushed. Such a
push won't be interfered by the new configuration and correctly fail
(or force).
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Junio C Hamano @ 2008-06-26 8:21 UTC (permalink / raw)
To: Jeff King; +Cc: Lea Wiemann, Git Mailing List
In-Reply-To: <20080626080841.GA27935@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmm, looks like I just missed you applying the original fix to maint.
> Ignore 2/2, then, as you already have it. I think it is still worth
> doing the test script cleanup, though.
Absolutely. And thanks.
^ permalink raw reply
* Re: [PATCH] daemon: accept "git program" as well
From: Tommi Virtanen @ 2008-06-26 8:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce,
しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vmyl9w0y1.fsf@gitster.siamese.dyndns.org>
On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
> By the way I looked at gitosis (Tommi CC'ed).
>
> http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4
>
> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
> compared with user commands after doing:
Yeah, that's pretty much a trivial change, doing it now to future-proof
gitosis.
--
:(){ :|:&};:
^ permalink raw reply
* Re: [REPLACEMENT PATCH] parse-opt: fake short strings for callers to believe in.
From: Pierre Habouzit @ 2008-06-26 8:35 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <20080624205801.GG9189@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
Hi Junio,
I saw that you merged this series into pu, for which I'm really glad,
though I believe that the version that works on top of the "leaky()"
series is better, since everyone agrees that the small leaks in the
option parser are better than the limitations the one you merged has.
I won't flood the list again with the patches, but you can find them
in git://git.madism.org/~madcoder/git.git#ph/parseopt (based on current
next). This includes the two leaky() patches (with the remarks that have
been made to me incorporated), the current state of the parse-options
improvements, and the current builtin-blame.c proof of concept (without
the ugly strdup).
I really don't like the strbuf thingy, and I'd be glad to never see it
merged in next, it will cause more harm than it helps.
TIA.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [REPLACEMENT PATCH] parse-opt: fake short strings for callers to believe in.
From: Junio C Hamano @ 2008-06-26 8:40 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20080626083506.GA7237@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> I saw that you merged this series into pu, for which I'm really glad,
Heh, you shouldn't be glad to have "landed" on 'pu', as being in 'pu' is
just a sign of "undecided" ;-)
And thanks for a reminder. Every bit of help to make integration smoother
really helps. I've been swamped and I still have your "revisions:
refactor init_revisions and setup_revisions" sitting in my inbox.
^ permalink raw reply
* Re: [Bug?] git submodule add doesn't respect core.autocrlf
From: Lars Hjemli @ 2008-06-26 8:40 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <g3vaaq$pm1$1@ger.gmane.org>
On Thu, Jun 26, 2008 at 7:43 AM, Edward Z. Yang
<edwardzyang@thewritingpot.com> wrote:
> mkdir test
> cd test
> git init
> git config core.safecrlf true
> git config core.autocrlf true
You can work around the problem by issuing the following commands at this point:
echo ".gitattributes -crlf" >> .gitattributes
echo ".gitmodules -crlf" >> .gitattributes
git add .gitattributes
> git submodule add http://repo.or.cz/w/htmlpurifier.git htmlpurifier
>
> You get: "fatal: LF would be replaced by CRLF in .gitmodules" and inspecting .gitmodules reveals that it uses LF, instead of CRLF.
>
> Can anyone reproduce? Thanks.
Yes, this also fails on linux (without the workaround).
To fix it "properly", git-config needs to choose between lf and crlf
(git-submodule uses git-config to write .gitmodules). But this depends
on
* whether the 'configfile' is (or will be!) tracked by git (e.g. .gitmodules)
* whether a crlf-attribute is specified for the 'configfile'
* the setting of core.autocrlf
A simpler solution might be to treat .gitmodules specially in
check_safe_crlf(), maybe something like this (possibly wrapped by
gmail...):
diff --git a/convert.c b/convert.c
index 1c66844..254a99b 100644
--- a/convert.c
+++ b/convert.c
@@ -91,6 +91,15 @@ static void check_safe_crlf(const char *path, int action,
if (!checksafe)
return;
+ /* Dirty hack: git-submodule uses git-config to update .gitmodules, and
+ * there's no reasonable way for git-config to know if the user prefers
+ * crlf or lf line endings for this file. And since it really doesn't
+ * matter, lets just ignore that the line endings might be modified by
+ * a later checkout.
+ */
+ if (!strcmp(path, ".gitmodules"))
+ return;
+
if (action == CRLF_INPUT || auto_crlf <= 0) {
/*
* CRLFs would not be restored by checkout:
--
larsh
^ permalink raw reply related
* Re: update-index --assume-unchanged doesn't make things go fast
From: Michael J Gruber @ 2008-06-26 8:47 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130806251102l6e71a050o82fbd4f272d1d23f@mail.gmail.com>
Avery Pennarun venit, vidit, dixit 25.06.2008 20:02:
> On 6/25/08, Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
>>> 4) My idea is to eventually --assume-unchanged my whole repository,
>>> then write a cheesy daemon that uses the Win32 dnotify-equivalent to
>>> watch for files that get updated and then selectively
>>> --no-assume-unchanged files that it gets notified about. That would
>>> avoid the need to ever synchronously scan the whole repo for changes,
>>> thus making my git-Win32 experience much faster and more enjoyable.
>>> (This daemon ought to be possible to run on Linux as well, for similar
>>> improvements on gigantic repositories. Also note that TortoiseSVN for
>>> Windows does something similar to track file status updates, so this
>>> isn't *just* me being crazy.)
>> Looks like users on slow NFS would profit, too. Hate to say it, but hg
>> feels faster on (slow) NFS than git. Yet I use git, for other reasons ;)
>
> Hmm, can you do dnotify over NFS?
>
> I'd like to know how hg goes any faster. As far as I can see, git is
> going as fast as can be without some kind of daemon or other magic.
> (Except for my point #3, which seems relatively minor.)
I haven't done any measurements, maybe I should; getting consistent
results would require setting up an isolated NFS environment, though.
The thing is that hg is very careful about serializing and minimizing
disk I/O, whereas git is very clever about delegating stuff to the
kernel and processing data efficiently. In my work environment I have to
keep my repos on NFS. For heavy history rewriting I resort to /tmp or
/dev/shm temporarily. But git status is kinda slow on NFS. I don't know
about [di]?notify over NFS.
Michael
^ 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