* [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-11 1:49 UTC (permalink / raw)
To: paulus; +Cc: git, David Aguilar
gitk fails to show diffs when browsing a repository for which
we have read-only access. This is due to gitk's assumption
that the current directory is always writable.
This teaches gitk to honor the GITK_TMPDIR environment
variable. This allows users to override the default location
used for writing temporary files.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
gitk | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..9139ace 100755
--- a/gitk
+++ b/gitk
@@ -3170,11 +3170,15 @@ proc flist_hl {only} {
}
proc gitknewtmpdir {} {
- global diffnum gitktmpdir gitdir
+ global diffnum env gitktmpdir gitdir
if {![info exists gitktmpdir]} {
- set gitktmpdir [file join [file dirname $gitdir] \
- [format ".gitk-tmp.%s" [pid]]]
+ if {[info exists env(GITK_TMPDIR)]} {
+ set tmpdir $env(GITK_TMPDIR)
+ } else {
+ set tmpdir [file dirname $gitdir]
+ }
+ set gitktmpdir [file join $tmpdir [format ".gitk-tmp.%s" [pid]]]
if {[catch {file mkdir $gitktmpdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $gitktmpdir] $err"
unset gitktmpdir
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* Re: [PATCH 18/24] merge: do not setup worktree twice
From: Jonathan Nieder @ 2009-11-11 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vws1y6sxg.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> 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. I think something like this should go on top on maint, then
reverted in master.
Sorry for the trouble,
Jonathan
-- %< --
Subject: check-ref-format does not know --print yet
Don’t advertise the --print option of the future in the current
usage string.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-check-ref-format.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index 96382e3..a5ba4ea 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -8,7 +8,7 @@
#include "strbuf.h"
static const char builtin_check_ref_format_usage[] =
-"git check-ref-format [--print] <refname>\n"
+"git check-ref-format <refname>\n"
" or: git check-ref-format --branch <branchname-shorthand>";
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH 20/24] http-fetch: add missing initialization of argv0_path
From: Jonathan Nieder @ 2009-11-11 1:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <7vpr7q6sw8.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> 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.
No good reason. Thanks for cleaning up my mess.
Jonathan
^ permalink raw reply
* Re: gitk : french translation
From: Emmanuel Trillaud @ 2009-11-11 1:10 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Maximilien Noal, Matthieu Moy, Nicolas Pitre, Thomas Moulard,
Guy Brand, Git Mailing List
In-Reply-To: <20091110204742.GA27518@vidovic>
2009/11/10 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:
>> commiter : auteur du commit : commiteur
>
> Why not "commiteur" for gitk too?
It's ok for me.
>> Check out : Récupérer : charger
>> to cherry-pick : Ceuillir
>> Diff : Différence : Diff
>
> See comment at the end.
>
>> Soft (Reset) : Douce :
>
> Léger ?
Souds better. I will make the change, except if someone has a better
proposal.
>> 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'.
I see now that I have no good reasons to prefer "Différences".
>> translation of "cherry-pick". For this one we could use "<translation>
>> (<english-word>) ..." as suggest previously.
>
> I'm fine here.
Thanks for your comments.
Emmanuel Trillaud
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-11 0:10 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:
> +"Last-Translator: YOUR NAME <E-MAIL@ADDRESS>\n"
> +"Language-Team: FRENCH\n"
Please, fill in these fields.
> +#: gitk:337
> +msgid "No files selected: --merge specified but no files are unmerged."
> +msgstr "Aucun fichier sélectionné : --merge précisé, mais tous les
> fichiers sont fusionnés."
Line wraping error; configure your mail user agent to not wrap lines,
please.
> +#FIXME : améliorer la traduction de 'file limite'
If you add some FIXME (which is good), you also should mark the
translation as "fuzzy" like this:
> +#: gitk:340
#, fuzzy
> +msgid ""
> +"No files selected: --merge specified but no unmerged files are within file "
> +"limit."
> +msgstr "Aucun fichier sélectionné : --merge précisé mais aucun
> fichier non fusionné n'est dans la limite des fichiers."
<...>
> +#: gitk:1437
> +msgid "Can't parse git log output:"
> +msgstr "Impossible de lire le résultat de git log :"
s/le résultat/la sortie/
> +#: gitk:1793 gitk:1817 gitk:3916 gitk:8786 gitk:10322 gitk:10498
> +msgid "OK"
> +msgstr "OK"
This one should not be required.
> +#: gitk:1934
> +msgid "New view..."
> +msgstr "Nouvelle vue ..."
s/vue /vue/
> +#: gitk:2099 gitk:2101
> +msgid "Exact"
> +msgstr "Exact"
This one should not be required.
> +#: gitk:2215
> +msgid "Patch"
> +msgstr "Patch"
Ditto.
> +#: gitk:2366 gitk:8604
> +msgid "Create new branch"
> +msgstr "Créer nouvelle branche"
"Créer une nouvelle branche"
> +#: gitk:2368
> +msgid "Reset HEAD branch to here"
> +msgstr "Réinitialiser la branch HEAD vers cet état"
"branche" (missing "e").
> +#: gitk:2656
> +msgid ""
> +"\n"
> +"Gitk - a commit viewer for git\n"
> +"\n"
> +"Copyright © 2005-2008 Paul Mackerras\n"
> +"\n"
> +"Use and redistribute under the terms of the GNU General Public License"
> +msgstr ""
> +"\n"
> +"Gitk - visualisateur de commit pour git\n"
> +"\n"
> +"Copyright © 2005-2008 Paul Mackerras\n"
> +"\n"
> +"Utilisation et redistribution soumis aux termes de la GNU General
> Public License"
"soumises"
> +#: gitk:2693
> +msgid "<Left>, z, j\tGo back in history list"
> +msgstr "<Gauche>, z, j\tAvancer dans l'historique"
s/Avancer/Reculer/
> +#: gitk:2694
> +msgid "<Right>, x, l\tGo forward in history list"
> +msgstr "<Droite>, x, l\tRemonter dans l'historique"
s/Remonter/Avancer/
> +#: gitk:2713
> +msgid "/\t\tFocus the search box"
> +msgstr "/"
No idea?
> +#: gitk:3401
> +msgid "No such commit"
> +msgstr "commit inexistant"
s/commit/Commit/
> +#: gitk:3415
> +msgid "git gui blame: command failed:"
> +msgstr "git gui blame : échec de la commande"
Missing ending " :".
> +#: gitk:3446
> +#, tcl-format
> +msgid "Couldn't read merge head: %s"
> +msgstr "Impossible de lire le head de la fusion: %s"
s/fusion/fusion /
> +#: gitk:3479
> +#, tcl-format
> +msgid "Couldn't start git blame: %s"
> +msgstr "impossible de démarrer git blame : %s"
s/impossible/Impossible/
> +#: gitk:3679
> +msgid "References (space separated list):"
> +msgstr "Références (liste d'éléments séparer par des espaces) :"
s/séparer/séparés/
> +#: gitk:3684
> +msgid "All remote-tracking branches"
> +msgstr "Toutes les branches de suivie distante"
"Toutes les branches de suivi distantes"
> +#: gitk:3687
> +msgid "Committer:"
> +msgstr "Committer :"
"Commiter"
> +#: gitk:3690
> +msgid "Changes to Files:"
> +msgstr "Changements des fichiers"
Missing ":".
> +#: gitk:3695
> +msgid "Since:"
> +msgstr "Depuis :"
"De :"
> +# FIXME : traduction de "skip"
"éviter"?
> +#: gitk:3697
> +msgid "Limit and/or skip a number of revisions (positive integer):"
> +msgstr "Limiter et/ou sauter un certain nombre (entier positif) de révision :"
^
"Limiter et/ou éviter un certain nombre (entier positif) de révisions :"
> +#: gitk:3699
> +msgid "Number to skip:"
> +msgstr "Nombre à sauter :"
"éviter"?
> +#FIXME : traduction de "branch sides"
> +#: gitk:3702
#, fuzzy
> +msgid "Mark branch sides"
> +msgstr "Marquer le flanc des branches"
What about "côté"?
> +#: gitk:3837
> +msgid "-- criteria for selecting revisions"
> +msgstr "-- critère pour la séléction des révisions"
"sélection"
> +#: gitk:3955
> +msgid "Error in commit selection arguments:"
> +msgstr "Erreur dans les arguments de sélection des commits"
Missing ":".
> +#: gitk:4456 gitk:6303 gitk:8065 gitk:8080
> +msgid "Date"
> +msgstr "Date"
Should not be required.
> +#: gitk:4456 gitk:6303
> +msgid "CDate"
> +msgstr "CDate"
Ditto.
> +#: gitk:4605 gitk:4610
> +msgid "Descendant"
> +msgstr "Descendant"
Ditto.
> +#FIXME : plutôt traduire par "pas un descendant"
> +#: gitk:4606
#, fuzzy
> +msgid "Not descendant"
> +msgstr "Non descendant"
<...>
> +#FIXME : plutôt traduire par "pas un ancêtre"
> +#: gitk:4614
#, fuzzy
> +msgid "Not ancestor"
> +msgstr "Non ancêtre"
<...>
> +#: gitk:4904
> +msgid "Local changes checked in to index but not committed"
> +msgstr "Modifications locales enregistrées dans l'index mais non comittées"
"commitées"
> +#: gitk:4940
> +msgid "Local uncommitted changes, not checked in to index"
> +msgstr "Modifications locales non enregistrées dans l'index et non committées"
Ditto.
> +#: gitk:6822 gitk:6828 gitk:8058
> +msgid "Parent"
> +msgstr "Parent"
Should not be required.
> +#: gitk:7926
> +#, tcl-format
> +msgid "Revision %s is not in the current view"
> +msgstr "Révision %s n'est pas dans la vue courante"
s/Révision/ La révision/
> +#: gitk:8127
> +msgid "Detached head: can't reset"
> +msgstr "Head détachée: impossible de réinitialiser"
"détaché" instead of "détachée" is better FMPOV.
> +#: gitk:8236 gitk:8242
> +msgid "Skipping merge commit "
> +msgstr "Sauter le commit de la fusion "
"Éviter le commit de fusion "
> +#: gitk:8262 gitk:8265 gitk:8273 gitk:8283 gitk:8292
> +msgid "Commit "
> +msgstr "Commit "
Should not be required.
> +#: gitk:8274
> +msgid ""
> +" differs from\n"
> +" "
> +msgstr ""
> +"diffère de\n"
Miss the space at the begining?
> +#: gitk:8483
> +msgid "Error creating tag:"
> +msgstr "Erreur à la création du tag"
Missing ":".
> +#: gitk:8705
> +#, tcl-format
> +msgid "Commit %s is already included in branch %s -- really re-apply it?"
> +msgstr "Commit %s est déjà inclus dans la branche %s -- faut-il
> vraiment le ré-appliquer?"
Peut-être :
"ré-appliquer malgré tout ?"
> +#: gitk:8719
> +#, tcl-format
> +msgid ""
> +"Cherry-pick failed because of local changes to file '%s'.\n"
> +"Please commit, reset or stash your changes and try again."
> +msgstr "La cueillette a échouée à cause de modifications locale au
> fichier '%s'.\n"
s/locale/locales/
> +"Veuillez committer, reset ou stash vos changements et essayer de nouveau."
s/committer/commiter/
s/reset/réinitialiser/ (for consistency with this whole translation)
s/stash/stasher/
> +#: gitk:8741
> +msgid "No changes committed"
> +msgstr "Aucun changement committer"
"Aucun changement commité"
> +# FIXME: faut-il traduire working tree par répertoire de travail ou
> arbre de travail?
> +# FIXME : traduction de Soft/Hard/Mixed
> +#: gitk:8777
> +msgid "Soft: Leave working tree and index untouched"
> +msgstr "Douce: Laisse l'arbre de travail et l'index dans leur état courant"
"Léger : laisse les fichiers du work tree et l'index intacts"
> +#: gitk:8780
> +msgid "Mixed: Leave working tree untouched, reset index"
> +msgstr "Hybride: Laisse l'arbre de travail dans son état courant,
> réinitialise l'index"
"Hybride : ne touche pas aux fichiers du work tree, réinitialise l'index"
> +#: gitk:8783
> +msgid ""
> +"Hard: Reset working tree and index\n"
> +"(discard ALL local changes)"
> +msgstr ""
> +"Dur: Réinitialise l'arbre de travail et l'index\n"
"Réinitialise le work tree et l'index"
> +"(abandonne TOUS les changements locaux)"
<...>
> +#: gitk:8857
#, fuzzy
> +msgid "Checking out"
> +msgstr "Récupération"
<...>
> +#: gitk:9257
> +msgid ""
> +"Error reading commit topology information; branch and preceding/following "
> +"tag information will be incomplete."
> +msgstr ""
> +"Erreur à la lecture des informations sur la topology des commits. "
s/topology/topologie/
s/./ ;/
> +"Les informations sur les branches et les tags précédents/suivant "
s/L/l/
> +"seront incomplètes."
> +
> +#: gitk:10243
> +msgid "Tag"
> +msgstr "Tag"
Should not be required.
> +#: gitk:10243
> +msgid "Id"
> +msgstr "Id"
Ditto.
> +#: gitk:10308
> +msgid "B"
> +msgstr "B"
Ditto.
> +#: gitk:10311
> +msgid "I"
> +msgstr "I"
Ditto.
> +#FIXME : Traduction standard de "pane"?
> +#: gitk:10416
#, fuzzy
> +#, tcl-format
> +msgid "Maximum graph width (% of pane)"
> +msgstr "Longueur maximum du graphe (% du panneau)"
<...>
> +#: gitk:10441
> +msgid "Support per-file encodings"
> +msgstr "Support pour un encodage de caractère par fichier"
s/de caractère/ des caractères/
> +#: gitk:10449
> +msgid "Choose..."
> +msgstr "Choisir ..."
No space.
> +#: gitk:10475
> +msgid "Diff: hunk header"
> +msgstr "Différences : entête de l'extrait"
"diff : entête du hunk"
> +#: gitk:10477
> +msgid "diff hunk header"
> +msgstr "différences : entête de l'extrait"
Ditto.
> +#: gitk:10973
> +msgid ""
> +"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
> +" Gitk requires at least Tcl/Tk 8.4."
> +msgstr ""
> +"Désolé, gitk ne peut être exécuté par cette version de Tcl/Tk.\n"
> +" Gitk requiert Tcl/Tk version 8.4 ou supérieur."
s/par/avec/
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Potapov @ 2009-11-10 23:43 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091110T154312-665@post.gmane.org>
On Tue, Nov 10, 2009 at 02:54:43PM +0000, Dmitry Smirnov wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
> > And then if you really want
> > to have good and clean history, you need more than just a branch. You
> > should be able to amend your previous commits while you work on some
> > feature. With Git, it is trivial, you just run 'git rebase -i' and may
> > edit some previous commits, correct comments, squash fix-ups, etc...
> > How can you model that? By creating another branch and moving patches
> > to it by hands... Well, it is not very productive time spending, and
> > the cost of branch becomes even more prominent.
>
> This is a cool feature, but it contradicts to my understanding of VCS.
Yes, it may *appear* to contradict one of basic axioms of any VCS --
history is immutable, but here is the rule -- you never ever rebase or
change in any other way the public history of the official repository.
So once your commits hit the master branch, you should never try to
change them. This may be enforced through Git hooks.
However, when we speak about history of commits in your private feature
branch then no one cares about how you have arrived to these series of
patches more than in what order you have edited your files. What really
matters is the end result -- our patches are clean and easy to review.
Now, what is 'public' history or what is not. If no one has seen your
commits then it is clearly not public. If your commits are integrated
to the main development branch ('master') then they are clearly public.
However, many Git users have an international branch (often called as
proposed updates or 'pu' for short). The 'pu' branch is regularly
rewound, so no one should based their work on it. It is more for review
and additional testing of things that may not ready yet. When your
branch is merged to 'pu', it considered to be a fair play to re-write
your patches. However, you should do that in the way that will not
cause problems for people who review your changes.
Finally, when you re-write some branch using interactive rebase or
something else. Your old changes do not disappear immediately from your
repository. Git has 'reflog', which keeps _all_ commits in your local
repository for 30 days (or whatever time your choose). So, if you did
something wrong during rebase, you can always go back to the original
version, though you will hardly ever need that feature unless you do
something really stupid...
> BTW, as I undestood it, it is just a feature that can be implemented
> in any VCS (if you have access to its internals).
At least, not so simple. Have you heard about Mercurial? It is another
DVCS, which in many aspects similar to Git, but the underlying backend
is very different. I do not follow it very closely, but for a long time
it did not have 'rebase' and users were advised to use Mercurial Queues
instead, which is patch management system on top of Mercurial. While Git
has its own implementations of patch management systems on top of Git
such as StGit and recently TopGit, I do not think they come even close
when it comes to easy to use in everyday work, especially if you do not
want to be bothered with thinking about patch management.
Much power of Git and its flexibility comes from clean separation of the
underlying storage format and repository history. This makes 'rebase'
almost trivial in Git (unless you have merges in rebased history and you
try to preserve them), while with many other VCSes, those changes will
require significant changes to the underlying storage, which may be
difficult to implement safely and efficiently. The price that Git has to
pay for its flexibility is the need to run the garbage collection to
purge loose objects and compact all objects in one compressed pack...
Dmitry
^ 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
* 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
* 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: [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
* 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
* [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
* [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
* 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
* 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: 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: [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: [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 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 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 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: [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: [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: [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: 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
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