* Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
From: Alex Riesen @ 2006-01-20 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christopher Faylor
In-Reply-To: <7vzmlqaf5o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Jan 20, 2006 20:10:59 +0100:
> >> The recent Cygwin defines DT_UNKNOWN although it does not have d_type
> >> in struct dirent. Give an option to tell us not to use d_type on such
> >> platforms. Hopefully this problem will be transient.
> >
> > You still have to #undef all the DT_ macros if you have a somewhat
> > old Cygwin (before Christopher removed the macros).
>
> Ah, you mean something like this?
>
> +#undef DT_UNKNOWN
> +#undef DT_DIR
> +#undef DT_REG
> +#undef DT_LNK
yes, of course
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Ryan Anderson @ 2006-01-20 20:48 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <43CF97AF.9060300@op5.se>
On Thu, Jan 19, 2006 at 02:44:15PM +0100, Andreas Ericsson wrote:
>
> The full kernel tree, with history since 1991 or some such, is about 3.2
> GB. It was for this reason that the early history was dropped. I don't
> think another drop will be necessary any time soon, since incremental
> updates are fairly cheap over git and git+ssh. Only gitk suffers, but
> that's just for a short while.
Just to make sure this is corrected, the 3.2GB was for a fully unpacked
tree, which is still fairly bad in the current tree.
The historical tree, packed, runs about 266M in a single pack.
Admittedly, I still refuse to try to run gitk on it.
> >But I'm not saying that it's bad thing to keep
> >that history. It just would be nice to allow developpers that don't
> >care about old history to get rid of it.
>
> You could ofcourse create a new repository with the files from the
> version you want, but then you'd have a hard time merging the two repos
> if you ever want to import the old history.
It's always possible to use a "graft" to tie the history together, and
if you really need to merge changes across the boundary, my graft-ripple
(in the archives) tool can make it happen, though it does some ... nasty
things to the history tree in the process. (It might be useful on a
throwaway tree to provide a way to merge, then, from which a set of
diffs could be taken and applied back on an un-messy tree.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
From: Junio C Hamano @ 2006-01-20 19:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Christopher Faylor
In-Reply-To: <81b0412b0601200701n76f1d912y4671c6800735cd0d@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On 1/20/06, Junio C Hamano <junkio@cox.net> wrote:
>> The recent Cygwin defines DT_UNKNOWN although it does not have d_type
>> in struct dirent. Give an option to tell us not to use d_type on such
>> platforms. Hopefully this problem will be transient.
>
> You still have to #undef all the DT_ macros if you have a somewhat old Cygwin
> (before Christopher removed the macros).
> -
Ah, you mean something like this?
-- >8 --
diff --git a/cache.h b/cache.h
index 8339931..6f13434 100644
--- a/cache.h
+++ b/cache.h
@@ -13,6 +13,10 @@
#if defined(DT_UNKNOWN) && !NO_D_TYPE_IN_DIRENT
#define DTYPE(de) ((de)->d_type)
#else
+#undef DT_UNKNOWN
+#undef DT_DIR
+#undef DT_REG
+#undef DT_LNK
#define DT_UNKNOWN 0
#define DT_DIR 1
#define DT_REG 2
^ permalink raw reply related
* [PATCH] update using-topic-branches
From: Luck, Tony @ 2006-01-20 19:00 UTC (permalink / raw)
To: git
Update documentation to warn users not to create noise in then Linux
history by creating pointless "Auto-update from upstream" merge
commits.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
index b3d592f..2c98194 100644
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -9,7 +9,7 @@ GIT as a Linux subsystem maintainer.
-Tony
-Last updated w.r.t. GIT 0.99.9f
+Last updated w.r.t. GIT 1.1
Linux subsystem maintenance using GIT
-------------------------------------
@@ -92,6 +92,14 @@ These can be easily kept up to date by m
$ git checkout test && git merge "Auto-update from upstream" test linus
$ git checkout release && git merge "Auto-update from upstream" release linus
+Important note! If you have any local changes in these branches, then
+this merge will create a commit object in the history (with no local
+changes git will simply do a "Fast forward" merge). Many people dislike
+the "noise" that this creates in the Linux history, so you should avoid
+doing this capriciously in the "release" branch, as these noisy commits
+will become part of the permanent history when you ask Linus to pull
+from the release branch.
+
Set up so that you can push upstream to your public tree (you need to
log-in to the remote system and create an empty tree there before the
first push).
^ permalink raw reply related
* [PATCH] git-{fetch,peek-remote} handling of --upload-pack
From: Michal Ostrowski @ 2006-01-20 18:38 UTC (permalink / raw)
To: git; +Cc: mostrows
git-peek-remote needs to handle a -u|--upload-pack parameter just like
git-fetch (and git-fetch has to pass it on to git-peek-remote).
(This is actually a follow-up to my previous git-fetch patch.)
Signed-off-by: Michal Ostrowski <mostrows@heater.watson.ibm.com>
---
git-fetch.sh | 6 ++++--
git-ls-remote.sh | 13 ++++++++++---
2 files changed, 14 insertions(+), 5 deletions(-)
86e69492820679894278a20dd9d9768a07f78f96
diff --git a/git-fetch.sh b/git-fetch.sh
index d1659e2..6b02098 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -18,6 +18,7 @@ force=
verbose=
update_head_ok=
exec=
+upload_pack=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -28,6 +29,7 @@ do
--upload-pac|--upload-pack)
shift
exec="--exec=$1"
+ upload_pack="-u $1"
;;
-f|--f|--fo|--for|--forc|--force)
force=t
@@ -202,7 +204,7 @@ reflist=$(get_remote_refs_for_fetch "$@"
if test "$tags"
then
taglist=$(IFS=" " &&
- git-ls-remote --tags "$remote" |
+ git-ls-remote $upload_pack --tags "$remote" |
while read sha1 name
do
case "$name" in
@@ -367,7 +369,7 @@ fetch_main "$reflist"
case "$no_tags$tags" in
'')
taglist=$(IFS=" " &&
- git-ls-remote --tags "$remote" |
+ git-ls-remote $upload_pack --tags "$remote" |
sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index f699268..64f37af 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -2,7 +2,8 @@
#
usage () {
- echo >&2 "usage: $0 [--heads] [--tags] <repository> <refs>..."
+ echo >&2 "usage: $0 [--heads] [--tags] [-u|--upload-pack <upload-pack>]"
+ echo >&2 " <repository> <refs>..."
exit 1;
}
@@ -11,6 +12,7 @@ die () {
exit 1
}
+exec=
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -18,6 +20,11 @@ do
heads=heads; shift ;;
-t|--t|--ta|--tag|--tags)
tags=tags; shift ;;
+ -u|--u|--up|--upl|--uploa|--upload|--upload-|--upload-p|--upload-pa|\
+ --upload-pac|--upload-pack)
+ shift
+ exec="--exec=$1"
+ shift;;
--)
shift; break ;;
-*)
@@ -34,7 +41,7 @@ case ",$heads,$tags," in
esac
. git-parse-remote
-peek_repo="$(get_remote_url "$@")"
+peek_repo="$(get_remote_url $*)"
shift
tmp=.ls-remote-$$
@@ -66,7 +73,7 @@ rsync://* )
;;
* )
- git-peek-remote "$peek_repo" ||
+ git-peek-remote $exec "$peek_repo" ||
echo "failed slurping"
;;
esac |
--
1.1.4.g0b63-dirty
^ permalink raw reply related
* Re: StGIT: "stg new" vs "stg new --force"
From: J. Bruce Fields @ 2006-01-20 18:22 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Yann Dirson, Catalin Marinas, git, Charles Lever
In-Reply-To: <1137738224.27911.26.camel@dv>
On Fri, Jan 20, 2006 at 01:23:44AM -0500, Pavel Roskin wrote:
> On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:
> > That command could be "cat" to get the current "refresh" behaviour, or
> > an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
> > whatever clever filter one would want to use.
> >
> > Does it sound better ?
>
> Yes. The first step would be to fix "stg refresh --edit --showpatch" to
> actually respect edits made to the patch.
I tend to use stg refresh -es as a quick (well, not quite as quick as
I'd like) way to look at the current patch. Often I leave it up while
I'm working (editing the patched files). So if exiting from stg refresh
-es suddenly started overwriting my working files, I'd be very
unhappy....
--b.
^ permalink raw reply
* [PATCH] --upload-pack for git-fetch
From: Michal Ostrowski @ 2006-01-20 18:05 UTC (permalink / raw)
To: git
Implement "git-clone"'s "--upload-pack" parameter in git-fetch, making
it available for git-pull. Without this, there is no way to specify a
remote executable when invoking git-pull/git-fetch as there is for
git-clone.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
Documentation/fetch-options.txt | 7 +++++++
git-fetch.sh | 8 +++++++-
2 files changed, 14 insertions(+), 1 deletions(-)
0b6314bc51945c2ce1e4c8627a00779c23bef3e1
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index e624d3d..8323756 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -3,6 +3,13 @@
existing contents of `.git/FETCH_HEAD`. Without this
option old data in `.git/FETCH_HEAD` will be overwritten.
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+ When given, and the repository to fetch from is handled
+ by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+ the command to specify non-default path for the command
+ run on the other end.
+
-f, \--force::
When `git-fetch` is used with `<rbranch>:<lbranch>`
refspec, it refuses to update the local branch
diff --git a/git-fetch.sh b/git-fetch.sh
index 4a0cb32..d1659e2 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -17,12 +17,18 @@ append=
force=
verbose=
update_head_ok=
+exec=
while case "$#" in 0) break ;; esac
do
case "$1" in
-a|--a|--ap|--app|--appe|--appen|--append)
append=t
;;
+ -u|--u|--up|--upl|--uploa|--upload|--upload-|--upload-p|--upload-pa|\
+ --upload-pac|--upload-pack)
+ shift
+ exec="--exec=$1"
+ ;;
-f|--f|--fo|--for|--forc|--force)
force=t
;;
@@ -312,7 +318,7 @@ fetch_main () {
( : subshell because we muck with IFS
IFS=" $LF"
(
- git-fetch-pack $keep "$remote" $rref || echo failed "$remote"
+ git-fetch-pack $exec $keep "$remote" $rref || echo failed "$remote"
) |
while read sha1 remote_name
do
--
1.1.4.ge755-dirty
^ permalink raw reply related
* Re: git binary size...
From: Jon Loeliger @ 2006-01-20 18:00 UTC (permalink / raw)
To: Git List
In-Reply-To: <Pine.LNX.4.64.0601121013030.3535@g5.osdl.org>
On Thu, 2006-01-12 at 12:13, Linus Torvalds wrote:
> More importantly, autoconf is a worse hack than _any_ of the config hacks
> we do currently.
>
> Repeat after me: "autoconf is crap"
Autoconf is also extraordinarily painful.
If there is actually enough configuration stuff needed,
would there be interest in a Kconfig-like mechanism?
I could spare time that into existence, perhaps...?
jdl
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Junio C Hamano @ 2006-01-20 17:59 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <cda58cb80601200207g7c3495ddx@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> writes:
> 2006/1/20, Junio C Hamano <junkio@cox.net>:
>
>> $ git clone git.git junk
>> $ cd junk ;# I am not brave enough to risk the real thing ;-)
>> $ git rev-parse master~4 >.git/refs/info/grafts
Typo: 's|.git/refs/info/grafts|.git/info/grafts|'
BTW the above exact sequence will not work with my "master"
today, since I merged up bunch of things last night. You have
to cauterize all the paths that lead to earlier history. For
example, if I have this:
---o---o---x---o---o---o---o (master)
\ /
o---o---o
cauterizing at master~4 ('x') will still leak history via the
side branch, if you follow the history from the tip and go
backwards. I have to also cauterize the merge commit after that
to remove the side branch, or cauterize the leftmost branch
point and live with a bit deeper history. The choice depends on
how much real history I want to keep in the pruned history.
For example, to pretend the history was like this:
---o---o x---o---o---o---o (master)
\
o---o---o
$ git rev-parse master~4 >.git/info/grafts ;# 'x'
$ git rev-parse master~3 master~4 >.git/info/grafts
The second line says master~3 (the one that comes after 'x') has
only a single parent, which is master~4, in order to throw the
side branch away [*1*].
Back to the original example...
>> $ cd ..
>> $ mkdir cloned
>> $ cd cloned
>> $ git init-db
>> $ cp ../junk/.git/info/grafts .git/info/
>> $ git clone-pack ../baz
There are a couple of typos here and that was the reason your
experiment did not work. Sorry. The "clone-pack" should have
been like this:
$ git clone-pack ../junk master
Packing 471 objects
e7555785f4edcf4988c53305349e3f525216e2cb refs/heads/master
$ git-rev-parse e7555785f >.git/refs/heads/master
This 'cloned' is the lightweight one.
> does the git protocol is really needed in your example ? or can rsync
> work fine too since "franck.git" repo is cautorized so every objects
> of this repo shouldn't be part of old history, so they should be
> usefull, no ?
rsync may for the initial clone but its use afterwards is
frowned upon for other reasons these days.
[Footnote]
*1* There still is an anomaly if you look at "git log" after
pruning side branch this way; master~3 commit is still shown as
"merge". I think you could call it a bug, but I am not sure it
is worth fixing.
^ permalink raw reply
* Re: /etc in git?
From: Junio C Hamano @ 2006-01-20 17:55 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <43D0EAA2.8090308@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
>>... This does not match typical "package" use.
>>
> To provide an off-topic, but perhaps useful, counter-example, where I
> work, I've made a package that does something similar...
Ah, haven't thought about the use of postinstallation scripts.
If your environment is more or less uniform that is an excellent
way of doing it.
Unfortunately, our Solaris boxen do not understand .deb postinst
scripts, so that is why we are not doing it X-<. Maybe after we
get rid of them perhaps..
^ permalink raw reply
* Re: [PATCH] fix generation of "humanish" part of source repo
From: Uwe Zeisberger @ 2006-01-20 16:16 UTC (permalink / raw)
To: git
In-Reply-To: <20060120064739.GA2306@informatik.uni-freiburg.de>
Hello,
I resent this patch against (a more) current HEAD:
If repo has the form <host>:<path> and <path> doesn't contain a slash, the
cloned repository is named "<host>:<path>", instead of "<path>" only.
Signed-off-by: Uwe Zeisberger <zeisberg@cepheus.pub>
---
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
300d15b114323292c25259ce68b25cf1fb5769e2
diff --git a/git-clone.sh b/git-clone.sh
index 168eb96..ded4085 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -99,7 +99,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
-[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*/||g')
+[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
[ -e "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(cd "$dir" && pwd) &&
--
1.0.8
Best regards
Uwe
--
Uwe Zeisberger
main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34%c";printf(a,34,a,34
,10);a=",10);a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}
^ permalink raw reply related
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Christopher Faylor @ 2006-01-20 15:40 UTC (permalink / raw)
To: Junio C Hamano, Alex Riesen, git
In-Reply-To: <81b0412b0601200723k1a271046u9c310d9c9b7d83f0@mail.gmail.com>
On Fri, Jan 20, 2006 at 04:23:10PM +0100, Alex Riesen wrote:
>On 1/20/06, Christopher Faylor <me@cgf.cx> wrote:
>> On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote:
>> >Christopher Faylor <me@cgf.cx> writes:
>> >>Inodes are only calculated by hashing the path name when the OS lacks
>> >>the support to provide a "real" inode and in that case there is no hard
>> >>link support available so it's a non-issue.
>> >
>> >Does that mean on such filesystems "mv foo bar" would change the i-num
>> >of the moved entity?
>
>It is just a rename. It will not change inode by definition (the file is the
>same, it is the name which was changed). To get inode change you
>have to create it, like "cp foo bar; rm foo". And now, if a filesystem
>has (or exports) inodes, would the inode change. If it does not, you
>really can't say anything about the inode (it can even change, and
>does in this case, being calculated from pathname).
>
>> I just tried this on Windows XP. On a FAT32 or a NTFS filesystem the
>
>I have FAT32. It does not support inodes"
> $ : > foo
> $ stat foo |grep node
> Device: 111712fch/286724860d Inode: 3595119992080318288 Links: 1
> $ mv foo bar
> $ stat bar |grep node
> Device: 111712fch/286724860d Inode: 3595119974866484701 Links: 1
Ok, I must have been hallucinating. I just tried it again. It doesn't
work on FAT32.
cgf
^ permalink raw reply
* Re: [PATCH] Support precise tracking of file modes
From: Alex Riesen @ 2006-01-20 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Ryan Anderson, Adam Hunt, git
In-Reply-To: <7vacdsdqio.fsf@assigned-by-dhcp.cox.net>
On 1/19/06, Junio C Hamano <junkio@cox.net> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
> > attitude to testing and documentation... ;-)
>
> It is premature for us mere mortals to imitate Linus in that
> aspect by at least ten years ;-). Please don't.
>
> About the content of the change, if we were to do this, we need
> to also record owner and group. recording full permissions
> without recording owner and group does not make much sense.
>
Maybe implement tracking of a generic file attribute would be a better idea?
So that porcellans can implement permissions/ownership/EA themselves,
if they really want to...
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Alex Riesen @ 2006-01-20 15:23 UTC (permalink / raw)
To: Christopher Faylor; +Cc: Junio C Hamano, git
In-Reply-To: <20060120033548.GE5090@trixie.casa.cgf.cx>
On 1/20/06, Christopher Faylor <me@cgf.cx> wrote:
> On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote:
> >Christopher Faylor <me@cgf.cx> writes:
> >>Inodes are only calculated by hashing the path name when the OS lacks
> >>the support to provide a "real" inode and in that case there is no hard
> >>link support available so it's a non-issue.
> >
> >Does that mean on such filesystems "mv foo bar" would change the i-num
> >of the moved entity?
It is just a rename. It will not change inode by definition (the file is the
same, it is the name which was changed). To get inode change you
have to create it, like "cp foo bar; rm foo". And now, if a filesystem
has (or exports) inodes, would the inode change. If it does not, you
really can't say anything about the inode (it can even change, and
does in this case, being calculated from pathname).
> I just tried this on Windows XP. On a FAT32 or a NTFS filesystem the
I have FAT32. It does not support inodes"
$ : > foo
$ stat foo |grep node
Device: 111712fch/286724860d Inode: 3595119992080318288 Links: 1
$ mv foo bar
$ stat bar |grep node
Device: 111712fch/286724860d Inode: 3595119974866484701 Links: 1
> inode is unchanged. On a FAT filesystem, it changes. I assume that
> means that FAT doesn't support a real file ID. The only thing I think
> anyone would be using FAT for these days is possibly a boot partition.
It's still faster than NTFS, I use it as a temporary compilation partition,
and as NT is painfully slow about filesystems and throughput in general,
I keep my sources on the partition as well.
> That's the only reason I have one. I use to to multi-boot various
> flavors of Windows. It's the lowest common denominator.
Lowliest.
^ permalink raw reply
* Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
From: Alex Riesen @ 2006-01-20 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christopher Faylor
In-Reply-To: <7voe277lbe.fsf@assigned-by-dhcp.cox.net>
On 1/20/06, Junio C Hamano <junkio@cox.net> wrote:
> The recent Cygwin defines DT_UNKNOWN although it does not have d_type
> in struct dirent. Give an option to tell us not to use d_type on such
> platforms. Hopefully this problem will be transient.
You still have to #undef all the DT_ macros if you have a somewhat old Cygwin
(before Christopher removed the macros).
^ permalink raw reply
* Re: [PATCH] Support precise tracking of file modes
From: Peter Baumann @ 2006-01-20 14:16 UTC (permalink / raw)
To: git
In-Reply-To: <20060119094156.GY28365@pasky.or.cz>
2006/1/19, Petr Baudis <pasky@suse.cz>:
> It seems that this is mostly an artificial imposition and it's annoying.
> Hey, I need to leave for an exam in 15 minutes and I have few urgent
> items in my Cogito TODO (sorry, Pavel!), but I couldn't resist.
>
> Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
> attitude to testing and documentation... ;-)
>
> diff --git a/cache.h b/cache.h
> index 29c9e81..0311066 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -94,7 +94,9 @@ struct cache_entry {
> #define ce_size(ce) cache_entry_size(ce_namelen(ce))
> #define ce_stage(ce) ((CE_STAGEMASK & ntohs((ce)->ce_flags)) >> CE_STAGESHIFT)
>
> -#define ce_permissions(mode) (((mode) & 0100) ? 0755 : 0644)
> +extern int track_filemode;
> +
> +#define ce_permissions(mode) (track_filemode ? (mode) : (((mode) & 0100) ? 0755 : 0644))
> static inline unsigned int create_ce_mode(unsigned int mode)
> {
> if (S_ISLNK(mode))
> diff --git a/checkout-index.c b/checkout-index.c
> index 53dd8cb..b073baa 100644
> --- a/checkout-index.c
> +++ b/checkout-index.c
> @@ -115,6 +115,8 @@ int main(int argc, char **argv)
> int newfd = -1;
> int all = 0;
>
> + git_config(git_default_config);
> +
> prefix = setup_git_directory();
> prefix_length = prefix ? strlen(prefix) : 0;
>
> diff --git a/config.c b/config.c
> index 8355224..a92ee0f 100644
> --- a/config.c
> +++ b/config.c
> @@ -222,6 +222,11 @@ int git_default_config(const char *var,
> return 0;
> }
>
> + if (!strcmp(var, "core.trackallfilemodes")) {
> + track_filemode = git_config_bool(var, value);
> + return 0;
> + }
> +
> if (!strcmp(var, "core.symrefsonly")) {
> only_use_symrefs = git_config_bool(var, value);
> return 0;
> diff --git a/entry.c b/entry.c
> index 410b758..493f2b9 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -87,6 +87,11 @@ static int write_entry(struct cache_entr
> return error("git-checkout-index: unable to create file %s (%s)",
> path, strerror(errno));
> }
> + if (track_filemode) {
> + if (fchmod(fd, ntohl(ce->ce_mode)) < 0)
> + return error("git-checkout-index: unable to chmod file %s (%s)",
> + path, strerror(errno));
> + }
> wrote = write(fd, new, size);
> close(fd);
> free(new);
> diff --git a/environment.c b/environment.c
> index 0596fc6..53248ec 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -12,6 +12,7 @@
> char git_default_email[MAX_GITNAME];
> char git_default_name[MAX_GITNAME];
> int trust_executable_bit = 1;
> +int track_filemode = 0;
> int only_use_symrefs = 0;
> int repository_format_version = 0;
> char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> diff --git a/fsck-objects.c b/fsck-objects.c
> index 90e638e..719add2 100644
> --- a/fsck-objects.c
> +++ b/fsck-objects.c
> @@ -174,7 +174,8 @@ static int fsck_tree(struct tree *item)
> if (!check_strict)
> break;
> default:
> - has_bad_modes = 1;
> + if (!track_filemode || (entry->mode & ~(S_IFREG|0777)))
> + has_bad_modes = 1;
> }
>
> if (last) {
> diff --git a/read-cache.c b/read-cache.c
> index c5474d4..624d2c3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -98,7 +98,7 @@ static int ce_match_stat_basic(struct ca
> * "mode changes"
> */
> if (trust_executable_bit &&
> - (0100 & (ntohl(ce->ce_mode) ^ st->st_mode)))
> + ((track_filemode ? 0777 : 0100) & (ntohl(ce->ce_mode) ^ st->st_mode)))
> changed |= MODE_CHANGED;
> break;
> case S_IFLNK:
>
>
> --
> Petr "Pasky" Baudis
I didn't test the patch, but the feature the patch tries to implement
is really something I'm missing from git (or any other scm I know of).
Ideally, this will be combined with exact owner tracking, but exact
permission and/or owner handling should be activated independently per
repository.
Peter Baumann
^ permalink raw reply
* git-grep documentation
From: sean @ 2006-01-20 13:47 UTC (permalink / raw)
To: git
It looks as though git-grep.sh was coded to allow git-ls-files
options to be passed after a '--' marker. However, this marker will
never be seen by the script unless the user identifies the <pattern>
by preceding it with an '-e'.
If it's not seen the '--' ends up getting passed to git-ls-files and any
options are mistakenly interpreted as paths. For instance, the following
two commands will do different things:
$ git-grep -e NAME -- --others Documentation/git-grep.txt
$ git-grep NAME -- --others Documentation/git-grep.txt
Either the comment in the git-grep.sh script should be changed to
say that only paths are acceptable after the '--' or fixed up to
handle this case a bit better. The documentation patch below is
only applicable if the script is fixed first.
Sean
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 2bfd8ed..c2c6ff3 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -8,7 +8,7 @@ git-grep - print lines matching a patter
SYNOPSIS
--------
-'git-grep' [<option>...] <pattern> [<path>...]
+'git-grep' [<option>...] [-e] <pattern> [-- [<ls option>...]] [<path>...]
DESCRIPTION
-----------
@@ -20,12 +20,21 @@ OPTIONS
-------
<option>...::
Either an option to pass to `grep` or `git-ls-files`.
- Some `grep` options, such as `-C` and `-m`, that take
- parameters are known to `git-grep`.
+
+ The specific `git-ls-files` options that may be supplied are:
+ `--cached`, `--deleted`, `--others`, `--killed`, `--ignored`,
+ `--exclude=*`, `--exclude-from=*`, or `--exclude-per-directory=*`.
+
+ All other options will be passed to `grep`.
<pattern>::
The pattern to look for.
+<ls option>...::
+ Additional options for `git-ls-files` which must be preceded
+ by the '--' marker. See `git-ls-files` for a list of
+ available options.
+
<path>...::
Optional paths to limit the set of files to be searched;
passed to `git-ls-files`.
^ permalink raw reply related
* Re: /etc in git?
From: Ryan Anderson @ 2006-01-20 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvewgirlt.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
Junio C Hamano wrote:
>Ryan Anderson <ryan@michonline.com> writes:
>
>
>>Junio C Hamano wrote:
>>
>>
>>>You are much better off to keep /usr/src/rootstuff/.git (and
>>>working tree files are /usr/src/rootstuff/etc/hosts and
>>>friends), have a build procedure (read: Makefile) there, and
>>>version control that source directory. I usually have 'install'
>>>and 'diff' target in that Makefile, so that I can do this:
>>>...
>>>
>>>
>>If you're doing this, especially if you're doing this on multiple
>>machines, creating a package is probably a worthwhile thing to
>>contemplate as well.
>>
>>
>
>In my workplace environment, the equivalent of the above
>/usr/src/rootstuff is accessible throughout the networked
>machines (mostly NFS mounted); for things that needs per-host
>customization, we do not have /usr/src/rootstuff/etc/hosts but
>keep /usr/src/rootstuff/etc/hosts.in as the source, and Makefile
>customizes that into a form suitable for installation for each
>machine. Especially useful is vfstab.in --- a single source
>builds fstab for local mounting and nfs exports, while other
>machines have mountpoints and project symlinks pointing into
>location automounted from that machine with disk, generated
>automatically. This does not match typical "package" use.
>
>
To provide an off-topic, but perhaps useful, counter-example, where I
work, I've made a package that does something similar.
I use a Makefile to generate a few template files, such as
/etc/resolv.conf, /etc/apt/preferences, /etc/sudoers, /etc/ntp.conf
It Pre-Depends on, ntp, sudo, (etc).
A postinstallation script does a little bit of tweaking of these files
based upon the answers to one or two questions asked during installation.
It's simply another way of looking at the problem.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Franck @ 2006-01-20 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v3bjkf54k.fsf@assigned-by-dhcp.cox.net>
2006/1/19, Junio C Hamano <junkio@cox.net>:
> Franck <vagabon.xyz@gmail.com> writes:
>
> > I don't see why it is so bad to create a "grafted" repository ? I want
> > it to be small but still want to merge by using git-resolve with XX
> > repository.
>
> Franck, and people on the list,
>
> I have a bad habit of responding to a "call for help" request by
> stating how things are currently done and why, sometimes with an
what ? Hey, I would say that you, Linus and other people on the list
have a GREAT habit to spend time to answer others how things work. And
there are usually accurate explanations, examples with a lot of
details with them.
Thanks !
--
Franck
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Alex Riesen @ 2006-01-20 13:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christopher Faylor
In-Reply-To: <7vzmlr7lc3.fsf@assigned-by-dhcp.cox.net>
On 1/20/06, Junio C Hamano <junkio@cox.net> wrote:
> Just removing "-Dsockaddr_storage=sockaddr_in" from ALL_CFLAGS
> seems to solve the problem for new Cygwin.
>
> I doubt that -Dsockaddr_storage=sockaddr_in should be tied to
> NO_IPV6. Maybe a better approach would be something like the
> attached patch.
>
> Although /usr/include/cygwin/in.h seems to have struct sockaddr_in6,
> getaddrinfo() and friends still do not seem to be there, so
> NO_IPV6 still remains in effect on Cygwin.
>
> Comments?
It compiles, I don't think I can try the daemon though...
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Franck @ 2006-01-20 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7virsf7lb9.fsf@assigned-by-dhcp.cox.net>
2006/1/20, Junio C Hamano <junkio@cox.net>:
> Junio C Hamano <junkio@cox.net> writes:
>
> > It _might_ work if you tell your downloader to have a proper
> > graft file in his repository to cauterize the commit ancestry
> > chain _before_ he pulls from you, though. I haven't tried it
> > (and honestly I did not feel that is something important to
> > support, so it might work by accident but that is not by
> > design).
>
> I just tried it and it actually works.
>
> $ git clone git.git junk
> $ cd junk ;# I am not brave enough to risk the real thing ;-)
> $ git rev-parse master~4 >.git/refs/info/grafts
> $ cd ..
> $ mkdir cloned
> $ cd cloned
> $ git init-db
> $ cp ../junk/.git/info/grafts .git/info/
> $ git clone-pack ../baz
> $ git fsck-objects --full
> $ git log --pretty=short | cat
>
Just to be sure, what you call baz is actually junk ?
> This "only the tip of the git.git" repository has about 450
> objects in it, fully packed because of clone-pack, with one 680K
> packfile.
I tried that but I don't have same results. Did you delete all branchs
except master before running clone-pack ? In my case I cloned the
whole thing. So junk and cloned repos are the same size
> I think the true full history of git.git/ packed into
> one is aruond a 5MB packfile. I suspect a bigger repository
> would not see that much size reduction, as Linus already
> explained here.
sorry, but I didn't understand his explaination, surely because of my
very limited knowledge about git internals...
>
> You could emulate what I just did above to prepare the
> equivalent of "baz" above, and make it available over git://
> protocol, say at git://franck.example.com/franck.git/.
>
does the git protocol is really needed in your example ? or can rsync
work fine too since "franck.git" repo is cautorized so every objects
of this repo shouldn't be part of old history, so they should be
usefull, no ?
Thanks.
--
Franck
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.1.4
From: Johannes Schindelin @ 2006-01-20 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wz31e9t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 20 Jan 2006, Junio C Hamano wrote:
> git-fetch-pack: really do not ask for funny refs
>
> * This fixes a case where "git-fetch-pack" is asked to
> fetch all the refs; git barebone Porcelain never
> triggers it and that is one reason why it was never
> noticed so far.
Not really true. I did "git fetch some_url:git/", and it triggered. Bug?
Ciao,
Dscho
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-01-20 8:42 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Now 1.1.4 is out, here is a summary of what are not there but
already merged to the "master" branch (i.e. 1.2.0 material).
Build and Environment issues:
Makefile: add 'strip' target
Fix the installation location.
Allow building of RPM from interim snapshot.
Exec git programs without using PATH (Michal Ostrowski).
Disable USE_SYMLINK_HEAD by default (Pavel Roskin)
CVS:
git-cvsimport: Add -A <author-conv-file> option (Andreas).
cvsimport: ease migration from CVSROOT/users format
Pushes and Pulls:
git-push: avoid falling back on pushing "matching" refs.
git-push: fix --tags and document it.
clone: --naked option.
Add --keep option to keep downloaded packs to git-fetch (Tom Prince).
Fix generation of "humanish" part of source repo (Uwe Zeisberger)
Usability Enhancements:
git-describe: default to HEAD
Documentation: show-branch.
show-branch: make the current branch and merge commits stand out.
show-branch: --current includes the current branch.
show-branch: take default arguments from configuration file.
octopus: allow criss-cross and clarify the message when it rejects
octopus: allow manual resolve on the last round.
checkout: automerge local changes while switching branches.
checkout: merge local modifications while switching branches.
checkout: show dirty state upon switching branches.
format-patch: always --mbox and show sane Date:
----------------------------------------------------------------
These are still cooking in "pu" branch.
Build and Environment:
Makefile: do not assume lack of IPV6 means no sockaddr_storage.
fsck-objects: support platforms without d_ino in struct dirent.
DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
* These are for the latest Cygwin builds.
Documentation:
New Tutorial (J. Bruce Fields)
* Waiting for updates after the last round of comments.
Subproject:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>/ and --exclude=<prefix>/.
commit-tree: --bind <sha1> <path>/ option.
* Basic design has been outlined, and read-tree/write-tree
are probably safe to push out, but commit objects that
contain "bind" lines are unsafe until fsck-objects and
rev-list are updated.
Annotate:
rev-list: stop when the file disappears (Linus)
* I've only taken a cursory look at this patch.
^ permalink raw reply
* [ANNOUNCE] GIT 1.1.4
From: Junio C Hamano @ 2006-01-20 8:42 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.1.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.1.4.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.1.4-1.$arch.rpm (RPM)
This contains one minor fix and one performance fix.
----------------------------------------------------------------
Changes since v1.1.3 are as follows:
Johannes Schindelin:
git-fetch-pack: really do not ask for funny refs
* This fixes a case where "git-fetch-pack" is asked to
fetch all the refs; git barebone Porcelain never
triggers it and that is one reason why it was never
noticed so far.
Junio C Hamano:
Revert "check_packed_git_idx(): check integrity of the idx file itself."
* This was causing significant performance degradation
compared to 0.99.9x. First noticed and complained by
Andrew, and the bisect tool by Linus helped to pinpoint
it. I just took credit for what the two kernel titans
did to help us ;-).
^ permalink raw reply
* [PATCH] fix generation of "humanish" part of source repo
From: Uwe Zeisberger @ 2006-01-20 6:47 UTC (permalink / raw)
To: git
If repo has the form <host>:<path> and <path> doesn't contain a slash, the
cloned repository is named "<host>:<path>", instead of "<path>" only.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3aa74cf5b61fdd2f75ebda942e839a3ecc1e1f9c
diff --git a/git-clone.sh b/git-clone.sh
index f99e0ad..0504ba4 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -97,7 +97,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
-[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*/||g')
+[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
[ -e "$dir" ] && $(echo "$dir already exists."; usage)
mkdir -p "$dir" &&
D=$(
--
1.0.8
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=Planck%27s+constant%3D
^ 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