* [PATCH] rebase -i: call editor just once for a multi-squash
From: Johannes Schindelin @ 2007-07-21 17:09 UTC (permalink / raw)
To: skimo; +Cc: git, gitster
In-Reply-To: <20070713103025.GR1528MdfPADPa@greensroom.kotnet.org>
Sometimes you want to squash more than two commits. Before this patch,
the editor was fired up for each squash command. Now the editor is
started only with the last squash command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 13 Jul 2007, Sven Verdoolaege wrote:
> If I squash a whole series of commits, how do I prevent
> git-rebase -i from firing up an editor after every single commit
> in the series?
By applying this patch ;-)
git-rebase--interactive.sh | 56 +++++++++++++++++++++++++++++++++-------
t/t3404-rebase-interactive.sh | 9 ++++++
2 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a2d4d09..579a45e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -19,6 +19,8 @@ require_work_tree
DOTEST="$GIT_DIR/.dotest-merge"
TODO="$DOTEST"/todo
DONE="$DOTEST"/done
+MSG="$DOTEST"/message
+SQUASH_MSG="$DOTEST"/message-squash
REWRITTEN="$DOTEST"/rewritten
PRESERVE_MERGES=
STRATEGY=
@@ -158,6 +160,38 @@ pick_one_preserving_merges () {
esac
}
+nth_string () {
+ case "$1" in
+ *1[0-9]|*[04-9]) echo "$1"th;;
+ *1) echo "$1"st;;
+ *2) echo "$1"nd;;
+ *3) echo "$1"rd;;
+ esac
+}
+
+make_squash_message () {
+ if [ -f "$SQUASH_MSG" ]; then
+ COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
+ < "$SQUASH_MSG" | tail -n 1)+1))
+ echo "# This is a combination of $COUNT commits."
+ sed -n "2,\$p" < "$SQUASH_MSG"
+ else
+ COUNT=2
+ echo "# This is a combination of two commits."
+ echo "# The first commit's message is:"
+ echo
+ git cat-file commit HEAD | sed -e '1,/^$/d'
+ echo
+ fi
+ echo "# This is the $(nth_string $COUNT) commit message:"
+ echo
+ git cat-file commit $1 | sed -e '1,/^$/d'
+}
+
+peek_next_command () {
+ sed -n "1s/ .*$//p" < "$TODO"
+}
+
do_next () {
test -f "$DOTEST"/message && rm "$DOTEST"/message
test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
@@ -194,17 +228,19 @@ do_next () {
die "Cannot 'squash' without a previous commit"
mark_action_done
- MSG="$DOTEST"/message
- echo "# This is a combination of two commits." > "$MSG"
- echo "# The first commit's message is:" >> "$MSG"
- echo >> "$MSG"
- git cat-file commit HEAD | sed -e '1,/^$/d' >> "$MSG"
- echo >> "$MSG"
+ make_squash_message $sha1 > "$MSG"
+ case "$(peek_next_command)" in
+ squash)
+ EDIT_COMMIT=
+ cp "$MSG" "$SQUASH_MSG"
+ ;;
+ *)
+ EDIT_COMMIT=-e
+ test -f "$SQUASH_MSG" && rm "$SQUASH_MSG"
+ esac
+
failed=f
pick_one -n $sha1 || failed=t
- echo "# And this is the 2nd commit message:" >> "$MSG"
- echo >> "$MSG"
- git cat-file commit $sha1 | sed -e '1,/^$/d' >> "$MSG"
git reset --soft HEAD^
author_script=$(get_author_ident_from_commit $sha1)
echo "$author_script" > "$DOTEST"/author-script
@@ -213,7 +249,7 @@ do_next () {
# This is like --amend, but with a different message
eval "$author_script"
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
- git commit -F "$MSG" -e
+ git commit -F "$MSG" $EDIT_COMMIT
;;
t)
cp "$MSG" "$GIT_DIR"/MERGE_MSG
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 43a6675..8206436 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -65,6 +65,7 @@ cat > fake-editor.sh << EOF
#!/bin/sh
test "\$1" = .git/COMMIT_EDITMSG && {
test -z "\$FAKE_COMMIT_MESSAGE" || echo "\$FAKE_COMMIT_MESSAGE" > "\$1"
+ test -z "\$FAKE_COMMIT_AMEND" || echo "\$FAKE_COMMIT_AMEND" >> "\$1"
exit
}
test -z "\$FAKE_LINES" && exit
@@ -212,4 +213,12 @@ test_expect_success 'verbose flag is heeded, even after --continue' '
grep "^ file1 | 2 +-$" output
'
+test_expect_success 'multi-squash only fires up editor once' '
+ base=$(git rev-parse HEAD~4) &&
+ FAKE_COMMIT_AMEND="ONCE" FAKE_LINES="1 squash 2 squash 3 squash 4" \
+ git rebase -i $base &&
+ test $base = $(git rev-parse HEAD^) &&
+ test 1 = $(git show | grep ONCE | wc -l)
+'
+
test_done
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* Re: Volume of commits
From: Johannes Schindelin @ 2007-07-21 17:12 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20070713103025.GR1528MdfPADPa@greensroom.kotnet.org>
Hi,
On Fri, 13 Jul 2007, Sven Verdoolaege wrote:
> [...] if I do the following:
>
> bash-3.00$ git init
> Initialized empty Git repository in .git/
> bash-3.00$ for i in a b c; do touch $i; git add $i; git commit -m $i -a; done
> Created initial commit 19a8485: a
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 a
> Created commit 4a00f85: b
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 b
> Created commit defe3b5: c
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 c
> bash-3.00$ git rebase -i HEAD~2
>
> and then replace the second "pick" by "squash", then I get presented
> a commit message that contains the commit message of "c" twice and
> after the rebase there are still three commits in the history.
> This is with git version 1.5.3.rc1.10.gae1ae
> (on top of v1.5.3-rc1-4-gaf83bed).
It no longer reproduces, which probably means that I inadvertently fixed
the bug ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-21 17:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707210832180.27249@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 21 Jul 2007, David Kastrup wrote:
>
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>> > Of course, it seldom matters, but basically, you should test a directory
>> > structure that has the files
>> >
>> > dir.c
>> > dir/test
>> >
>> > in it, and the "dir" directory should always sort _after_ "dir.c".
>> >
>> > And yes, having the index entry with a '/' at the end would handle
>> > that automatically.
>>
>> You completely lost me here. I guess I'll be able to pick this up
>> only after investing considerable more time into the data structures.
[Basic explanation about git sort order and trees sorting as tree/ in
order to be in the right sort order for a prefix]
Ok, I could not have figured this out on my own. Are there any design
documents or does one just have to pester the list?
> So the basic issue is that not only does git obviously think that only
> content matters, but it describes it with a single SHA1.
>
> That's not an issue at all for a single file, but if you want to describe
> *multiple* files with a single SHA1 (which git obviously very much wants
> to do), the way you generate the SHA1 matters a lot.
>
> In particular, the order.
>
> So git is very very strict about the ordering of tree structures. A tree
> structure is not just a random list of
>
> <ASCII mode> + <space> + <filename> + <NUL> + <SHA1>
Ok.
> So git filenames are very much a "stream of bytes", not anything
> else. And they need to sort 100% reliably, always the same way, and
> never with any localized meaning.
There is some utf-8/Unicode trouble to be expected in connection with
that eventually: some, but not all operating and/or file systems
canonicalize file names, replacing accented letters by a combining
accent and the letter. But that's beside the point.
> And, partly because it seemed most natural, and partly for
> historical reasons, the way git sorts filenames is by sorting by
> *pathname*. So if you have three files named
>
> a.c
> a/c
> abc
>
> then they sort in that exact order, and no other! They sort as a
> "memcmp" in the full pathname, and that's really nice when you see
> whole collections of files, and you know the list is globally
> sorted.
It is amusing that my description of git having no external concept of
directories except as an expedience for representing slashes in
filenames was much closer to the mark that I would have expected.
> So that "global pathname sorting" has nice properties, and it seems
> "obvious", but it means that because git actually *encodes* those three
> files hierarchically as two different trees (because there's a
> subdirectory there), the tree objects themselves sort a bit oddly. The
> tree obejcts themselves will look like
>
> top-level tree:
> 100644 a.c -> blob1
> 040000 a -> tree2
> 100644 abc -> blob3
>
> sub-tree:
> 100644 c -> blob2
>
> and notice how the *tree* is not sorted alphabetically at all. It has a
> subtly different sort, where the entry "a" sorts *after* the entry "a.c",
> because we know that it's a tree entry, and thus will (in the *global*
> order) sort as if it had a "/" at the end!
>
> Traditionally, when we have the index, the index sorting has been very
> simple: you just sort the names as memcmp() would sort them. But note how
> that changes, if "a" is an empty directory. Now the index needs to sort as
>
> file a.c
> dir a
> file abc
>
> because when we create the tree entry, it needs to be sorted the same way
> all tree entries are always sorted - as if "a" had a slash at the end!
Here is the layout as I would scheme it:
tree1:
0?0000 . -> dir1
100644 a.c -> blob1
040000 a -> tree2
100644 abc -> blob3
sub-tree:
0?0000 . -> dir2
100644 c -> blob2
Remember that a tree evaporates when it is empty, and if we don't want
to mess with that (which appears like a good idea to me), the "don't
delete this" indication belongs in the subtree where its natural name
is ".". Since the dir entries are _leaves_ in the tree, there is no
necessity for sorting them specially. They will usually appear first,
but people to all sorts of things, so filenames starting with "!"
might still come before them.
So the sorted flat file list for the above would be
. [dir]
a.c [file]
a/ [tree]
a/. [dir]
a/c [file]
abc [file]
Note that a tree is basically just a string arrangement tool which
gets only incidentally mapped to directories when checking out.
So I am quite unhappy that 040000 is already taken by it. I can't
even say, "ok, let . look like an empty tree" because there should not
be something like an empty tree! I find the correlation empty->gone
very important.
> [ Yeah, yeah, we could make a special case and just say "the empty
> tree sorts differently", but that actually results in huge problems
> when doing a "diff" between two trees: our diff machinery very much
> depends on the fact that the index and the trees always sort the
> same way, and if we sorted the "a" entry (when it is an empty
> directory) differently from the "a" entry (when it has entries in
> it), that would just be insane and cause no end of trouble for
> comparing two trees - one with an empty directory and one with
> content added to that directory.
It appears to me like our ideas are still out of sync: a directory
under my scheme is _not_ at all an empty tree, rather it is an entry
_inside_ of a tree, making the tree non-empty (which means that git
will not be tempted to delete the corresponing real-world directory
_until_ one deletes the directory entry keeping the tree alive).
> So the sorting is doubly important: it's what makes "one content"
> always have the same SHA1, but it is also much easier and
> efficient to compare directories when we know they are sorted the
> same way. ]
>
> It's *probably* just a few lines of code, and it actually would
> result in some nice changes ("git ls-files" would show a '/' at the
> end of an empty directory entry, for example), so this is not a big
> deal, but it's an example of how subtly different a directory is
> from a file when it comes to git.
Linus, a directory is simply non-existent inside of git. Trees are an
indexing mechanism solely determined by their content. That is not a
subtle difference. Git _uses_ directories when exporting in order to
simulate a flat namespace. But it is internally oblivious to their
existence. And that is a perfectly elegant and reasonable approach
and I like it very much and don't want to mess with it at all.
But I also want to have directories represented within git, because
not doing so leads to awkward problems. And the proper way as I see
it is _not_ to mess with trees and stick them with "stay when empty"
flags or similar. This messes up the whole elegance of git's flat
name space. The proper way is to create a distinct object that
represents a physical directory. We don't need to represent the
contents of it: those are already tracked in the flat namespace fine,
with trees serving as an implementation detail.
All we need to represent is ".".
So git-ls-files on
. [dir]
a.c [file]
a/ [tree]
a/. [dir]
a/c [file]
abc [file]
should likely list
.
a.c
a/.
a/c
abc
If one wants to see the _tree_ because of its SHA1, it may also be
listed. The SHA1 of a _directory_ like a/., in contrast, is
uninteresting: it will be the same for every directory.
Whether the _tree_ is listed as "a" or "a/" is probably a matter of
taste. Personally, I think "a/" is better for bringing across the
notion that it is a structuring device not really related to the
physical _directory_ a which is _identical_ (meaning inode-identical,
which is what counts in the physical world) to "a/." even though it is
another name of it.
And using "a/" puts it closer to its natural sort order.
I'd write up a philosophy paper about git's relation between trees,
files, directories if that were not utterly preposterous.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 3/5] Internationalization of git-gui
From: David Kastrup @ 2007-07-21 17:41 UTC (permalink / raw)
To: git
In-Reply-To: <46A233DE.6010304@fs.ei.tum.de>
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:
> David Kastrup wrote:
>>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
>>> +msgid "Sign Off"
>>> +msgstr "Freizeichnen"
>>
>> Gegenzeichnen?
>
> Abzeichnen!
Absegnen. Ich denke mal, in der Form mit "Ab" ist das dermaßen
gebräuchlich, daß man damit keine religiösen Befindlichkeiten
verletzt.
Ansonsten: Abnicken oder Gutheißen.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Simon 'corecode' Schubert @ 2007-07-21 17:52 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, git
In-Reply-To: <85tzrxslms.fsf@lola.goethe.zz>
David Kastrup wrote:
> But I also want to have directories represented within git, because
> not doing so leads to awkward problems. And the proper way as I see
> it is _not_ to mess with trees and stick them with "stay when empty"
> flags or similar. This messes up the whole elegance of git's flat
> name space. The proper way is to create a distinct object that
> represents a physical directory. We don't need to represent the
> contents of it: those are already tracked in the flat namespace fine,
> with trees serving as an implementation detail.
>
> All we need to represent is ".".
What I still don't get is: How do you carry this information about "this directory should not be removed" from one checkout to the next commit? When creating a .gitignore, this file exists in the workdir. Of course you add some data to the index to stage it. But how does this work with your "." "file"? You can't put that in the filesystem.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-21 18:08 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: Linus Torvalds, git
In-Reply-To: <46A247C1.4000902@fs.ei.tum.de>
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:
> David Kastrup wrote:
>> But I also want to have directories represented within git, because
>> not doing so leads to awkward problems. And the proper way as I see
>> it is _not_ to mess with trees and stick them with "stay when empty"
>> flags or similar. This messes up the whole elegance of git's flat
>> name space. The proper way is to create a distinct object that
>> represents a physical directory. We don't need to represent the
>> contents of it: those are already tracked in the flat namespace fine,
>> with trees serving as an implementation detail.
>>
>> All we need to represent is ".".
>
> What I still don't get is: How do you carry this information about
> "this directory should not be removed" from one checkout to the next
> commit?
I don't. The only information in the file system is whether a
directory exists or not. "Should not removed" is not a property that
is tracked.
> When creating a .gitignore, this file exists in the workdir. Of
> course you add some data to the index to stage it. But how does
> this work with your "." "file"? You can't put that in the
> filesystem.
Either the directory is in the file system or it is not. Like with
every other file. And either git tracks the directory, in which case
it will notice its addition (when doing git-add) and removal (when
doing git-rm or git-commit -a) or git doesn't track the directory.
When git tracks the directory (a matter of gitignore settings for
implicit tracking, and git-add for explicit tracking), and considers
it existent, it will not touch it. If it tracks it but considers it
removed in particular commit, it will attempt to remove it.
Fineprint: actually, things are more involved here: git does not
actually attempt to remove directories at the time it deletes them
from the tree: this is sort of pointless since the sort order
means that there might still be files it needs to take out from
the physical directory). Instead, like before, git attempts to
remove a physical directory whenever the corresponding tree in git
becomes empty, and it is a prerequisite to delete a possibly
tracked directory from it.
After it has attempted to remove it, it will leave it alone since it
is now no longer tracking it. If you add and remove a contained file,
it will again try to remove the directory. If you add _both_
directory and a contained file, just removing the contained file will
not make git attempt to delete the directory.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Translation process (was: [PATCH 3/5] Internationalization of git-gui)
From: Christian Stimming @ 2007-07-21 18:50 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85ps2l98eq.fsf@lola.goethe.zz>
Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:
> Christian Stimming <stimming@tuhh.de> writes:
> > And a new German translation, so far 100% but many more strings are to
> > come.
>
> I have somewhat different proposals which sound less awkward, I
> think. Of course, it is always a matter of taste whether a technical
> term should really be translated always, but assuming that, I'll make
> some German proposals. Some may be tongue in cheek.
Thanks for the suggestions. However, I don't think it is of much worth to
discuss individual message translations *right now*; instead, here's what I
would propose instead:
The most difficult issue in a program translation is to find good translation
wordings for those key words which are used each and every time throughout
the program. Once you've decided on a particular translation for each of
these words, the rest is just grunt work. So the important part is to
translate these key words. Incidentally, I've added the file po/glossary.cvs
for exactly this purpose. In there you find my current collection of key
words that occur throughout git-gui (and git, for that matter), including a
set of proposed translations to German language. This should be the place
where the keyword translations should be discussed first. The discussion of
the actual translations should be deferred until after the glossary
translations have been discussed and agreed upon.
(I'm unsure whether the translations should be kept in the same glossary file;
in the glossary for the gnucash project [1] we've actually added an extra
directory and encourage translators to add an extra po file for their
glossary translations. However, the glossary of gnucash has more than 150
terms and many of them require to be defined clearly as well, as translators
would otherwise be unable to translate them concisely. In git-gui, the
glossary is 25 terms so far and I think the git documentation already
contains enough definitions of all of them. Nevertheless, maybe it would make
a better structure if the translations of the glossary are kept in a separate
po file for each language. Hm.)
In short: Please discuss the glossary first, and not the actual de.po message
file. Once the glossary has been decided upon, the de.po will be adapted, and
*after that* a discussion of de.po makes sense. But not before that.
Regards,
Christian
[1]
http://svn.gnucash.org/trac/browser/gnucash/trunk/po/glossary/gnc-glossary.txt
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Paolo Ciarrocchi @ 2007-07-21 18:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Shawn O. Pearce, Johannes Schindelin, Christian Stimming, git
In-Reply-To: <7vr6n2upwv.fsf@assigned-by-dhcp.cox.net>
On 7/21/07, Junio C Hamano <gitster@pobox.com> wrote:
paolo@paolo-desktop:~/git-gui-i18n$ ls
git-gui.sh GIT-VERSION-GEN lib Makefile po
> - Run 'make' once, to get po/git-gui.pot generated;
paolo@paolo-desktop:~/git-gui-i18n$ make
GITGUI_VERSION = 0.8.GITGUI
* new locations or Tcl/Tk interpreter
GEN git-gui
BUILTIN git-citool
INDEX lib/
paolo@paolo-desktop:~/git-gui-i18n$ ls po/
de.msg de.po glossary.csv ja.msg ja.po
There is "po/git-gui.pot" file in my repository.
Am I doing something wrong?
Thanks!
Ciao,
--
Paolo
"Tutto cio' che merita di essere fatto,merita di essere fatto bene"
Philip Stanhope IV conte di Chesterfield
^ permalink raw reply
* Re: German translations (was: [PATCH 3/5] Internationalization of git-gui)
From: Christian Stimming @ 2007-07-21 19:27 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85ps2l98eq.fsf@lola.goethe.zz>
Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:
> Christian Stimming <stimming@tuhh.de> writes:
> > And a new German translation, so far 100% but many more strings are to
> > come.
>
> I have somewhat different proposals which sound less awkward, I
> think. Of course, it is always a matter of taste whether a technical
> term should really be translated always, but assuming that, I'll make
> some German proposals. Some may be tongue in cheek.
Thanks for additional word proposals. I'll discuss these and the two followups
in German below.
> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
> > +msgid "Commit"
> > +msgstr "Übertragen"
>
> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
> passendes Substantiv zu finden. "Sendung"?
Richtig - eine Kombination Substantiv/Verb wird benötigt. Ich habe im
Glossar "übertragen (senden?, übergeben?)". Ersteres wird bei TortoiseSVN
benutzt. Im Prinzip gehen die anderen auch; bei "Sendung"/"senden" befürchte
ich aber zu viele Mehrdeutigkeiten, wenn man z.B. davon redet. den commit
über TCP wohin senden will. Die Sendung wohin senden? Andererseits hat man
bei Übertragung das gleiche Problem.
> > +#: git-gui.sh:1631
> > +msgid "Fetch"
> > +msgstr "Holen"
>
> Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben
> häßlich ist)
Importieren ist bereits für "git-{cvs,svn}import" reserviert, kann also hier
nicht verwendet werden. Deswegen wird was anderes benötigt. Für fetch und
pull gleichermaßen würden holen/ziehen/übernehmen gehen und man muss sich
halt auf eine Zuordnung festlegen.
> > +#: git-gui.sh:1632 git-gui.sh:2140
> > +msgid "Push"
> > +msgstr "Schieben"
>
> Exportieren
Dito - bereits reserviert für git-cvsexport u.ä., also hier nicht benutzbar.
Deswegen momentan dieses, ich bin aber auch nicht glücklich damit. Siehe
Glossar: "schieben (hochladen? verschicken?)"
> > +#: git-gui.sh:1641
> > +msgid "Browse Current Branch"
> > +msgstr "Aktuellen Zweig durchblättern"
>
> Im aktuellen Zweig stöbern.
stöbern für "to browse"? Das ist aber definitiv nicht das, was normalerweise
als Übersetzung von "to browse" gewählt wird. Da ist man eben bei blättern.
Außerdem ist "stöbern" hart an der Grenze zur Flapsigkeit, die man (im
Gegensatz zum engl. Original) bei deutscher Software unbedingt vermeiden
muss.
> > +#: git-gui.sh:1659
> > +msgid "Compress Database"
> > +msgstr "Datenbank komprimieren"
>
> Ganz Deutsch: verdichten.
Alle E-Mail-Programme reden aber bereits von komprimieren (was in den Motoren
schon immer ein deutscher Begriff war), so dass ich hier auch dabei bleiben
würde.
> > +#: git-gui.sh:1662
> > +msgid "Verify Database"
> > +msgstr "Datenbank prüfen"
>
> überprüfen (prüfen wäre eher zu "checking")
"to verify" -> überprüfen? Ok.
> > +#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354
> > +msgid "Select All"
> > +msgstr "Alle auswählen"
>
> Alles auswählen zöge ich vor.
Kommt auf den Kontext an - was soll denn ausgewählt werden? "Alle Sendungen"
oder "Alles, was sichtbar ist"...
> > +#: git-gui.sh:1724
> > +msgid "Checkout..."
> > +msgstr "Auschecken..."
>
> Ausspielung.
Äh... nein. Auschecken ist auch nicht so toll (auch hier übernommen von
TortoiseSVN), aber was besseres hab ich noch nicht gefunden.
> > +#: git-gui.sh:2057
> > +msgid "Staged Changes (Will Be Committed)"
> > +msgstr "Bereitgestellte Änderungen (werden übertragen)"
>
> Einzupflegende Änderungen
Nein, hier muss irgendwie die "staging area" mit auftauchen, denn so lautet
die Beschriftung der linken Listbox. Da ich die mit "Bereitstellung" gewählt
habe, muss das Wort hier wieder auftauchen.
> > David Kastrup wrote:
> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
> >>> +msgid "Sign Off"
> >>> +msgstr "Freizeichnen"
> >>
> >> Gegenzeichnen?
> >
> > Abzeichnen!
>
> Absegnen. Ich denke mal, in der Form mit "Ab" ist das dermaßen
> gebräuchlich, daß man damit keine religiösen Befindlichkeiten
> verletzt.
>
> Ansonsten: Abnicken oder Gutheißen.
Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht. Gegenzeichnen
lässt nicht erahnen, dass man seine eigenen commits ja auch "sign off" soll
(wie z.B. in git.git/Documents/SubmittingPatches erklärt). Abzeichnen wäre
okay, aber das ist Freizeichnen auch.
Gruß
Christian
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Junio C Hamano @ 2007-07-21 19:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Christian Stimming, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0707211427190.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
> - Make the current revision my new 'master'. That branch already exists,
> and I am on 'christian-new', though. No problem:
>
> $ git branch -M christian-new master
>
> (But if you do that with "-M", which means _force_ rename, make sure
> twice that this is really what you want.)
>
> - Push it.
>
> $ git push origin +master
> ...
> refs/heads/master: da7b699[...] -> cc2b761b[...]
>
> The "+" is necessary, since I rebased it...
>
> If there were more pushers than just me, I'd verify that da7b699 is
> indeed the old state of my master:
>
> $ git reflog
> ...
> d36cd96... HEAD@{20}: checkout: moving from master to christian-new
> da7b699... HEAD@{21}: commit [...]
>
> Yep.
>
> Good. Happy.
Two questions and a half.
- The above means git-gui-i18n.git's master is rebased. Is
that the intention? IOW, people are supposed to work on it
with fetch+rebase, not fetch+merge (= pull)?
- It seems that the tip of 'mob' now is out of sync wrt
'master'. What's the plan to update it with framework
changes made in 'master' (e.g. addition of po/glossary.csv)?
While I think keeping a reference for consistent translation
(within one language's *.po file) is a useful practice,
the po/glossary.csv file on 'master' seems a way suboptimal
solution. Currently it is:
$ file po/glossary.csv
po/glossary.csv: ISO-8859 text
$ head -n 1 po/glossary.csv
"English Term" "de translation"
which implies that other languages will be added at the end
separated with <TAB>?
There are two HUGE problems with that.
* Supporting many languages means looooong lines in that file.
Translators for languages later on the line would have hard
time updating or looking at that file.
* Mixed encodings. What if next language wants its strings in
UTF-8? How would you have that and ISO-8859 on a same line?
I would suggest having one glossary file per language.
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Christian Stimming @ 2007-07-21 19:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <7vejj1v92b.fsf@assigned-by-dhcp.cox.net>
Am Samstag, 21. Juli 2007 21:41 schrieb Junio C Hamano:
> While I think keeping a reference for consistent translation
> (within one language's *.po file) is a useful practice,
> the po/glossary.csv file on 'master' seems a way suboptimal
> solution. Currently it is:
>
> $ file po/glossary.csv
> po/glossary.csv: ISO-8859 text
Oops. I created it with utf8 locally. Must have turned into latin1 either in
my mailer or during Johannes' mbox tweaking.
(Also, the de.po was created in utf8 here and must have been messed up during
transmission. Johannes, for future reference: All i18n files should probably
be submitted as utf8, and if they have a different encoding, the submitter
better gave a clear sign this was intentional.)
> $ head -n 1 po/glossary.csv
> "English Term" "de translation"
>
> which implies that other languages will be added at the end
> separated with <TAB>?
>
> There are two HUGE problems with that.
>
> * Supporting many languages means looooong lines in that file.
> Translators for languages later on the line would have hard
> time updating or looking at that file.
>
> * Mixed encodings. What if next language wants its strings in
> UTF-8? How would you have that and ISO-8859 on a same line?
>
> I would suggest having one glossary file per language.
Agreed. I propose to throw away the "add glossary" patch and I'll resubmit,
this time in a separate po/glossary/ directory, where each language will get
a po file for the glossary.
As I've written in another thread: In the glossary for the gnucash project [1]
we've actually added an extra
directory and encourage translators to add an extra po file for their
glossary translations. However, the glossary of gnucash has more than 150
terms and many of them require to be defined clearly as well, as translators
would otherwise be unable to translate them concisely. In git-gui, the
glossary is 25 terms so far and I think the git documentation already
contains enough definitions of all of them. Nevertheless, maybe it would make
a better structure if the translations of the glossary are kept in a separate
po file for each language.
Christian
[1]
http://svn.gnucash.org/trac/browser/gnucash/trunk/po/glossary/gnc-glossary.txt
^ permalink raw reply
* Re: German translations
From: David Kastrup @ 2007-07-21 19:57 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <200707212127.51840.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
> Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:
>> Christian Stimming <stimming@tuhh.de> writes:
>> > And a new German translation, so far 100% but many more strings are to
>> > come.
>>
>> I have somewhat different proposals which sound less awkward, I
>> think. Of course, it is always a matter of taste whether a technical
>> term should really be translated always, but assuming that, I'll make
>> some German proposals. Some may be tongue in cheek.
>
> Thanks for additional word proposals. I'll discuss these and the two
> followups in German below.
>
>> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
>> > +msgid "Commit"
>> > +msgstr "Übertragen"
>>
>> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
>> passendes Substantiv zu finden. "Sendung"?
>
> Richtig - eine Kombination Substantiv/Verb wird benötigt. Ich habe im
> Glossar "übertragen (senden?, übergeben?)". Ersteres wird bei TortoiseSVN
> benutzt. Im Prinzip gehen die anderen auch; bei "Sendung"/"senden" befürchte
> ich aber zu viele Mehrdeutigkeiten, wenn man z.B. davon redet. den commit
> über TCP wohin senden will. Die Sendung wohin senden? Andererseits hat man
> bei Übertragung das gleiche Problem.
Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.
Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.
>> > +#: git-gui.sh:1631
>> > +msgid "Fetch"
>> > +msgstr "Holen"
>>
>> Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben
>> häßlich ist)
>
> Importieren ist bereits für "git-{cvs,svn}import" reserviert, kann
> also hier nicht verwendet werden.
Ok.
> Deswegen wird was anderes benötigt. Für fetch und pull gleichermaßen
> würden holen/ziehen/übernehmen gehen und man muss sich halt auf eine
> Zuordnung festlegen.
fetch = anfordern, pull = übernehmen?
>> > +#: git-gui.sh:1632 git-gui.sh:2140
>> > +msgid "Push"
>> > +msgstr "Schieben"
>>
>> Exportieren
>
> Dito - bereits reserviert für git-cvsexport u.ä., also hier nicht
> benutzbar. Deswegen momentan dieses, ich bin aber auch nicht
> glücklich damit. Siehe Glossar: "schieben (hochladen? verschicken?)"
Ausliefern? Durchgeben?
>> > +#: git-gui.sh:1641
>> > +msgid "Browse Current Branch"
>> > +msgstr "Aktuellen Zweig durchblättern"
>>
>> Im aktuellen Zweig stöbern.
>
> stöbern für "to browse"? Das ist aber definitiv nicht das, was
> normalerweise als Übersetzung von "to browse" gewählt wird. Da ist
> man eben bei blättern.
Aber das wäre "leafing through" und ist eben auf Bücher beschränkt.
> Außerdem ist "stöbern" hart an der Grenze zur Flapsigkeit, die man
> (im Gegensatz zum engl. Original) bei deutscher Software unbedingt
> vermeiden muss.
Finde ich nicht, aber bei Interfaces ist natürlich die
Mehrheitsmeinung ausschlaggebend. "wühlen" wäre flapsig. Etwas
hochsprachlicher wäre noch "durchforsten", aber das trägt uns
natürlich den Zorn der Förster für den Begriffsmißbrauch zu.
"erkunden" wäre auch noch möglich.
>> > +#: git-gui.sh:2057
>> > +msgid "Staged Changes (Will Be Committed)"
>> > +msgstr "Bereitgestellte Änderungen (werden übertragen)"
>>
>> Einzupflegende Änderungen
>
> Nein, hier muss irgendwie die "staging area" mit auftauchen, denn so
> lautet die Beschriftung der linken Listbox. Da ich die mit
> "Bereitstellung" gewählt habe, muss das Wort hier wieder auftauchen.
Sehe ich zwar nicht so.
>> > David Kastrup wrote:
>> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
>> >>> +msgid "Sign Off"
>> >>> +msgstr "Freizeichnen"
>> >>
>> >> Gegenzeichnen?
>> >
>> > Abzeichnen!
>>
>> Absegnen. Ich denke mal, in der Form mit "Ab" ist das dermaßen
>> gebräuchlich, daß man damit keine religiösen Befindlichkeiten
>> verletzt.
>>
>> Ansonsten: Abnicken oder Gutheißen.
>
> Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht.
Abnicken ja, aber Gutheißen ist nun wirklich ein hochsprachlicher
Begriff.
> Abzeichnen wäre okay, aber das ist Freizeichnen auch.
Freizeichnen ist viel zu nischensprachlich. Mit Abzeichnen könnte ich
leben, obwohl ich Gutheißen besser fände.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: German translations
From: David Kastrup @ 2007-07-21 20:09 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <200707212127.51840.stimming@tuhh.de>
After a view of the glossary:
"amend" "ergänzen"
ist nicht ganz korrekt. "nachbessern" wäre da erheblich besser.
"message" würde ich als "Nachricht" statt "Meldung" übersetzen.
"revert" "zurückkehren" würde ich eher als "revidieren" oder
"aufheben" bezeichnen.
"revision" ist wohl schlicht eine "Version" statt der "Revision", die
einem das Finanzamt ins Haus bringt.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-21 21:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Stimming, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <7vejj1v92b.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 21 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ...
> > - Make the current revision my new 'master'. That branch already exists,
> > and I am on 'christian-new', though. No problem:
> >
> > $ git branch -M christian-new master
> >
> > (But if you do that with "-M", which means _force_ rename, make sure
> > twice that this is really what you want.)
> >
> > - Push it.
> >
> > $ git push origin +master
> > ...
> > refs/heads/master: da7b699[...] -> cc2b761b[...]
> >
> > The "+" is necessary, since I rebased it...
> >
> > If there were more pushers than just me, I'd verify that da7b699 is
> > indeed the old state of my master:
> >
> > $ git reflog
> > ...
> > d36cd96... HEAD@{20}: checkout: moving from master to christian-new
> > da7b699... HEAD@{21}: commit [...]
> >
> > Yep.
> >
> > Good. Happy.
>
> Two questions and a half.
>
> - The above means git-gui-i18n.git's master is rebased. Is
> that the intention? IOW, people are supposed to work on it
> with fetch+rebase, not fetch+merge (= pull)?
Okay, you have me there. Usually I am the one saying "rebasing is bad".
So I'll refrain from that practice. From now on, 'master' will _not_ be
rebased. From time to time I will prepare 'for-shawn' branches, which are
"master rebased onto git-gui".
In related news, I will push to 'mob' whenever I update 'master'. I will
never force a push to 'mob', and neither should anybody else have to.
(Except in the case that you want to correct one of your pushes.)
> - It seems that the tip of 'mob' now is out of sync wrt
> 'master'. What's the plan to update it with framework
> changes made in 'master' (e.g. addition of po/glossary.csv)?
IMHO the best practice is to keep it up-to-date with 'master', as I
outlined above.
> [Half a question about po/glossary.csv]
This was answered by Christian, I guess.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-21 21:20 UTC (permalink / raw)
To: Christian Stimming
Cc: Junio C Hamano, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <200707212150.49351.stimming@tuhh.de>
Hi,
On Sat, 21 Jul 2007, Christian Stimming wrote:
> Am Samstag, 21. Juli 2007 21:41 schrieb Junio C Hamano:
> > While I think keeping a reference for consistent translation
> > (within one language's *.po file) is a useful practice,
> > the po/glossary.csv file on 'master' seems a way suboptimal
> > solution. Currently it is:
> >
> > $ file po/glossary.csv
> > po/glossary.csv: ISO-8859 text
>
> Oops. I created it with utf8 locally. Must have turned into latin1 either in
> my mailer or during Johannes' mbox tweaking.
D'oh. I think it was my tweaking. But now, with 'mob' in place, there
are less chances for me to fsck up.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-21 21:25 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Junio C Hamano,
しらいしななこ,
Shawn O. Pearce, Christian Stimming, git
In-Reply-To: <4d8e3fd30707211157l1be243basfb259082b7aa8160@mail.gmail.com>
Hi,
On Sat, 21 Jul 2007, Paolo Ciarrocchi wrote:
> On 7/21/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> paolo@paolo-desktop:~/git-gui-i18n$ ls
> git-gui.sh GIT-VERSION-GEN lib Makefile po
>
>
> > - Run 'make' once, to get po/git-gui.pot generated;
>
> paolo@paolo-desktop:~/git-gui-i18n$ make
> GITGUI_VERSION = 0.8.GITGUI
> * new locations or Tcl/Tk interpreter
> GEN git-gui
> BUILTIN git-citool
> INDEX lib/
>
> paolo@paolo-desktop:~/git-gui-i18n$ ls po/
> de.msg de.po glossary.csv ja.msg ja.po
>
> There is "po/git-gui.pot" file in my repository.
My fault. I was rebasing Junio's patch on top of Christian's new series.
Alas, the PO_TEMPLATE was no longer created by default.
Should be fixed now.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Junio C Hamano @ 2007-07-21 21:28 UTC (permalink / raw)
To: Christian Stimming
Cc: Johannes Schindelin, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <200707212150.49351.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
>> There are two HUGE problems with that.
>>
>> * Supporting many languages means looooong lines in that file.
>> Translators for languages later on the line would have hard
>> time updating or looking at that file.
>>
>> * Mixed encodings. What if next language wants its strings in
>> UTF-8? How would you have that and ISO-8859 on a same line?
>>
>> I would suggest having one glossary file per language.
>
> Agreed. I propose to throw away the "add glossary" patch and I'll resubmit,
> this time in a separate po/glossary/ directory, where each language will get
> a po file for the glossary.
>
> As I've written in another thread: In the glossary for the gnucash project [1]
> we've actually added an extra
> directory and encourage translators to add an extra po file for their
> glossary translations. However, the glossary of gnucash has more than 150
> terms and many of them require to be defined clearly as well, as translators
> would otherwise be unable to translate them concisely. In git-gui, the
> glossary is 25 terms so far and I think the git documentation already
> contains enough definitions of all of them. Nevertheless, maybe it would make
> a better structure if the translations of the glossary are kept in a separate
> po file for each language.
Actually, I would even suggest that we should NOT have a
separate glossary file at all, if gettext suite allows what I
outline below.
How about having it as a part of header comment in each of the
xx.po file?
The division of labor I think would make sense for message l10n
process goes like this:
- The software developer (primarily Shawn): responsible for
marking messages subject to i18n;
- The i18n coordinator (could be Shawn but anybody else can
volunteer; as things stand, I think Christian and Johannes
are doing this): responsible for running "make
po/git-gui.pot; make update-po" from time to time in order to
keep po/*.po in sync with the vocabulary.
initially, populate "glossary" part in po/git-gui.pot;
as needed, add entries "glossary" part in po/git-gui.pot, and
(if possible) add corresponding placeholders to po/*.po;
- Translators (one for each language): responsible for updating
po/xx.po file;
initially, start by copying po/git-gui.pot to create
po/xx.po;
maintainance of "glossary" part of po/xx.po could also be
made this person's responsibility instead of i18n
coordinator's.
This way, the translators do not have to be so familiar with the
gettext toolchain nor even have to have gettext installed.
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-21 21:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Stimming, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <7vabtpv43d.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 21 Jul 2007, Junio C Hamano wrote:
> The division of labor I think would make sense for message l10n
> process goes like this:
>
> - The software developer (primarily Shawn): responsible for
> marking messages subject to i18n;
>
> - The i18n coordinator (could be Shawn but anybody else can
> volunteer; as things stand, I think Christian and Johannes
> are doing this): responsible for running "make
> po/git-gui.pot; make update-po" from time to time in order to
> keep po/*.po in sync with the vocabulary.
>
> initially, populate "glossary" part in po/git-gui.pot;
>
> as needed, add entries "glossary" part in po/git-gui.pot, and
> (if possible) add corresponding placeholders to po/*.po;
>
> - Translators (one for each language): responsible for updating
> po/xx.po file;
>
> initially, start by copying po/git-gui.pot to create
> po/xx.po;
>
> maintainance of "glossary" part of po/xx.po could also be
> made this person's responsibility instead of i18n
> coordinator's.
>
> This way, the translators do not have to be so familiar with the
> gettext toolchain nor even have to have gettext installed.
Makes tons of sense to me.
Ciao,
Dscho
^ permalink raw reply
* The philosophy behind my directory proposal in a nutshell
From: David Kastrup @ 2007-07-21 22:22 UTC (permalink / raw)
To: git
Ok, a big nut.
Many people have lost track since I developed the idea over dozens of
postings and so I have been explaining only details instead of the
actual picture.
Let us assume we habe the following files in the work tree (there is a
reason for starting off with / always in this discussion):
/i/never/saw/this
/i/never/should/have
/i/would/have
Now it is obvious that we _also_ have the directories (which I'll call
by their proposed git name):
/i/never/saw/.
/i/never/should/.
/i/never/.
/i/would/.
/i/.
/.
Git does right now not track any of them. It _induces_ their
existence through trees in the repository. Let us call the _trees_ in
the following way:
/i/never/saw/
/i/never/should/
/i/never/
/i/would/
/i/
/
[The last line here is the reason we prepended / everywhere: it makes
the root tree more apparent].
All those _trees_ are just string prefixes of file names, and those
prefixes are without a physical existence. But if we check out the
files, we need to create directories to accommodate them. And for
efficiency reasons, we call every prefix occuring in the flat file
list ending in / a "tree" and give it an SHA1 value.
Now when do we remove a directory that is in the work filesystem?
When the corresponding tree (=prefix) in the repository becomes empty,
namely the prefix becomes unused, the tree evaporates. At that
moment, git has lost the necessity for keeping the directory around,
and attempts to remove it. If the attempt does not succeed, something
outside of git is using the directory. At this point removing the
directory becomes somebody else's problem: git will not try again.
The tree is gone from the repository, so there is nothing that makes
git even _think_ about that directory.
So far, so well. Quite consistent, in some cases quite convenient,
but not in all. There are situations where empty directories matter.
So we want git to be able to track them. Let us take a simple example
first:
mkdir a
mkdir a/b
touch a/b/c
git add a/b/c
git commit
git rm a/b/c
git commit
The naive expectation would be that the directories made by the user
will not get touched by git. Trying to implement anything like a "git
removes only directories it created itself" would be insane, and here
is why: the user actually has no _chance_ not to create those
directories before checking the files in. And there is no way to
deduce whether he did it on behalf of git or because of some other
reason. Also it is not important _how_ the directory got created: git
tracks states, not responsibilities.
So this case _must_ behave the same: after the first commit, we have
/a/b/c in the repository as the only file, and it induces the
existence of the trees
/a/b
/a
/
So when we remove /a/b first /a collapses and evaporates (if a tree
falls in the repository and there is nobody to hear it...), then /
collapses but is kept alive because we can't remove our current work
directory, not even if the repository is kept elsewhere (and actually,
/ _is_ special after all).
This behavior _must_ stay the same, regardless of what settings we
use. Now let us assume that git can be told to track directories, and
that the user wants to keep a around even if empty, but not
necessarily b. How can he achieve this?
mkdir a
git-add a
mkdir a/b
touch a/b/c
git-add a/b/c
git-commit
git-rm a/b/c
git-commit
Now directories come into play. After the first git-add, the
repository contains the following non-volatile stuff:
/a/.
and in consequence it contains the trees
/a/
/
as well. The second add adds /a/b/c but nothing else, so we have
/a/.
/a/b/c
and the trees
/a/b/
/a/
/
Ok, so now do the git-rm and following commit. The tree then contains
/a/.
and /a/b/ collapses while /a/ and / are held up by /a/. perfectly
well. The collapse of /a/b/ leads to the deletion of the
corresponding directory in the work tree (so the collapse of a tree in
the repository _does_ make a sound in the work directory as long as
somebody is there to hear it).
[As a note aside: working directories get removed when their
corresponding tree collapses and disappears from the
repository. I should think it only consistent if the same
happened with git-rm: let the file by default disappear at
the moment when it gets removed from the repository,
implying --cached. Namely, let
git-rm some-file
git-add some-file
be a noop, regardless whether the file was registered
previously. This also implies that git-rm will always leave
unregistered files alone.]
So when directory tracking is on, basically whenever adding
a directory explicitly by naming it or a parent directory in
the add or commit, the corresponding entry ending in "/."
gets added and keeps the tree alive even if no other file
does. And while the tree is alive, git does not touch the
directory in the work tree.
So that are the basics for more or less manually adding and
removing directories when they are being tracked. How do we
let git decide whether or not to track directories? It
never tracks them if our git-add commands only mention
files: in that case, the behavior is indistinguishable from
previously. But if we use git-add to add directories, then
not just files, but also directories make it to the index
and repository.
Of course, we can have a configuration variable to set
this. But this is not enough. Fortunately, all directories
carry a name ending with "/." in the repository, and thus we
can use the gitignore mechanism to make git ignore
directories.
Some commands accept "ignore this" or "don't ignore this" on
the command line, this takes highest priority.
Then .gitignore files come to play in the directory
hierarchy: those make it easy to exclude or include any
subtree in directory tracking by specifying the pattern "."
or "!.". Then $GIT_DIR/info/exclude takes effect in a
similar way, another level lower core.excludesfile is
consulted, and at the very lowest level, if nobody else
cares (unlikely that a project would not set forth a policy
in $GIT_DIR/info/exclude), the users preference variable
core.trackdirs takes effect, defaulting to false for
compatibility until all projects wanting to keep directories
out of their repository have made their wish explicit in
their configuration.
I hope the concept now is somewhat clearer.
Now how does git _exactly_ deal with ignored files? Ignored
files basically means that git skips them when they get
added (unless you use -f). However, it _does_ notice when
they get deleted and updates the repository correspondingly.
What does this mean for interoperability of users with
different preferences of directory tracking? First assume
that both have git versions capable of tracking directories.
One ignores ".", the other doesn't. "." entries will in
this case be removed when the non-tracker commits a
directory with -a where the physical directory has
disappeared (and thus also all files beneath that). That's
reasonably harmless. "." entries will be added for a
directory and its subdirectories when the tracking person
commits a directory.
No problems here, little cause for violence. Now what
happens with a "legacy" git? The legacy git _never_ sees
anything corresponding to the weird directory entries in the
file system. So with every commit of a tree with -a, the
tree gets "corrected" by removing the "strange" entries.
They will get added again when somebody else commits, but in
the mean time, empty directories might disappear. If that
is a problem, you should not have given a person using an
old git commit access. Could be worse.
So that basically wraps this up.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 3/4] --decorate now decorates ancestors, too
From: Johannes Schindelin @ 2007-07-21 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git
In-Reply-To: <7vmyy1tq96.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 12 Jul 2007, Junio C Hamano wrote:
> But in general I do not see ("I haven't realized" might turn out to be a
> better expression) much value in this series yet except for the initial
> clean-up patches, while I think this option would be quite expensive in
> terms of memory footprints on projects with nontrivial size of history.
> I dunno.
It would not, since you do not have to say "--decorate" at all. However,
if you do want the functionality this patch provides, you have to jump
through hoops right now. ATM an alias is my work around, since I run
'master' as you requested:
git config --global alias.decoratelog '!sh -c
"(case \"\$0\" in
sh) git log --color;;
*) git log --color \"\$0\" \"\$@\";;
esac) |
git -p name-rev --tags --stdin"'
Ugly, ain't it?
And I still have to look up at which release certain features were
introduced every day.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Junio C Hamano @ 2007-07-21 22:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Christian Stimming, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0707212208110.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Two questions and a half.
>>
>> - The above means git-gui-i18n.git's master is rebased. Is
>> that the intention? IOW, people are supposed to work on it
>> with fetch+rebase, not fetch+merge (= pull)?
>
> Okay, you have me there. Usually I am the one saying "rebasing is bad".
> So I'll refrain from that practice. From now on, 'master' will _not_ be
> rebased. From time to time I will prepare 'for-shawn' branches, which are
> "master rebased onto git-gui".
I did not mean to say "rebase is bad". Quite the contrary.
Rebase is bad for a repository meant for public consumption of
the under-development-snapshot, like git.git's 'master' and
'next'. For a repository like git-gui-i18n whose sole point is
to serve as a public gathering point of narrowly focused area of
development (only translation of messages), I actually think
"everybody fetches and rebases" workflow is perfectly fine, as
long as all participants understand what the expected workflows
are. My comment was more about making it clear what the policy
is to its intended audience.
Rebasing git-gui-i18n to keep its history clean would eventually
allow you to merge it directly into git-gui. But if you are not
aiming for that (and you said your plan is to cherry pick the
result, not to merge, which is fine), then rebasing would no buy
you anything, so I think it would be a reasonable and manageable
workflow to:
- people fork from 'mob', push back to 'mob';
- you
- build 'master' by cherry picking good bits from 'mob', and
- do your own fixups and framework changes on 'master',
- merge 'master' back to 'mob' to allow contributors to
adjust their work on the updated 'master' by simply
following 'mob',
- and eventually clean-up 'master' to make it mergeable and/or
applicable to git-gui itself.
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Junio C Hamano @ 2007-07-21 22:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Paolo Ciarrocchi,
しらいしななこ,
Shawn O. Pearce, Christian Stimming, git
In-Reply-To: <Pine.LNX.4.64.0707212224480.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> paolo@paolo-desktop:~/git-gui-i18n$ ls po/
>> de.msg de.po glossary.csv ja.msg ja.po
>>
>> There is "po/git-gui.pot" file in my repository.
>
> My fault. I was rebasing Junio's patch on top of Christian's new series.
> Alas, the PO_TEMPLATE was no longer created by default.
>
> Should be fixed now.
Note that if everybody agrees that the division of labor between
the developer, the i18n coordinator and translators I suggested
in the earlier message is the way to go, po/git-gui.pot should
be managed by the i18n coordinator and revision tracked in-tree.
Simple "make" should not try to update it for ordinary people,
but we can have a "i18n coordinator only" maintenance target to
update it.
That way, translators do not have to touch anything other than
their own po/xx.po files.
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-21 23:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Stimming, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <7vzm1ptmdm.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 21 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Two questions and a half.
> >>
> >> - The above means git-gui-i18n.git's master is rebased. Is
> >> that the intention? IOW, people are supposed to work on it
> >> with fetch+rebase, not fetch+merge (= pull)?
> >
> > Okay, you have me there. Usually I am the one saying "rebasing is bad".
> > So I'll refrain from that practice. From now on, 'master' will _not_ be
> > rebased. From time to time I will prepare 'for-shawn' branches, which are
> > "master rebased onto git-gui".
>
> I did not mean to say "rebase is bad". Quite the contrary.
Yeah, I was not really precise. Rebase is only bad for branches that want
to be tracked.
As you can see from my work on rebase -i, I recently converted to an avid
user of rebase, from somebody who detested the feature a year ago.
> [...] I think it would be a reasonable and manageable workflow to:
>
> - people fork from 'mob', push back to 'mob';
>
> - you
> - build 'master' by cherry picking good bits from 'mob', and
> - do your own fixups and framework changes on 'master',
> - merge 'master' back to 'mob' to allow contributors to
> adjust their work on the updated 'master' by simply
> following 'mob',
>
> - and eventually clean-up 'master' to make it mergeable and/or
> applicable to git-gui itself.
I plan to pull and push from mob, from time to time
cherry-picking/rebasing and cleaning up to a branch called 'for-shawn'.
To keep things a little synchronised, I plan to make grafts at stages
where master^{tree} = for-shawn^{tree}, so that rebase is easier.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Jakub Narebski @ 2007-07-21 23:30 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git, Petr Baudis, Luben Tuikov
In-Reply-To: <1184699486.9831.7.camel@mattlaptop2>
From: Matt McCutchen <hashproduct@gmail.com>
Subject: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
- Centralize knowledge about snapshot formats (mime types, extensions,
commands) in %known_snapshot_formats and improve how some of that
information is specified. In particular, zip files are no longer a
special case.
- Add support for offering multiple snapshot formats to the user so
that he/she can download a snapshot in the format he/she prefers.
The site-wide or project configuration now gives a list of formats
to offer, and if more than one format is offered, the "_snapshot_"
link becomes something like "snapshot (_tar.bz2_ _zip_)".
- If only one format is offered, a tooltip on the "_snapshot_" link
tells the user what it is.
- Fix out-of-date "tarball" -> "archive" in comment.
Alert for gitweb site administrators: This patch changes the format of
$feature{'snapshot'}{'default'} in gitweb_config.perl from a list of
three pieces of information about a single format to a list of one or
more formats you wish to offer from the set ('tgz', 'tbz2', 'zip').
Update your gitweb_config.perl appropriately. There was taken care
for old-style gitweb configuration to work as it used to, but this
backward compatibility works only for the values which correspond to
gitweb.snapshot values of 'gzip', 'bzip2' and 'zip', i.e.
['x-gzip', 'gz', 'gzip']
['x-bzip2', 'bz2', 'bzip2']
['x-zip', 'zip', '']
The preferred names for gitweb.snapshot in repository configuration
have also changed from 'gzip' and 'bzip2' to 'tgz' and 'tbz2', but
the old names are still recognized for compatibility.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This tries to address concerns that was raised in this thread.
Namely:
- hash is used instead of fixed order of mixed arguments array
- it tries to be backward compatibile wrt. gitweb config
gitweb/gitweb.perl | 166 ++++++++++++++++++++++++++++++++++++----------------
1 files changed, 116 insertions(+), 50 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6754e26..c4f8824 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -114,6 +114,49 @@ our $fallback_encoding = 'latin1';
# - one might want to include '-B' option, e.g. '-B', '-M'
our @diff_opts = ('-M'); # taken from git_commit
+# information about snapshot formats that gitweb is capable of serving
+our %known_snapshot_formats = (
+ # name => {
+ # 'display' => display name,
+ # 'type' => mime type,
+ # 'suffix' => filename suffix,
+ # 'format' => --format for git-archive,
+ # 'compressor' => [compressor command and arguments]
+ # (array reference, optional)}
+ #
+ 'tgz' => {
+ 'display' => 'tar.gz',
+ 'type' => 'application/x-gzip',
+ 'suffix' => '.tar.gz',
+ 'format' => 'tar',
+ 'compressor' => ['gzip']},
+
+ 'tbz2' => {
+ 'display' => 'tar.bz2',
+ 'type' => 'application/x-bzip2',
+ 'suffix' => '.tar.bz2',
+ 'format' => 'tar',
+ 'compressor' => ['bzip2']},
+
+ 'zip' => {
+ 'display' => 'zip',
+ 'type' => 'application/x-zip',
+ 'suffix' => '.zip',
+ 'format' => 'zip'},
+);
+
+# Aliases so we understand old gitweb.snapshot values in repository
+# configuration.
+our %known_snapshot_format_aliases = (
+ 'gzip' => 'tgz',
+ 'bzip2' => 'tbz2',
+
+ # backward compatibility: legacy gitweb config support
+ 'x-gzip' => undef, 'gz' => undef,
+ 'x-bzip2' => undef, 'bz2' => undef,
+ 'x-zip' => undef, '' => undef,
+);
+
# You define site-wide feature defaults here; override them with
# $GITWEB_CONFIG as necessary.
our %feature = (
@@ -144,20 +187,22 @@ our %feature = (
'override' => 0,
'default' => [0]},
- # Enable the 'snapshot' link, providing a compressed tarball of any
+ # Enable the 'snapshot' link, providing a compressed archive of any
# tree. This can potentially generate high traffic if you have large
# project.
+ # Value is a list of formats defined in %known_snapshot_formats that
+ # you wish to offer.
# To disable system wide have in $GITWEB_CONFIG
- # $feature{'snapshot'}{'default'} = [undef];
+ # $feature{'snapshot'}{'default'} = [];
# To have project specific config enable override in $GITWEB_CONFIG
# $feature{'snapshot'}{'override'} = 1;
- # and in project config gitweb.snapshot = none|gzip|bzip2|zip;
+ # and in project config, a comma-separated list of formats or "none"
+ # to disable. Example: gitweb.snapshot = tbz2,zip;
'snapshot' => {
'sub' => \&feature_snapshot,
'override' => 0,
- # => [content-encoding, suffix, program]
- 'default' => ['x-gzip', 'gz', 'gzip']},
+ 'default' => ['tgz']},
# Enable text search, which will list the commits which match author,
# committer or commit text to a given string. Enabled by default.
@@ -256,28 +301,19 @@ sub feature_blame {
}
sub feature_snapshot {
- my ($ctype, $suffix, $command) = @_;
+ my (@fmts) = @_;
my ($val) = git_get_project_config('snapshot');
- if ($val eq 'gzip') {
- return ('x-gzip', 'gz', 'gzip');
- } elsif ($val eq 'bzip2') {
- return ('x-bzip2', 'bz2', 'bzip2');
- } elsif ($val eq 'zip') {
- return ('x-zip', 'zip', '');
- } elsif ($val eq 'none') {
- return ();
+ if ($val) {
+ @fmts = ($val eq 'none' ? () : split /\s*[,\s]\s*/, $val);
+ @fmts = grep { defined } map {
+ exists $known_snapshot_format_aliases{$_} ?
+ $known_snapshot_format_aliases{$_} : $_ } @fmts;
+ @fmts = grep(exists $known_snapshot_formats{$_}, @fmts);
}
- return ($ctype, $suffix, $command);
-}
-
-sub gitweb_have_snapshot {
- my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
- my $have_snapshot = (defined $ctype && defined $suffix);
-
- return $have_snapshot;
+ return @fmts;
}
sub feature_grep {
@@ -563,6 +599,7 @@ sub href(%) {
order => "o",
searchtext => "s",
searchtype => "st",
+ snapshot_format => "sf",
);
my %mapping = @mapping;
@@ -1257,6 +1294,39 @@ sub format_diff_line {
return "<div class=\"diff$diff_class\">" . esc_html($line, -nbsp=>1) . "</div>\n";
}
+# Generates undef or something like "_snapshot_" or "snapshot (_tbz2_ _zip_)",
+# linked. Pass the hash of the tree/commit to snapshot.
+sub format_snapshot_links {
+ my ($hash) = @_;
+ my @snapshot_fmts = gitweb_check_feature('snapshot');
+ my $num_fmts = @snapshot_fmts;
+ if ($num_fmts > 1) {
+ # A parenthesized list of links bearing format names.
+ return "snapshot (" . join(' ', map
+ $cgi->a({
+ -href => href(
+ action=>"snapshot",
+ hash=>$hash,
+ snapshot_format=>$_
+ )
+ }, $known_snapshot_formats{$_}{'display'})
+ , @snapshot_fmts) . ")";
+ } elsif ($num_fmts == 1) {
+ # A single "snapshot" link whose tooltip bears the format name.
+ my ($fmt) = @snapshot_fmts;
+ return $cgi->a({
+ -href => href(
+ action=>"snapshot",
+ hash=>$hash,
+ snapshot_format=>$fmt
+ ),
+ -title => "in format: $known_snapshot_formats{$fmt}{'display'}"
+ }, "snapshot");
+ } else { # $num_fmts == 0
+ return undef;
+ }
+}
+
## ----------------------------------------------------------------------
## git utility subroutines, invoking git commands
@@ -3321,8 +3391,6 @@ sub git_shortlog_body {
# uses global variable $project
my ($commitlist, $from, $to, $refs, $extra) = @_;
- my $have_snapshot = gitweb_have_snapshot();
-
$from = 0 unless defined $from;
$to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
@@ -3349,8 +3417,9 @@ sub git_shortlog_body {
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
$cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
- if ($have_snapshot) {
- print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
+ my $snapshot_links = format_snapshot_links($commit);
+ if (defined $snapshot_links) {
+ print " | " . $snapshot_links;
}
print "</td>\n" .
"</tr>\n";
@@ -4132,8 +4201,6 @@ sub git_blob {
}
sub git_tree {
- my $have_snapshot = gitweb_have_snapshot();
-
if (!defined $hash_base) {
$hash_base = "HEAD";
}
@@ -4167,11 +4234,10 @@ sub git_tree {
hash_base=>"HEAD", file_name=>$file_name)},
"HEAD"),
}
- if ($have_snapshot) {
+ my $snapshot_links = format_snapshot_links($hash);
+ if (defined $snapshot_links) {
# FIXME: Should be available when we have no hash base as well.
- push @views_nav,
- $cgi->a({-href => href(action=>"snapshot", hash=>$hash)},
- "snapshot");
+ push @views_nav, $snapshot_links;
}
git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
@@ -4235,33 +4301,36 @@ sub git_tree {
}
sub git_snapshot {
- my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
- my $have_snapshot = (defined $ctype && defined $suffix);
- if (!$have_snapshot) {
- die_error('403 Permission denied', "Permission denied");
+ my @supported_fmts = gitweb_check_feature('snapshot');
+
+ my $format = $cgi->param('sf');
+ unless ($format =~ m/[a-z0-9]+/
+ && exists($known_snapshot_formats{$format})
+ && grep($_ eq $format, @supported_fmts)) {
+ die_error(undef, "Unsupported snapshot format");
}
if (!defined $hash) {
$hash = git_get_head_hash($project);
}
- my $git = git_cmd_str();
+ my $git_command = git_cmd_str();
my $name = $project;
$name =~ s,([^/])/*\.git$,$1,;
$name = basename($name);
my $filename = to_utf8($name);
$name =~ s/\047/\047\\\047\047/g;
my $cmd;
- if ($suffix eq 'zip') {
- $filename .= "-$hash.$suffix";
- $cmd = "$git archive --format=zip --prefix=\'$name\'/ $hash";
- } else {
- $filename .= "-$hash.tar.$suffix";
- $cmd = "$git archive --format=tar --prefix=\'$name\'/ $hash | $command";
+ $filename .= "-$hash$known_snapshot_formats{$format}{'suffix'}";
+ $cmd = "$git_command archive " .
+ "--format=$known_snapshot_formats{$format}{'format'}" .
+ "--prefix=\'$name\'/ $hash";
+ if (exists $known_snapshot_formats{$format}{'compressor'}) {
+ $cmd .= ' | ' . join ' ', @{$known_snapshot_formats{$format}{'compressor'}};
}
print $cgi->header(
- -type => "application/$ctype",
+ -type => $known_snapshot_formats{$format}{'type'},
-content_disposition => 'inline; filename="' . "$filename" . '"',
-status => '200 OK');
@@ -4271,7 +4340,6 @@ sub git_snapshot {
print <$fd>;
binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
close $fd;
-
}
sub git_log {
@@ -4390,8 +4458,6 @@ sub git_commit {
my $refs = git_get_references();
my $ref = format_ref_marker($refs, $co{'id'});
- my $have_snapshot = gitweb_have_snapshot();
-
git_header_html(undef, $expires);
git_print_page_nav('commit', '',
$hash, $co{'tree'}, $hash,
@@ -4430,9 +4496,9 @@ sub git_commit {
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$hash)},
"tree");
- if ($have_snapshot) {
- print " | " .
- $cgi->a({-href => href(action=>"snapshot", hash=>$hash)}, "snapshot");
+ my $snapshot_links = format_snapshot_links($hash);
+ if (defined $snapshot_links) {
+ print " | " . $snapshot_links;
}
print "</td>" .
"</tr>\n";
--
1.5.2.4
^ permalink raw reply related
* git-rm semantics (was: The philosophy behind my directory proposal in a nutshell)
From: David Kastrup @ 2007-07-21 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <85fy3hqtwl.fsf@lola.goethe.zz>
Following up on the git-rm note:
> [As a note aside: working directories get removed when their
> corresponding tree collapses and disappears from the
> repository. I should think it only consistent if the same
> happened with git-rm: let the file by default disappear at
> the moment when it gets removed from the repository,
> implying --cached. Namely, let
>
> git-rm some-file
> git-add some-file
>
> be a noop, regardless whether the file was registered
> previously. This also implies that git-rm will always leave
> unregistered files alone.]
Ok, this is somewhat incorrect: if we call git-rm and the file still
exists, this is strictly speaking the same situation as calling
git-add when a file does not exist.
And that gives:
fatal: pathspec 'geo' did not match any files
whether or not the repository has an idea about the file.
So in analogy, git-rm on an existing file could possibly made to barf.
Anyway, the following appears inconsistent to me:
touch geo
git-add geo
git-commit -m xxx -a
git-rm geo
[Now geo is gone]
git-add geo
[geo is complained about as unknown]
git-checkout geo
[geo is complained about as unknown!]
Now the last complaint clearly is quite a nuisance, because
git-checkout .
_will_ resurrect geo.
So for consistency's sake, it would appear that git-rm should really
only schedule a removal, and pull through only at the moment where the
file is actually removed from the repository. There is a slight
discordance with git-add in that git-add requires the existence of the
file at the time of the add. That is inevitable since git records the
_contents_ of the file at the time of the add. git-rm does not need
any such information.
Now what if a file disappears before we commit, namely
touch woozle
git add woozle
rm woozle
?
Woozle will in that case get committed if and only if the commit is
done without the -a option.
Makes sense. So in a nutshell: git-rm should not look at the working
directory. That's the business of the commit. When the repository
copy gets removed, this is the right time to remove the corresponding
file, and this is perfectly equivalent with the case for trees.
What _is_ strange is that a git-rmed file can't be restored by naming
it for a checkout.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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