* [PATCH 2/4] git-gui i18n: Update German glossary according to mailing list discussion.
From: Christian Stimming @ 2007-10-05 20:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, git
In-Reply-To: <200710052239.02492.stimming@tuhh.de>
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
po/glossary/de.po | 45 ++++++++++++++++++++++++++++++++++-----------
1 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/po/glossary/de.po b/po/glossary/de.po
index aab3b22..054cf4d 100644
--- a/po/glossary/de.po
+++ b/po/glossary/de.po
@@ -6,7 +6,8 @@
msgid ""
msgstr ""
"Project-Id-Version: git-gui glossary\n"
-"PO-Revision-Date: 2007-07-26 14:45+0200\n"
+"POT-Creation-Date: 2007-10-05 22:30+0200\n"
+"PO-Revision-Date: 2007-10-05 22:32+0200\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German \n"
"MIME-Version: 1.0\n"
@@ -19,11 +20,17 @@ msgid ""
msgstr ""
"Deutsche Übersetzung.\n"
"Andere deutsche SCM:\n"
-" http://tortoisesvn.net/docs/release/TortoiseSVN_de/index.html und http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Languages/Tortoise_de.po (username=guest, password empty, gut),\n"
-" http://msdn.microsoft.com/de-de/library/ms181038(vs.80).aspx (MS Visual Source Safe, kommerziell),\n"
-" http://cvsbook.red-bean.com/translations/german/Kap_06.html (mittelmäßig),\n"
-" http://tortoisecvs.cvs.sourceforge.net/tortoisecvs/po/TortoiseCVS/de_DE.po?view=markup (mittelmäßig),\n"
-" http://rapidsvn.tigris.org/svn/rapidsvn/trunk/src/locale/de/rapidsvn.po (username=guest, password empty, schlecht)"
+" http://tortoisesvn.net/docs/release/TortoiseSVN_de/index.html und http://"
+"tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Languages/Tortoise_de.po "
+"(username=guest, password empty, gut),\n"
+" http://msdn.microsoft.com/de-de/library/ms181038(vs.80).aspx (MS Visual "
+"Source Safe, kommerziell),\n"
+" http://cvsbook.red-bean.com/translations/german/Kap_06.html "
+"(mittelmäßig),\n"
+" http://tortoisecvs.cvs.sourceforge.net/tortoisecvs/po/TortoiseCVS/de_DE.po?"
+"view=markup (mittelmäßig),\n"
+" http://rapidsvn.tigris.org/svn/rapidsvn/trunk/src/locale/de/rapidsvn.po "
+"(username=guest, password empty, schlecht)"
#. ""
msgid "amend"
@@ -43,19 +50,31 @@ msgstr "verzweigen"
#. ""
msgid "checkout [noun]"
-msgstr "Auscheck? Ausspielung? Abruf? (Source Safe: Auscheckvorgang)"
+msgstr ""
+"Arbeitskopie (Erstellung einer Arbeitskopie; Auscheck? Ausspielung? Abruf? "
+"Source Safe: Auscheckvorgang)"
#. "The action of updating the working tree to a revision which was stored in the object database."
msgid "checkout [verb]"
-msgstr "auschecken? ausspielen? abrufen? (Source Safe: auschecken)"
+msgstr ""
+"Arbeitskopie erstellen; Zweig umstellen [checkout a branch] (auschecken? "
+"ausspielen? abrufen? Source Safe: auschecken)"
+
+#. ""
+msgid "clone [verb]"
+msgstr "kopieren"
#. "A single point in the git history."
msgid "commit [noun]"
-msgstr "Übertragung (Sendung?, Übergabe?, Einspielung?, Ablagevorgang?)"
+msgstr ""
+"Version; Eintragung; Änderung (Buchung?, Eintragung?, Übertragung?, "
+"Sendung?, Übergabe?, Einspielung?, Ablagevorgang?)"
#. "The action of storing a new snapshot of the project's state in the git history."
msgid "commit [verb]"
-msgstr "übertragen (TortoiseSVN: übertragen; Source Safe: einchecken; senden?, übergeben?, einspielen?, einpflegen?, ablegen?)"
+msgstr ""
+"eintragen (TortoiseSVN: übertragen; Source Safe: einchecken; senden?, "
+"übergeben?, einspielen?, einpflegen?, ablegen?)"
#. ""
msgid "diff [noun]"
@@ -87,7 +106,11 @@ msgstr "zusammenführen"
#. ""
msgid "message"
-msgstr "Meldung (Nachricht?; Source Safe: Kommentar)"
+msgstr "Beschreibung (Meldung?, Nachricht?; Source Safe: Kommentar)"
+
+#. ""
+msgid "prune"
+msgstr "löschen"
#. "Pulling a branch means to fetch it and merge it."
msgid "pull"
--
1.5.3.rc2.6.g40240
^ permalink raw reply related
* [PATCH] git-config: don't silently ignore options after --list
From: Frank Lichtenheld @ 2007-10-05 20:16 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
Error out if someone gives options after --list since that is
not a valid syntax.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
builtin-config.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
Two minutes of my life I don't get back ;)
diff --git a/builtin-config.c b/builtin-config.c
index 0a605e0..cb7e9e9 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -172,8 +172,11 @@ int cmd_config(int argc, const char **argv, const char *prefix)
type = T_INT;
else if (!strcmp(argv[1], "--bool"))
type = T_BOOL;
- else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
+ else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l")) {
+ if (argc != 2)
+ usage(git_config_set_usage);
return git_config(show_all_config);
+ }
else if (!strcmp(argv[1], "--global")) {
char *home = getenv("HOME");
if (home) {
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Christian Stimming @ 2007-10-05 20:39 UTC (permalink / raw)
To: Johannes Schindelin, Shawn Pearce; +Cc: git
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
po/glossary/git-gui-glossary.pot | 12 ++++++++++--
po/glossary/git-gui-glossary.txt | 2 ++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/po/glossary/git-gui-glossary.pot b/po/glossary/git-gui-glossary.pot
index c955b46..a2e5c73 100644
--- a/po/glossary/git-gui-glossary.pot
+++ b/po/glossary/git-gui-glossary.pot
@@ -6,12 +6,12 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2007-07-27 19:21+0200\n"
+"POT-Creation-Date: 2007-10-05 22:30+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: ENCODING\n"
#. "English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
@@ -42,6 +42,10 @@ msgstr ""
msgid "checkout [verb]"
msgstr ""
+#. ""
+msgid "clone [verb]"
+msgstr ""
+
#. "A single point in the git history."
msgid "commit [noun]"
msgstr ""
@@ -82,6 +86,10 @@ msgstr ""
msgid "message"
msgstr ""
+#. ""
+msgid "prune"
+msgstr ""
+
#. "Pulling a branch means to fetch it and merge it."
msgid "pull"
msgstr ""
diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
index bb55aa8..b53740d 100644
--- a/po/glossary/git-gui-glossary.txt
+++ b/po/glossary/git-gui-glossary.txt
@@ -5,6 +5,7 @@
"branch [verb]" ""
"checkout [noun]" ""
"checkout [verb]" "The action of updating the working tree to a revision which was stored in the object database."
+"clone [verb]" ""
"commit [noun]" "A single point in the git history."
"commit [verb]" "The action of storing a new snapshot of the project's state in the git history."
"diff [noun]" ""
@@ -15,6 +16,7 @@
"merge [noun]" "A successful merge results in the creation of a new commit representing the result of the merge."
"merge [verb]" "To bring the contents of another branch into the current branch."
"message" ""
+"prune" ""
"pull" "Pulling a branch means to fetch it and merge it."
"push" "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
"redo" ""
--
1.5.3.rc2.6.g40240
^ permalink raw reply related
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Linus Torvalds @ 2007-10-05 19:33 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Sam Ravnborg, Pierre Habouzit, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <37fcd2780710051227n96d29a9v543831ca8292c862@mail.gmail.com>
On Fri, 5 Oct 2007, Dmitry Potapov wrote:
>
> On the other hand, I don't see what is the problem with using C string
> routines with it. ::data() returns a pointer and :capacity () returns
> allocated size of the buffer. ::resize() changes the size of the string.
> If you need a greater allocated size, you can use ::reserve().
> Or did I miss something?
No, you didn't miss anything. Except for the fact that the original point
was that it's just a damn lot simpler and more straightforward to code
just using "sb->buf" for the data. IOW, go back two or three emails in the
thread.
Linus
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Dmitry Potapov @ 2007-10-05 19:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sam Ravnborg, Pierre Habouzit, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <alpine.LFD.0.999.0710051036282.23684@woody.linux-foundation.org>
On 10/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> - Qt (QString): QString::"data()", "ascii()" or "utf8()" or something.
>
> At least this has the excuse of really being able to handle different
> locales (it didn't do that originally, though!), but they end up having
> a million helper functions exactly because you cannot use the normal
> string routines on anything!
I am afraid you cannot allow the direct access to the internal buffer of
a string if this buffer can be implicitly shared between different
instances as it is the case with QString. Because when you want to make
some modification or want to get a non-const pointer to this buffer, its
content has to be copied if the buffer is shared between a few copies.
On the other hand, I don't see what is the problem with using C string
routines with it. ::data() returns a pointer and :capacity () returns
allocated size of the buffer. ::resize() changes the size of the string.
If you need a greater allocated size, you can use ::reserve().
Or did I miss something?
Dmitry
^ permalink raw reply
* Re: Many gits are offline this week
From: Jeff King @ 2007-10-05 18:33 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Randal L. Schwartz, git
In-Reply-To: <37fcd2780710051019l37b3dde2p57f24fef27b62bf6@mail.gmail.com>
On Fri, Oct 05, 2007 at 09:19:02PM +0400, Dmitry Potapov wrote:
> > "git-commit -a" also detects files that have been deleted, whereas
> > "git-add" does not.
> I just tried "git-add -u ." and it *does* detect deleted files.
IIRC, this was a fix by Junio recently, but I can't seem to find the
commit.
-Peff
^ permalink raw reply
* Re: Question about "git commit -a"
From: Marko Macek @ 2007-10-05 18:16 UTC (permalink / raw)
To: Kristian Høgsberg
Cc: Andreas Ericsson, Paolo Ciarrocchi, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Wincent Colaiuta, Git Mailing List
In-Reply-To: <1191599763.7117.18.camel@hinata.boston.redhat.com>
> I understand why people like staging and commit without -a, seeing how
> it's faster and all, but I have a serious problem with this practice
> that I haven't seen brought up on the list. How do you know what you
> commit actually works or even compiles? The reason that I almost
> exclusively use -a with commit is that I want to know that what I just
> compiled and tested is what I will be committing. I don't want to just
> commit half the files in my working copy, I want to make sure that the
> exact state of my project that I just compiled and tested is what gets
> into version controlled history.
>
> git commit -a isn't sloppy to me - eye balling some subset of your
> working copy and committing that under the assumption that you don't
> make mistakes and don't need to compile what you commit... that is
> sloppy.
Agreed. For this reason git-commit without -a, staging, index, ... is
not really interesting to me.
In CVS and subversion (which has nicer working-copy command line interface IMHO),
I simply make a copy of the working copy, revert the non-commitable parts, build,
commit the minor changes, and then update the first copy. For larger projects,
where this can be slow, I use diff/revert/patch.
Small checkins are nice for git-bisect, but if they don't build...
Mark
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Linus Torvalds @ 2007-10-05 18:05 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Pierre Habouzit, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005172425.GD31413@uranus.ravnborg.org>
On Fri, 5 Oct 2007, Sam Ravnborg wrote:
>
> Point taken although no sane person would name it strbuf_to_c(...).
I agree with the "no sane person", but the problem is that the insane
people seem to be in no short supply.
Go look at string libraries, and they all do something like that. Or
worse.
- ustr: yes, it uses *exactly* what I described: "ustr_cstr()" and
"ustr_len()" instead of having the data/length available easily
(although it claims to do it for size reasons - perhaps valid in some
cases!)
- libast: SPIF_CHARPTR_C(x). No, really.
- Vstr: doesn't have a linear data representation. Needs explicit
flattening - although it appears to be something you're not ever
supposed to do - it has 200+ functions to do various magic things.
- Qt (QString): QString::"data()", "ascii()" or "utf8()" or something.
At least this has the excuse of really being able to handle different
locales (it didn't do that originally, though!), but they end up having
a million helper functions exactly because you cannot use the normal
string routines on anything!
- safesrtr, bstring: you just cast the pointer to "char *". Now *that* is
classy and safe.
So there's a few sane out there, but I actually think they are in the
minority (Glib, others)
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Steven Grimm @ 2007-10-05 17:48 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071005164912.GE4797@xp.machine.xx>
Peter Baumann wrote:
> That's new to me. Glancing over git-commit.sh, I could only find a
> 'git-gc --auto', but no prune. I am not against doing a 'git gc --auto',
> but I am against the --prune, because this could make shared
> repositories unfunctional.
>
Does anyone run "git svn dcommit" from a shared repository? That is the
only command that will trigger this code path.
Given that you lose all the svn metadata if you do "git clone" (or "git
clone -s") on a git-svn-managed repository, it's not clear to me that
anyone would ever be bitten by this. Counterexamples welcome, of course.
How would you feel about a separate config option to specifically enable
auto-pruning, and having "git svn clone" set that option by default?
Presumably anyone who is setting up a shared git-svn repository will be
up to the task of disabling the option.
-Steve
^ permalink raw reply
* Re: Problems using StGit and -rt kernel patchset
From: Clark Williams @ 2007-10-05 17:28 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <1191591921.7321.63.camel@pc1117.cambridge.arm.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Catalin Marinas wrote:
> Clark,
>
> What version of StGIT are you using? You might use a too new GIT with an
> older StGIT or maybe there are just some bugs in StGIT.
>
$ stg --version
Stacked GIT 0.13
git version 1.5.3.3
Python version 2.5.1 (r251:54863, Sep 14 2007, 10:49:05)
[GCC 4.1.2 20070821 (Red Hat 4.1.2-23)]
> On Wed, 2007-10-03 at 09:19 -0500, Clark Williams wrote:
>> I've been working on the -rt patch series for the kernel and would like to to use
>> StGit to manage the patches. Unfortunately I've had limited success, so I thought I'd
>> ask the git/stgit community if what I'm doing is wrong.
>>
>> I clone Linus's tree to a common directory, then clone it locally to work:
>>
>> $ git clone -s -l /home/src/linux-2.6.git scratch.git
>> $ cd scratch.git
>> $ stg init
>> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc8
>> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc8-rt1/series
>> <fix the things quilt lets through and stg barfs on, like malformed email addresses>
>
> If git-quiltimport behaves better with malformed patches, use it and run
> 'stg uncommit -n 368' afterwards (the 'uncommit' takes some other useful
> options as well, see --help).
Ah, I *knew* I had seen a git import command go by on the list. I may try that.
>
>> <watch 368 patches be applied and committed>
>> <work work work>
>
> Do you modify any of the -rt patches or you create new ones?
I've modified patches in the past, but normally I just apply patches on top of the
- -rt patchset
>
>> <get a new patch queue>
>> $ (cd /home/src/linux-2.6.git && git pull)
>> $ stg pull
>> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc9
>> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc9-rt1/series
>> Checking for changes in the working directory ... done
>> stg import: env git-commit-tree 520b9d0db6a1142271a68b2b38cca002be40f6cb -p
>> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 failed (fatal:
>> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 is not a valid 'commit' object)
>
> I'm not sure why the first import worked. It seems that StGIT uses the
> tag id (da0a81e9) rather than the corresponding commit id (3146b39c). I
> remember having this problem in the past when creating branches and I
> fixed StGIT to always get the corresponding commit id. Using
> 'v2.6.23-rc9^{commit}' as the 'branch' argument rather than just the tag
> should fix the problem.
>
Gah, I just realized I typoed the above stg branch. It should have been named
rt-2.6.23-rc9-rt1.
Hmmm, you're saying that when I want to create a branch that's based on a particular
tag, I need to use this:
$ stg branch --create rt-2.6.23-rc9-rt1 v2.6.23-rc9^{commit}
That is, add '^{commit}' to the tag I want to base from?
>> At this point I'm clueless as to:
>>
>> 1. What I've done wrong
>
> Probably nothing (just hidden features of StGIT :-))
>
>> 2. How to recover/debug this
>
> You can recreate the branch with the commit rather than tag id. With a
> sufficiently new StGIT, you could use 'stg rebase <id>' on the branch. I
> assume that no patch was pushed because import failed (though the first
> imported patch might be in an undefined state and can be removed).
>
I'm not really sure that 'stg rebase' is what I want, since I tend to go back and
forth between -rt kernel and would like to leave them alone (i.e. not rebase the
rt-2.6.23-rt8 branch to rt-2.6.23-rt9, but just create a new branch). Possibly I'm
missing a usage for stg rebase?
Thanks for the ideas. I'll go try some out right now!
clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHBnRUqA4JVb61b9cRAvoPAJsG4Ej3J6mSuHeT6KEpiRF33+4dcgCglmvT
18DbpCixAt/x+Ug0pUn24cw=
=oL/g
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Sam Ravnborg @ 2007-10-05 17:25 UTC (permalink / raw)
To: Pierre Habouzit, Linus Torvalds, Junio C Hamano, git,
Bernt Hansen
In-Reply-To: <20071005163517.GD20305@artemis.corp>
On Fri, Oct 05, 2007 at 06:35:17PM +0200, Pierre Habouzit wrote:
> On Fri, Oct 05, 2007 at 04:21:39PM +0000, Sam Ravnborg wrote:
> > On Fri, Oct 05, 2007 at 08:26:44AM -0700, Linus Torvalds wrote:
> > >
> > >
> > > On Fri, 5 Oct 2007, Pierre Habouzit wrote:
> > > >
> > > > - strbuf_grow(buf, len);
> > > > + /* only grow if not in place */
> > > > + if (strbuf_avail(buf) + buf->len < len)
> > > > + strbuf_grow(buf, len - buf->len);
> > >
> > > Umm. This is really ugly.
> > >
> > > The whole point of strbuf's was that you shouldn't be doing your own
> > > allocation decisions etc. So why do it?
> > >
> > > Wouldn't it be much better to have a strbuf_make_room() interface that
> > > just guarantees that there is enough room fo "len"?
> > >
> > > Otherwise, code like the above would seem to make the whole point of a
> > > safer string interface rather pointless. The above code only makes sense
> > > if you know how the strbuf's are internally done, so it should not exists
> > > except as internal strbuf code. No?
> >
> > Took a short look at strbuf.h after seeing the above code.
> > And I was suprised to see that all strbuf users were exposed to
> > the strbuf structure.
> > Following patch would at least make sure noone fiddle with strbuf internals.
> > Cut'n'paste - only for the example of it.
> > It simply moves strbuf declaration to the .c file where it rightfully belongs.
>
> you're looking at an antiquated version, please look at the one in
> current master on current next. In this one, what you can do or not do
> with the struct is explained
>
> > git did not build with this change....
>
> Of course it doesn't! people want to have direct access to ->buf and
> ->len, and it's definitely OK.
Understood now - thanks for the clarification.
Sam
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Sam Ravnborg @ 2007-10-05 17:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <alpine.LFD.0.999.0710050933330.23684@woody.linux-foundation.org>
Hi Linus.
> No, following patch is fundamentally broken - it's not even a good
> starting point. It's bad, bad, bad.
>
> It's also broken in another way: we want it to be really easy to use
> strbuf's as normal C strings.
>
> Yes, many (totally idiotic and broken) interfaces think it's so important
> to "protect" their internal data structures that you have a
> "string_to_c()" helper function for that. That may be "good abstraction",
> but it's totally idiotic, because it results in horrible source code!
>
> Tell me which is more readable:
>
> printf("Hello %s\n", sb->buf);
>
> or
>
> printf("Hello %s\n", strbuf_to_c(sb));
Point taken although no sane person would name it strbuf_to_c(...).
Sam
^ permalink raw reply
* Re: Many gits are offline this week
From: Dmitry Potapov @ 2007-10-05 17:19 UTC (permalink / raw)
To: Dmitry Potapov, Randal L. Schwartz, git
In-Reply-To: <20071005162029.GA18522@old.davidb.org>
> >I believe I have found one mistake in your slides. Slide 18 reads:
> >"git-commit -a" is like "git-add .; git-commit"
> >
> >But it is incorrect, because "git-commit -a" does not add new files, so
> >it works like "git-add -u .; git-commit".
>
> "git-commit -a" also detects files that have been deleted, whereas
> "git-add" does not.
I just tried "git-add -u ." and it *does* detect deleted files.
$ git-status
# On branch master
nothing to commit (working directory clean)
$ rm oldfile
$ git-status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: oldfile
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git-add -u .
$ git-status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: oldfile
#
$ git-commit
Created commit 17e2bba: delete
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 oldfile
So, it works exactly as "git-commit -a" in this case.
Dmitry
^ permalink raw reply
* RE: [ALTERNATE PATCH] Add a simple option parser.
From: Linus Torvalds @ 2007-10-05 16:51 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: Pierre Habouzit, Mike Hommey, Kristian H?gsberg, git,
Junio C Hamano
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270162501A@az33exm24.fsl.freescale.net>
On Fri, 5 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
>
> From what I understand argp is part of glibc.
So are you arguing that we include all of glibc just to get git to be
portable?
That's even worse.
Linus
^ permalink raw reply
* Re: [ALTERNATE PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-05 16:49 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: Linus Torvalds, Mike Hommey, Kristian H?gsberg, git,
Junio C Hamano
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270162501A@az33exm24.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
On Fri, Oct 05, 2007 at 04:41:48PM +0000, Medve Emilian-EMMEDVE1 wrote:
> Hello Linus,
>
>
> > On Fri, 5 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
> > > >
> > > > Because it's GNU and that it's a heavy dependency to begin with.
> > >
> > > So it's more of a political decision then a technical one?
> >
> > I'd *strongly* argue against new dependencies unless they buy us
> > something major.
> >
> > We've been good at cutting them down, including any required
> > libraries internally. We shouldn't add new ones.
> >
> > So we'd have to include GNU getopt sources with the git tree, at
> > which point any advantage would be gone. Might as well include a
> > private and simpler version of our own.
>
>
> From what I understand argp is part of glibc.
And of course requiring the glibc would be a big step forward for the
msys (or AIX, or HP-UX, or …) port !
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Peter Baumann @ 2007-10-05 16:49 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <47066255.6080500@midwinter.com>
On Fri, Oct 05, 2007 at 09:12:05AM -0700, Steven Grimm wrote:
> Peter Baumann wrote:
>> I don't like the automatic prune. What if someone has other objects in
>> there which shouldn't be pruned? Making git svn dcommit doing the prune
>> would be at least suprising, because how is one supposed to know that
>> doing a commit into svn will prune all your precious objects?
>>
>
> "git commit" already does garbage collection, so we've already set a
> precedent for a commit operation also doing some cleanup at the end.
> However, you're correct that this cleanup behavior (and the way to turn it
> off) should be documented so that there's some way to know about it. Doc
> patch forthcoming.
>
That's new to me. Glancing over git-commit.sh, I could only find a
'git-gc --auto', but no prune. I am not against doing a 'git gc --auto',
but I am against the --prune, because this could make shared
repositories unfunctional.
-Peter
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Linus Torvalds @ 2007-10-05 16:43 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Pierre Habouzit, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005162139.GC31413@uranus.ravnborg.org>
On Fri, 5 Oct 2007, Sam Ravnborg wrote:
>
> Took a short look at strbuf.h after seeing the above code.
> And I was suprised to see that all strbuf users were exposed to
> the strbuf structure.
Well, they *have* to. We want people to declare their strbufs as automatic
or static structures, and using a opaque struct pointer is *not* an option
(like "FILE" is doing in stdio.h).
> Following patch would at least make sure noone fiddle with strbuf internals.
No, following patch is fundamentally broken - it's not even a good
starting point. It's bad, bad, bad.
It's also broken in another way: we want it to be really easy to use
strbuf's as normal C strings.
Yes, many (totally idiotic and broken) interfaces think it's so important
to "protect" their internal data structures that you have a
"string_to_c()" helper function for that. That may be "good abstraction",
but it's totally idiotic, because it results in horrible source code!
Tell me which is more readable:
printf("Hello %s\n", sb->buf);
or
printf("Hello %s\n", strbuf_to_c(sb));
and I claim that anybody who claims that the latter is "more readable" is
full of shit, and has an agenda to push, so it's "more agenda-friendly"
rather than readable!
So having "sb->buf" and "sb->len" be visible to users is a *good* thing.
Otherwise you end up having to create millions of idiotic small helper
functions, rather than just use the standard ones.
Linus
^ permalink raw reply
* RE: [ALTERNATE PATCH] Add a simple option parser.
From: Medve Emilian-EMMEDVE1 @ 2007-10-05 16:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pierre Habouzit, Mike Hommey, Kristian H?gsberg, git,
Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710050924530.23684@woody.linux-foundation.org>
Hello Linus,
> On Fri, 5 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
> > >
> > > Because it's GNU and that it's a heavy dependency to begin with.
> >
> > So it's more of a political decision then a technical one?
>
> I'd *strongly* argue against new dependencies unless they buy us
> something major.
>
> We've been good at cutting them down, including any required
> libraries
> internally. We shouldn't add new ones.
>
> So we'd have to include GNU getopt sources with the git tree,
> at which
> point any advantage would be gone. Might as well include a
> private and
> simpler version of our own.
>From what I understand argp is part of glibc.
Cheers,
Emil.
^ permalink raw reply
* Re: [ALTERNATE PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-05 16:38 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86wsu1v8ha.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
On Fri, Oct 05, 2007 at 04:20:33PM +0000, David Kastrup wrote:
> "Medve Emilian-EMMEDVE1" <Emilian.Medve@freescale.com> writes:
>
> > Hi Pierre,
> >
> >> -----Original Message-----
> >> From: Pierre Habouzit [mailto:madcoder@debian.org]
> >> Sent: Friday, October 05, 2007 10:57 AM
> >> To: Medve Emilian-EMMEDVE1
> >> Cc: Mike Hommey; Kristian Høgsberg; git@vger.kernel.org;
> >> Junio C Hamano
> >> Subject: Re: [ALTERNATE PATCH] Add a simple option parser.
> >>
> >> On ven, oct 05, 2007 at 03:45:36 +0000, Medve Emilian-EMMEDVE1 wrote:
> >> > You probably already considered and rejected the GNU argp parser. I
> >> > used it before and I'd like to know reasons I should stay away from
> >> > it.
> >>
> >> Because it's GNU and that it's a heavy dependency to begin with.
> >
> > So it's more of a political decision then a technical one?
>
> Well, if it is GNU then it is likely to mean GPLv3 (or GPLv3+) at some
> point of time, though it should certainly be possible for now to still
> secure a v2-licensed version (either GPL or LGPL).
That is an issue indeed.
> And the typical git developer AFAICT prefers to consider themselves as
> unaligned with GNU and the FSF as much as possible.
And is nothing near reality in my case.
The real issue is dependency and bloat. getopt_long would need the GNU
implementation, That I believe depends upon gettext, and argp is just
bloated, and I'm not even sure it's distributed outside from the glibc
anyways.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Pierre Habouzit @ 2007-10-05 16:35 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linus Torvalds, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005162139.GC31413@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
On Fri, Oct 05, 2007 at 04:21:39PM +0000, Sam Ravnborg wrote:
> On Fri, Oct 05, 2007 at 08:26:44AM -0700, Linus Torvalds wrote:
> >
> >
> > On Fri, 5 Oct 2007, Pierre Habouzit wrote:
> > >
> > > - strbuf_grow(buf, len);
> > > + /* only grow if not in place */
> > > + if (strbuf_avail(buf) + buf->len < len)
> > > + strbuf_grow(buf, len - buf->len);
> >
> > Umm. This is really ugly.
> >
> > The whole point of strbuf's was that you shouldn't be doing your own
> > allocation decisions etc. So why do it?
> >
> > Wouldn't it be much better to have a strbuf_make_room() interface that
> > just guarantees that there is enough room fo "len"?
> >
> > Otherwise, code like the above would seem to make the whole point of a
> > safer string interface rather pointless. The above code only makes sense
> > if you know how the strbuf's are internally done, so it should not exists
> > except as internal strbuf code. No?
>
> Took a short look at strbuf.h after seeing the above code.
> And I was suprised to see that all strbuf users were exposed to
> the strbuf structure.
> Following patch would at least make sure noone fiddle with strbuf internals.
> Cut'n'paste - only for the example of it.
> It simply moves strbuf declaration to the .c file where it rightfully belongs.
you're looking at an antiquated version, please look at the one in
current master on current next. In this one, what you can do or not do
with the struct is explained
> git did not build with this change....
Of course it doesn't! people want to have direct access to ->buf and
->len, and it's definitely OK.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about "git commit -a"
From: Matthieu Moy @ 2007-10-05 16:33 UTC (permalink / raw)
To: Kristian Høgsberg
Cc: Andreas Ericsson, Paolo Ciarrocchi, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Wincent Colaiuta, Git Mailing List
In-Reply-To: <1191599763.7117.18.camel@hinata.boston.redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> I understand why people like staging and commit without -a, seeing how
> it's faster and all,
Actually, commit without -a is not much faster, since it runs "status"
internally, to show it to the user when launching the editor. So, it
still checks for changes in the working tree.
> but I have a serious problem with this practice that I haven't seen
> brought up on the list. How do you know what you commit actually
> works or even compiles?
That's a general problem with partial commits, and that's why I
personnaly don't like partial commits in general ($scm commit file1
file2 has the same problem, \forall $scm).
To me, the right approach to partial commit is to stash the unwanted
changes, test, commit, and unstash.
(side note: it would be cool to have a "git stash --unstaged" command,
to put the unstaged changes aside, and match the tree to the index. A
good approximation for that is:
$ git stash # put all aside
$ git reset --mixed stash^2 # get back what the index used to be
$ git add -u # and put it back into the index.
)
*But*, the cool thing with git is that you can view rather easily not
only what you're about to commit (git diff --cached), but also what
you're about _not_ to commit (git diff). So, if the unstaged changes
are trivial enough, it can be OK (for example, Linus changes the linux
version in a Makefile a few commits before the release, and doesn't
add it to the index, to keep it as a reminder).
But I agree with your that splitting a huge patch into smaller ones
using just the index is bad practice, except if you intend to come
back to each commit and test it later.
--
Matthieu
^ permalink raw reply
* RE: [ALTERNATE PATCH] Add a simple option parser.
From: Linus Torvalds @ 2007-10-05 16:28 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: Pierre Habouzit, Mike Hommey, Kristian H?gsberg, git,
Junio C Hamano
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701624FF2@az33exm24.fsl.freescale.net>
On Fri, 5 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
> >
> > Because it's GNU and that it's a heavy dependency to begin with.
>
> So it's more of a political decision then a technical one?
I'd *strongly* argue against new dependencies unless they buy us
something major.
We've been good at cutting them down, including any required libraries
internally. We shouldn't add new ones.
So we'd have to include GNU getopt sources with the git tree, at which
point any advantage would be gone. Might as well include a private and
simpler version of our own.
Linus
^ permalink raw reply
* Re: [ALTERNATE PATCH] Add a simple option parser.
From: David Kastrup @ 2007-10-05 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701624FF2@az33exm24.fsl.freescale.net>
"Medve Emilian-EMMEDVE1" <Emilian.Medve@freescale.com> writes:
> Hi Pierre,
>
>> -----Original Message-----
>> From: Pierre Habouzit [mailto:madcoder@debian.org]
>> Sent: Friday, October 05, 2007 10:57 AM
>> To: Medve Emilian-EMMEDVE1
>> Cc: Mike Hommey; Kristian Høgsberg; git@vger.kernel.org;
>> Junio C Hamano
>> Subject: Re: [ALTERNATE PATCH] Add a simple option parser.
>>
>> On ven, oct 05, 2007 at 03:45:36 +0000, Medve Emilian-EMMEDVE1 wrote:
>> > You probably already considered and rejected the GNU argp parser. I
>> > used it before and I'd like to know reasons I should stay away from
>> > it.
>>
>> Because it's GNU and that it's a heavy dependency to begin with.
>
> So it's more of a political decision then a technical one?
Well, if it is GNU then it is likely to mean GPLv3 (or GPLv3+) at some
point of time, though it should certainly be possible for now to still
secure a v2-licensed version (either GPL or LGPL).
GNU also means a different coding and indentation style.
Personally, I couldn't care less about both points (I prefer the GNU
coding style anyway), but that's for the maintainer to decide, and one
also has to take into account the effect on developer motivation.
And the typical git developer AFAICT prefers to consider themselves as
unaligned with GNU and the FSF as much as possible.
--
David Kastrup
^ permalink raw reply
* Re: Many gits are offline this week
From: David Brown @ 2007-10-05 16:20 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Randal L. Schwartz, git
In-Reply-To: <37fcd2780710050741x1760a585yeaa9023a8d8cdccf@mail.gmail.com>
On Fri, Oct 05, 2007 at 06:41:43PM +0400, Dmitry Potapov wrote:
>I believe I have found one mistake in your slides. Slide 18 reads:
>"git-commit -a" is like "git-add .; git-commit"
>
>But it is incorrect, because "git-commit -a" does not add new files, so
>it works like "git-add -u .; git-commit".
"git-commit -a" also detects files that have been deleted, whereas
"git-add" does not. In fact, I haven't found an easy way to detect this
other than "git-commit -a", and it is the only reason I ever run
"git-commit -a"
Dave
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Sam Ravnborg @ 2007-10-05 16:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, Junio C Hamano, git, Bernt Hansen
In-Reply-To: <alpine.LFD.0.999.0710050819540.23684@woody.linux-foundation.org>
On Fri, Oct 05, 2007 at 08:26:44AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 5 Oct 2007, Pierre Habouzit wrote:
> >
> > - strbuf_grow(buf, len);
> > + /* only grow if not in place */
> > + if (strbuf_avail(buf) + buf->len < len)
> > + strbuf_grow(buf, len - buf->len);
>
> Umm. This is really ugly.
>
> The whole point of strbuf's was that you shouldn't be doing your own
> allocation decisions etc. So why do it?
>
> Wouldn't it be much better to have a strbuf_make_room() interface that
> just guarantees that there is enough room fo "len"?
>
> Otherwise, code like the above would seem to make the whole point of a
> safer string interface rather pointless. The above code only makes sense
> if you know how the strbuf's are internally done, so it should not exists
> except as internal strbuf code. No?
Took a short look at strbuf.h after seeing the above code.
And I was suprised to see that all strbuf users were exposed to
the strbuf structure.
Following patch would at least make sure noone fiddle with strbuf internals.
Cut'n'paste - only for the example of it.
It simply moves strbuf declaration to the .c file where it rightfully belongs.
git did not build with this change....
Sam
diff --git a/strbuf.c b/strbuf.c
index e33d06b..0d2d578 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -1,6 +1,14 @@
#include "cache.h"
#include "strbuf.h"
+struct strbuf {
+ int alloc;
+ int len;
+ int eof;
+ char *buf;
+};
+
+
void strbuf_init(struct strbuf *sb) {
sb->buf = NULL;
sb->eof = sb->alloc = sb->len = 0;
diff --git a/strbuf.h b/strbuf.h
index 74cc012..c057be3 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -1,11 +1,6 @@
#ifndef STRBUF_H
#define STRBUF_H
-struct strbuf {
- int alloc;
- int len;
- int eof;
- char *buf;
-};
+struct strbuf;
extern void strbuf_init(struct strbuf *);
extern void read_line(struct strbuf *, FILE *, int);
^ permalink raw reply related
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