* Re: gitk : french translation
From: Emmanuel Trillaud @ 2009-11-10 18:05 UTC (permalink / raw)
To: Maximilien Noal, Matthieu Moy, Nicolas Pitre, Nicolas Sebrecht,
Emmanuel
Cc: Git Mailing List
In-Reply-To: <9f50533b0911060605p6ad28ad9neac3620a1809c3db@mail.gmail.com>
Here is a glossary which contains the Git words and the proposed translations.
Terme : Traduction(gitk) : Traduction(git-gui)
Branch : branche :
To blame : blâmer : blâmer
Commit : commit : commit
to commit : commiter : commiter
commiter : auteur du commit : commiteur
Check out : Récupérer : charger
to cherry-pick : Ceuillir
Diff : Différence : Diff
Index : Index
Tag : Tag : Marque (tag)
Revision : Révision : Révision
Merge : fusion : fusion
to merge : fusionner : fusionner
Head : Head : Head
to reset : Réinitialiser : Réinitialiser
reset : réinitialisation ;
Hard (Reset) : Dure :
Mixed (reset) : Hybride :
Soft (Reset) : Douce :
Patch : Patch :
To stage : Indexer :
some RFCs :
I am ok with the translation of "patch" by "patch" since it is use in
france in other context
I prefer to translate "Diff" by "Différences" _especially_ when we are
talking about the action of making a "diff"
translation of "Hard", "Mixed", "Soft" in the Reset context
translation of "cherry-pick". For this one we could use "<translation>
(<english-word>) ..." as suggest previously.
Best regards
Emmanuel
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Štěpán Němec @ 2009-11-10 18:06 UTC (permalink / raw)
To: git; +Cc: rocketraman
In-Reply-To: <1257869339-15999-2-git-send-email-rocketraman@fastmail.fm>
On Tue, Nov 10, 2009 at 11:08:59AM -0500, rocketraman@fastmail.fm wrote:
A small typo:
> +'maint' should now updated to the new release code so that maintenance
> +fixes can be merged for the current version:
There is a missing `be' somewhere, something like: "'maint' should now be
updated..."
Regards,
Štěpán
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Raman Gupta @ 2009-11-10 18:10 UTC (permalink / raw)
To: Štěpán Němec; +Cc: git
In-Reply-To: <20091110180612.GB12012@headley>
Štěpán Němec wrote:
> On Tue, Nov 10, 2009 at 11:08:59AM -0500, rocketraman@fastmail.fm wrote:
>
> A small typo:
>
>> +'maint' should now updated to the new release code so that maintenance
>> +fixes can be merged for the current version:
>
> There is a missing `be' somewhere, something like: "'maint' should now be
> updated..."
Oops, thanks, good catch.
Cheers,
Raman
^ permalink raw reply
* [PATCH] git-update-index.txt: Document the --really-refresh option.
From: Štěpán Němec @ 2009-11-10 18:11 UTC (permalink / raw)
To: git
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
---
I sent this patch last week, but it seems to somehow have got lost among
other mails. Of course it's nothing fabulous, still I expect at least
somebody to tell me I'm not making any sense ;-)
Štěpán
Original message:
I noticed that --really-refresh is included in SYNOPSIS, but otherwise
undocumented, although mentioned in the text and example.
This is an attempt at fixing that.
Documentation/git-update-index.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 25e0bbe..6052484 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -99,6 +99,10 @@ in the index e.g. when merging in a commit;
thus, in case the assumed-untracked file is changed upstream,
you will need to handle the situation manually.
+--really-refresh::
+ Like '--refresh', but checks stat information unconditionally,
+ without regard to the "assume unchanged" setting.
+
-g::
--again::
Runs 'git-update-index' itself on the paths whose index
@@ -308,7 +312,7 @@ Configuration
-------------
The command honors `core.filemode` configuration variable. If
-your repository is on an filesystem whose executable bits are
+your repository is on a filesystem whose executable bits are
unreliable, this should be set to 'false' (see linkgit:git-config[1]).
This causes the command to ignore differences in file modes recorded
in the index and the file mode on the filesystem if they differ only on
--
1.6.5.2.74.g610f9.dirty
^ permalink raw reply related
* relative path specs not understood
From: David Reitter @ 2009-11-10 18:13 UTC (permalink / raw)
To: git
I'm troubled by a repository in which I can access certain files only
using the full path specification, but not from within the directory.
The protocol below should explain this.
I have a hunch this may have to do with certain symlinks (stored in
the repository), or maybe with renaming. Any help on debugging this
would be great. Perhaps I've just misunderstood something here...
- David
~/ae.git$ git --version
git version 1.6.5.2
~/ae.git$ cd etc
~/ae.git/etc$ git ls-files DISTRIB
DISTRIB
~/ae.git$ cd ..
~/ae.git$ git ls-files -t -- aquamacs/TODO
H aquamacs/TODO
~/ae.git$ cd aquamacs/
~/ae.git/aquamacs$ git ls-files -t -- TODO
~/ae.git/aquamacs$ git ls-files -vmo -- TODO
? TODO
~/ae.git/aquamacs$ git status TODO
error: pathspec 'TODO' did not match any file(s) known to git.
~/ae.git/aquamacs$ git add TODO
~/ae.git/aquamacs$ git status TODO
error: pathspec 'TODO' did not match any file(s) known to git.
~/ae.git/aquamacs$ cd ../lisp/
~/ae.git/lisp$ ls -la aquamacs
lrwxr-xr-x 1 dr dr 25 Oct 7 22:30 aquamacs -> ../aquamacs/src/site-
lisp
~/ae.git/.git$ cat config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
(...)
^ permalink raw reply
* git-svn not fetching all revisions
From: Marcus Better @ 2009-11-10 18:08 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have trouble cloning a SVN repository with a somewhat weird history.
Its layout has been reorganised, and is currently using a standard
layout like this:
project/
trunk/
branches/
tags/
otherproject/
...
The problem is that the trunk was replaced by a branch at some point.
When I do "git svn clone -s svn://host/repo/project" it only fetches the
"old" trunk up to the time of the switch, and then stops. Newer
revisions of the "new" trunk are not fetched and cannot be seen with
"find-rev".
The history of the repo is something like this: Initial layout is
trunk/
project/
otherstuff/
branches/
Then we had the following sequence:
1. commit stuff to trunk/project/...
2. create "branches/mybranch" from trunk/project
3. some commits on trunk and branches
4. moved trunk/project to branches/old_trunk
5. moved trunk/otherstuff to /otherstuff. /trunk is now empty (***)
6. removed /trunk directory
7. create /project
8. move branches/mybranch to project/trunk
9. commit stuff on project/trunk
(***) last commit seen in clone.
Now step 5 is the last revision that appears in the git svn clone. It
shows up as the last commit on remotes/trunk.
Apparently git svn has failed to follow the move from branches/mybranch
to trunk. The last commit seen on remotes/mybranch in the clone is from
before the move to trunk (step 3).
I have tried replaying the above steps with some variations in a new svn
repository, but apparently I'm missing something because I couldn't
reproduce the issue. I cannot publish the real svn repo.
I use git and git-svn 1.6.5.2 (Debian amd64 packages).
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkr5rBkACgkQXjXn6TzcAQnRZQCgrAsQ72wLw/iWx33lHQHi6Di7
wWkAnioEAxJyM/vr802+vzRXq+ZeWjeA
=TW7j
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Ingo Molnar @ 2009-11-10 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Zijlstra, git
In-Reply-To: <20091110071927.GB11942@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> * Junio C Hamano <gitster@pobox.com> wrote:
>
> > [Footnote]
> >
> > *1* To spell it out... The people who are in the "hate
> > chain-reply-to very much" camp would have already done their own
> > configuration to get the behaviour they want by now, so changing the
> > default would not help them much, while potentially hurting "love
> > chain-reply-to" people who have been content because they got what
> > they wanted without setting any configuration.
>
> Stupid question: i researched the Git mailing list archive (and read
> the link you provided) and found no arguments (at all) in favor of the
> nested chaining. Are you aware of any?
Btw., dont get me wrong - i'm perfectly happy with the fix in 1.7.0. You
are also right that behavioral changes dont belong into stable releases.
( I'm just seeing this problem through the biased eyes of someone who is
affected by it, so i naturally want to have the benefit of the change
ASAP - without fully perceiving the risks of the change.)
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 4/4] Add explicit Cygwin check to guard WIN32 header inclusion
From: Ramsay Jones @ 2009-11-10 18:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Marius Storm-Olsen, GIT Mailing-list
In-Reply-To: <4AF7C2C6.5070307@viscovery.net>
Johannes Sixt wrote:
> Ramsay Jones schrieb:
>> Since commit 435bdf8c ("Make usage of windows.h lean and mean",
>> 16-9-2009), the amount of code potentially including the WIN32
>> API header files has greatly increased. In particular, the Cygwin
>> build is at greater risk of inadvertently including WIN32 code
>> within preprocessor sections protected by the WIN32 or _WIN32
>> macros.
>
> Thanks, this makes the problem pretty clear that you want to solve.
>
Hmm, OK. Note the "... potentially including ..." above.
>> The previous commit message, along with comments elsewhere, assert
>> that the WIN32 macro is not defined on Cygwin. Currently, this is
>> true for the cygwin build. However, the cygwin platform can be
>> used to develop WIN32 GUI, WIN32 console, and POSIX applications.
>> Indeed it is possible to create applications which use a mix of
>> the WIN32 API and POSIX code (eg git!).
>
> In this paragraph, you are only saying that cygwin comes with headers and
> libraries that can be used to write code using the Windows API in addition
> to the POSIX headers and libraries. (I'm just asking, not complaining;
> perhaps this could be stated differently.)
>
;-) The above paragraph, along with the one below, was once part of an even
larger paragraph which I had edited multiple times and, eventually, split
up. I had intended to delete the last two sentences from the above paragraph.
Whilst the content of those sentences is true, it is not necessary for them
to be there and, having been orphaned at the end of the paragraph, now sound
a bit odd.
If I were to create a version 4 of the patch, I would delete that text.
>> Unlike native WIN32 compilers, gcc on cygwin does not automatically
>> define the _WIN32 macro. However, as soon as you include the
>> <windows.h> header file, the _WIN32 and WIN32 macros are defined.
>>
>> In order to reduce the risk of problems in the future, we protect
>> the inclusion of the windows header with an explicit check for
>> __CYGWIN__. Also, we move the other use of the <windows.h> header
>> from compat/win32.h to compat/cygwin.c
>
> But I sense a contradiction here. Above you are arguing that much more
> WIN32 code is included, but here you are saying that the explicit check
---------------^
potentially
> for __CYGWIN__ is just a safety measure to protect us from failures in
> future changes. Indeed, looking at the code it seems that this extra check
> is *currently* not necessary:
*correct*! I have not claimed otherwise.
[snipped other text I also agree with!]
> IOW, I disagree with your analysis that a lot of code suffers from
> windows.h pollution. What am I missing?
Hmm, I don't know; but the analysis that you claim for me, I don't
think is mine! :-D
Hmm, I don't have a great investment in this patch (it doesn't fix a bug
after all), so given that you don't see any merit in it, I'm more than
happy just to drop it! :-P
So, Junio, could you please drop this patch from the series.
Thanks!
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Michael Witten @ 2009-11-10 19:46 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, git, Junio C Hamano
In-Reply-To: <1257838352.21088.5.camel@twins>
[Sorry about the repeat, Peter]
On Tue, Nov 10, 2009 at 1:32 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
>> about half of every patch series that gets sent to me on lkml is
>> unreadable in my email client due to the default threading that
>> git-send-email does. It looks like this:
>>
>> 28685 r T Nov 05 Hitoshi Mitake ( 31) [PATCH v5 0/7] Adding general performance benchmarki
>> 28686 T Nov 05 Hitoshi Mitake ( 31) +->[PATCH v5 1/7] Adding new directory and header fo
>> 28687 T Nov 05 Hitoshi Mitake ( 368) | +->[PATCH v5 2/7] sched-messaging.c: benchmark for
>> 28688 T Nov 05 Hitoshi Mitake ( 148) | | +->[PATCH v5 3/7] sched-pipe.c: benchmark for pi
>> 28689 T Nov 05 Hitoshi Mitake ( 149) | | | +->[PATCH v5 4/7] builtin-bench.c: General fra
>> 28690 T Nov 05 Hitoshi Mitake ( 24) | | | | +->[PATCH v5 5/7] Modifying builtin.h for ne
>> 28691 T Nov 05 Hitoshi Mitake ( 25) | | | | | +->[PATCH v5 6/7] Modyfing perf.c for subc
>> 28692 T Nov 05 Hitoshi Mitake ( 30) | | | | | | +->[PATCH v5 7/7] Modyfing Makefile to b
>
> Do what I do and flame the sender and have them repost.
>
> I simply won't even attempt to read crap send like that.
What, precisely, is unreadable or crappy about that? I suppose the
chaining was introduced to keep some order to the patches.
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Peter Zijlstra @ 2009-11-10 19:58 UTC (permalink / raw)
To: Michael Witten; +Cc: Ingo Molnar, git, Junio C Hamano
In-Reply-To: <b4087cc50911101146j7f773613j74d6d6716a82ebd4@mail.gmail.com>
On Tue, 2009-11-10 at 13:46 -0600, Michael Witten wrote:
> [Sorry about the repeat, Peter]
>
> On Tue, Nov 10, 2009 at 1:32 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
> >> about half of every patch series that gets sent to me on lkml is
> >> unreadable in my email client due to the default threading that
> >> git-send-email does. It looks like this:
> >>
> >> 28685 r T Nov 05 Hitoshi Mitake ( 31) [PATCH v5 0/7] Adding general performance benchmarki
> >> 28686 T Nov 05 Hitoshi Mitake ( 31) +->[PATCH v5 1/7] Adding new directory and header fo
> >> 28687 T Nov 05 Hitoshi Mitake ( 368) | +->[PATCH v5 2/7] sched-messaging.c: benchmark for
> >> 28688 T Nov 05 Hitoshi Mitake ( 148) | | +->[PATCH v5 3/7] sched-pipe.c: benchmark for pi
> >> 28689 T Nov 05 Hitoshi Mitake ( 149) | | | +->[PATCH v5 4/7] builtin-bench.c: General fra
> >> 28690 T Nov 05 Hitoshi Mitake ( 24) | | | | +->[PATCH v5 5/7] Modifying builtin.h for ne
> >> 28691 T Nov 05 Hitoshi Mitake ( 25) | | | | | +->[PATCH v5 6/7] Modyfing perf.c for subc
> >> 28692 T Nov 05 Hitoshi Mitake ( 30) | | | | | | +->[PATCH v5 7/7] Modyfing Makefile to b
> >
> > Do what I do and flame the sender and have them repost.
> >
> > I simply won't even attempt to read crap send like that.
>
> What, precisely, is unreadable or crappy about that? I suppose the
> chaining was introduced to keep some order to the patches.
As can be seen in the example above, the subjects become useless at
about the 4th patch.
The reply to the first patch together with sort on subject or date also
keeps the patches in order, since consecutive patches have increasing
timestamps and properly increasing numbers in them. It also keeps the
subjects readable.
People want me to read their patches, if they make it hard on me, I
simply wont spend my time on their stuff and do something else instead.
^ permalink raw reply
* Re: [PATCH 07/24] check-ref-format: update usage string
From: Junio C Hamano @ 2009-11-10 20:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <1257779104-23884-7-git-send-email-jrnieder@gmail.com>
This deserves to go to maint, so I ejected it out of the series.
Thanks.
^ permalink raw reply
* Re: [PATCH 18/24] merge: do not setup worktree twice
From: Junio C Hamano @ 2009-11-10 20:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <1257779104-23884-18-git-send-email-jrnieder@gmail.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Builtins do not need to run setup_worktree() for themselves, since
> the builtin machinery runs it for them.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> This matter since '-h' cannot suppress _this_ setup_work_tree()
> through the builtin machinery.
I think this should directly go to 'maint'. I ejected it from the
series.
Thanks.
^ permalink raw reply
* Re: [PATCH 20/24] http-fetch: add missing initialization of argv0_path
From: Junio C Hamano @ 2009-11-10 20:12 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Johannes Sixt
In-Reply-To: <1257779104-23884-20-git-send-email-jrnieder@gmail.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
Why do you have inclusion of "exec_cmd.h" in [19/24]? As far as I can
tell, nothing you do in that patch depends on it.
According to c6dfb39 (remote-curl: add missing initialization of
argv0_path, 2009-10-13), this patch is necessary (and you must include
"exec_cmd.h") on MinGW, regardless of the "give help upon -h" topic.
I think this should be ejected from your series go directly to 'maint', or
am I mistaken?
http-fetch.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index e8f44ba..88f7dc8 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
#include "walker.h"
int main(int argc, const char **argv)
@@ -19,8 +20,8 @@ int main(int argc, const char **argv)
int get_verbosely = 0;
int get_recover = 0;
+ git_extract_argv0_path(argv[0]);
prefix = setup_git_directory();
-
git_config(git_default_config, NULL);
while (arg < argc && argv[arg][0] == '-') {
^ permalink raw reply related
* Re: [PATCH 22/24] Let usage() take a printf-style format
From: Junio C Hamano @ 2009-11-10 20:16 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <1257779104-23884-22-git-send-email-jrnieder@gmail.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> merge-recursive and diff --no-index are not able to use usage()
> because their usage strings depend on the circumstances in which
> they are called.
Since die() and warn() are already printf-like, it may be tempting
to do this, but this is wrong.
I do not want to vet all the existing call sites to usage() of make sure
that all of them _happen_ to pass constant strings that do not have any
'%' in them.
Much more importantly, without a patch to future-proof all existing
callsites to modify from
usage(blame_usage);
to
usage("%s", blame_usage);
everybody needs to remember that some *_usage strings are special and have
to double % in it forever, which is a maintenance nightmare.
Besides, the majority of usage strings are _expected_ to be constant.
That is an important difference from die/warn whose purpose is to diagnose
and give appropriate message to the situation (hence they benefit from
formatting).
I've renamed this to usagef() and updated your two callers to use it in
the version I queued to 'pu'.
Thanks.
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Junio C Hamano @ 2009-11-10 20:17 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Johannes Sixt, git
In-Reply-To: <20091110133427.GC8896@plop>
"Philippe Bruhat (BooK)" <book@cpan.org> writes:
> On Tue, Nov 10, 2009 at 01:26:53PM +0100, Johannes Sixt wrote:
>> >
>> > +test -z "$NO_PERL" && test -z "$PERL_PATH" && export PERL_PATH=/usr/bin/perl
>>
>> Wouldn't
>>
>> ... && export PERL_PATH=perl
>>
>> be a safer fall-back?
>
> /usr/bin/perl is the value used in the top-level Makefile.
> I used this for consistency.
Hmm, but that means two separate definitions in ./Makefile and
t/test-lib.sh must be kept in sync forever, and there is not even a
comment next to the line that requires such care in your patch to help
people who might want to change these lines in the future.
^ permalink raw reply
* Re: Bug: "git svn clone" does not honor svn.authorsfile setting
From: Junio C Hamano @ 2009-11-10 20:18 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Curt Sampson, git
In-Reply-To: <fabb9a1e0911100524p2cf3f2ebp698ecb50fc53f8e9@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Tue, Nov 10, 2009 at 14:09, Curt Sampson <cjs@cynic.net> wrote:
>> [Note that I've set Reply-to to both myself and this list, as I am not
>> subscribed to the list. Broken list software and MUAs sometimes don't
>> honor this. Check to whom you're replying!]
>
> Please don't. It is custom on the git list to always keep those who
> are involved in the conversation cc-ed, adding a Reply-to makes this
> difficult.
I've seen people use Mail-Followup-To to cause grumbles, but Reply-To
seems worse in a sense. If I wanted to respond _privately_ to Curt, and
said "Reply", the message would have been broadcast to the public, and I
am using a MUA that is *not* broken and honors this setting.
Not good.
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-10 20:47 UTC (permalink / raw)
To: Emmanuel Trillaud
Cc: Maximilien Noal, Matthieu Moy, Nicolas Pitre, Nicolas Sebrecht,
Thomas Moulard, Guy Brand, Git Mailing List
In-Reply-To: <9f50533b0911101005j4839bd93ld69edfa94241c755@mail.gmail.com>
The 10/11/09, Emmanuel Trillaud wrote:
> Here is a glossary which contains the Git words and the proposed translations.
>
> Terme : Traduction(gitk) : Traduction(git-gui)
Nice idea, this will help for consistency.
> Branch : branche :
branche (git gui)
> To blame : blâmer : blâmer
> Commit : commit : commit
> to commit : commiter : commiter
> commiter : auteur du commit : commiteur
Why not "commiteur" for gitk too?
> Check out : Récupérer : charger
> to cherry-pick : Ceuillir
> Diff : Différence : Diff
See comment at the end.
> Index : Index
> Tag : Tag : Marque (tag)
> Revision : Révision : Révision
> Merge : fusion : fusion
> to merge : fusionner : fusionner
> Head : Head : Head
> to reset : Réinitialiser : Réinitialiser
> reset : réinitialisation ;
> Hard (Reset) : Dure :
> Mixed (reset) : Hybride :
> Soft (Reset) : Douce :
Léger ?
> Patch : Patch :
> To stage : Indexer :
>
> some RFCs :
> I am ok with the translation of "patch" by "patch" since it is use in
> france in other context
> I prefer to translate "Diff" by "Différences" _especially_ when we are
> talking about the action of making a "diff"
You don't explain _why_. We had 3 points in favour of the "diff" term in
french in this thread (keep Git's commands consistency, rough
translation and english word more used even by french people as for
"patch"). I have another argument to use "diff" now: keep consistency
with 'git gui'.
> translation of "Hard", "Mixed", "Soft" in the Reset context
> translation of "cherry-pick". For this one we could use "<translation>
> (<english-word>) ..." as suggest previously.
I'm fine here.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-10 21:02 UTC (permalink / raw)
To: Emmanuel Trillaud
Cc: Maximilien Noal, Matthieu Moy, Nicolas Pitre, Nicolas Sebrecht,
Thomas Moulard, Guy Brand, Git Mailing List
In-Reply-To: <9f50533b0911100945l2c3b7399w1d72771fd2cf8df@mail.gmail.com>
The 10/11/09, Emmanuel Trillaud wrote:
> Subject : [PATCHv2] French translation of gitk
>
> Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
> Signed-off-by: Thomas Moulard <thomas.moulard@gmail.com>
> Signed-off-by: Guy Brand <gb@unistra.fr>
> ---
> This translation is complete and has been proofread (thanks to Thomas and Guy).
There are still spelling errors in some translations. I'll correct the
patch when we'll find a consensus for the semantic fields of the
translation.
> I will (again) appreciate the feedback on this translation or on the
> glossary that will follow.
My first concerns go there; read the other sub-thread, please.
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH v4 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Thomas Rast @ 2009-11-10 21:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <4AE945D0.5030403@viscovery.net>
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused.
Furthermore, the case for --subdirectory-filter supplies its own --,
so the user cannot provide one himself, so the following was
impossible:
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
To keep the argument handling sane, we filter $@ to contain only the
non-revision arguments, and store all revisions in $ref_args. The
$ref_args are easy to handle since only the SHA1s are needed; the
actual branch names have already been stored in $tempdir/heads at this
point.
An extra separating -- is only required if the user did not provide
any non-revision arguments, as the latter disambiguate the
$filter_subdir following after them (or fail earlier because they are
ambiguous themselves).
Thanks to Johannes Sixt for suggesting this solution.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Thanks once again for your reviews. It's been a while since I last
looked into this, but after some staring, I think you're right on all
counts.
Johannes Sixt wrote:
> # we need "--" only if there are no path arguments in $@
> nonrevs=$(git rev-parse --no-revs "$@") || exit
> dashdash=${nonrevs+"--"}
>
> (including the comment; you can drop the dquotes in the dashdash
> assignment if you think the result is still readable.)
Ok. I was briefly scared that this was bash-specific syntax, but dash
seems happy so I'll trust your advice.
> This is not correct: $filter_subdir undergoes an extra level of
> evaluation. You must write it like this:
>
> eval set -- "$(git rev-parse --sq --no-revs "$@" \
> $dashdash "$filter_subdir")"
Hopefully I finally understand what's going on here. The quoting
rules make my head spin.
> > - ancestor=$(git rev-list --simplify-merges -1 \
> > - $ref -- "$filter_subdir")
> > + ancestor=$(git rev-list --simplify-merges -1 "$ref" "$@")
>
> You added dquotes around $ref: while not absolutely necessary, I agree
> with this change.
It's kind of a sneak fix, but I broke this back in the ancestor
rewriting patch... Luckily the refname sanity rules are designed to
prevent this from causing any harm.
git-filter-branch.sh | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..96b2182 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -257,15 +257,24 @@ git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
+# we need "--" only if there are no path arguments in $@
+nonrevs=$(git rev-parse --no-revs "$@") || exit
+dashdash=${nonrevs+"--"}
+rev_args=$(git rev-parse --revs-only "$@")
+
case "$filter_subdir" in
"")
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@"
+ eval set -- "$(git rev-parse --sq --no-revs "$@")"
;;
*)
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@" -- "$filter_subdir"
-esac > ../revs || die "Could not get the commits"
+ eval set -- "$(git rev-parse --sq --no-revs "$@" $dashdash \
+ "$filter_subdir")"
+ ;;
+esac
+
+git rev-list --reverse --topo-order --default HEAD \
+ --parents --simplify-merges $rev_args "$@" > ../revs ||
+ die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -356,8 +365,7 @@ then
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- ancestor=$(git rev-list --simplify-merges -1 \
- $ref -- "$filter_subdir")
+ ancestor=$(git rev-list --simplify-merges -1 "$ref" "$@")
test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
done < "$tempdir"/heads
fi
--
1.6.5.2.365.ge9237
^ permalink raw reply related
* [PATCH v4 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Thomas Rast @ 2009-11-10 21:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <0280836a32983c848bbb0e3b441be256d3c8f4fa.1257885121.git.trast@student.ethz.ch>
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Compared to v3 this only changes the comment, as suggested by Johannes
Sixt.
Documentation/git-filter-branch.txt | 13 ++++++++++++-
git-filter-branch.sh | 18 +++++++++++++-----
t/t7003-filter-branch.sh | 18 ++++++++++++++++++
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2b40bab..394a77a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -159,7 +159,18 @@ to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
- project root.
+ project root. Implies --remap-to-ancestor.
+
+--remap-to-ancestor::
+ Rewrite refs to the nearest rewritten ancestor instead of
+ ignoring them.
++
+Normally, positive refs on the command line are only changed if the
+commit they point to was rewritten. However, you can limit the extent
+of this rewriting by using linkgit:rev-list[1] arguments, e.g., path
+limiters. Refs pointing to such excluded commits would then normally
+be ignored. With this option, they are instead rewritten to point at
+the nearest ancestor that was not excluded.
--prune-empty::
Some kind of filters will generate empty commits, that left the tree
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 96b2182..a5a0352 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -125,6 +125,7 @@ filter_subdir=
orig_namespace=refs/original/
force=
prune_empty=
+remap_to_ancestor=
while :
do
case "$1" in
@@ -137,6 +138,11 @@ do
force=t
continue
;;
+ --remap-to-ancestor)
+ shift
+ remap_to_ancestor=t
+ continue
+ ;;
--prune-empty)
shift
prune_empty=t
@@ -182,6 +188,7 @@ do
;;
--subdirectory-filter)
filter_subdir="$OPTARG"
+ remap_to_ancestor=t
;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
@@ -354,12 +361,13 @@ while read commit parents; do
die "could not write rewritten commit"
done <../revs
-# In case of a subdirectory filter, it is possible that a specified head
-# is not in the set of rewritten commits, because it was pruned by the
-# revision walker. Fix it by mapping these heads to the unique nearest
-# ancestor that survived the pruning.
+# If we are filtering for paths, as in the case of a subdirectory
+# filter, it is possible that a specified head is not in the set of
+# rewritten commits, because it was pruned by the revision walker.
+# Ancestor remapping fixes this by mapping these heads to the unique
+# nearest ancestor that survived the pruning.
-if test "$filter_subdir"
+if test "$remap_to_ancestor" = t
then
while read ref
do
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..9503875 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -288,4 +288,22 @@ test_expect_success 'Prune empty commits' '
test_cmp expect actual
'
+test_expect_success '--remap-to-ancestor with filename filters' '
+ git checkout master &&
+ git reset --hard A &&
+ test_commit add-foo foo 1 &&
+ git branch moved-foo &&
+ test_commit add-bar bar a &&
+ git branch invariant &&
+ orig_invariant=$(git rev-parse invariant) &&
+ git branch moved-bar &&
+ test_commit change-foo foo 2 &&
+ git filter-branch -f --remap-to-ancestor \
+ moved-foo moved-bar A..master \
+ -- -- foo &&
+ test $(git rev-parse moved-foo) = $(git rev-parse moved-bar) &&
+ test $(git rev-parse moved-foo) = $(git rev-parse master^) &&
+ test $orig_invariant = $(git rev-parse invariant)
+'
+
test_done
--
1.6.5.2.365.ge9237
^ permalink raw reply related
* Re: [LIBGIT2 PATCH] git_odb_open ckeck for valid path to database
From: Esben Mose Hansen @ 2009-11-10 21:07 UTC (permalink / raw)
To: Ramsay Jones; +Cc: ae, git
In-Reply-To: <4AF86A7F.1010500@ramsay1.demon.co.uk>
[-- Attachment #1: Type: Text/Plain, Size: 1245 bytes --]
On Monday 09 November 2009 20:16:15 Ramsay Jones wrote:
I have made 2 new patchsets: One
0001-git_odb_open-check-for-valid-path-to-database.patch
which is simply the patch before with fixups, and another series
0001-Add-gitfo_is_diretory.patch
0002-git_odb_open-ckeck-for-valid-path-to-database-using-.patch
which adds a gitfo_is_directory (0001) and then uses this new function from
git_odb_open (0002).
I hope I have done this git/email stuff correctly.
> This should be declared at the head of the function (or generally at the
> start of a block/scope); ie we don't use this C99 facility. This breaks
> MSVC, which does not understand C99.
C89 (?) is a tough monster, I see :)
>
> > + if (stat(db->objects_dir, &objects_dir_stat)) {
> > + free(db);
> > + return GIT_EOSERR;
> > + }
> > + if (!S_ISDIR(objects_dir_stat.st_mode)) {
>
> This breaks on MSVC, since the MS headers do not define S_ISDIR. It's not
> difficult to add; it's on my TODO list. (Andreas, I can add this later if
> you like)
I have not fixed this.
> (I think Andreas would prefer to see libgit2 somewhere in the subject,
> perhaps like [LIBGIT2 PATCH], otherwise he may miss you email
OK.
Thanks for looking at my code.
--
Kind regards, Esben
[-- Attachment #2: 0001-git_odb_open-check-for-valid-path-to-database.patch --]
[-- Type: text/x-patch, Size: 3133 bytes --]
From bb29cbb2fc42ce46bd8a53ad02d291aa833846fa Mon Sep 17 00:00:00 2001
From: Esben Mose Hansen <kde@mosehansen.dk>
Date: Fri, 6 Nov 2009 10:32:16 +0100
Subject: [PATCH] git_odb_open check for valid path to database
---
src/errors.c | 1 +
src/git/common.h | 3 +++
src/odb.c | 9 +++++++++
tests/t0204-opendb_errors.c | 38 ++++++++++++++++++++++++++++++++++++++
4 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 tests/t0204-opendb_errors.c
diff --git a/src/errors.c b/src/errors.c
index f348997..074c01c 100644
--- a/src/errors.c
+++ b/src/errors.c
@@ -36,6 +36,7 @@ static struct {
{ GIT_ENOTOID, "Not a git oid" },
{ GIT_ENOTFOUND, "Object does not exist in the scope searched" },
{ GIT_ENOMEM, "Not enough space" },
+ { GIT_ENOTDIR, "Not a directory" }
};
const char *git_strerror(int num)
diff --git a/src/git/common.h b/src/git/common.h
index c470e0e..96f2971 100644
--- a/src/git/common.h
+++ b/src/git/common.h
@@ -65,6 +65,9 @@
/** Consult the OS error information. */
#define GIT_EOSERR (GIT_ERROR - 4)
+/** The path is not a directory */
+#define GIT_ENOTDIR (GIT_ERROR - 5)
+
GIT_BEGIN_DECL
/** A revision traversal pool. */
diff --git a/src/odb.c b/src/odb.c
index 6d646a4..a588c1b 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -1014,6 +1014,7 @@ int git_odb_exists(git_odb *db, const git_oid *id)
int git_odb_open(git_odb **out, const char *objects_dir)
{
+ struct stat objects_dir_stat;
git_odb *db = git__calloc(1, sizeof(*db));
if (!db)
return GIT_ERROR;
@@ -1023,6 +1024,14 @@ int git_odb_open(git_odb **out, const char *objects_dir)
free(db);
return GIT_ERROR;
}
+ if (stat(db->objects_dir, &objects_dir_stat)) {
+ free(db);
+ return GIT_EOSERR;
+ }
+ if (!S_ISDIR(objects_dir_stat.st_mode)) {
+ free(db);
+ return GIT_ENOTDIR;
+ }
gitlck_init(&db->lock);
diff --git a/tests/t0204-opendb_errors.c b/tests/t0204-opendb_errors.c
new file mode 100644
index 0000000..e9b52c9
--- /dev/null
+++ b/tests/t0204-opendb_errors.c
@@ -0,0 +1,38 @@
+#include "test_lib.h"
+#include "test_helpers.h"
+#include <git/odb.h>
+#include "fileops.h"
+
+static char *odb_dir = "test-objects";
+
+static unsigned char one_bytes[] = {
+ 0x31, 0x78, 0x9c, 0xe3, 0x02, 0x00, 0x00, 0x0b,
+ 0x00, 0x0b,
+};
+
+static unsigned char one_data[] = {
+ 0x0a,
+};
+
+static object_data one = {
+ one_bytes,
+ sizeof(one_bytes),
+ "8b137891791fe96927ad78e64b0aad7bded08bdc",
+ "blob",
+ "test-objects/8b",
+ "test-objects/8b/137891791fe96927ad78e64b0aad7bded08bdc",
+ one_data,
+ sizeof(one_data),
+};
+
+BEGIN_TEST(opendb_errors)
+ git_odb *db;
+ int error = git_odb_open(&db, odb_dir);
+ must_be_true(error == GIT_EOSERR);
+ must_be_true(errno == ENOENT);
+ must_pass(write_object_files(odb_dir, &one));
+ error = git_odb_open(&db, one.file);
+ must_be_true(error == GIT_ENOTDIR);
+
+ must_pass(remove_object_files(odb_dir, &one));
+END_TEST
--
1.6.3.3
[-- Attachment #3: 0001-Add-gitfo_is_diretory.patch --]
[-- Type: text/x-patch, Size: 2026 bytes --]
From d1eb250c11a35e30aaaf0652a24daa27b6b90b8f Mon Sep 17 00:00:00 2001
From: Esben Mose Hansen <kde@mosehansen.dk>
Date: Tue, 10 Nov 2009 21:58:04 +0100
Subject: [PATCH 1/2] Add gitfo_is_diretory
---
src/errors.c | 1 +
src/fileops.c | 11 +++++++++++
src/fileops.h | 5 +++++
src/git/common.h | 3 +++
4 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/errors.c b/src/errors.c
index f348997..074c01c 100644
--- a/src/errors.c
+++ b/src/errors.c
@@ -36,6 +36,7 @@ static struct {
{ GIT_ENOTOID, "Not a git oid" },
{ GIT_ENOTFOUND, "Object does not exist in the scope searched" },
{ GIT_ENOMEM, "Not enough space" },
+ { GIT_ENOTDIR, "Not a directory" }
};
const char *git_strerror(int num)
diff --git a/src/fileops.c b/src/fileops.c
index 5de89cb..47a8681 100644
--- a/src/fileops.c
+++ b/src/fileops.c
@@ -274,3 +274,14 @@ int gitfo_dirent(
closedir(dir);
return GIT_SUCCESS;
}
+
+int gitfo_is_directory(const char* path) {
+ struct stat path_stat;
+ if (stat(path, &path_stat)) {
+ return GIT_EOSERR;
+ }
+ if (!S_ISDIR(path_stat.st_mode)) {
+ return GIT_ENOTDIR;
+ }
+ return GIT_SUCCESS;
+}
diff --git a/src/fileops.h b/src/fileops.h
index 02e4e5b..73eb72c 100644
--- a/src/fileops.h
+++ b/src/fileops.h
@@ -126,4 +126,9 @@ extern int gitfo_write_cached(gitfo_cache *ioc, void *buf, size_t len);
extern int gitfo_flush_cached(gitfo_cache *ioc);
extern int gitfo_close_cached(gitfo_cache *ioc);
+/**
+ * Check if path is a directory
+ */
+extern int gitfo_is_directory(const char* path);
+
#endif /* INCLUDE_fileops_h__ */
diff --git a/src/git/common.h b/src/git/common.h
index c470e0e..96f2971 100644
--- a/src/git/common.h
+++ b/src/git/common.h
@@ -65,6 +65,9 @@
/** Consult the OS error information. */
#define GIT_EOSERR (GIT_ERROR - 4)
+/** The path is not a directory */
+#define GIT_ENOTDIR (GIT_ERROR - 5)
+
GIT_BEGIN_DECL
/** A revision traversal pool. */
--
1.6.3.3
[-- Attachment #4: 0002-git_odb_open-ckeck-for-valid-path-to-database-using-.patch --]
[-- Type: text/x-patch, Size: 936 bytes --]
From 4db79e006b722291d645f05a2340cd7d26a3d777 Mon Sep 17 00:00:00 2001
From: Esben Mose Hansen <kde@mosehansen.dk>
Date: Tue, 10 Nov 2009 21:58:36 +0100
Subject: [PATCH 2/2] git_odb_open ckeck for valid path to database using gitfo_is_directory
---
src/odb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index 6d646a4..709fe58 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -1014,6 +1014,7 @@ int git_odb_exists(git_odb *db, const git_oid *id)
int git_odb_open(git_odb **out, const char *objects_dir)
{
+ int status;
git_odb *db = git__calloc(1, sizeof(*db));
if (!db)
return GIT_ERROR;
@@ -1023,6 +1024,10 @@ int git_odb_open(git_odb **out, const char *objects_dir)
free(db);
return GIT_ERROR;
}
+ if ((status = gitfo_is_directory(db->objects_dir))) {
+ free(db);
+ return status;
+ }
gitlck_init(&db->lock);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 20/24] http-fetch: add missing initialization of argv0_path
From: Johannes Sixt @ 2009-11-10 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vpr7q6sw8.fsf@alter.siamese.dyndns.org>
On Dienstag, 10. November 2009, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> > Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> > ---
>
> Why do you have inclusion of "exec_cmd.h" in [19/24]? As far as I can
> tell, nothing you do in that patch depends on it.
>
> According to c6dfb39 (remote-curl: add missing initialization of
> argv0_path, 2009-10-13), this patch is necessary (and you must include
> "exec_cmd.h") on MinGW, regardless of the "give help upon -h" topic.
>
> I think this should be ejected from your series go directly to 'maint', or
> am I mistaken?
You are right.
This command (in bash):
comm <(git grepc -l main\( *.c) <(git grepc -l extract_argv0 *.c)
shows programs in the 1st column that have main(), but do not call
git_extract_argv0_path. One remaining candidate is show-index.c, but its only
call-out is sha1_to_hex(), which doesn't use any other services.
http-fetch.c is the only file that needs this patch.
-- Hannes
^ permalink raw reply
* git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-10 22:23 UTC (permalink / raw)
To: git list
Hello,
A git-svn mirror is created using Git v1.6.4. When I copy this mirror
into another machine which is using v1.6.5 I get the following error:
$ git svn rebase
fatal: Invalid revision range
d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk
rev-list --pretty=raw --no-color --reverse
d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --:
command returned error: 128
Using v1.6.4 instead I have no problem. Any idea to track this problem down?
Thanks.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Avery Pennarun @ 2009-11-10 22:28 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4AF9E7FE.3060701@obry.net>
On Tue, Nov 10, 2009 at 5:23 PM, Pascal Obry <pascal@obry.net> wrote:
> $ git svn rebase
> fatal: Invalid revision range
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk
> rev-list --pretty=raw --no-color --reverse
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --: command
> returned error: 128
Is d2cf08bb67e4b7da33a250127aab784f1f2f58d3 a valid revision? (git
log d2cf08bb67e4b7da33a250127aab784f1f2f58d3). Is
refs/remotes/svn/trunk valid? (git log refs/remotes/svn/trunk). It
seems like a strange problem.
> Using v1.6.4 instead I have no problem. Any idea to track this problem down?
You could try using git bisect to figure out which exact commit to
git.git created the problem.
Avery
^ permalink raw reply
* Re: git replace woes: dirty stat with clean workdir
From: Christian Couder @ 2009-11-10 23:33 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4AF992F8.8010309@drmicha.warpmail.net>
Hi,
On mardi 10 novembre 2009, Michael J Gruber wrote:
> Hi there,
>
> when cooking up a "warning example" for git replace (don't draw
> premature conclusions when there are replaced objects) I came across the
> following problem: git status seems to compare the work dir with the
> tree of HEAD, not the replacing tree. Even deleting the index does not
> help.
Yeah, you are right. I must say that I never tested replacing trees before.
> [ The example also shows that we need a way to specify
> --no-replace-objects for gitk. Would easier if gitk really where git
> something. ]
Yeah, I think --no-replace-objects might not work well for shell scripts or
even commands that call other commands using run_command(). Perhaps we need
an environment variable GIT_NO_REPLACE_OBJECTS to be set by commands that
are passed --no-replace-objects and checked by all the commands. I will
have a look at that.
Thanks,
Christian.
^ 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