* Re: Git newbie question: permissions
From: Ed Schofield @ 2008-10-09 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <2008-10-09-23-41-14+trackit+sam@rfc1149.net>
On Thu, Oct 9, 2008 at 10:41 PM, Samuel Tardieu <sam@rfc1149.net> wrote:
>>>>>> "Ed" == Ed Schofield <edschofield@gmail.com> writes:
>
> Ed> I have now run "git --bare init --shared=group" to reinitialize
> Ed> the repository. This seems to have changed the directories to be
> Ed> g+sx. (Is this all it did?). There are still some objects
> Ed> directories with 755 permissions rather than 770, which I presume
> Ed> I want, and the group ownership of these is wrong. Shall I change
> Ed> these by hand? The sha1 files all have 444 permissions; is this
> Ed> right?
>
> Ed> The last question I have is how to ensure that git creates object
> Ed> files etc. with the right permissions when users push in future.
>
> As Marc said, you should first make sure that "config" contains
> "sharedrepository = 1" in the "[core]" section.
>
> Then you can do the following:
>
> - remove all permissions for "others": chmod -R o-rwx .
> - mirror "user" permissions to "group": chmod -R g=u .
> - add +s flag to directories: find . -type d | xargs chmod g+s
>
> This should fix your current situation. The "sharedrepository = 1"
> will tell git to maintain a proper shared state in the future
> on objects it creates (i.e. mirror "user" permission to "group" ones).
This worked beautifully. Thanks Sam, thanks Marc!
-- Ed
^ permalink raw reply
* Re: Different behaviour of rebase -i
From: Caio Marcelo de Oliveira Filho @ 2008-10-09 23:25 UTC (permalink / raw)
To: git
In-Reply-To: <6beb92080810091204n6df4338fs3b182194a8d6454e@mail.gmail.com>
"Leonardo Sobral Cunha" <sobral@gmail.com> writes:
> Is this different behaviour of rebase -i expected or is this a bug?
> This is still happening in git version 1.6.0.2.443.g52e83
To illustrate the problem:
----8<----
~$ git --version
git version 1.6.0.2.514.g23abd3
~$ mkdir a
~$ cd a
~/a$ git init
Initialized empty Git repository in /home/cmarcelo/a/.git/
~/a$ touch A && git add A && git commit A -m "First commit"
Created initial commit d956e0c: First commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 A
~/a$ touch B && git add B && git commit B -m "Second commit"
Created commit 7b6512d: Second commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 B
~/a$ cd ..
~$ git clone a b
Initialized empty Git repository in /home/cmarcelo/b/.git/
~$ cd b
~/b$ git reset --hard HEAD~1
HEAD is now at d956e0c First commit
~/b$ git rebase -i origin/master
Nothing to do
~/b$ git show
commit d956e0ca33e10bac8a0a14200b1e13d84535d728
Author: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Date: Thu Oct 9 20:18:53 2008 -0300
First commit
diff --git a/A b/A
new file mode 100644
index 0000000..e69de29
~/b$ git rebase origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to origin/master.
~/b$ git show
commit 7b6512d5f4b2c51753f4d06033651cee8e6d1460
Author: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Date: Thu Oct 9 20:19:11 2008 -0300
Second commit
diff --git a/B b/B
new file mode 100644
index 0000000..e69de29
---->8----
Wasn't the first "rebase -i" supposed to get to "Second commit"?
--
Caio Marcelo de Oliveira Filho
OpenBossa Labs - INdT
^ permalink raw reply
* Re: Really remove a file ?
From: Stefan Karpinski @ 2008-10-09 23:43 UTC (permalink / raw)
To: marcreddist; +Cc: git
In-Reply-To: <81b0412b0810091156v15dea27an95050a06cfb4f8df@mail.gmail.com>
Specifically, you probably want to do something like this:
$ git filter-branch --index-filter 'git update-index --remove
<filename>' --force -- --all
Beware that this will make your repository effectively "incompatible"
with those of others who've pulled from you before—because all of your
history is now completely rewritten. You should probably have them
clone a new copy from the repo you've run this on instead of trying to
continue working with their old repos. Otherwise all hell breaks
loose. You'll probably also want to run "git gc" on your repo to
actually get rid of the huge object that was added (or does
filter-branch do this automatically?).
On Thu, Oct 9, 2008 at 11:56 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
>
> 2008/10/9 <marcreddist@aim.com>:
> > So is there a way to really remove a file in the git repository so that it
> > never existed (I mean not having the diff in the logs and the data stored
> > somewhere in the .git directory) ? Or if it's not the was git is supposed to
> > be used, is there a way to hide the diff (even from git-log) or something ?
>
> Yes. But you'll change the whole history (of course, it should _never_
> mention the file).
> See git filter-branch (there is even an example at the end of its man page.
> Replace mv with rm)
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] git-daemon: Worked around uclibc buffer problem
From: Nicolas Pitre @ 2008-10-10 0:16 UTC (permalink / raw)
To: Lars Stoltenow; +Cc: git
In-Reply-To: <20081009213448.GA11204@derf.homelinux.org>
On Thu, 9 Oct 2008, Lars Stoltenow wrote:
> uclibc immediately write()s every string argument to fprintf, which causes
> superfluous 'remote: ' strings to appear when cloning repos. This patch
> makes it write the message in one shot.
What is your client version? From v1.6.0.2 and later (with commit
6b9c42b4da) this shouldn't matter as things are properly handled on the
receiving end.
Nicolas
^ permalink raw reply
* [PATCH] fix pread()'s short read in index-pack
From: Nicolas Pitre @ 2008-10-10 2:08 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: Alex Riesen, git
In-Reply-To: <20081009195518.GA1497@blimp.localhost>
Since v1.6.0.2~13^2~ the completion of a thin pack uses sha1write() for
its ability to compute a SHA1 on the written data. This also provides
data buffering which, along with commit 92392b4a45, will confuse pread()
whenever an appended object is 1) freed due to memory pressure because
of the depth-first delta processing, and 2) needed again because it has
many delta children, and 3) its data is still buffered by sha1write().
Let's fix the issue by simply forcing cached data out when such an
object is written so it can be pread()'d at leisure.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Thu, 9 Oct 2008, Alex Riesen wrote:
> Somehow I got my gnulib mirror to a strange state where I can't fetch
> anything from it:
>
> $ cd gnulib
> $ git fetch -f ../gnulib.git 'refs/heads/*:refs/remotes/origin/*'
> remote: Counting objects: 2202, done.
> remote: Compressing objects: 100% (633/633), done.
> remote: Total 1769 (delta 1448), reused 1455 (delta 1134)
> Receiving objects: 100% (1769/1769), 404.11 KiB, done.
> fatal: premature end of pack file, 1745 bytes missing
> fatal: index-pack failed
>
> This is with current Shawn's master (Junio's master erroneously gives
> an error). Bisect points at ac0463ed44e859c84e354cd0ae47d9b5b124e112
Thanks for providing a good test data set. As you can see above, this
is something that is tricky to reproduce otherwise. This patch is meant
for the maint branch but should be included in master as well.
diff --git a/csum-file.c b/csum-file.c
index bb70c75..3b3e090 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -11,7 +11,7 @@
#include "progress.h"
#include "csum-file.h"
-static void sha1flush(struct sha1file *f, void *buf, unsigned int count)
+static void flush(struct sha1file *f, void *buf, unsigned int count)
{
for (;;) {
int ret = xwrite(f->fd, buf, count);
@@ -30,22 +30,28 @@ static void sha1flush(struct sha1file *f, void *buf, unsigned int count)
}
}
-int sha1close(struct sha1file *f, unsigned char *result, unsigned int flags)
+void sha1flush(struct sha1file *f)
{
- int fd;
unsigned offset = f->offset;
if (offset) {
SHA1_Update(&f->ctx, f->buffer, offset);
- sha1flush(f, f->buffer, offset);
+ flush(f, f->buffer, offset);
f->offset = 0;
}
+}
+
+int sha1close(struct sha1file *f, unsigned char *result, unsigned int flags)
+{
+ int fd;
+
+ sha1flush(f);
SHA1_Final(f->buffer, &f->ctx);
if (result)
hashcpy(result, f->buffer);
if (flags & (CSUM_CLOSE | CSUM_FSYNC)) {
/* write checksum and close fd */
- sha1flush(f, f->buffer, 20);
+ flush(f, f->buffer, 20);
if (flags & CSUM_FSYNC)
fsync_or_die(f->fd, f->name);
if (close(f->fd))
@@ -83,7 +89,7 @@ int sha1write(struct sha1file *f, void *buf, unsigned int count)
left -= nr;
if (!left) {
SHA1_Update(&f->ctx, data, offset);
- sha1flush(f, data, offset);
+ flush(f, data, offset);
offset = 0;
}
f->offset = offset;
diff --git a/csum-file.h b/csum-file.h
index 72c9487..01f13b5 100644
--- a/csum-file.h
+++ b/csum-file.h
@@ -24,6 +24,7 @@ extern struct sha1file *sha1fd(int fd, const char *name);
extern struct sha1file *sha1fd_throughput(int fd, const char *name, struct progress *tp);
extern int sha1close(struct sha1file *, unsigned char *, unsigned int);
extern int sha1write(struct sha1file *, void *, unsigned int);
+extern void sha1flush(struct sha1file *f);
extern void crc32_begin(struct sha1file *);
extern uint32_t crc32_end(struct sha1file *);
diff --git a/index-pack.c b/index-pack.c
index 530d820..ca72329 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -704,6 +704,7 @@ static struct object_entry *append_obj_to_pack(struct sha1file *f,
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset += write_compressed(f, buf, size);
obj[0].idx.crc32 = crc32_end(f);
+ sha1flush(f);
hashcpy(obj->idx.sha1, sha1);
return obj;
}
^ permalink raw reply related
* Re: Fwd: git status options feature suggestion
From: Caleb Cushing @ 2008-10-10 2:20 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, git, Jeff King, Junio C Hamano
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>
> Could you list exactly which options you want implemented?
--new --untracked --modified
I believe there are other states as well that I'm not thinking of off
the top of my head. Those should probably be included as well. another
option could be to have an option --filter=modified for example.
> Requests for stuff like that keep appearing recently
> ...
> Michael
all way over my head
--
Caleb Cushing
^ permalink raw reply
* [BUG] Gitk elides backslashes in author names
From: Eric Hanchrow @ 2008-10-10 2:51 UTC (permalink / raw)
To: git
Here's how to reproduce the problem with git version 1.6.0.2.415.g9800c0:
$ cd /tmp
$ rm -rf x
$ mkdir x
$ cd x
$ git init
Initialized empty Git repository in /tmp/x/.git/
$ touch it
$ git commit -a --author="back\\slash <foo@bar.com>" -m "yeah"
Created initial commit 0f65eda: yeah
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 it
$ git log
commit 0f65eda51f33f5c56ba61f2c9dc1c5d38baec75c
Author: back\slash <foo@bar.com>
Date: Thu Oct 9 19:42:17 2008 -0700
yeah
$ gitk
Now note that the author appears as "backslash", not "back\slash".
You might wonder why I have backslashes in my author names: it's
because I'm using git-svn, and our Subversion setup -- which uses
Windows authentication -- creates names with backslashes.
--
However lousy it is to sit in your basement and pretend to be an
elf, I can tell you from personal experience it's worse to sit in your
basement and try to figure if Ginger or Mary Ann is cuter.
-- Clay Shirky
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Elijah Newren @ 2008-10-10 4:25 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Caleb Cushing, git, Jeff King,
Junio C Hamano
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>
On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
<snip>
> A few radical suggestions might be:
>
> 1. make ls-files and diff --name-status use compatible letters
>
> 2. rename git commit -n to git commit -b (as in bypass), make git commit
> -n do what's expected ("--dry-run", n as in duNNo yet)
Ouch. Please not -b. I guess I need to get my other suggestions
upstream if I want to avoid option conflicts like this...
> 3. rename git status to git commit -n
>
> 4. make git status generate git diff --name-status like output
I'd really prefer to be able to get staged vs. unstaged information
out of status. And the single-letter output, like what cvs/svn/hg
have, is less descriptive here. (Sure, git status could use some
cleanup IMO, but a word instead of a letter for modification status is
a usability improvement in git over those other systems for new VCS
users.)
> (3+4)'. make git status -l generate git diff --name-status like output
> (l as in status Letter) as an alternative to 3+4
That seems nicer.
And another radical suggestion (wasn't this brought up before too?):
5. Allow limiting the status output to a set of paths. diff, log,
add, grep, etc. can all take a subdirectory name and limit their
operation to files recursively underneath that path, but git status
doesn't do so when you run 'git status DIR'. I know why it currently
behaves as it does, but it sure seems like unnecessary UI
inconsistency.
Just my $0.02,
Elijah
^ permalink raw reply
* Re: [PATCH] fix pread()'s short read in index-pack
From: Alex Riesen @ 2008-10-10 6:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.2.00.0810092140500.26244@xanadu.home>
2008/10/10 Nicolas Pitre <nico@cam.org>:
>
> Since v1.6.0.2~13^2~ the completion of a thin pack uses sha1write() for
> its ability to compute a SHA1 on the written data. This also provides
> data buffering which, along with commit 92392b4a45, will confuse pread()
> whenever an appended object is 1) freed due to memory pressure because
> of the depth-first delta processing, and 2) needed again because it has
> many delta children, and 3) its data is still buffered by sha1write().
So I seem to have had luck not doing gc in either of source or target repos
(I usually repack, than fetch. Especially this one repo, it's very active).
BTW, I run into complications trying to test the fix on Shawn's
master: conflicts,
and my trivial resolution wasn't good enough.
Aside from that, I confirm the case fixed.
^ permalink raw reply
* merge hook
From: Erik Colson @ 2008-10-10 7:21 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 207 bytes --]
Hello,
Is it possible to launch a custom script on all files involved in a
merge to master ?
If yes, is it then also possible to reject the merge if the script
returns an error ?
Thanks
--
Erik
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Peter Krefting @ 2008-10-10 8:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <48E4C401.90409@drmicha.warpmail.net>
Michael J Gruber:
> I'm not sure about the lessons, but I wanted to share the numbers
> anyways. I think this (your script and its usage) is heading in a useful
> direction and should maybe made more known, if not made easier from the
> git side.
I had very positive experiences with the script for my use-case. I did
post them to the list, but it seems as if they got lost. At least I
can't seem to find them, did they show up?
I had some problems with the script when trying to run it under
Windows, though. Running Windows-Git from a Cygwin prompt provides some
confusion about some of the Unix tools' behaviour that I needed to
work around (like removing "/cygdrive" prefixes).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: Peter Krefting @ 2008-10-10 8:24 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, David Soria Parra, Rotem Yaari, Git Mailing List
In-Reply-To: <32541b130810081621k32493e20occba9cd97671775d@mail.gmail.com>
Avery Pennarun:
> I guess bash completions would help with this (if you're using bash),
> but even then it's kind of unreasonable to name branches something
> like "bug-111234-widget-performance-improvements-for-customer-x",
> which is the sort of information that would be awfully helpful two
> months later when you're looking at old unmerged branches.
That's exactly what I do for one of the projects I am working on (well,
minus the "bug-" prefix, that's implied). Bash completion works quite
well for that, and the merge commits do give meaningful information.
But I would still like to be able to annotate it. Especially for
long-living bug-fix branches, it could be useful to be able to add
describe a branch with what state it is in, for instance.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCHv2] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-10 8:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce, Petr Baudis
In-Reply-To: <1223457985-27094-1-git-send-email-giuseppe.bilotta@gmail.com>
On Wed, 8 Oct 2008, Giuseppe Bilotta wrote:
> Since input parameters can be obtained both from CGI parameters and
> PATH_INFO, we would like most of the code to be agnostic about the way
> parameters were retrieved. We thus collect all the parameters into the
> new %input_params hash, delaying validation after the collection is
> completed.
>
> Although the kludge removal is minimal at the moment, it makes life much
> easier for future expansions such as more extensive PATH_INFO use or
> other form of input such as command-line support.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Very nice.
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-10 8:56 UTC (permalink / raw)
To: git@vger.kernel.org >> Git Mailing List; +Cc: Michael J Gruber
In-Reply-To: <48EE132E.1040407@drmicha.warpmail.net>
Michael J Gruber wrote:
> Knut Eldhuset venit, vidit, dixit 08.10.2008 11:20:
>> Michael J Gruber wrote:
>>> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
<snip>
>>> So, in order to help you, we would need to know
>>>
>>> - the layout of your svn repo: where are trunk, branches and tags, how
>>> did you create branches and tags in svn, are "projects" entirely separate
>> https://server/trunk
>> https://server/branches
>> https://server/tags
>>
>> We really only have one "project" source tree at
>> https://server/trunk/some_folder/project/src
>>
>> However, once the sources were at
>> https://server/trunk/some_folder/project/old_source
>
> That may be the source of the trouble. In fact, the log below indicates
> that it is more like the following two paths:
>
> https://server/trunk/project/old_source
> https://server/trunk/project/src/client
>
I think my description is correct, but these particular log messages may
not be the best examples. We did have files and folders in "old_source"
that moved to "src".
>> Therefore we have the following:
>>
>> $ svn log -v -r4871 https://server/
>> ------------------------------------------------------------------------
>> r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>> D /trunk/project/old_source/some_file
>> A /trunk/project/src/client/some_file (from
>> /trunk/project/old_source/some_file:4795)
>>
>> commit-message
>> ------------------------------------------------------------------------
>>
>> $ svn log -v -r4869 https://server/
>> ------------------------------------------------------------------------
>> r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>> A /trunk/project/src
>> A /trunk/project/src/client
>>
>> commit-message
>>
>> ------------------------------------------------------------------------
>>
>> $ svn log -v -r4868 https://server/
>> ------------------------------------------------------------------------
>> r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>>
>> commit-message
>>
>
> That one is funny. A modified directory but no paths modified
> underneath. Was this a propset?
>
These give identical output:
svn log -v -r4868 --xml https://server
and
svn log -v -r4868 --with-all-revprops --xml https://server
I don't understand what happened there. It was a commit made with svk,
so maybe that had something to do with it.
>> ------------------------------------------------------------------------
>>
>> $ svn log -v -r4867 https://server/
>> ------------------------------------------------------------------------
>> r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>> A /trunk/project/some_file
>>
>> commit-message
>> ------------------------------------------------------------------------
>
> Maybe you're trying too hard to disguise things. Are you really adding
> some_file right under project here and under project/src/client in r4871?
>
No, those were different files... I'm sorry I can't share the repo publicly.
>> r4868 appears twice in git. One commit is on master/trunk and has parent
>> and child, while the other is on a branch and has no parent.
>>
>>> - your incarnation of git-svn
>>>
>> # git --version
>> git version 1.6.0.2
>
> I actually meant incantation, I guess I should brush up on my little
> latin, uhm ;)
>
> So, did you use something like
>
> git svn init -s https://server/
>
> or
>
> git svn init -T trunk/project/src/client -t 'tags/*/project/src/client'
> -b 'branches/*/project/src/client' https://server/
>
I used
git svn clone -s https://server/
initially. Then I tried
git svn clone -T trunk/project/src -r tags -b branches https://server/
which gave better results. Then I settled on using "-r4869:HEAD".
> My suggestion would to use two svn sections (option "-R") with different
> configs for different repo structures, and to fetch the first one with
> "-r1:4866" and the second one with "-r4871:HEAD". Reorganising the svn
> repo layout can confuse git-svn quite a bit (and understandably so).
> Using different configs for different "epochs" helps. grafts are your
> friend when it comes to connecting the two.
>
> Michael
Good suggestion. I didn't realize one could do it that way.
Regards,
Knut
^ permalink raw reply
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-10 8:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo Molnar, FNST-Lai Jiangshan, FJ-KOSAKI Motohiro,
H. Peter Anvin, git, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810101046260.3271@apollo>
Thomas Gleixner said the following on 2008-10-10 16:56:
> On Fri, 10 Oct 2008, Wang Chen wrote:
>> Thomas Gleixner said the following on 2008-10-10 16:40:
>>> On Fri, 10 Oct 2008, Ingo Molnar wrote:
>>>
>>>> Cc:-ed Thomas too - Thomas just ran a clean git clone and that succeeded
>>>> for him, both over the http and over the git protocols.
>>> No, I did ssh and git. Will start a http one now.
>> OK. I will wait.
>> Thanks, Thomas :)
>
> git clone http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>
> fails here as well.
>
> Getting pack 7c461fa5d92f9e047ae07b70eb30828a63a803f5
> which contains 874e848aefc2d5952b00593c9fd23d748259eec7
> walk 874e848aefc2d5952b00593c9fd23d748259eec7
> Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/
> error: Unable to find 85ba94ba0592296053f7f2846812173424afe1cb under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> Cannot obtain needed object 85ba94ba0592296053f7f2846812173424afe1cb
> while processing commit 874e848aefc2d5952b00593c9fd23d748259eec7.
> fatal: Fetch failed.
>
> The needed object 85ba94ba0592296053f7f2846812173424afe1cb is a commit
> in linus tree.
>
> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
> 1.5.3.x)
>
My git version is 1.5.5.1, although it doesn't matter ;)
> Junio, can you please have a look ? I know it's http again, but we can
> not sanitze the corporate firewall folks by any means.
>
^ permalink raw reply
* Re: tip tree clone fail
From: Thomas Gleixner @ 2008-10-10 8:56 UTC (permalink / raw)
To: Wang Chen
Cc: Ingo Molnar, FNST-Lai Jiangshan, FJ-KOSAKI Motohiro,
H. Peter Anvin, git, Junio C Hamano
In-Reply-To: <48EF14FC.1000801@cn.fujitsu.com>
On Fri, 10 Oct 2008, Wang Chen wrote:
> Thomas Gleixner said the following on 2008-10-10 16:40:
> > On Fri, 10 Oct 2008, Ingo Molnar wrote:
> >
> >> Cc:-ed Thomas too - Thomas just ran a clean git clone and that succeeded
> >> for him, both over the http and over the git protocols.
> >
> > No, I did ssh and git. Will start a http one now.
>
> OK. I will wait.
> Thanks, Thomas :)
git clone http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
fails here as well.
Getting pack 7c461fa5d92f9e047ae07b70eb30828a63a803f5
which contains 874e848aefc2d5952b00593c9fd23d748259eec7
walk 874e848aefc2d5952b00593c9fd23d748259eec7
Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/
error: Unable to find 85ba94ba0592296053f7f2846812173424afe1cb under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Cannot obtain needed object 85ba94ba0592296053f7f2846812173424afe1cb
while processing commit 874e848aefc2d5952b00593c9fd23d748259eec7.
fatal: Fetch failed.
The needed object 85ba94ba0592296053f7f2846812173424afe1cb is a commit
in linus tree.
So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
1.5.3.x)
Junio, can you please have a look ? I know it's http again, but we can
not sanitze the corporate firewall folks by any means.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] test-lib: fix color reset in say_color()
From: Jakub Narebski @ 2008-10-10 9:30 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1223590030-7464-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> When executing a single test with colors enabled, the cursor was not set
> back to the previous one, and you had to hit an extra enter to get it
> back.
>
> Work around this problem by calling 'tput sgr0' before printing the
> final newline.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> Actually I'm not 100% sure about how many users are affected. I have a
> black background in konsole with white letters, and after the test I get
> a green cursor, and once I hit enter, I get the white one back.
I also had this very minor irritation that cursor retained color
of last line till enter (or IIRC any key which moved cursor). I use
ordinary xterm from X.Org 6.8.2(213).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Really remove a file ?
From: marcreddist @ 2008-10-10 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <d4bc1a2a0810091643u3903a1f4h44d3579b98fe6922@mail.gmail.com>
Hi,
Thank you both, that's exactly what i needed.
In case someone finds this post in the future, this :
> $ git filter-branch --index-filter 'git update-index --remove
' --force -- --all
worked perfectly. Although, it told me that git can't work on a dirty
directory so I did this :
$ git add .
$ git commit
And after the filter-branch
$ git reset --hard HEAD^
> You'll probably also want to run "git gc" on your repo to
> actually get rid of the huge object that was added (or does
> filter-branch do this automatically?).
I'm not sure it's required by git-filter-branch alone. In this case :
git-gc saves almost 5% after the file deletion
it saves 4.5% before the file deletion
If I run git gc before and after the git filter-branch, it saves 4.5%
and then 0.2%.
But maybe my tests applies to my particular environment and cannot be
generalized.
Thank you again for the help.
Take care,
Marc, happy git user.
--
^ permalink raw reply
* Re: merge hook
From: Johannes Schindelin @ 2008-10-10 10:07 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <20081010072148.GB303@Mac2.local>
Hi,
On Fri, 10 Oct 2008, Erik Colson wrote:
> Is it possible to launch a custom script on all files involved in a
> merge to master ? If yes, is it then also possible to reject the merge
> if the script returns an error ?
>From Documentation/githooks.txt:
-- snip --
prepare-commit-msg
------------------
This hook is invoked by 'git-commit' right after preparing the
default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file that
the commit log message. The second is the source of the commit message,
and can be: [...] `merge` (if the commit is a merge or a `.git/MERGE_MSG`
file exists); [...]
If the exit status is non-zero, 'git-commit' will abort.
-- snap --
To see which files are affected, you'd just need to ask "git diff
--name-only --cached".
I guess that you want to disallow merging in changes from people who
changed files that are none of their business? If so, it would be nice to
contribute the hook as a patch to contrib/.
Ciao,
Dscho
^ permalink raw reply
* Re: merge hook
From: Erik Colson @ 2008-10-10 10:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810101204540.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
On Fri, Oct 10, 2008 at 12:07:16PM +0200, Johannes Schindelin wrote:
[..]
> From Documentation/githooks.txt:
thank you for pointing me there
[..]
> I guess that you want to disallow merging in changes from people who
> changed files that are none of their business? If so, it would be nice to
> contribute the hook as a patch to contrib/.
wrong guess ;)
The purpose is to check if source code still has debug code in
it. Our policy is to have it removed before reaching master, but
checking by hand is way too buggy ;)
--
erik
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
From: Paul Mackerras @ 2008-10-10 10:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alexander Gavrilov, git, Shawn O. Pearce
In-Reply-To: <48E36086.7050504@viscovery.net>
Johannes Sixt writes:
> I'm about to add a .gitattributes file that specifies the encoding for
> some of my files *today* because I was not clever enough to anticipate the
> usefulness of an "encoding" attribute a year ago when those files were
> added to the repository. When I browse history, I *do* want that *today's*
> encoding is picked.
Fair enough.
> > (Also it seems that we won't
> > notice if the user changes .gitattributes after we've looked at it, or
> > if they create one after we've looked for one and not found it.)
>
> This is not a show stopper, IMHO. The user will notice soon enough, and
> can restart gitk. Nobody sane will change the encoding attributes every hour.
The scenario I'm thinking of is this: a user clicks on a file to
display it, sees that it isn't displayed using the encoding he wants,
says "duh" and creates a .gitattributes file. User clicks on the file
again, sees that it *still* isn't displayed using the right encoding,
and says something worse than "duh". :)
If it was just one .gitattributes file, then it wouldn't be hard to
stat it each time we go to display some file, and throw away our cache
if it has changed. But it looks like we would have to do N+1 stats
for a file N levels deep in the tree (since it looks like we also need
to stat $GIT_DIR/info/attributes). Still, it may be worth it. At
least on Linux, stat is pretty fast.
Paul.
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Johannes Schindelin @ 2008-10-10 11:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Caleb Cushing, git, Jeff King, Junio C Hamano
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>
Hi,
On Thu, 9 Oct 2008, Michael J Gruber wrote:
> 1. make ls-files and diff --name-status use compatible letters
ls-files and diff (at least partially) are plumbing. Breaking backwards
compatibility in these is out of the question.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (GITK) v2 3/4] gitk: Support filenames in the locale encoding.
From: Paul Mackerras @ 2008-10-10 11:23 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <18671.15020.13951.943822@cargo.ozlabs.ibm.com>
I wrote:
> > @@ -6250,11 +6250,12 @@ proc gettreeline {gtf id} {
> > set line [string range $line 0 [expr {$i-1}]]
> > if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
> > set sha1 [lindex $line 2]
> > - if {[string index $fname 0] eq "\""} {
> > - set fname [lindex $fname 0]
> > - }
> > lappend treeidlist($id) $sha1
> > }
> > + if {[string index $fname 0] eq "\""} {
> > + set fname [lindex $fname 0]
> > + }
>
> Concerning this part of the change, do we know whether git ls-files
> will quote filenames containing special characters or not?
A little experiment has convinced me that it does. So this part looks
OK.
Paul.
^ permalink raw reply
* Re: [PATCH (GITK) v2 3/4] gitk: Support filenames in the locale encoding.
From: Paul Mackerras @ 2008-10-10 11:21 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1222772422-28020-4-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> The previous patch changed the encoding used for
> reading diffs to binary, which broke non-ASCII filename
> support. This one fixes the breakage, together with some
> existing bugs related to filename encoding.
Sounds like this patch should be combined with the previous one.
> @@ -6250,11 +6250,12 @@ proc gettreeline {gtf id} {
> set line [string range $line 0 [expr {$i-1}]]
> if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
> set sha1 [lindex $line 2]
> - if {[string index $fname 0] eq "\""} {
> - set fname [lindex $fname 0]
> - }
> lappend treeidlist($id) $sha1
> }
> + if {[string index $fname 0] eq "\""} {
> + set fname [lindex $fname 0]
> + }
Concerning this part of the change, do we know whether git ls-files
will quote filenames containing special characters or not?
Paul.
^ permalink raw reply
* Re: Different behaviour of rebase -i
From: Johannes Schindelin @ 2008-10-10 11:40 UTC (permalink / raw)
To: Leonardo Sobral Cunha; +Cc: git
In-Reply-To: <6beb92080810091204n6df4338fs3b182194a8d6454e@mail.gmail.com>
Hi,
On Thu, 9 Oct 2008, Leonardo Sobral Cunha wrote:
> While doing a git rebase with my upstream branch ahead of my local
> branch, first git rewinds my local branch to point to the upstream and
> then prints "Nothing to do". As expected, my local branch ends pointing
> to the upstream head.
>
> But when I use the same command with the same branches using git rebase
> -i, nothing happens and my local branch does not point to upstream (the
> behaviour is different).
>
> Is this different behaviour of rebase -i expected or is this a bug? This
> is still happening in git version 1.6.0.2.443.g52e83
This is by design. You need to have a way to stop rebasing in the editor.
For example when you realize that you passed the wrong upstream or
something.
The most intuitive way (I thought) is to behave the same as "git commit":
if you do not want to continue, just delete everything.
Now, I can see that it is unconvenient.
A workaround would be to add a line "bla" and when rebase complains about
the unknown command, continue with "git rebase --skip".
Maybe we should add a new command "noop" which is automatically inserted
when there is no other command?
Ciao,
Dscho
^ 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