* Re: Allowing push --dry-run through fetch url
From: Junio C Hamano @ 2009-11-06 9:44 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20091106073707.GA14881@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> The typical use of both at the same time is to put an authenticated
> value for pushurl (ssh://, for example) and an anonymous one (git://,
> for example) for url.
>
> What has been annoying me lately is that git push --dry-run asks me
> for the ssh key or password. I know I could be using an ssh-agent, but
> that's not the point.
I actually sense a possible XY problem here.
What are you trying to achieve with "git push --dry-run", especially when
you would instead be doing an equivalent of "git fetch" (or "ls-remote")
but not storing what you learned from that session with a change like what
you are imagining?
The answer to the above question is the real reason "X".
It could be that what you are interested in is if you are ahead of the
other side. In other words, you would want to know if some branches
result in non-fast-forward error, causing you to re-fetch and re-merge (or
rebase).
And "push --dry-run" that fails would give you that information, if it
worked for you without authenticating. And that could be your "Y".
But doesn't "branch -v" give the necessary information for that purpose
and even a bit more? Couldn't "git fetch && git branch -v" be a better
solution for your real problem "X"?
It is a better solution _if_ the real problem you are trying to solve is
what I suspected above because:
(1) If you will end up fetching to make you ahead of them again, doing
"push --dry-run" to learn fast-forwardness first would still require
you to fetch from there anyway. With "git fetch && git branch -v",
you have already fetched when you learned that you are not ahead;
(2) When you learn from "git fetch && git branch -v" that you were indeed
ahead, you can push. In such a case, because you were ahead, the
fetch wouldn't have slurped a lot of data from the other end anyway,
so there is no real overhead for doing so.
(3) In either case, "branch -v" output would give you not just "is it
fast-forward?" but also "if not, by how much they have diverged" (in
addition to the commit message for the tip).
But this may not be an XY problem. I am just curious.
^ permalink raw reply
* Re: Problem signing a tag
From: Michael J Gruber @ 2009-11-06 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joshua J. Kugler, Alex Riesen, git
In-Reply-To: <7vy6mk91ig.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 05.11.2009 21:09:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Dig dig dig... gpg exits with 2 in a lot of cases, one would need to
>> parse fd-error to find out more. But it also looks as if gpg exits
>> normally with a good passphrase. So I tried, and at least with gpg 1.4.9
>> and git 1.6.5.2 I can sign tags with "use-agent" and without a running
>> agent: I get asked for the passphrase (after reporting the agent MIA),
>> and everything's fine.
>>
>> My gpg returns 0 in this case; it returns 2 only if I don't enter the
>> passphrase. So, this seems to depend on the version of gpg. Or on
>> entering the correct passphrase ;)
>
> If the problematic gpg that gives 2 is older than yours, the situation
> looks to me that "exiting 2 when failed to contact agent but got a good
> passphrase some other way and successfully signed" was diagnosed as a bug
> and then fixed in gpg. If that is the case can we find out which version
> that fix is in, and add an entry to FAQ to help next person who will be
> hit by this when using "tag -s"?
Both of us seem to be using gpg 1.4.9, which is weird. I even checked
Fedora's srpm, they don't apply any patches for this. For the record,
I'm doing
unset GPG_AGENT_INFO
echo a |gpg -bsa
with "use-agent" and a default key signing specified in my gpg conf.
This returns "0" if I enter the correct passphrase (after being warned
about the missing agent) and "2" if I enter a wrong one repeatedly.
Joshua, your reports seem to confirm that you get 2 in both cases from
your gpg 1.4.9, right?
Michael
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Mike Hommey @ 2009-11-06 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx8s0yy1.fsf@alter.siamese.dyndns.org>
On Fri, Nov 06, 2009 at 01:44:54AM -0800, Junio C Hamano wrote:
<snip>
> But doesn't "branch -v" give the necessary information for that purpose
> and even a bit more? Couldn't "git fetch && git branch -v" be a better
> solution for your real problem "X"?
Usually, when I run git push --dry-run, it's to check that what follows
(usually the refspec part) does what I want it to do, such as not pushing
tags I didn't intend to push(*), and stuff like that.
Mike
(*) the fact that all tags from all remotes are being mixed doesn't help,
here, and without dry-running, I end up pushing tags from one remote onto
another.
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Junio C Hamano @ 2009-11-06 10:00 UTC (permalink / raw)
To: Jeff King; +Cc: Brian Collins, git
In-Reply-To: <20091106084855.GA20964@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> git-grep currently throws an error when you combine the -F and -i
>> flags. This isn't in line with how GNU grep handles it. This patch
>> allows the simultaneous use of those flags.
>
> I don't see a reason not to allow this combination if our grep
> implementation supports it. My only reservation would be that we
> sometimes call out to an external grep, and non-GNU grep might barf on
> this. But I think that is OK, as the user should get a sane error from
> the external grep.
I think that is OK but not for the reason you stated. The user should
never get such an error message.
The reason why I think this is OK is because the builder can choose to use
NO_EXTERNAL_GREP if the external grep does not allow this combination.
We need to update comments on the Makefile if we are going to take this
patch. Currently the description suggests three possible reasons you
might want to choose NO_EXTERNAL_GREP. "lacks grep" is obvious, "slower"
is not about correctness, but "is broken" is way underspecified, and this
patch adds one more reason to label your "grep" as broken.
Currently, SunOS and IRIX/IRIX64 are the only ones that specify
NO_EXTERNAL_GREP, and I suspect both are defined due to "is broken", but
we do not tell the builder in what way they are considered broken, iow,
what features we expect from the platform "grep", so somebody coming up
with a new port would be at loss.
I suspect 01ae841 (SunOS grep does not understand -C<n> nor -e, 2009-07-23)
would be a good starting point. Something like this...
# Define NO_EXTERNAL_GREP if you don't want "git grep" to ever call
# your external grep (e.g., if your system lacks grep, if its grep
# does not support necessary features, or spawning external process is
# slower than built-in grep git has). To be usable, your grep must
# support -C<n> (show n lines of context), -e <pattern> (primarily
# used to quote a pattern that begins with a dash), and use of -F and
# -i at the same time. Otherwise define this.
But I didn't try hard to find out what _else_ we are depending on.
> Tests? They help prove to us that your feature works, and also prevent
> us from accidentally breaking your feature in the future.
Yeah, thanks. The latter is the primary purpose of test.
^ permalink raw reply
* Timur Sufiev: Re: [PATCH I18N filenames v2 3/3] Provide compatibility with MinGW
From: Timur Sufiev @ 2009-11-06 10:00 UTC (permalink / raw)
To: git
[-- Attachment #1: forwarded message --]
[-- Type: message/rfc822, Size: 2205 bytes --]
From: Timur Sufiev <tsufiev@gmail.com>
To: Peter Krefting <peter@softwolves.pp.se>
Subject: Re: [PATCH I18N filenames v2 3/3] Provide compatibility with MinGW
Date: Tue, 03 Nov 2009 19:53:44 +0300
Hello, Peter
> Hi!
>
> Instead of calling the open_i18n() which converts from UTF-8 to a local
> 8-bit character set, this should probably call a version that converts from
> UTF-8 to UTF-16 and uses _wopen().
>
> Same thing for fopen_i18n() and _wfopen().
>
> I created a small RFC patch for that that changed parts of the system
> earlier this year - http://kerneltrap.org/mailarchive/git/2009/3/2/5350814
>
> I did not address readdir() and friends, I'm not sure if they are available
> in UTF-16 form or if they need to be rewritten using findfirst()/findnext().
>
> --
> \\// Peter - http://www.softwolves.pp.se/
I've decided to stick to local 8-bit encoding for now having considered
the following issues:
1. Many git front-ends, e.g. TortoiseGit, use 8-bit set, not UTF-16:
they call git plumbing commands and pass filenames to command line (in
local 8-bit encoding). So, using [UTF-8] <-> [UTF-16] approach, I had to
deal with 3 different encodings: UTF-8, UTF-16 and local 8-bit one
(CP1251 in my case). Moreover, Windows itself uses both UTF-16 and
CP1251, so one had to deal with reencoding between them (if he plans to
support UTF-16). Too much confusion.
2. UTF-16 is a proper solution for Windows, but my patch is useful for
other OSes with locales different from UTF-8 (e.g. Linux with KOI8-R
locale).
Still there is a possibility that one day we'll stumble upon some UTF-8
symbol which cannot not be correctly mapped into 8-bit encoding. UTF-16
would be a remedy in this case, but what if don't have it (see 2)?
--
Timur Sufiev
[-- Attachment #2: Signature --]
[-- Type: text/plain, Size: 17 bytes --]
--
Timur Sufiev
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Jeff King @ 2009-11-06 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Collins, git
In-Reply-To: <7vbpjg0y8k.fsf@alter.siamese.dyndns.org>
On Fri, Nov 06, 2009 at 02:00:11AM -0800, Junio C Hamano wrote:
> > I don't see a reason not to allow this combination if our grep
> > implementation supports it. My only reservation would be that we
> > sometimes call out to an external grep, and non-GNU grep might barf on
> > this. But I think that is OK, as the user should get a sane error from
> > the external grep.
>
> I think that is OK but not for the reason you stated. The user should
> never get such an error message.
>
> The reason why I think this is OK is because the builder can choose to use
> NO_EXTERNAL_GREP if the external grep does not allow this combination.
Yes, I think that would be a sane thing to do (and I suspect anyone
using non-GNU grep is probably already doing it). But what I meant more
was that the _transition_ should be fine. If we start shipping with this
patch but people haven't updated their build configuration, it is not
going to break horribly; it should just produce an error, which is what
it is doing now.
> # Define NO_EXTERNAL_GREP if you don't want "git grep" to ever call
> # your external grep (e.g., if your system lacks grep, if its grep
> # does not support necessary features, or spawning external process is
> # slower than built-in grep git has). To be usable, your grep must
> # support -C<n> (show n lines of context), -e <pattern> (primarily
> # used to quote a pattern that begins with a dash), and use of -F and
> # -i at the same time. Otherwise define this.
>
> But I didn't try hard to find out what _else_ we are depending on.
It is not really _us_ depending on it. It is "things the user wants to
do that _we_ support, but that their grep might not." So I don't think
there is much point in enumerating features. If their system grep
doesn't handle options that they want to use, then it won't work for
them. If they don't use them, then they will be fine.
Though "-e" might be the exception, as I think we might use it
unconditionally. But something like "-F -i" really depends on whether
the user wants to use it.
So I am fine with the text above, but I wouldn't worry too hard about
trying to come up with an exhaustive feature list.
-Peff
^ permalink raw reply
* Re: Automatically remote prune
From: Petr Baudis @ 2009-11-06 10:31 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, John Tapsell, Git List
In-Reply-To: <76718490911051638w7cd5306bx65ed8d9ac525d2c3@mail.gmail.com>
On Thu, Nov 05, 2009 at 07:38:39PM -0500, Jay Soffian wrote:
> On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis <pasky@suse.cz> wrote:
> > On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:
> >> Actually, mirror mode applies to push only. Unless I'm missing
> >> something obvious.
> >
> > Perhaps you are, mirror mode applies to fetch as well; that's how e.g.
> > repo.or.cz mirror mode is done currently.
>
> Can you please be more specific? There is no mention of mirror in
> builtin-fetch.c, only builtin-push.c. Further, the docs for
> "remote.<name>.mirror" indicate it's a push option only.
>
> So please explain what you mean by "that's how repo.or.cz mirror mode is done".
Ok, I got a bit confused there. :-) For fetches, it just sets up the
refspec to point to main namespace instead of refs/remote/, of course it
doesn't use the remote.*.mirror config. I'm not sure what Junio meant by
the change being easy, seeing that push uses a technical trick in
send-pack that doesn't seem to be straightforwardly applicable to
fetch... but I don't know this part of code too well.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* [PATCH] git_odb_open ckeck for valid path to database
From: Esben Mose Hansen @ 2009-11-06 12:32 UTC (permalink / raw)
To: ae; +Cc: git, Esben Mose Hansen
---
src/errors.c | 1 +
src/git/common.h | 3 +++
src/odb.c | 13 +++++++++++++
tests/t0204-opendb_errors.c | 38 ++++++++++++++++++++++++++++++++++++++
4 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 tests/t0204-opendb_errors.c
diff --git a/src/errors.c b/src/errors.c
index f348997..074c01c 100644
--- a/src/errors.c
+++ b/src/errors.c
@@ -36,6 +36,7 @@ static struct {
{ GIT_ENOTOID, "Not a git oid" },
{ GIT_ENOTFOUND, "Object does not exist in the scope searched" },
{ GIT_ENOMEM, "Not enough space" },
+ { GIT_ENOTDIR, "Not a directory" }
};
const char *git_strerror(int num)
diff --git a/src/git/common.h b/src/git/common.h
index c470e0e..96f2971 100644
--- a/src/git/common.h
+++ b/src/git/common.h
@@ -65,6 +65,9 @@
/** Consult the OS error information. */
#define GIT_EOSERR (GIT_ERROR - 4)
+/** The path is not a directory */
+#define GIT_ENOTDIR (GIT_ERROR - 5)
+
GIT_BEGIN_DECL
/** A revision traversal pool. */
diff --git a/src/odb.c b/src/odb.c
index 6d646a4..89d6d03 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -30,6 +30,10 @@
#include "hash.h"
#include "odb.h"
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
#define GIT_PACK_NAME_MAX (5 + 40 + 1)
struct git_pack {
git_odb *db;
@@ -1023,6 +1027,15 @@ int git_odb_open(git_odb **out, const char *objects_dir)
free(db);
return GIT_ERROR;
}
+ struct stat objects_dir_stat;
+ if (stat(db->objects_dir, &objects_dir_stat)) {
+ free(db);
+ return GIT_EOSERR;
+ }
+ if (!S_ISDIR(objects_dir_stat.st_mode)) {
+ free(db);
+ return GIT_ENOTDIR;
+ }
gitlck_init(&db->lock);
diff --git a/tests/t0204-opendb_errors.c b/tests/t0204-opendb_errors.c
new file mode 100644
index 0000000..e9b52c9
--- /dev/null
+++ b/tests/t0204-opendb_errors.c
@@ -0,0 +1,38 @@
+#include "test_lib.h"
+#include "test_helpers.h"
+#include <git/odb.h>
+#include "fileops.h"
+
+static char *odb_dir = "test-objects";
+
+static unsigned char one_bytes[] = {
+ 0x31, 0x78, 0x9c, 0xe3, 0x02, 0x00, 0x00, 0x0b,
+ 0x00, 0x0b,
+};
+
+static unsigned char one_data[] = {
+ 0x0a,
+};
+
+static object_data one = {
+ one_bytes,
+ sizeof(one_bytes),
+ "8b137891791fe96927ad78e64b0aad7bded08bdc",
+ "blob",
+ "test-objects/8b",
+ "test-objects/8b/137891791fe96927ad78e64b0aad7bded08bdc",
+ one_data,
+ sizeof(one_data),
+};
+
+BEGIN_TEST(opendb_errors)
+ git_odb *db;
+ int error = git_odb_open(&db, odb_dir);
+ must_be_true(error == GIT_EOSERR);
+ must_be_true(errno == ENOENT);
+ must_pass(write_object_files(odb_dir, &one));
+ error = git_odb_open(&db, one.file);
+ must_be_true(error == GIT_ENOTDIR);
+
+ must_pass(remove_object_files(odb_dir, &one));
+END_TEST
--
1.6.3.3
^ permalink raw reply related
* gitk: Update Japanese translation
From: Mizar @ 2009-11-06 13:57 UTC (permalink / raw)
To: paulus, git, gitster
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
The main changes are as follows.
Several issues remain and is pending because there is no improvement.
http://github.com/mizar/gitk/issues
| msgid ""
| "\n"
| "Gitk - a commit viewer for git\n"
| "\n"
| -"Copyright c 2005-2008 Paul Mackerras\n"
| +"Copyright © 2005-2008 Paul Mackerras\n"
| "\n"
| "Use and redistribute under the terms of the GNU General Public License"
| msgstr ""
| "\n"
| "Gitk - gitコミットビューア\n"
| "\n"
| -"Copyright c 2005-2008 Paul Mackerras\n"
| +"Copyright © 2005-2008 Paul Mackerras\n"
| "\n"
| "使用および再配布は GNU General Public License に従ってください"
| msgid "Author"
| -msgstr "作成者"
| +msgstr "作者"
| msgid "Committer"
| -msgstr "コミットした人"
| +msgstr "コミット者"
| msgid "Write commit to file"
| -msgstr "コミットをファイルに書き込む"
| +msgstr "コミットをファイルに書き出す"
| msgid "Error writing commit to file: %s"
| -msgstr "ファイルへのコミット書き込みエラー: %s"
| +msgstr "ファイルへのコミット書き出しエラー: %s"
| msgid "Write"
| -msgstr "書き込み"
| +msgstr "書き出し"
| msgid "Error writing commit:"
| -msgstr "コミット書き込みエラー:"
| +msgstr "コミット書き出しエラー:"
| -msgstr "この子孫を見つけてマークする"
| +msgstr "これとマークをつけた所との子孫を見つける"
| msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
| -msgstr "<Shift-Up>\t後ろを検索 (上方・後のコミット)"
| +msgstr "<Shift-Up>\t後方を検索 (上方の・新しいコミット)"
| msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
| -msgstr "<Shift-Down>\t前を検索（下方・前のコミット）"
| +msgstr "<Shift-Down>\t前方を検索（下方の・古いコミット）"
| msgid "Author:"
| -msgstr "作成者:"
| +msgstr "作者:"
| msgid "Committer:"
| -msgstr "コミットした人:"
| +msgstr "コミット者:"
| msgid "Children"
| -msgstr "子供達"
| +msgstr "子"
| +msgid "Interface"
| +msgstr "インターフェイス"
| +msgid "interface"
| +msgstr "インターフェイス"
| -msgid ""
| -"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
| -" Gitk requires at least Tcl/Tk 8.4."
| -msgstr ""
| -"申し訳ありませんが、このバージョンの Tcl/Tk では gitk を実行できません。\n"
| -" Gitk は最低でも Tcl/Tk 8.4 を必要とします。"
[-- Attachment #2: patch0.patch.gz --]
[-- Type: application/x-gzip, Size: 9048 bytes --]
[-- Attachment #3: ja.po.gz --]
[-- Type: application/x-gzip, Size: 8152 bytes --]
^ permalink raw reply
* gitk : french translation
From: Emmanuel Trillaud @ 2009-11-06 14:05 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
Hello all,
I made an attempt to translate gitk in french. The translation is
_almost_ complete
and I would really appreciate to have some comments by the french people here.
I also need to improve some translations I am not happy with so it's
really a work in progress.
Best regards,
Emmanuel Trillaud
[-- Attachment #2: fr.po.bz2 --]
[-- Type: application/x-bzip2, Size: 6915 bytes --]
^ permalink raw reply
* How to merge into my working copy?
From: Patrick Doyle @ 2009-11-06 14:53 UTC (permalink / raw)
To: git
I would like to pull a set of changes from a branch back into the
working copy of my current branch without affecting the index. I
can't figure out the right combination of --commit, --no-commit, -ff,
-no-ff, --log, --no-log, --squash, --no-squash, etc... options to use
with git-merge.
Basically, I created a branch off my mainline branch a few days ago.
Made some commits on that branch. Then went back to my mainline
branch, made a few commits there, and now I would like to make my
working copy look like a merge of its current state with the changes
from the branch, minus any associated commits.
I probably should have just used git-stash to tuck those changes away,
but I didn't.
--wpd
^ permalink raw reply
* Re: How to merge into my working copy?
From: Bruce Stephens @ 2009-11-06 14:59 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0911060653t7bbb54ebp948eac0dffeaba64@mail.gmail.com>
Patrick Doyle <wpdster@gmail.com> writes:
[...]
> Basically, I created a branch off my mainline branch a few days ago.
> Made some commits on that branch. Then went back to my mainline
> branch, made a few commits there, and now I would like to make my
> working copy look like a merge of its current state with the changes
> from the branch, minus any associated commits.
>
> I probably should have just used git-stash to tuck those changes away,
> but I didn't.
Rather than spending time worrying about optimal ways to do this,
wouldn't it work just to do merge (to get the right tree) followed by
rebase -i to get the commits in the way you want (removing the merge,
anyway)?
[...]
^ permalink raw reply
* [PATCH] gitweb: Fix blob linenr links in pathinfo mode
From: Petr Baudis @ 2009-11-06 15:08 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In pathinfo mode, we use <base href> that refers to the base location
of gitweb in order for various external media links to work well.
However, this means that for the page to refer to itself, it must
regenerate full link, and this is exactly what the blob view page
did not do for line numbers.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..62325ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5127,7 +5127,8 @@ sub git_blob {
chomp $line;
$nr++;
$line = untabify($line);
- printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
+ printf "<div class=\"pre\"><a id=\"l%i\" href=\"" . href(-replay => 1)
+ . "#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
$nr, $nr, $nr, esc_html($line, -nbsp=>1);
}
}
--
tg: (8cc62c1..) t/blob/pathinfo (depends on: vanilla/master)
^ permalink raw reply related
* [PATCH] gitweb: Refactor project list routines
From: Petr Baudis @ 2009-11-06 15:10 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
This is a preparatory patch for separation of project list and frontpage
actions; it factors out most logic of git_project_list():
* git_project_list_all() as a git_project_list_body() wrapper for
complete project listing
* git_project_search_form() for printing the project search form
Also, git_project_list_ctags() is now separated out of
git_project_list_body(), showing tag cloud for given project list.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++---------------------
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..e82ca45 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4201,10 +4201,9 @@ sub git_patchset_body {
# project in the list, removing invalid projects from returned list
# NOTE: modifies $projlist, but does not remove entries from it
sub fill_project_list_info {
- my ($projlist, $check_forks) = @_;
+ my ($projlist, $check_forks, $show_ctags) = @_;
my @projects;
- my $show_ctags = gitweb_check_feature('ctags');
PROJECT:
foreach my $pr (@$projlist) {
my (@activity) = git_get_last_activity($pr->{'path'});
@@ -4254,12 +4253,26 @@ sub print_sort_th {
}
}
+sub git_project_list_ctags {
+ my ($projects) = @_;
+
+ my %ctags;
+ foreach my $p (@$projects) {
+ foreach my $ct (keys %{$p->{'ctags'}}) {
+ $ctags{$ct} += $p->{'ctags'}->{$ct};
+ }
+ }
+ my $cloud = git_populate_project_tagcloud(\%ctags);
+ print git_show_project_tagcloud($cloud, 64);
+}
+
sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
my $check_forks = gitweb_check_feature('forks');
- my @projects = fill_project_list_info($projlist, $check_forks);
+ my $show_ctags = gitweb_check_feature('ctags');
+ my @projects = fill_project_list_info($projlist, $check_forks, $show_ctags);
$order ||= $default_projects_order;
$from = 0 unless defined $from;
@@ -4278,16 +4291,8 @@ sub git_project_list_body {
@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
}
- my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
- my %ctags;
- foreach my $p (@projects) {
- foreach my $ct (keys %{$p->{'ctags'}}) {
- $ctags{$ct} += $p->{'ctags'}->{$ct};
- }
- }
- my $cloud = git_populate_project_tagcloud(\%ctags);
- print git_show_project_tagcloud($cloud, 64);
+ git_project_list_ctags(\@projects);
}
print "<table class=\"project_list\">\n";
@@ -4361,6 +4366,28 @@ sub git_project_list_body {
print "</table>\n";
}
+sub git_project_search_form {
+ print $cgi->startform(-method => "get") .
+ "<p class=\"projsearch\">Search:\n" .
+ $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+ "</p>" .
+ $cgi->end_form() . "\n";
+}
+
+sub git_project_list_all {
+ my $order = $input_params{'order'};
+ if (defined $order && $order !~ m/none|project|descr|owner|age/) {
+ die_error(400, "Unknown order parameter");
+ }
+
+ my @list = git_get_projects_list();
+ if (!@list) {
+ die_error(404, "No projects found");
+ }
+
+ git_project_list_body(\@list, $order);
+}
+
sub git_shortlog_body {
# uses global variable $project
my ($commitlist, $from, $to, $refs, $extra) = @_;
@@ -4630,28 +4657,14 @@ sub git_search_grep_body {
## actions
sub git_project_list {
- my $order = $input_params{'order'};
- if (defined $order && $order !~ m/none|project|descr|owner|age/) {
- die_error(400, "Unknown order parameter");
- }
-
- my @list = git_get_projects_list();
- if (!@list) {
- die_error(404, "No projects found");
- }
-
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
insert_file($home_text);
print "</div>\n";
}
- print $cgi->startform(-method => "get") .
- "<p class=\"projsearch\">Search:\n" .
- $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
- "</p>" .
- $cgi->end_form() . "\n";
- git_project_list_body(\@list, $order);
+ git_project_search_form();
+ git_project_list_all();
git_footer_html();
}
--
tg: (8cc62c1..) t/frontpage/refactor (depends on: vanilla/master)
^ permalink raw reply related
* [PATCH] gitweb: Support for no project list on gitweb front page
From: Petr Baudis @ 2009-11-06 15:11 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
On very large sites like repo.or.cz (but maybe also git.debian.org,
git.kernel.org, etc.), it is desirable not to have the project list
on the front page since generating it is significant overhead and it
takes significant data transfer and load time for the user, who might
prefer to instead use the search form and possibly content tags to
navigate to the target project. A link to the full list of projects is
still available on the front page for users who wish to browse it. The
whole feature is turned off by default.
The patch introduces a new config variable $frontpage_no_project_list,
by default 0 keeping the current behavior; if set to 1, no project list
will be shown, but all projects will be still scanned if ctags are
enabled; if set to 2, no project will be shown and no projects will
be scanned while showing the front page. The compromise value of 1 is
useful for sites where project scan time is not an issue or which
use additional project list caching patches.
The patch furthermore modifies project_list action not to show the
index text, and introduces new default action frontpage which is by
default identical to old project_list action, but can be further
controlled by the $frontpage_no_project_list variable.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/README | 8 ++++++++
gitweb/gitweb.css | 5 +++++
gitweb/gitweb.perl | 32 +++++++++++++++++++++++++++++---
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 66c6a93..c5fd1b8 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -223,6 +223,14 @@ not include variables usually directly set during build):
repositories from launching cross-site scripting (XSS) attacks. Set this
to true if you don't trust the content of your repositories. The default
is false.
+ * $frontpage_no_project_list
+ If 0, the gitweb frontpage will contain the project list; if 1 instead,
+ it will contain just the index text, search form, tag cloud (if enabled)
+ and a link to the actual project list. The page is reduced, but all
+ projects still need to be scanned for the tag cloud construction. If the
+ option is set to 2, not even the tag cloud will be shown; this is fastest.
+ This option is useful for sites with large amount of projects. The default
+ is 0.
Projects list file format
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index cb3f0ba..9fee3f0 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -97,6 +97,11 @@ div.readme {
padding: 8px;
}
+p.projectlist_link {
+ text-align: center;
+ font-weight: bold;
+}
+
a.title:hover {
background-color: #d9d8d1;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 97e88b4..48326a4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -152,6 +152,11 @@ our @diff_opts = ('-M'); # taken from git_commit
# the gitweb domain.
our $prevent_xss = 0;
+# Whether to include project list on the gitweb front page; 0 means yes,
+# 1 means no list but show tag cloud if enabled (all projects still need
+# to be scanned), 2 means no list and no tag cloud (very fast)
+our $frontpage_no_project_list = 0;
+
# information about snapshot formats that gitweb is capable of serving
our %known_snapshot_formats = (
# name => {
@@ -601,6 +606,7 @@ our %actions = (
"object" => \&git_object,
# those below don't need $project
"opml" => \&git_opml,
+ "frontpage" => \&git_frontpage,
"project_list" => \&git_project_list,
"project_index" => \&git_project_index,
);
@@ -901,13 +907,13 @@ if (!defined $action) {
} elsif (defined $project) {
$action = 'summary';
} else {
- $action = 'project_list';
+ $action = 'frontpage';
}
}
if (!defined($actions{$action})) {
die_error(400, "Unknown action");
}
-if ($action !~ m/^(?:opml|project_list|project_index)$/ &&
+if ($action !~ m/^(?:opml|frontpage|project_list|project_index)$/ &&
!$project) {
die_error(400, "Project needed");
}
@@ -4377,6 +4383,7 @@ sub git_project_list_body {
sub git_project_search_form {
print $cgi->startform(-method => "get") .
+ $cgi->hidden({-name=>"a", -value=>"project_list"}) . "\n" .
"<p class=\"projsearch\">Search:\n" .
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
"</p>" .
@@ -4665,7 +4672,7 @@ sub git_search_grep_body {
## ======================================================================
## actions
-sub git_project_list {
+sub git_frontpage {
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
@@ -4673,6 +4680,25 @@ sub git_project_list {
print "</div>\n";
}
git_project_search_form();
+ if (not $frontpage_no_project_list) {
+ git_project_list_all();
+ } else {
+ my $show_ctags = gitweb_check_feature('ctags');
+ if ($frontpage_no_project_list == 1 and $show_ctags) {
+ my @list = git_get_projects_list();
+ my @projects = fill_project_list_info(\@list, gitweb_check_feature('forks'), $show_ctags);
+ git_project_list_ctags(\@projects);
+ }
+ print "<p class=\"projectlist_link\">" .
+ $cgi->a({-href => href(action=>'project_list')}, "Browse all projects") .
+ "</p>\n";
+ }
+ git_footer_html();
+}
+
+sub git_project_list {
+ git_header_html();
+ git_project_search_form();
git_project_list_all();
git_footer_html();
}
--
tg: (e731dcd..) t/frontpage/separate (depends on: t/frontpage/ctags)
^ permalink raw reply related
* [PATCH] gitweb: Polish the content tags support
From: Petr Baudis @ 2009-11-06 15:10 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
This patch integrates the tag filtering CGI parameter into the framework
for parameter passing, dropping 'by_tag' and instead using query name 't'
and symbolic name 'ctag_filter'. Compatibility support for 'by_tag' query
name is retained.
This means that content tag links are now created using $cgi->a() and
the href() method, and that they now point to the proper action;
project_list in case of global content tags, forks in case of per-fork
content tags. Also any other arguments like sorting order of projects
are replayed within the links.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e82ca45..97e88b4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -566,6 +566,7 @@ our @cgi_param_mapping = (
searchtext => "s",
searchtype => "st",
snapshot_format => "sf",
+ ctag_filter => 't',
extra_options => "opt",
search_use_regexp => "sr",
);
@@ -622,6 +623,11 @@ while (my ($name, $symbol) = each %cgi_param_mapping) {
}
}
+# Backwards compatibility - by_tag= <=> t=
+if ($cgi->param('by_tag')) {
+ $input_params{'ctag_filter'} = $cgi->param('by_tag');
+}
+
# now read PATH_INFO and update the parameter list for missing parameters
sub evaluate_path_info {
return if defined $input_params{'project'};
@@ -2257,7 +2263,7 @@ sub git_get_project_ctags {
}
sub git_populate_project_tagcloud {
- my $ctags = shift;
+ my ($ctags, $action) = @_;
# First, merge different-cased tags; tags vote on casing
my %ctags_lc;
@@ -2280,7 +2286,8 @@ sub git_populate_project_tagcloud {
$title =~ s/ / /g;
$title =~ s/^/ /g;
$title =~ s/$/ /g;
- $cloud->add($title, $home_link."?by_tag=".$_, $ctags_lc{$_}->{count});
+ $cloud->add($title, href(-replay=>1, action=>$action, ctag_filter=>$_),
+ $ctags_lc{$_}->{count});
}
} else {
$cloud = \%ctags_lc;
@@ -2289,14 +2296,15 @@ sub git_populate_project_tagcloud {
}
sub git_show_project_tagcloud {
- my ($cloud, $count) = @_;
+ my ($cloud, $count, $action) = @_;
print STDERR ref($cloud)."..\n";
if (ref $cloud eq 'HTML::TagCloud') {
return $cloud->html_and_css($count);
} else {
my @tags = sort { $cloud->{$a}->{count} <=> $cloud->{$b}->{count} } keys %$cloud;
return '<p align="center">' . join (', ', map {
- "<a href=\"$home_link?by_tag=$_\">$cloud->{$_}->{topname}</a>"
+ $cgi->a({-href => href(-replay=>1, action=>$action, ctag_filter=>$_)},
+ $cloud->{$_}->{topname});
} splice(@tags, 0, $count)) . '</p>';
}
}
@@ -4254,7 +4262,8 @@ sub print_sort_th {
}
sub git_project_list_ctags {
- my ($projects) = @_;
+ my ($projects, $action) = @_;
+ $action ||= 'project_list';
my %ctags;
foreach my $p (@$projects) {
@@ -4262,13 +4271,13 @@ sub git_project_list_ctags {
$ctags{$ct} += $p->{'ctags'}->{$ct};
}
}
- my $cloud = git_populate_project_tagcloud(\%ctags);
- print git_show_project_tagcloud($cloud, 64);
+ my $cloud = git_populate_project_tagcloud(\%ctags, $action);
+ print git_show_project_tagcloud($cloud, 64, $action);
}
sub git_project_list_body {
# actually uses global variable $project
- my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+ my ($projlist, $order, $from, $to, $extra, $no_header, $ctags_action) = @_;
my $check_forks = gitweb_check_feature('forks');
my $show_ctags = gitweb_check_feature('ctags');
@@ -4292,7 +4301,7 @@ sub git_project_list_body {
}
if ($show_ctags) {
- git_project_list_ctags(\@projects);
+ git_project_list_ctags(\@projects, $ctags_action);
}
print "<table class=\"project_list\">\n";
@@ -4309,7 +4318,7 @@ sub git_project_list_body {
"</tr>\n";
}
my $alternate = 1;
- my $tagfilter = $cgi->param('by_tag');
+ my $tagfilter = $input_params{'ctag_filter'};
for (my $i = $from; $i <= $to; $i++) {
my $pr = $projects[$i];
@@ -4682,7 +4691,7 @@ sub git_forks {
git_header_html();
git_print_page_nav('','');
git_print_header_div('summary', "$project forks");
- git_project_list_body(\@list, $order);
+ git_project_list_body(\@list, $order, undef, undef, undef, undef, 'forks');
git_footer_html();
}
@@ -4756,12 +4765,12 @@ sub git_summary {
my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
- my $cloud = git_populate_project_tagcloud($ctags);
+ my $cloud = git_populate_project_tagcloud($ctags, 'project_list');
print "<tr id=\"metadata_ctags\"><td>Content tags:<br />";
print "</td>\n<td>" unless %$ctags;
print "<form action=\"$show_ctags\" method=\"post\"><input type=\"hidden\" name=\"p\" value=\"$project\" />Add: <input type=\"text\" name=\"t\" size=\"8\" /></form>";
print "</td>\n<td>" if %$ctags;
- print git_show_project_tagcloud($cloud, 48);
+ print git_show_project_tagcloud($cloud, 48, 'project_list');
print "</td></tr>";
}
@@ -4805,7 +4814,7 @@ sub git_summary {
git_project_list_body(\@forklist, 'age', 0, 15,
$#forklist <= 15 ? undef :
$cgi->a({-href => href(action=>"forks")}, "..."),
- 'no_header');
+ 'no_header', 'forks');
}
git_footer_html();
--
tg: (73bafe5..) t/frontpage/ctags (depends on: t/frontpage/refactor)
^ permalink raw reply related
* Re: Preserving branches after merging on ancestor
From: rhlee @ 2009-11-06 15:21 UTC (permalink / raw)
To: git
In-Reply-To: <20091106050353.GA8824@progeny.tock>
Hi John, Björn and Eric,
Thank you very much for your replies from which I gained a lot insight about
git merging and different workflows.
Yes, I have tried out --no-ff and it does the job for me. (Incidentally,
doing that take it look neater in git gui as all the master nodes appear on
top of each other. Using empty commits, the merged branches appear on top
the master nodes in the graph.)
Jonathan Nieder-2 wrote:
>
> Then your response pushed me towards the question of whether --no-ff is a
> good idea in general
>
John, I get the feeling from what you say in general that fast forwards are
default behaviour for merges for a reason and by using the --no-ff option I
am making my workflow and git history uncessesarily awkward and working
against best practices?
Jonathan Nieder-2 wrote:
>
>> I guess Richard took the "branch topic1, merge topic1, branch topic2,
>> merge topic2" thing just as an example because that ends up with two
>> fast-forwards.
>
> Hmm, I found Richard’s example pretty realistic. I used to work like
> that, and I don’t think I am the only one.
>
I'm not saying there is any one "right" workflow. But is there a more
suitable workflow than than "branch topic1, merge topic1, branch topic2,
merge topic2"?
Thanks,
Richard
--
View this message in context: http://n2.nabble.com/Preserving-branches-after-merging-on-ancestor-tp3954131p3959325.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] gitweb: Refactor project list routines
From: Petr Baudis @ 2009-11-06 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <1257520246-6548-1-git-send-email-pasky@suse.cz>
Oops, I'm sorry, I expected tg mail to submit the mails in series...
The correct order is:
[PATCH] gitweb: Refactor project list routines
[PATCH] gitweb: Support for no project list on gitweb front page
[PATCH] gitweb: Polish the content tags support
(The blob linenr patch is independent.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Timur Sufiev: Re: [PATCH I18N filenames v2 3/3] Provide compatibility with MinGW
From: Peter Krefting @ 2009-11-06 14:55 UTC (permalink / raw)
To: Timur Sufiev; +Cc: git
In-Reply-To: <4af3f3cb.0305560a.7a34.0f43@mx.google.com>
Timur Sufiev:
> 1. Many git front-ends, e.g. TortoiseGit, use 8-bit set, not UTF-16:
All of them do, that is because the output is using 8-bit. That is why the
internal encoding need to remain eight-bit, for instance UTF-8.
> they call git plumbing commands and pass filenames to command line (in
> local 8-bit encoding).
Well, yes. On Windows, however, there is the complication that the command
line is available in two versions. There is a eight-bit and a UTF-16 version
of it. Which one is constructed from which depends on how the application
was launched. We can read the UTF-16 version and hope that it contains
proper names (possibly looking at the eight-bit version as UTF-8 if
necessary).
> 2. UTF-16 is a proper solution for Windows, but my patch is useful for
> other OSes with locales different from UTF-8 (e.g. Linux with KOI8-R
> locale).
Well, your patch re-implements the fopen() calls, converting the file name
at that point (as well as readdir() and friends). I would do that on Windows
as well, with the modification that on Windows, I would convert to UTF-16
and use _wfopen() instead. On systems that have it, you could also make it
convert to UTF-32 and use their wfopen() (I'm not aware of many other OSes
having those functions, though).
> Still there is a possibility that one day we'll stumble upon some UTF-8
> symbol which cannot not be correctly mapped into 8-bit encoding. UTF-16
> would be a remedy in this case, but what if don't have it (see 2)?
That is of course an issue. There are several approaches to that:
- Fail with an error.
- Convert to a place-holder character.
- QP encode the file name, perhaps?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Git drawbacks?
From: Dmitry Smirnov @ 2009-11-06 16:17 UTC (permalink / raw)
To: git
Hi,
Sorry if I selected the wrong place to discuss the drawbacks of the Git. Just
point to the proper one...
I'm just trying to select the best VCS for me personally.
I have a very small experience with Git but I see is also not very sutable for
me.
First, it seems to be very hard to setup some really big project (like Android,
for example). Otherwise, why do they need to invent 'repo'? What purpose it
solves? It looks like it
1. Integrates few subcomponents (projects) and checkout the code in the proper
configuration. The question is why this is not the Git task? For me, it looks
like the ClearCase client spec.
2.? What others (except integration with review tool)?
The next issue with git is its clone. Why do I need the whole set of revisions?
Why do I need to get 1GB of Android? You could say this should happen once. I
would agree but when I tried to resync the Android tree after 2 months, I was
struggled with many errors (both git and repo). Finally, I had decided to sync
again. :-)
There is one point against clone. The typical situation in my office is to have
few Perforce clients with the same or slightly different code. This is just
wasting a space since you need them all but versions of many files are the same.
I'm trying to imagine the same situation with Git. Are there any benefits? It
seems, no. Moreover, I will have not only few working trees but few repository
clones!
It is obvious that configuration management with Git is very difficult (for ex,
http://groups.google.com/group/repo-
discuss/browse_thread/thread/2fa368ed7cac5d79/64ced51656240ddc?
lnk=gst&q=create+android+bare+repository#64ced51656240ddc)
Let's consider the foolwing use case. Suppose I'm intending to create a new
product that consists of specific versions (or branches) of some subcomponents
(or directories). How can I do this with Git? Subsequent changes could either be
submitted to the appropriate component branch or branched to the new one (this
way is possible with Git, of course, if I will branch the code I need to this
new branch).
So, I'm wondering, why Git (or any other VCS) is not trying to solve these
problems? Perhaps, there is a simple solution with Git I'm not aware of?
Here is the wish list for the VCS I would prefer:
1. Atomit commits
2. The possibility to get any slice of the code repository with the possibility
to commit my changes on tip or on separate branch.
3. The minimum footprint of the same code on my local machine.
4. No code/history on my machine untill I really need it.
5. Easy mirroring and replication
I would say, ClearCase might be my favorite if it is not commercial. :-)
Dmitry
^ permalink raw reply
* Re: Git drawbacks?
From: Avery Pennarun @ 2009-11-06 16:49 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091106T160709-387@post.gmane.org>
On Fri, Nov 6, 2009 at 11:17 AM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Here is the wish list for the VCS I would prefer:
> 1. Atomit commits
> 2. The possibility to get any slice of the code repository with the possibility
> to commit my changes on tip or on separate branch.
> 3. The minimum footprint of the same code on my local machine.
> 4. No code/history on my machine untill I really need it.
> 5. Easy mirroring and replication
>
> I would say, ClearCase might be my favorite if it is not commercial. :-)
#1 and #5 are features of any DVCS, so git already has them. #2, 3,
and 4 are all just saying the same thing: "I can't afford the disk
space to store the entire repo." Are you sure this is true, or is it
a preconception? Even a 1GB repository is tiny by modern disk
standards.
My (limited) experience with ClearCase is that it's so slow that you'd
do *anything* to track fewer files in your working copy, so they put a
lot of work into exactly that, and no work into performance. This
lousy performance isn't the case in git (except in Windows). Are you
using Windows, by chance?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] pre-commit.sample: Diff against the empty tree when HEAD is invalid
From: Heiko Voigt @ 2009-11-06 17:11 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git
In-Reply-To: <20091105105757.GA31787@atjola.homenet>
Hallo,
On Thu, Nov 05, 2009 at 11:57:57AM +0100, Björn Steinbrink wrote:
> This was already the case for the old "diff --check" call, but the new
> one that checks whether there are any non-ascii file names was missing
> it, making that check fail for root commits.
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
[...]
> - test "$(git diff --cached --name-only --diff-filter=A -z |
> + test "$(git diff --cached --name-only --diff-filter=A -z $against |
Looks sensible to me. Thanks for that fix.
As this went unnoticed for quite some time it seems as either not many
are actually using our example hook or at least not starting new
projects with it. I fit in the latter group I suppose.
cheers Heiko
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-06 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911060849s2d8f13f5sb9b8390f075f8d15@mail.gmail.com>
> > Here is the wish list for the VCS I would prefer:
> > 1. Atomit commits
> > 2. The possibility to get any slice of the code repository with the
possibility
> > to commit my changes on tip or on separate branch.
> > 3. The minimum footprint of the same code on my local machine.
> > 4. No code/history on my machine untill I really need it.
> > 5. Easy mirroring and replication
> >
> > I would say, ClearCase might be my favorite if it is not commercial.
>
> #1 and #5 are features of any DVCS, so git already has them. #2, 3,
> and 4 are all just saying the same thing:
No, #2 is about the repository slicing, branching, merging (SCM in other words).
Let's suppose I have the product that have 2 directories: component1 and
component2. They were developing together for previous product (on the same
branch, for example). Now, I would like to have component1 and replace
component2 with some 3rd party component. What should I do with Git to get this?
Or maybe I wish to stick with some version of component2 and provide only bug
fixes for this product...
Or let's take a look at GDB. They are using binutils which are in separate
repository (they use CVS, but let's imagine they use Git). How many effors they
will need for SCM? For example, they would prefer to stick to some stable
version/branch of the binutils but should be able to commit bug fixes.
Once again, perhaps there is some way to do this with Git? I did not yet find
it.
> "I can't afford the disk
> space to store the entire repo." Are you sure this is true, or is it
> a preconception? Even a 1GB repository is tiny by modern disk
> standards.
oh, yes, since we have big drives and fast internet, we do not have to worry
about space and download time... :-)
> My (limited) experience with ClearCase is that it's so slow that you'd
> do *anything* to track fewer files in your working copy, so they put a
> lot of work into exactly that, and no work into performance.
This probably true. Thought I did not have a lot of problems with it unless I
use GUI.
> This
> lousy performance isn't the case in git (except in Windows). Are you
> using Windows, by chance?
yes. I did not yet noticed any performance problems with Git on windows, except
a sync/download time (for android, mostly)
^ permalink raw reply
* Re: Git drawbacks?
From: Jacob Helwig @ 2009-11-06 17:41 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091106T180313-750@post.gmane.org>
On Fri, Nov 6, 2009 at 09:35, Dmitry Smirnov <divis1969@gmail.com> wrote:
> No, #2 is about the repository slicing, branching, merging (SCM in other words).
> Let's suppose I have the product that have 2 directories: component1 and
> component2. They were developing together for previous product (on the same
> branch, for example). Now, I would like to have component1 and replace
> component2 with some 3rd party component. What should I do with Git to get this?
> Or maybe I wish to stick with some version of component2 and provide only bug
> fixes for this product...
> Or let's take a look at GDB. They are using binutils which are in separate
> repository (they use CVS, but let's imagine they use Git). How many effors they
> will need for SCM? For example, they would prefer to stick to some stable
> version/branch of the binutils but should be able to commit bug fixes.
>
> Once again, perhaps there is some way to do this with Git? I did not yet find
> it.
>
Sounds like you want submodules. Check out the git-submodule(1) manpage.
^ permalink raw reply
* Re: Git drawbacks?
From: Avery Pennarun @ 2009-11-06 17:51 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091106T180313-750@post.gmane.org>
On Fri, Nov 6, 2009 at 12:35 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> No, #2 is about the repository slicing, branching, merging (SCM in other words).
> Let's suppose I have the product that have 2 directories: component1 and
> component2. They were developing together for previous product (on the same
> branch, for example). Now, I would like to have component1 and replace
> component2 with some 3rd party component. What should I do with Git to get this?
> Or maybe I wish to stick with some version of component2 and provide only bug
> fixes for this product...
There are three methods I know of to manage this:
1) Just commit whatever version of a subproject you want as a subtree
of your current project, and if you want to replace/delete/upgrade it,
just do that. (You rarely want to track the actual *history* of the
third party tool, just the history of versions *you* used, which is
easy to do.)
2) Use git-submodule to link repositories together. (Arguably, one
major reason 'repo' was written is that git-submodule is too
complicated, though.)
3) Try my git-subtree tool, which basically makes it easier to
split/join repositories (similar to #1) without losing the history
(similar to #2).
>> This
>> lousy performance isn't the case in git (except in Windows). Are you
>> using Windows, by chance?
>
> yes. I did not yet noticed any performance problems with Git on windows, except
> a sync/download time (for android, mostly)
Basically, performance is linear with the number of files in your
repo. If you can check out just a "slice" of your repo (say 10% of
the whole), you'll have faster performance (eg. 10x) from any VCS.
git on Linux is so fast that this isn't very necessary most of the
time. But git on Windows isn't really any faster than other VCSes on
Windows, so the time-per-file is much greater, and thus the penalty
for huge repositories is much worse. Doing things like switching
branches, which is near-instantaneous on Linux even with tens of
thousands of files, really crawls on Windows.
So I can see an argument that Windows users would want arbitrary
"slices" much more often than Linux+git users, but I think this is
largely due to performance, not because people really *want* to be
stuck with a restricted view of the repo.
Have fun,
Avery
^ 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