* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 12:38 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git
In-Reply-To: <20091229123127.GA6154@bit.office.eurotux.com>
Hi Luciano,
>> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable
to
>> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
>
> Does the directory /var/cache/cgit/ exist?
Yap, with 777.
But the parent dirs don't, they have 755 the debian default, and both /var
& /var/log owner by root.
I also tryed to make /var & /var/log/ be owner by apache's user (www-data)
but nothing, and also tried make them 777 aswell, the same.
This lock dir can't be configureable?
^ permalink raw reply
* Re: Help on CGIT
From: Luciano Rocha @ 2009-12-29 12:31 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <31576a6d119e2edd66bd8bcc3281e9ad@192.168.1.222>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Tue, Dec 29, 2009 at 12:18:38PM +0000, Jorge Bastos wrote:
> Howdy people,
>
> Since i cannot find any CGIT web interface mailing list on their webpage,
> i'm asking here.
>
> I have CGIT working at 50%.
>
> The 1st page show's correctly, but when i click the project name, it
> becames unconfigured and wierd, and apache complains about this:
>
> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable to
> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
Does the directory /var/cache/cgit/ exist?
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Add --path-prefix option to git-fast-import
From: Gisle Aas @ 2009-12-29 12:51 UTC (permalink / raw)
To: git; +Cc: gitster, Gisle Aas
From: Gisle Aas <gisle@aas.no>
I found this useful when import multiple external repositories to be merged
into a single git repo. Not having the files be renamed during the merge
made it easier to follow the history of the individual files.
Signed-off-by: Gisle Aas <gisle@aas.no>
---
Documentation/git-fast-import.txt | 6 ++++++
fast-import.c | 24 ++++++++++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 288032c..b8f9593 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -58,6 +58,12 @@ OPTIONS
Maximum number of branches to maintain active at once.
See ``Memory Utilization'' below for details. Default is 5.
+--path-prefix=<str>:
+ Prepend the given prefix to all the paths imported.
+ This can be used to import stuff into a subdirectory
+ of where the original files where located. Most likely
+ you want <str> to end with a slash.
+
--export-marks=<file>::
Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`.
diff --git a/fast-import.c b/fast-import.c
index dd3c99d..32b0d70 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -351,6 +351,8 @@ static struct recent_command *rc_free;
static unsigned int cmd_save = 100;
static uintmax_t next_mark;
static struct strbuf new_data = STRBUF_INIT;
+static const char *path_prefix;
+static size_t path_prefix_len;
static void write_branch_report(FILE *rpt, struct branch *b)
{
@@ -1860,6 +1862,16 @@ static void load_branch(struct branch *b)
}
}
+static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
+{
+ if (p != sb->buf) {
+ strbuf_reset(sb);
+ strbuf_addstr(sb, p);
+ }
+ strbuf_insert(sb, 0, path_prefix, path_prefix_len);
+ return sb->buf;
+}
+
static void file_change_m(struct branch *b)
{
const char *p = command_buf.buf + 2;
@@ -1909,6 +1921,8 @@ static void file_change_m(struct branch *b)
die("Garbage after path in: %s", command_buf.buf);
p = uq.buf;
}
+ if (path_prefix)
+ p = path_prefix_prepend(&uq, p);
if (S_ISGITLINK(mode)) {
if (inline_data)
@@ -1961,6 +1975,8 @@ static void file_change_d(struct branch *b)
die("Garbage after path in: %s", command_buf.buf);
p = uq.buf;
}
+ if (path_prefix)
+ p = path_prefix_prepend(&uq, p);
tree_content_remove(&b->branch_tree, p, NULL);
}
@@ -1984,6 +2000,8 @@ static void file_change_cr(struct branch *b, int rename)
strbuf_add(&s_uq, s, endp - s);
}
s = s_uq.buf;
+ if (path_prefix)
+ s = path_prefix_prepend(&s_uq, s);
endp++;
if (!*endp)
@@ -1996,6 +2014,8 @@ static void file_change_cr(struct branch *b, int rename)
die("Garbage after dest in: %s", command_buf.buf);
d = d_uq.buf;
}
+ if (path_prefix)
+ d = path_prefix_prepend(&d_uq, d);
memset(&leaf, 0, sizeof(leaf));
if (rename)
@@ -2523,6 +2543,10 @@ int main(int argc, const char **argv)
if (max_depth > MAX_DEPTH)
die("--depth cannot exceed %u", MAX_DEPTH);
}
+ else if (!prefixcmp(a, "--path-prefix=")) {
+ path_prefix = a + 14;
+ path_prefix_len = strlen(path_prefix);
+ }
else if (!prefixcmp(a, "--active-branches="))
max_active_branches = strtoul(a + 18, NULL, 0);
else if (!prefixcmp(a, "--import-marks="))
--
1.6.6.rc4.12.g269e7
^ permalink raw reply related
* Re: [PATCH] Add --path-prefix option to git-fast-import
From: Sverre Rabbelier @ 2009-12-29 14:06 UTC (permalink / raw)
To: Gisle Aas; +Cc: git, gitster, Gisle Aas
In-Reply-To: <1262091083-25401-1-git-send-email-gisle.aas@it.uib.no>
Heya,
On Tue, Dec 29, 2009 at 06:51, Gisle Aas <gisle.aas@it.uib.no> wrote:
> +static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
> +{
> + if (p != sb->buf) {
> + strbuf_reset(sb);
> + strbuf_addstr(sb, p);
> + }
> + strbuf_insert(sb, 0, path_prefix, path_prefix_len);
> + return sb->buf;
> +}
> +
> static void file_change_m(struct branch *b)
> {
> const char *p = command_buf.buf + 2;
> @@ -1909,6 +1921,8 @@ static void file_change_m(struct branch *b)
> die("Garbage after path in: %s", command_buf.buf);
> p = uq.buf;
> }
> + if (path_prefix)
> + p = path_prefix_prepend(&uq, p);
You could reduce the size of this change by having path_prefix_prepend
check for path_prefix and just do nothing if it is not set.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Help on CGIT
From: Luciano Rocha @ 2009-12-29 14:08 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <9cf5f850c0c5ea8054e9bebc810ea6d3@192.168.1.222>
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
On Tue, Dec 29, 2009 at 12:38:15PM +0000, Jorge Bastos wrote:
> Hi Luciano,
>
> >> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable
> to
> >> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
> >
> > Does the directory /var/cache/cgit/ exist?
>
> Yap, with 777.
> But the parent dirs don't, they have 755 the debian default, and both /var
> & /var/log owner by root.
That's what they're supposed to be.
> I also tryed to make /var & /var/log/ be owner by apache's user (www-data)
> but nothing, and also tried make them 777 aswell, the same.
> This lock dir can't be configureable?
Probably, don't know much about cgit. One thing, are you using selinux?
What does sestatus show?
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Minor bug in bash completion
From: Sylvain RABOT @ 2009-12-29 14:36 UTC (permalink / raw)
To: spearce; +Cc: git
Hello,
I found a bug in the git bash completion.
It occurs when I press tab to complete branch name when I want to pull
from the origin.
Instead of completing the branch name it prompts me directly for my
password on the origin remote.
I pressed tab
here (just after mem)
|
srabot@khety:~/dev/ribeti.git[memcached]$ git pull origin
memsrabot@git.ps.agematis.loc's password:
srabot@git.ps.agematis.loc's password:
cached
srabot@git.ps.agematis.loc's password:
From git.ps.agematis.loc:/var/git/ribeti
* branch memcached -> FETCH_HEAD
Already up-to-date.
I'm using :
Linux khety 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009
i686 GNU/Linux
GNU bash, version 4.0.33(1)-release (i486-pc-linux-gnu)
git version 1.6.6
Best regards.
--
Sylvain
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 14:44 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git
In-Reply-To: <20091229140842.GB6154@bit.office.eurotux.com>
On Tue, 29 Dec 2009 14:08:42 +0000, Luciano Rocha <luciano@eurotux.com>
>> Yap, with 777.
>> But the parent dirs don't, they have 755 the debian default, and both
>> /var
>> & /var/log owner by root.
>
> That's what they're supposed to be.
>
>> I also tryed to make /var & /var/log/ be owner by apache's user
>> (www-data)
>> but nothing, and also tried make them 777 aswell, the same.
>> This lock dir can't be configureable?
>
> Probably, don't know much about cgit. One thing, are you using selinux?
> What does sestatus show?
no SELinux compiled or active on kernel.
don't even have setools installed on the system.
I'm out of ideas :(
The info on the web about CGIT is rare... don't find an answer for this.
^ permalink raw reply
* Re: Help on CGIT
From: Lars Hjemli @ 2009-12-29 14:57 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <31576a6d119e2edd66bd8bcc3281e9ad@192.168.1.222>
On Tue, Dec 29, 2009 at 13:18, Jorge Bastos <mysql.jorge@decimal.pt> wrote:
> I have CGIT working at 50%.
>
> The 1st page show's correctly, but when i click the project name, it
> becames unconfigured and wierd, and apache complains about this:
>
> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable to
> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
First, check if cgit works correctly with caching disabled (set
cache-size=0 in /etc/cgitrc).
> My apache configuration for CGIT is:
>
> AllowOverride None
> Options ExecCGI
> Order allow,deny
> Allow from all
>
> DirectoryIndex cgit.cgi
>
> AddHandler cgi-script cgi pl
>
What's the contents of /etc/cgitrc? Which cgit-version are you running?
--
larsh
^ permalink raw reply
* Re: Help on CGIT
From: Felipe Contreras @ 2009-12-29 14:58 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <31576a6d119e2edd66bd8bcc3281e9ad@192.168.1.222>
On Tue, Dec 29, 2009 at 2:18 PM, Jorge Bastos <mysql.jorge@decimal.pt> wrote:
> Am i missing something else? I've asked google but there's not much info
> on the web about it.
This is what I do:
ScriptAlias /cgit /var/www/cgit-files/cgit.cgi
You need a new cgit to use that properly, I use 0.8.3.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Smart-http: check if repository is OK to export before serving it
From: Shawn O. Pearce @ 2009-12-29 15:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tarmigan Casebolt, git
In-Reply-To: <7vy6kmjfwo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
>
> > Similar to how git-daemon checks whether a repository is OK to be
> > exported, smart-http should also check. This check can be satisfied
> > in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
> > may be set to export all repositories, or the individual repository
> > may have the file git-daemon-export-ok.
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
...
> Looks sane to me, although I am afraid that I am not as familiar with the
> codepath involved as I should be. Shawn, is your Ack still good?
Yes, my ACK is still good. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Wrap completions in `type git' conditional statement.
From: Shawn O. Pearce @ 2009-12-29 15:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Sung Pae, git
In-Reply-To: <20091229200530.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Junio, could you tell us what happened to this thread?
>
> The patch avoids failing completion script when git is not there.
> No discussion.
Actually, that's probably my fault. I never sent an ack or nak,
or anything else really, on this thread.
Originally this was because the completion was trying to run git
as it loaded. In 1.6.6 this is no longer true, the completion list
is generated lazily on demand during the first completion attempt.
With the lazy loading, I didn't see a reason to add this ugly block
around the entire script.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add --path-prefix option to git-fast-import
From: Shawn O. Pearce @ 2009-12-29 15:08 UTC (permalink / raw)
To: Gisle Aas; +Cc: git, gitster, Gisle Aas
In-Reply-To: <1262091083-25401-1-git-send-email-gisle.aas@it.uib.no>
Gisle Aas <gisle.aas@it.uib.no> wrote:
> I found this useful when import multiple external repositories to be merged
> into a single git repo. Not having the files be renamed during the merge
> made it easier to follow the history of the individual files.
>
> Signed-off-by: Gisle Aas <gisle@aas.no>
> ---
> Documentation/git-fast-import.txt | 6 ++++++
> fast-import.c | 24 ++++++++++++++++++++++++
> 2 files changed, 30 insertions(+), 0 deletions(-)
Interesting. Test cases?
> +static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
> +{
> + if (p != sb->buf) {
> + strbuf_reset(sb);
> + strbuf_addstr(sb, p);
> + }
I'd be a bit happier about the change if you could check not only
that p != sb->buf, but that p is not within sb->buf + sb->alloc.
I can't remember if all of the cases below are safe such that
any time you call the function with a p that p isn't pointing to
something within the strbuf you are handing in.
--
Shawn.
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 15:21 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530912290658m70075ad1u95e3692c01fb44b7@mail.gmail.com>
> This is what I do:
> ScriptAlias /cgit /var/www/cgit-files/cgit.cgi
>
> You need a new cgit to use that properly, I use 0.8.3.
I tried that way, no luck, apache always show on the errors that cannot
create the lock slot and it show all unconfigured on the page.
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 15:29 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530912290658m70075ad1u95e3692c01fb44b7@mail.gmail.com>
> This is what I do:
> ScriptAlias /cgit /var/www/cgit-files/cgit.cgi
>
> You need a new cgit to use that properly, I use 0.8.3.
Forgot to say, i'm running the last git version so i believe i'm updated
for that.
^ permalink raw reply
* Re: config for merging master to test branch
From: Daniel Convissor @ 2009-12-29 16:43 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20091228233838.GA28052@panix.com>
Hello Again Folks:
On Mon, Dec 28, 2009 at 06:38:39PM -0500, Daniel Convissor wrote:
>
> Now, here's the question. I want to go back into the testing directory
> and do a "git pull" and have the changes from master automatically merged
> into my test branch in one step, without having to do an explicit set of
> checkouts and merges.
I found this is possible by being in the "test" checkout and calling
"git pull origin master". Is this the best way to do it?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: config for merging master to test branch
From: Junio C Hamano @ 2009-12-29 16:53 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20091229164343.GA17546@panix.com>
Daniel Convissor <danielc@analysisandsolutions.com> writes:
> On Mon, Dec 28, 2009 at 06:38:39PM -0500, Daniel Convissor wrote:
>>
>> Now, here's the question. I want to go back into the testing directory
>> and do a "git pull" and have the changes from master automatically merged
>> into my test branch in one step, without having to do an explicit set of
>> checkouts and merges.
>
> I found this is possible by being in the "test" checkout and calling
> "git pull origin master". Is this the best way to do it?
Good. That is how it was designed to be used ;-)
If you feel lazy and want to omit typing " origin master", you could add a
few configuration items in your .git/config in the test repository.
[branch "test"]
remote = origin
merge = refs/heads/master
That configures git in such a way that...
When on branch "test", "pull" and "fetch" by default interact with the
"origin" repository, and "pull" integrates what was found on the
'master' branch from that remote into your history.
^ permalink raw reply
* Re: [PATCH] Documentation: always respect core.worktree if set
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <1262072921-11280-1-git-send-email-pclouds@gmail.com>
Thanks; I'll take this "match documentation to reality with caveats" patch
for now, but I personally think we should revisit the issue someday.
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Mike Hommey
In-Reply-To: <20091229200517.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> After discussing "git push --dry-run" that looks at URL used for
> fetching, because pushURL might require authentication, the
> maintainer recalls an earlier "git push --confirm" patch
>
> http://thread.gmane.org/gmane.comp.version-control.git/128426/focus=128429
>
> but nothing happens after that.
Your analysis is correct --- nothing happened after that ;-)
I think it is probably worthwhile to revisit Owen's patch, though. Back
then I was worried too much about giving IDE authors (who need to scrape
the output and interact with the "confirm" interface) enough flexibility
and wanted to see an interface to allow plugging a more machine readable
interaction before proceeding, but I changed my mind.
We can have --confirm with two output styles, one that is for consumption
by human sitting in front of a terminal (and is prone to future UI
tinkering like coloring), and the other with machine readable interaction,
that is more or less frozen (or "extensible"). And it is perfectly Ok to
start only with the human readable one, clearly documented that it is not
(yet) for use by IDE via scraping.
But I won't be the person with the --confirm itch, so interested people
need to help to make that happen.
Thanks for a stream of reminders, by the way.
^ permalink raw reply
* Re: [PATCH RFC v2] builtin-push: add --delete as syntactic sugar for :foo
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jan Krüger, Git ML, Sverre Rabbelier
In-Reply-To: <20091229200523.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> The patch implements "git push repo --delete branch" and rejects
> --delete used with other options like --all and --tags, as suggested in
> the initial review. I think it makes sense, but nothing happens after
> that.
Sverre cited an old discussion and the discussion stalled. I just re-read
the thread, and think the "this is a wrong idea" objection was primarily
about allowing --delete with non-delete kinds of refspecs, so in that
sense Jan's patch is a perfected form of the Sverre's patch from that old
discussion.
As a summary of the lesson learned and concensus from the old discussion,
I agree with this from Sverre:
http://article.gmane.org/gmane.comp.version-control.git/125901
namely, (1) barf and abort if src:dst is given; (2) touch only refs given
from the command line, "push there --delete" without any refspec is an
error; (3) be careful about "git push there tag v1.0.0" form.
So if Jan or Sverre want to resurrect the topic, I am all for it.
^ permalink raw reply
* Re: [PATCH] Wrap completions in `type git' conditional statement.
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, Junio C Hamano, Sung Pae, git
In-Reply-To: <20091229150217.GB6152@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Junio, could you tell us what happened to this thread?
>>
>> The patch avoids failing completion script when git is not there.
>> No discussion.
>
> Actually, that's probably my fault. I never sent an ack or nak,
> or anything else really, on this thread.
>
> Originally this was because the completion was trying to run git
> as it loaded. In 1.6.6 this is no longer true, the completion list
> is generated lazily on demand during the first completion attempt.
>
> With the lazy loading, I didn't see a reason to add this ugly block
> around the entire script.
Thanks, both.
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thomas Rast, git
In-Reply-To: <20091229200513.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> The patch rejects "git pull repo A:B" because it is almost always a mistake;
> I think it makes sense.
It seems that we got sidetracked into a long thread on different (but
interesting) side topics. I think what the patch attempts to do is quite
sane, and the implementation is very straightforward. Perhaps we should
resurrect it, but with a proper "declare deprecation now, first warn then
refuse in two releases" steps. I.e. the actual refusal would happen in
1.7.1 or later.
One side topic was Daniel wondering if we should restrict the value of B
for "git fetch repo A:B" so that "fetch" is not used to update the refs
outside refs/remotes namespace. I personally think it is an unwarranted
restriction, and also it is more or less an unrelated issue anyway.
Another side topic that distracted us was about the difference between the
autogenerated commit log messages for "git pull origin topic" and "git
fetch && git merge origin/topic". I personally think it is very good that
the latter already says "Merge remote branch 'origin/topic'" and there is
no need to turn that into "Merge 'topic' of ..." (actually I'd prefer it
the way it is).
^ permalink raw reply
* Re: [PATCH] Documentation: always respect core.worktree if set
From: Robin Rosenberg @ 2009-12-29 17:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Robin Rosenberg
In-Reply-To: <7v7hs5hg46.fsf@alter.siamese.dyndns.org>
tisdagen den 29 december 2009 17.58.17 skrev Junio C Hamano:
> Thanks; I'll take this "match documentation to reality with caveats" patch
> for now, but I personally think we should revisit the issue someday.
>
I'm happy with this.
-- robin
^ permalink raw reply
* Re: config for merging master to test branch
From: Daniel Convissor @ 2009-12-29 17:56 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <7vvdfphgbu.fsf@alter.siamese.dyndns.org>
Hi Junio:
> Good. That is how it was designed to be used ;-)
Thanks for the reassurance.
> [branch "test"]
> remote = origin
> merge = refs/heads/master
>
> When on branch "test", "pull" and "fetch" by default interact with the
> "origin" repository, and "pull" integrates what was found on the
> 'master' branch from that remote into your history.
Excellent. Initially, I wasn't sure what the following commands did:
git config branch.test.remote origin
git config branch.test.merge refs/heads/master
Between further reading and your explanation I now understand it better.
"refs/heads/master" refers items displayed by "git show-ref".
So what is "refs/remotes/origin/master", please?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: config for merging master to test branch
From: Junio C Hamano @ 2009-12-29 18:32 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20091229175607.GA3683@panix.com>
Daniel Convissor <danielc@analysisandsolutions.com> writes:
> Excellent. Initially, I wasn't sure what the following commands did:
>
> git config branch.test.remote origin
> git config branch.test.merge refs/heads/master
>
> Between further reading and your explanation I now understand it better.
> "refs/heads/master" refers items displayed by "git show-ref".
Not quite. refs/heads/master there refers to the _local_ master branch,
but it is _local_ with respect to the origin repository, not your
repository. "git show-ref" is about showing refs in _your_ repository.
> So what is "refs/remotes/origin/master", please?
http://gitster.livejournal.com/30313.html
If you read Japanese, you may also want to read Ch.13 of my book ;-)
The refs/remotes/ hierarchy is used to store a copy of the branch tips
fetched from the named remotes (like "origin").
^ permalink raw reply
* [PATCH] git count-objects: handle packs bigger than 4G
From: Andreas Schwab @ 2009-12-29 19:09 UTC (permalink / raw)
To: git
Use off_t to count sizes of packs and objects to avoid overflow after
4Gb.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
builtin-count-objects.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index 1b0b6c8..2bdd8eb 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -11,7 +11,7 @@
static void count_objects(DIR *d, char *path, int len, int verbose,
unsigned long *loose,
- unsigned long *loose_size,
+ off_t *loose_size,
unsigned long *packed_loose,
unsigned long *garbage)
{
@@ -77,7 +77,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
int len = strlen(objdir);
char *path = xmalloc(len + 50);
unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
- unsigned long loose_size = 0;
+ off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(&verbose),
OPT_END(),
@@ -103,7 +103,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
if (verbose) {
struct packed_git *p;
unsigned long num_pack = 0;
- unsigned long size_pack = 0;
+ off_t size_pack = 0;
if (!packed_git)
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
@@ -116,15 +116,15 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
num_pack++;
}
printf("count: %lu\n", loose);
- printf("size: %lu\n", loose_size / 1024);
+ printf("size: %lu\n", (unsigned long) (loose_size / 1024));
printf("in-pack: %lu\n", packed);
printf("packs: %lu\n", num_pack);
- printf("size-pack: %lu\n", size_pack / 1024);
+ printf("size-pack: %lu\n", (unsigned long) (size_pack / 1024));
printf("prune-packable: %lu\n", packed_loose);
printf("garbage: %lu\n", garbage);
}
else
printf("%lu objects, %lu kilobytes\n",
- loose, loose_size / 1024);
+ loose, (unsigned long) (loose_size / 1024));
return 0;
}
--
1.6.6
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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