* Re: git on Cygwin: Not a valid object name HEAD
From: Mark Levedahl @ 2007-08-08 16:41 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Linus Torvalds, Git Mailing List, Shawn O. Pearce,
Sebastian Schuberth
In-Reply-To: <A2397231-1B81-4AD4-87CB-8FF8FB9BA89C@zib.de>
On 8/8/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> The bottom line for me is, git does not yet support Windows in a
> usable way for the organizations that I need to convince.
>
> Steffen
>
Have you considered jumping in to help on the msys git port Johannes
Schindelin is working? He has very generously offered to do
essentially everything except find bugs, the latter because he does
not actually use Windows so can't, and is clearly putting a great deal
of effort into this. A stable and complete Windows port may be much
closer than you think.
Mark
^ permalink raw reply
* Re: Template commit messages.
From: Jan Hudec @ 2007-08-08 16:24 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0708050532x2d9bfddw96a9428f4840b1fc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]
On Sun, Aug 05, 2007 at 13:32:48 +0100, Thomas Adam wrote:
> Am I correct in thinking that the new template messages that will be
> in the up and coming git release will alleviate an "annoyance" I've
> currently got with commit messages?
Reading the description below, I really doubt that. The templates are to
*add* stuff, not to remove it.
> Basically, I want a way of removing what is now, a long list of
> untracked files from the commit message before it hits the editor --
> I've looked at $GIT_DIR/.git/hooks/{pre,post}-commit as well as:
> $GIT_DIR/.git/hooks/commit-msg in the hopes I could add a sed command
> there to remove the list of files, and whilst the sed command worked
> fine on the command line, adding it to any of those files didn't.
Neither of this commands actually see the list. Because the list is *not*
part of the commit message. It is a comment, which is added just before the
editor is started and stripped right afterwards.
> Was this even the right approach? I didn't want to go messing with
> git-commit, frankly, so I am hoping that these new templates might
> just do the trick.
>
> You might ask why I've got such a large list of untracked files -- the
> reason is because I use the same repository to build files in, which
> themselves have no need to be added. And whilst I can catch some of
> these instances by using .gitignore, it's not enough since not all of
> the files have a common extension or anything. And whilst I realise
> the list of untracked file is just a friendly warning to me, I find it
> annoying and would rather it didn't appear at all if possible, since I
> know myself which files need explicitly adding. :)
a) The files don't need a common anything to be ignored with .gitignore. It
is a list of patterns, so you can list the names. Of course not suitable
if the names change or there is really a huge amount of them.
b) There is actually no problem in tracking files that match ignore pattern,
as it is only applied to files that don't appear in index. That gives you
the option to simply ignore '*' (and live with the minor annoyance that
you have to add -f to add command line -- git commit -a and git add -u
will include changes in tracked files all right).
c) Consider changing the build process to put the built files in
a subdirectory, if you have a chance. In my experience it not only helps
keeping track whether everything is versioned that should be, but also
helps navigating the tree (no uninteresting files interfering with shell
completion/cluttering file selection dialogs) and offer easy way to do
a clean build when you suspect the build might have screwed up somewhere
(just delete the directory).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-write-tree strangeness
From: Alex Riesen @ 2007-08-08 16:10 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <20070808154211.GA25015@dervierte>
On 8/8/07, Steven Walter <stevenrwalter@gmail.com> wrote:
> I'm importing a large repository from svn into git with a custom tool,
> and I noticed a strange issue with one of the commits.
>
> Upon investigating further, I found that when I ran "git-write-tree"
> followed immediately by "git-diff-index <tree>" I had differences. Does
> that mean that git-write-tree incorrectly recorded the index, or do I
> misunderstand things?
What kind of differences? Different sha1 of content?
I can't simply reproduce it.
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-08 15:51 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, Linus Torvalds, Git Mailing List, Shawn O. Pearce,
Sebastian Schuberth
In-Reply-To: <30e4a070708080650j5de7ee92p4acd7e82de7d9dff@mail.gmail.com>
On Aug 8, 2007, at 3:50 PM, Mark Levedahl wrote:
> On 8/7/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> I read your message and I just checked the most recent installer
>> of cygwin (screenshot attached).
>>
>> I see three choices I'm offered:
>> 1) the path to install;
>> 2) install for all or just me;
>> 3) choose the default text file type.
>>
>> I wouldn't call that deprecated, not even obsolenscent.
>
> Call it passively deprecated. there has been a lot of discussion about
> removing it, or at least hiding it behind the mount command and not
> offering it at all during installation. The objective of text mounts
> was noble, but it really is hard to automatically convert any
> occurrence of crlf->lf and lf->crlf everywhere it should be done but
> not where it should not be done. However, a lot of people use text
> mounts without trouble (or at least without complaining to the lists),
> so removing the option outright was thought too likely to cause an
> uproar.
That is what I'm facing now. A policy I need to handle tells
people explicitly to choose textmode to force cvs in cygwin to
do the right thing: converting lf->crlf->lf.
I'm not in a position to tell them not to follow this policy;
and I don't think it's reasonable to change the policy right away.
They have a lot of cvs working copies checked out and if they
switched from textmode to binmode now, they'd get crlf's on the
next commit, which they deliberately chose to avoid by using
textmode.
> So, consider that Cygwin is taking the "let it rot, remove it
> later" approach.
This may take years.
For me it would be easier if Cygwin (not I) told the world
very clearly: You must no longer use binary mounts. Consider
switching now, but you must switch until end of 2007. This
would make my life much more easier. I could tell that it's
not my fault and not git's fault, it's Cygwins decision to
drop support for textmode.
People might complain but I think they would understand.
Providing an option and letting people install software that is
not able to handle this option causes nothing but trouble. The
very least would be to only allow installing software that is
known to handle textmode. Or provide another mode that
guarantees that no conversion takes place and offers a larger
selection of packages.
> Anyone who has troubles is generally and not so
> gently encouraged to just use binary mounts. There are some known crlf
> problems, largely with bash/sh, pipes, forks, and redirection (of
> which git is a heavy user so git is a prime candidate to get into
> trouble) that are not being worked.
>
> For instance, when working on git-bundle.sh, I got bit by crlf
> conversions corrupting packfiles sent through a pipe on a system with
> pure binary mounts and CYGWIN=binmode. The cure to that bug is
> *removing* auto-crlf conversion from Cygwin.
Technically I agree. The problem is, textmode is not removed,
but appears as if it was supported (see installer).
I'm running out of options: git in cygwin appeared to work for
me, but it's not working in the context of the organization that
I need to deal with. I can't force them to switch to binary mode.
Other approaches to git on Windows are on their way, but, to my
understanding, are not mature enough. git-cvsserver doesn't provide
sufficient cvs functionality to be compatible with the needed
workflows.
The bottom line for me is, git does not yet support Windows in a
usable way for the organizations that I need to convince.
Steffen
^ permalink raw reply
* git-write-tree strangeness
From: Steven Walter @ 2007-08-08 15:42 UTC (permalink / raw)
To: git
I'm importing a large repository from svn into git with a custom tool,
and I noticed a strange issue with one of the commits.
Upon investigating further, I found that when I ran "git-write-tree"
followed immediately by "git-diff-index <tree>" I had differences. Does
that mean that git-write-tree incorrectly recorded the index, or do I
misunderstand things?
I just wanted to verify that I have at least some clue what is going on
before I dig too much deeper into this issue. I'm running
git-1.5.3-rc4; I'll see if it occurs with 1.5.2 and bisect if not.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* [PATCH] Documentation/user-manual.txt: fix a few omissions of gitlink commands.
From: David Kastrup @ 2007-08-08 15:34 UTC (permalink / raw)
To: git
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/user-manual.txt | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f89952a..4c9d69b 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1796,11 +1796,12 @@ taken from the message containing each patch.
Public git repositories
-----------------------
-Another way to submit changes to a project is to tell the maintainer of
-that project to pull the changes from your repository using git-pull[1].
-In the section "<<getting-updates-with-git-pull, Getting updates with
-git pull>>" we described this as a way to get updates from the "main"
-repository, but it works just as well in the other direction.
+Another way to submit changes to a project is to tell the maintainer
+of that project to pull the changes from your repository using
+gitlink:git-pull[1]. In the section "<<getting-updates-with-git-pull,
+Getting updates with git pull>>" we described this as a way to get
+updates from the "main" repository, but it works just as well in the
+other direction.
If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
@@ -2057,7 +2058,8 @@ $ cd work
Linus's tree will be stored in the remote branch named origin/master,
and can be updated using gitlink:git-fetch[1]; you can track other
public trees using gitlink:git-remote[1] to set up a "remote" and
-git-fetch[1] to keep them up-to-date; see <<repositories-and-branches>>.
+gitlink:git-fetch[1] to keep them up-to-date; see
+<<repositories-and-branches>>.
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
@@ -2512,9 +2514,9 @@ $ gitk origin..mywork &
And browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit --amend.
-The git-gui[1] command may also help as it allows you to individually
-select diff hunks for inclusion in the index (by right-clicking on the
-diff hunk and choosing "Stage Hunk for Commit").
+The gitlink:git-gui[1] command may also help as it allows you to
+individually select diff hunks for inclusion in the index (by
+right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:
--
1.5.3.rc4.43.gaf14
^ permalink raw reply related
* [PATCH] Further changes, thanks to <tp@lists.linux.it>
From: Paolo Ciarrocchi @ 2007-08-08 15:27 UTC (permalink / raw)
To: git
Further changes, thanks to <tp@lists.linux.it>
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
po/it.po | 130
++++++++++++++++++++++++++++++++------------------------------ 1 files
changed, 67 insertions(+), 63 deletions(-)
diff --git a/po/it.po b/po/it.po
index e87263e..1950b56 100644
--- a/po/it.po
+++ b/po/it.po
@@ -2,18 +2,21 @@
# Copyright (C) 2007 Shawn Pearce
# This file is distributed under the same license as the git-gui
package. # Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>, 2007
-#, fuzzy
+# , fuzzy
+# Michele Ballabio <barra_cuda@katamail.com>, 2007.
+#
+#
msgid ""
msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-07-31 19:24+0200\n"
-"PO-Revision-Date: 2007-08-01 19:10+0200\n"
-"Last-Translator: Michele Ballabio <barra_cuda@katamail.com>\n"
-"Language-Team: Italian\n"
+"PO-Revision-Date: 2007-08-08 17:21+0200\n"
+"Last-Translator: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>\n"
+"Language-Team: Italian <tp@lists.linux.it>\n"
"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
+"Content-Type: text/plain; charset=iso-8859-1\n"
+"Content-Transfer-Encoding: 8bit"
#: git-gui.sh:531
msgid "Cannot find git in PATH."
@@ -34,9 +37,9 @@ msgid ""
"\n"
"Assume '%s' is version 1.5.0?\n"
msgstr ""
-"La versione di GIT non può essere determinata.\n"
"\n"
-"%s sostiene che la versione è '%s'.\n"
"\n"
"%s richiede almeno Git 1.5.0 o superiore.\n"
"\n"
@@ -136,7 +139,7 @@ msgstr "Carattere principale"
#: git-gui.sh:1635
msgid "Diff/Console Font"
-msgstr "Carattere per confronti e terminale"
+msgstr "Caratteri per confronti e terminale"
#: git-gui.sh:1649
msgid "Repository"
@@ -156,11 +159,11 @@ msgstr "Commit"
#: git-gui.sh:1658 lib/merge.tcl:121 lib/merge.tcl:150
lib/merge.tcl:168 msgid "Merge"
-msgstr "Fondi (Merge)"
+msgstr "Fusione (Merge)"
#: git-gui.sh:1659
msgid "Fetch"
-msgstr "Recupera (Fetch)"
+msgstr "Preleva (Fetch)"
#: git-gui.sh:1660 git-gui.sh:2158 lib/transport.tcl:88
lib/transport.tcl:172 msgid "Push"
@@ -293,7 +296,7 @@ msgstr "Annulla modifiche"
#: git-gui.sh:1838 git-gui.sh:2148 git-gui.sh:2246
msgid "Sign Off"
-msgstr "Sign Off"
+msgstr "Approva"
#: git-gui.sh:1853
msgid "Local Merge..."
@@ -326,7 +329,7 @@ msgstr "Aiuto"
#: git-gui.sh:1938
msgid "Online Documentation"
-msgstr "Documentazione online"
+msgstr "Documentazione sul web"
#: git-gui.sh:2054
msgid "Current Branch:"
@@ -334,11 +337,11 @@ msgstr "Ramo attuale:"
#: git-gui.sh:2075
msgid "Staged Changes (Will Be Committed)"
-msgstr "Modifiche preparate (ne verrà effettuato il commit)"
#: git-gui.sh:2095
msgid "Unstaged Changes (Will Not Be Committed)"
-msgstr "Modifiche non preparate (non ne verrà effettuato il commit)"
#: git-gui.sh:2142
msgid "Stage Changed"
@@ -358,7 +361,7 @@ msgstr "Messaggio iniziale di commit corretto:"
#: git-gui.sh:2191
msgid "Amended Merge Commit Message:"
-msgstr "Messaggio di fusione corretto:"
+msgstr "Messaggio di commit per la fusione:"
#: git-gui.sh:2192
msgid "Merge Commit Message:"
@@ -386,11 +389,11 @@ msgstr "Applica/Inverti sezione"
#: git-gui.sh:2391
msgid "Decrease Font Size"
-msgstr "Diminuisci dimensione carattere"
+msgstr "Diminuisci dimensione caratteri "
#: git-gui.sh:2395
msgid "Increase Font Size"
-msgstr "Aumenta dimensione carattere"
+msgstr "Aumenta dimensione caratteri"
#: git-gui.sh:2400
msgid "Show Less Context"
@@ -398,7 +401,7 @@ msgstr "Mostra meno contesto"
#: git-gui.sh:2407
msgid "Show More Context"
-msgstr "Mostra più contesto"
#: git-gui.sh:2422
msgid "Unstage Hunk From Commit"
@@ -455,7 +458,7 @@ msgstr "Opzioni"
#: lib/branch_checkout.tcl:39 lib/branch_create.tcl:92
msgid "Fetch Tracking Branch"
-msgstr "Recupera ramo in 'tracking'"
+msgstr "Preleva ramo in 'tracking'"
#: lib/branch_checkout.tcl:44
msgid "Detach From Local Branch"
@@ -516,7 +519,7 @@ msgstr "Scegli un ramo in 'tracking'"
#: lib/branch_create.tcl:140
#, tcl-format
msgid "Tracking branch %s is not a branch in the remote repository."
-msgstr "Il ramo in 'tracking' %s non è un ramo nell'archivio remoto."
#: lib/branch_create.tcl:153 lib/branch_rename.tcl:86
msgid "Please supply a branch name."
@@ -525,7 +528,7 @@ msgstr "Devi dare un nome al ramo."
#: lib/branch_create.tcl:164 lib/branch_rename.tcl:106
#, tcl-format
msgid "'%s' is not an acceptable branch name."
-msgstr "'%s' non è utilizzabile come nome di ramo."
#: lib/branch_delete.tcl:15
msgid "Delete Branch"
@@ -558,7 +561,7 @@ msgid ""
"\n"
" Delete the selected branches?"
msgstr ""
-"Recuperare rami cancellati può essere complicato. \n"
"\n"
" Eliminare i rami selezionati?"
@@ -594,7 +597,7 @@ msgstr "Scegli un ramo da rinominare."
#: lib/branch_rename.tcl:96 lib/checkout_op.tcl:179
#, tcl-format
msgid "Branch '%s' already exists."
-msgstr "Il ramo '%s' esiste già"
#: lib/branch_rename.tcl:117
#, tcl-format
@@ -625,7 +628,7 @@ msgstr "Sfoglia"
#: lib/checkout_op.tcl:79
#, tcl-format
msgid "Fetching %s from %s"
-msgstr "Recupero %s da %s"
+msgstr "Prelevo %s da %s"
#: lib/checkout_op.tcl:140 lib/console.tcl:81 lib/database.tcl:31
msgid "Close"
@@ -643,15 +646,15 @@ msgid ""
"\n"
"It cannot fast-forward to %s.\n"
"A merge is required."
-msgstr "Il ramo '%s' esiste già.\n"
"\n"
-"Non può effettuare un 'fast-forward' a %s.\n"
"E' richiesta una fusione."
#: lib/checkout_op.tcl:220
#, tcl-format
msgid "Merge strategy '%s' not supported."
-msgstr "La strategia di fusione '%s' non è supportata."
#: lib/checkout_op.tcl:239
#, tcl-format
@@ -660,7 +663,7 @@ msgstr "Aggiornamento di '%s' fallito."
#: lib/checkout_op.tcl:251
msgid "Staging area (index) is already locked."
-msgstr "L'area di preparazione al commit (indice) è già bloccata."
#: lib/checkout_op.tcl:266
msgid ""
@@ -677,7 +680,7 @@ msgstr ""
"Bisogna effettuare una nuova analisi prima di poter cambiare il ramo "
"corrente.\n"
"\n"
-"La nuova analisi comincerà ora.\n"
#: lib/checkout_op.tcl:353
#, tcl-format
@@ -700,7 +703,7 @@ msgid ""
"If you wanted to be on a branch, create one now starting from 'This
Detached " "Checkout'."
msgstr ""
-"Non sei più su un ramo locale.\n"
"\n"
"Se volevi rimanere su un ramo, creane uno ora a partire da 'Questo
checkout " "staccato'."
@@ -708,7 +711,7 @@ msgstr ""
#: lib/checkout_op.tcl:478
#, tcl-format
msgid "Resetting '%s' to '%s' will lose the following commits:"
-msgstr "Ripristinare '%s' a '%s' comporterà la perdita dei seguenti
commit:"
#: lib/checkout_op.tcl:500
msgid "Recovering lost commits may not be easy."
@@ -735,11 +738,11 @@ msgid ""
msgstr ""
"Preparazione ramo corrente fallita.\n"
"\n"
-"Questa directory di lavoro è stata convertita solo parzialmente. I
tuoi file " "sono stati aggiornati correttamente, ma l'aggiornamento di
un file di Git ha " "prodotto degli errori.\n"
"\n"
-"Questo non sarebbe dovuto succedere. %s ora terminerà senza altre
azioni."
#: lib/choose_rev.tcl:53
msgid "This Detached Checkout"
@@ -772,7 +775,7 @@ msgstr "Nessuna revisione selezionata."
#: lib/choose_rev.tcl:346
msgid "Revision expression is empty."
-msgstr "L'espressione di revisione è vuota."
#: lib/commit.tcl:9
msgid ""
@@ -781,7 +784,7 @@ msgid ""
"You are about to create the initial commit. There is no commit before
this " "to amend.\n"
msgstr ""
-"Non c'è niente da correggere.\n"
"\n"
"Stai per creare il commit iniziale. Non esiste un commit precedente da
" "correggere.\n"
@@ -794,9 +797,9 @@ msgid ""
"completed. You cannot amend the prior commit unless you first abort
the " "current merge activity.\n"
msgstr ""
-"Non è possibile effettuare una correzione durante una fusione.\n"
"\n"
-"In questo momento stai effettuando una fusione che non è stata del
tutto " "completata. Non puoi correggere il commit precedente a meno che
prima tu non " "interrompa l'operazione di fusione in corso.\n"
@@ -806,7 +809,7 @@ msgstr "Errore durante il caricamento dei dati da
correggere:"
#: lib/commit.tcl:76
msgid "Unable to obtain your identity:"
-msgstr "Impossibile ottenere la tua identità:"
#: lib/commit.tcl:81
msgid "Invalid GIT_COMMITTER_IDENT:"
@@ -826,7 +829,7 @@ msgstr ""
"Un altro programma Git ha modificato questo repository dall'ultima
analisi. " "Bisogna effettuare una nuova analisi prima di poter creare
un nuovo commit.\n" "\n"
-"La nuova analisi comincerà ora.\n"
#: lib/commit.tcl:154
#, tcl-format
@@ -836,7 +839,7 @@ msgid ""
"File %s has merge conflicts. You must resolve them and stage the file
" "before committing.\n"
msgstr ""
-"Non è possibile effettuare il commit di file non sottoposti a
fusione.\n" "\n"
"Il file %s presenta dei conflitti. Devi risolverli e preparare il file
" "per il commit prima di effettuare questa azione.\n"
@@ -850,7 +853,7 @@ msgid ""
msgstr ""
"Stato di file %s sconosciuto.\n"
"\n"
-"Non si può effettuare il commit del file %s con questo programma.\n"
#: lib/commit.tcl:170
msgid ""
@@ -876,7 +879,7 @@ msgstr ""
"\n"
"Un buon messaggio di commit ha il seguente formato:\n"
"\n"
-"- Prima linea: descrivi in una frase ciò che hai fatto.\n"
"- Seconda linea: vuota.\n"
"- Terza linea: spiga a cosa serve la tua modifica.\n"
@@ -896,7 +899,7 @@ msgstr ""
"\n"
"Questo commit non modifica alcun file e non effettua alcuna
fusione.\n" "\n"
-"Si procederà subito ad una nuova analisi.\n"
#: lib/commit.tcl:286
msgid "No changes to commit."
@@ -980,10 +983,10 @@ msgstr ""
"\n"
"%s non ha modifiche.\n"
"\n"
-"La data di modifica di questo file è stata cambiata da un'altra "
-"applicazione, ma il contenuto del file è rimasto invariato.\n"
"\n"
-"Si procederà automaticamente ad una nuova analisi per trovare altri
file che " "potrebbero avere lo stesso stato."
#: lib/diff.tcl:97
@@ -996,11 +999,11 @@ msgstr "Errore nel caricamento delle differenze:"
#: lib/diff.tcl:278
msgid "Failed to unstage selected hunk."
-msgstr "La sezione scelta è ancora pronta per il commit."
#: lib/diff.tcl:285
msgid "Failed to stage selected hunk."
-msgstr "La sezione scelta non è ancora pronta per il commit."
#: lib/error.tcl:12 lib/error.tcl:102
msgid "error"
@@ -1057,7 +1060,7 @@ msgstr ""
"Un altro programma Git ha modificato questo repository dall'ultima
analisi." "Bisogna effettuare una nuova analisi prima di poter
effettuare una fusione.\n" "\n"
-"La nuova analisi comincerà ora.\n"
#: lib/merge.tcl:44
#, tcl-format
@@ -1090,10 +1093,10 @@ msgid ""
msgstr ""
"Sei nel mezzo di una modifica.\n"
"\n"
-"Il file %s è stato modificato.\n"
"\n"
"Bisogna completare il commit corrente prima di iniziare una fusione.
In " -"questo modo sarà più facile interrompere una fusione non
riuscita, nel caso " "ce ne fosse bisogno.\n"
#: lib/merge.tcl:106
@@ -1143,7 +1146,7 @@ msgid ""
msgstr ""
"Interrompere fusione?\n"
"\n"
-"L'interruzione della fusione corrente causerà la perdita di *TUTTE* le
" "modifiche non ancora presenti nei commit.\n"
"\n"
"Continuare con l'interruzione della fusione corrente?"
@@ -1158,7 +1161,7 @@ msgid ""
msgstr ""
"Annullare le modifiche?\n"
"\n"
-"L'annullamento delle modifiche causerà la perdita di *TUTTE* le "
"modifiche non ancora presenti nei commit.\n"
"\n"
"Continuare con l'annullamento delle modifiche correnti?"
@@ -1210,7 +1213,7 @@ msgstr "Riepilogo nei commit di fusione"
#: lib/option.tcl:189
msgid "Merge Verbosity"
-msgstr "Verbosità della fusione"
#: lib/option.tcl:190
msgid "Show Diffstat After Merge"
@@ -1222,7 +1225,7 @@ msgstr "Fidati delle date di modifica dei file"
#: lib/option.tcl:193
msgid "Prune Tracking Branches During Fetch"
-msgstr "Effettua potatura dei rami in 'tracking' durante il recupero"
+msgstr "Effettua potatura dei rami in 'tracking' durante il prelievo"
#: lib/option.tcl:194
msgid "Match Tracking Branches"
@@ -1254,7 +1257,7 @@ msgstr "Remoto:"
#: lib/remote_branch_delete.tcl:66 lib/transport.tcl:133
msgid "Arbitrary URL:"
-msgstr ""
+msgstr "URL arbitratio:"
#: lib/remote_branch_delete.tcl:84
msgid "Branches"
@@ -1282,12 +1285,12 @@ msgid ""
"One or more of the merge tests failed because you have not fetched the
" "necessary commits. Try fetching from %s first."
msgstr ""
-"Una o più verifiche di fusione sono fallite perché mancano i commit "
-"necessari. Prova prima a recuperarli da %s."
+"necessari. Prova prima a prelevarli da %s."
#: lib/remote_branch_delete.tcl:207
msgid "Please select one or more branches to delete."
-msgstr "Scegli uno o più rami da cancellare."
#: lib/remote_branch_delete.tcl:216
msgid ""
@@ -1295,7 +1298,7 @@ msgid ""
"\n"
"Delete the selected branches?"
msgstr ""
-"Recuperare rami cancellati è difficile.\n"
"\n"
"Cancellare i rami selezionati?"
@@ -1316,7 +1319,7 @@ msgstr "Analisi in corso %s..."
#: lib/remote.tcl:162
#, tcl-format
msgid "Fetch from %s..."
-msgstr "Recupera da %s..."
+msgstr "Preleva da %s..."
#: lib/remote.tcl:172
#, tcl-format
@@ -1344,7 +1347,7 @@ msgstr "%s ... %i di %i %s (%2i%%)"
#: lib/transport.tcl:7
#, tcl-format
msgid "Fetching new changes from %s"
-msgstr "Recupero nuove modifiche da %s"
+msgstr "Prelevo nuove modifiche da %s"
#: lib/transport.tcl:19
#, tcl-format
@@ -1384,3 +1387,4 @@ msgstr "Utilizza 'thin pack' (per connessioni
lente)" #: lib/transport.tcl:159
msgid "Include tags"
msgstr "Includi etichette"
+
--
1.5.3.rc3.24.g83b3d
^ permalink raw reply related
* [PATCH] patch open-editor-at-top-line
From: Dmitry Monakhov @ 2007-08-08 15:11 UTC (permalink / raw)
Cc: git
When i use "guilt series -e" for realy long series file
it is not confortable always search current top patch line.
IMHO editor have to start at the top patch automaticaly.
Btw: open_editor_at_line may be useful in other places
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
---
guilt | 34 ++++++++++++++++++++++++++++++++++
guilt-series | 5 +++--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/guilt b/guilt
index bc51472..66c3078 100755
--- a/guilt
+++ b/guilt
@@ -287,6 +287,18 @@ series_insert_patch()
mv "$series.tmp" "$series"
}
+# usage: line=get_series_top_line
+# return top patch line number in series
+get_series_top_line()
+{
+ awk -v top="`get_top`" -v new="$1" \
+ 'BEGIN{if (top == "") ; iter=0;}
+ {
+ iter=iter+1;
+ if (top != "" && top == $0) {print iter; exit};
+ }' "$series"
+}
+
# usage: series_remove_patch <patchname>
series_remove_patch()
{
@@ -508,6 +520,28 @@ __refresh_patch()
push_patch "$1"
}
+# usage: open_editor_at_line <editor> <filename> <line>
+# try to open editor with "filename"" at "line"
+# different editors use different syntax for start line parameter
+# so the only thing we can do is just compare with known editiors
+# and ignore line if editor is unknown.
+open_editor_at_line()
+{
+ editor_name=$1
+ file_name=$2
+ line_pos=$3
+ case "$editor_name" in
+ "vi" |"vim")
+ $editor_name $file_name +$line_pos;;
+ "emacs")
+ $editor_name $file_mame:$line_pos;;
+ *)
+ # editor is unknown, line_pos is just ignored
+ $editor_name $file_name;;
+ esac
+ return $?
+}
+
# usage: munge_hash_range <hash range>
#
# this means:
diff --git a/guilt-series b/guilt-series
index 9c34a08..5a9ebbc 100755
--- a/guilt-series
+++ b/guilt-series
@@ -21,8 +21,9 @@ do
shift
done
-if [ ! -z "$edit" ]; then
- $editor "$series"
+if [ ! -z "$edit" ]; then
+ top_line=`get_series_top_line`
+ open_editor_at_line $editor "$series" "$top_line"
elif [ ! -z "$gui" ]; then
[ -z "`get_top`" ] && die "No patches applied."
bottom=`head -1 $applied | cut -d: -f1`
--
1.5.2.2
^ permalink raw reply related
* [PATCH] git-p4: Fix git-p4 submit to include only changed files in the perforce submit template.
From: Simon Hausmann @ 2007-08-08 15:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Marius Storm-Olsen
Parse the files section in the "p4 change -o" output and remove lines with file changes in unrelated depot paths.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
---
contrib/fast-import/git-p4 | 36 ++++++++++++++++++++++++++++++------
1 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3cbb2da..805d632 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -390,6 +390,30 @@ class P4Submit(Command):
return result
+ def prepareSubmitTemplate(self):
+ # remove lines in the Files section that show changes to files outside the depot path we're committing into
+ template = ""
+ inFilesSection = False
+ for line in read_pipe_lines("p4 change -o"):
+ if inFilesSection:
+ if line.startswith("\t"):
+ # path starts and ends with a tab
+ path = line[1:]
+ lastTab = path.rfind("\t")
+ if lastTab != -1:
+ path = path[:lastTab]
+ if not path.startswith(self.depotPath):
+ continue
+ else:
+ inFilesSection = False
+ else:
+ if line.startswith("Files:"):
+ inFilesSection = True
+
+ template += line
+
+ return template
+
def applyCommit(self, id):
if self.directSubmit:
print "Applying local change in working directory/index"
@@ -467,7 +491,7 @@ class P4Submit(Command):
logMessage = logMessage.replace("\n", "\r\n")
logMessage = logMessage.strip()
- template = read_pipe("p4 change -o")
+ template = self.prepareSubmitTemplate()
if self.interactive:
submitTemplate = self.prepareLogMessage(template, logMessage)
@@ -558,24 +582,24 @@ class P4Submit(Command):
return False
[upstream, settings] = findUpstreamBranchPoint()
- depotPath = settings['depot-paths'][0]
+ self.depotPath = settings['depot-paths'][0]
if len(self.origin) == 0:
self.origin = upstream
if self.verbose:
print "Origin branch is " + self.origin
- if len(depotPath) == 0:
+ if len(self.depotPath) == 0:
print "Internal error: cannot locate perforce depot path from existing branches"
sys.exit(128)
- self.clientPath = p4Where(depotPath)
+ self.clientPath = p4Where(self.depotPath)
if len(self.clientPath) == 0:
- print "Error: Cannot locate perforce checkout of %s in client view" % depotPath
+ print "Error: Cannot locate perforce checkout of %s in client view" % self.depotPath
sys.exit(128)
- print "Perforce checkout for depot path %s located at %s" % (depotPath, self.clientPath)
+ print "Perforce checkout for depot path %s located at %s" % (self.depotPath, self.clientPath)
self.oldWorkingDirectory = os.getcwd()
if self.directSubmit:
--
1.5.3.rc3.91.g5c75
^ permalink raw reply related
* git-cvsserver and change=T
From: Donald Munro @ 2007-08-08 14:45 UTC (permalink / raw)
To: git
git-cvsserver (git v1.5.2.4) seems to be failing on cvs checkout with
the following message:
Died at /usr/bin/git-cvsserver line 2534, <FILELIST> chunk 24.
Issuing rollback() for database handle being DESTROY'd without
explicit disconnect(), <FILELIST> line 24.
The code around 2534 is:
my $filepipe = open(FILELIST, '-|', 'git-diff-tree', '-z', '-r',
$lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree :
$!");
........
my ($mode, $hash, $change) = ($1, $2, $3);
............
if ( $change eq "D" )
.......
elsif ( $change eq "M" )
........
elsif ( $change eq "A" )
........
else
{
$log->warn("UNKNOWN FILE CHANGE mode=$mode,
hash=$hash, change=$change, name=$name");
die;
}
^ permalink raw reply
* Re: [PATCH 1/2] merge-recursive: sometimes, d/f conflict is not an issue
From: Gerrit Pape @ 2007-08-08 14:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707171812490.14781@racer.site>
On Tue, Jul 17, 2007 at 06:13:12PM +0100, Johannes Schindelin wrote:
> When a merge has a d/f conflict on a path which was not touched
> between the merge base(s) and the remote HEAD, and the index and
> HEAD contain the same version for that path (even if empty), it
> is not really a conflict.
Hi, this patch solves the reported problem fine, and it didn't break
anything for me yet. Can this still be considered for 1.5.3?
Thanks, Gerrit.
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Mark Levedahl @ 2007-08-08 13:50 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Linus Torvalds, Git Mailing List, Shawn O. Pearce,
Sebastian Schuberth
In-Reply-To: <07BB2580-4406-496F-8ACE-F6A03D1687BE@zib.de>
On 8/7/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> I read your message and I just checked the most recent installer
> of cygwin (screenshot attached).
>
> I see three choices I'm offered:
> 1) the path to install;
> 2) install for all or just me;
> 3) choose the default text file type.
>
> I wouldn't call that deprecated, not even obsolenscent.
Call it passively deprecated. there has been a lot of discussion about
removing it, or at least hiding it behind the mount command and not
offering it at all during installation. The objective of text mounts
was noble, but it really is hard to automatically convert any
occurrence of crlf->lf and lf->crlf everywhere it should be done but
not where it should not be done. However, a lot of people use text
mounts without trouble (or at least without complaining to the lists),
so removing the option outright was thought too likely to cause an
uproar. So, consider that Cygwin is taking the "let it rot, remove it
later" approach. Anyone who has troubles is generally and not so
gently encouraged to just use binary mounts. There are some known crlf
problems, largely with bash/sh, pipes, forks, and redirection (of
which git is a heavy user so git is a prime candidate to get into
trouble) that are not being worked.
For instance, when working on git-bundle.sh, I got bit by crlf
conversions corrupting packfiles sent through a pipe on a system with
pure binary mounts and CYGWIN=binmode. The cure to that bug is
*removing* auto-crlf conversion from Cygwin.
Mark
^ permalink raw reply
* git-svn: commit author x commit committer issue
From: Richard MUSIL @ 2007-08-08 13:46 UTC (permalink / raw)
To: git
Normally, when patch is applied, git distinguishes commit author and
commit committer (relying on info from patch).
However, after the patches are committed to svn repository using:
git-svn dcommit
author and committer data are set to same values (or at least time and
date, I cannot verify it for names).
I wonder if there is any reason for this behavior, because I would
definitely like to keep original commit info (which came from patch) in
my git repository.
Richard Musil
(please cc: me)
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-08-08 11:39 UTC (permalink / raw)
To: Eran Tromer; +Cc: Junio C Hamano, git
In-Reply-To: <46B91F4E.8050008@tromer.org>
On Tue, Aug 07, 2007 at 09:41:34PM -0400, Eran Tromer wrote:
> On 2007-08-07 04:51, Sven Verdoolaege wrote:
> > Surely this is a lot worse than occasionally committing something you
> > didn't plan to commit, and only if you are performing a known "dangerous"
> > operation.
> >
> Are you saying that
> $ git reset --hard HEAD && vi foo && git commit -a
> is a "known dangerous" operation that can record corrupted content even
> though you didn't touch it?
I'm only saying that "git commit -a" will commit anything that has been
modified, so you have to be careful when using it and it just so happens
that git reset may leave submodules modified. This should probably
be documented.
And I agree with you that this is not ideal (personally, I'd want
all checked-out submodules to get updated automatically), but it's
certainly better than your earlier proposal.
> So, when I'm sure all the edits I did in the work tree are fine, how
> *do* I safely make a commit without manually inspecting the changed
> files list, or manually listing the changed files for "git add", or
> manually running "git submodule update", or manually checking whether
> there happens to be some submodules in this project, some other such
> cumbersome measure?
If you've ever done a "git submodule update" in the project, you should
know that there are submodules and if you haven't then there are no
checked-out submodules that can get out of sync.
If you're talking about tools, then they should indeed be extra careful.
[another proposal]
>
> Does this sound reasonable?
I'll leave it to others to comment on that one.
skimo
^ permalink raw reply
* Re: resumable git-clone?
From: Nguyen Thai Ngoc Duy @ 2007-08-08 11:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20070808035946.GP9527@spearce.org>
On 8/7/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > I was on a crappy connection and it was frustrated seeing git-clone
> > reached 80% then failed, then started over again. Can we support
> > resumable git-clone at some level? I think we could split into several
> > small packs, keep fetched ones, just get missing packs until we have
> > all.
>
> This is uh, difficult over the native git protocol. The problem
> is the native protocol negotiates what the client already has and
> what it needs by comparing sets of commits. If the client says
> "I have commit X" then the server assumes it has not only commit
> X _but also every object reachable from it_.
>
> Now packfiles are organized to place commits at the front of the
> packfile. So a truncated download will give the client a whole
> host of commits, like maybe all of them, but none of the trees
> or blobs associated with them as those come behind the commits.
> Worse, the commits are sorted most recent to least recent. So if
> the client claims he has the very first commit he received, that
> is currently an assertion that he has the entire repository.
I'm thinking about things like bisect and use it to cut the history
into parts. Clients only use completed parts. Uncompleted parts are
thrown away. So if users think they cannot suffer too big packs, they
tell server to send smaller (and less efficient) packs. Anyway I don't
have deep knowledge of Git internals, my opion could be completely
wrong.
--
Duy
^ permalink raw reply
* Re: Submodules
From: Sven Verdoolaege @ 2007-08-08 10:41 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Johannes Schindelin, git
In-Reply-To: <a1bbc6950708071631w5d232e92gd0fa27158b27b5c3@mail.gmail.com>
On Tue, Aug 07, 2007 at 04:31:57PM -0700, Dmitry Kakurin wrote:
> This is exactly the level of details I'm talking about:
> * how come sumbodules are not initialized when I do a clone of super.
See you second question.
> I expect to be able to build super after I clone it. Is there a new
> (undocumented) flag to clone?
Not (yet). Right now, you have to do
git submodule init
git submodule update
after you clone to fetch and check-out all (first-level) submodules.
> * is it OK to *not* init a submodule? will super become unhappy? Can I
> do commits to super in this case?
Yes. No. Yes.
In fact, only the "git submodule" subcommand are affected by a
"git submodule init". Doing a "git submodule update" will actually
check out the submodules and from then on, the HEAD of this checked-out
submodule will be considered the content of the submodule in
the working tree of the supermodule.
> * why submodules should be listed in 2 places: in .submodules and in
> super/.git/config?
It only has to be specified in .git/config.
The value in .gitmodules (if present) is used by "git submodule init"
as a default value for the one in .git/config.
skimo
^ permalink raw reply
* Re: Submodules
From: Sven Verdoolaege @ 2007-08-08 10:27 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Johannes Schindelin, git
In-Reply-To: <a1bbc6950708071610g4ea4d874t458cec14a444b519@mail.gmail.com>
On Tue, Aug 07, 2007 at 04:10:38PM -0700, Dmitry Kakurin wrote:
> Yeah, I've already went thru these. But I want (much) more details.
> I can ask a bunch of random questions on this list, like:
>
> * Why after 'submodule update' it becomes detached, what if I want it
> to stay on certain branch?
You'd need to have a way to specify which branch you want to have updated.
There was some discussion about this some time ago and the general
conclusion was that a detached HEAD was the best solution.
> * How do I control which branches are fetched?
Currently, you can't.
> * What if I do 'commit -a' standing in /super, will /super/submodule
> commit as well?
No.
> * What if I'm standing in /super/submodule and do 'commit -a'? Will
> super notice it in any way?
Any commit in the submodule will be seen as a "change" to the submodule
from the perspective of the supermodule.
skimo
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Jakub Narebski @ 2007-08-08 9:58 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708081022440.14781@racer.site>
Johannes Schindelin wrote:
> On Wed, 8 Aug 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> So I have the slight suspicion that all this will accomplish is "shut the
>>> darn thing up", and old-timers will have a harder time, since they no
>>> longer spot easily when they did a Dumb Thing and left the index out of
>>> sync.
>>
>> The hardest hit would be old-timers who try to be friendly by
>> trying to help new people, who has much less chance to notice
>> and report these much less prominent warnings, over e-mail or
>> irc.
>
> True. It is even bigger than that annoyance to people who know how git
> works.
Perhaps config variable, by default old behaviour if not set?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Johannes Schindelin @ 2007-08-08 9:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Steven Grimm, Jean-Fran?ois Veillette,
Matthieu Moy, git
In-Reply-To: <7v3ayu5scj.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 8 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So I have the slight suspicion that all this will accomplish is "shut the
> > darn thing up", and old-timers will have a harder time, since they no
> > longer spot easily when they did a Dumb Thing and left the index out of
> > sync.
>
> The hardest hit would be old-timers who try to be friendly by
> trying to help new people, who has much less chance to notice
> and report these much less prominent warnings, over e-mail or
> irc.
True. It is even bigger than that annoyance to people who know how git
works.
Ciao,
Dscho
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Karl Hasselström @ 2007-08-08 9:20 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <1186549433.2112.34.camel@dv>
On 2007-08-08 01:03:53 -0400, Pavel Roskin wrote:
> On Tue, 2007-08-07 at 04:20 +0200, Karl Hasselström wrote:
>
> > So I finally got my act together and published a 'pu'-like branch
> > for StGIT. Get it at git://repo.or.cz/stgit/kha.git; gitweb at
> > http://repo.or.cz/w/stgit/kha.git.
>
> Just a word of warning. This version converts all branches to
> version 3, so that the standard StGIT won't work with them anymore.
I believe I said (or tried to say) as much towards the end of my mail.
Thanks for trying it out though! It seems my evil master plan is
working. :-)
> Also, "stg import" commits the patch, which seems wrong to me.
Hmm, I hadn't noticed. That would be an unintended side-effect of the
DAG patches, presumably. I'll look into it tonight.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: resumable git-clone?
From: Johannes Schindelin @ 2007-08-08 9:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <20070808035946.GP9527@spearce.org>
Hi,
On Tue, 7 Aug 2007, Shawn O. Pearce wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > I was on a crappy connection and it was frustrated seeing git-clone
> > reached 80% then failed, then started over again. Can we support
> > resumable git-clone at some level? I think we could split into several
> > small packs, keep fetched ones, just get missing packs until we have
> > all.
>
> This is uh, difficult over the native git protocol. The problem
> is the native protocol negotiates what the client already has and
> what it needs by comparing sets of commits. If the client says
> "I have commit X" then the server assumes it has not only commit
> X _but also every object reachable from it_.
Now here is a thought: after an interrupted fetch, you could do a
(possibly expensive) analysis what commits are dangling, but do not
contain broken links in their _complete_ history. Then mark them as
(temporary) refs.
Another possibility should be to start with a shallow clone, and to deepen
it. However, IIRC there have been complaints that that does not work, and
it was not my itch, so I did not come around to scratch it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: David Kastrup @ 2007-08-08 9:13 UTC (permalink / raw)
To: git
In-Reply-To: <7v3ayu5scj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So I have the slight suspicion that all this will accomplish is "shut the
>> darn thing up", and old-timers will have a harder time, since they no
>> longer spot easily when they did a Dumb Thing and left the index out of
>> sync.
>
> The hardest hit would be old-timers who try to be friendly by
> trying to help new people, who has much less chance to notice
> and report these much less prominent warnings, over e-mail or
> irc.
"Dude, you got a stale index hanging out of your trousers."
I find it ridiculous to parade local problems in patches sent out to
the world rather than fixing them, so that old-timers have a chance to
get karma points.
Really: if stale indexes are considered a problem, git should silently
mark the staleness in the file, and the next time (or after three more
times or whatever) the index is used, it is silently regenerated.
Old-timers can get an option disabling this so that they can proud
themselves on cleaning up after themselves consciously, but for the
normal user, this is a bother he can do without.
--
David Kastrup
^ permalink raw reply
* Re: git-svn: Finding the svn-URL of the current branch in git
From: Junio C Hamano @ 2007-08-08 9:13 UTC (permalink / raw)
To: Matthias Kleine; +Cc: git
In-Reply-To: <f9c0d1$7md$1@sea.gmane.org>
Matthias Kleine <matthias_kleine@gmx.de> writes:
> Peter Baumann wrote:
>>
>> I had this situation, too.
>>
>>
>> a = svn branch 'a'
>> m b = svn branch 'b' (in my case, it was trunk)
>> / \ m = a merge of branch 'a' and 'b', not yet commited to svn
>> a b
>>
>> So trying to dcommit m, git svn can't figure out on which branch, as 'a'
>> and 'b' are both reachable. I had to use a graft file to lose one of the
>> parents, which let git-svn commit to SVN.
>
> You're right, both 'a' and 'b' are reachable from 'm'. But if I got
> it right 'm' also contains information as to which one is the first
> parent and thereby which branch we're on. So wouldn't it be enough, if
> git-svn automatically chose the first parent (using log
> --first-parent)?
Parents' order and which branch you are on may not have anything
to do with each other. Somebody else may have pulled a while on
b, and you might have pulled from him the merge he created by
doing so while you are on branch a.
^ permalink raw reply
* Re: git-svn: Finding the svn-URL of the current branch in git
From: Matthias Kleine @ 2007-08-08 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <20070807205543.GB27703@xp.machine.xx>
Peter Baumann wrote:
>
> I had this situation, too.
>
>
> a = svn branch 'a'
> m b = svn branch 'b' (in my case, it was trunk)
> / \ m = a merge of branch 'a' and 'b', not yet commited to svn
> a b
>
> So trying to dcommit m, git svn can't figure out on which branch, as 'a'
> and 'b' are both reachable. I had to use a graft file to lose one of the
> parents, which let git-svn commit to SVN.
You're right, both 'a' and 'b' are reachable from 'm'. But if I got it
right 'm' also contains information as to which one is the first parent
and thereby which branch we're on. So wouldn't it be enough, if git-svn
automatically chose the first parent (using log --first-parent)?
>
> So for a short fix to get the work done, you could create a graft file
> where you fake m to only have one parent.
>
Thanks for that one. I didn't know about the grafts file before.
Matthias
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-08 8:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Steven Grimm, Jean-Fran?ois Veillette,
Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0708080923580.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So I have the slight suspicion that all this will accomplish is "shut the
> darn thing up", and old-timers will have a harder time, since they no
> longer spot easily when they did a Dumb Thing and left the index out of
> sync.
The hardest hit would be old-timers who try to be friendly by
trying to help new people, who has much less chance to notice
and report these much less prominent warnings, over e-mail or
irc.
^ 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