* Re: untracked symlinks are less precious than untracked files?
From: Junio C Hamano @ 2011-02-02 20:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201102022025.06140.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Is it by design that symlinks are less precious than files, or is it an
> oversight?
I don't recall making conscious distinction between symmlinks and regular
files, so it is likely to be just a bug. Perhaps using stat() where
lstat() should be used and mistaking an error return as missing, or
something silly like that?
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: introduce "feature notes" command
From: Sverre Rabbelier @ 2011-02-02 19:57 UTC (permalink / raw)
To: Thomas Rast
Cc: Jonathan Nieder, git, Johan Herland, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <201102022047.55152.trast@student.ethz.ch>
Heya,
On Wed, Feb 2, 2011 at 20:47, Thomas Rast <trast@student.ethz.ch> wrote:
> to test, and use notes depending on success. In both cases old gits
> will be regarded as incompatible. Or am I missing something?
I agree, old gits breaking on "feature notes", is/should be intended
behavior. Perhaps we can submit a patch to maint to have it (the
oldest git that supports the 'feature' command) recognize 'feature
notes' though?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: introduce "feature notes" command
From: Thomas Rast @ 2011-02-02 19:47 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Johan Herland, Sverre Rabbelier, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <20110202050735.GE15285@elie>
Jonathan Nieder wrote:
>
> Support for importing notes was added to git fast-import quite a while
> ago (v1.6.6-rc0~21^2~8, 2009-10-09), before the 'feature' facility was
> introduced (v1.7.0-rc0~95^2~4, fast-import: add feature command,
> 2009-12-04) so for compatibility with older git versions, authors
> of existing frontends should not start using the "feature notes"
> command. Most git versions in wide use support notemodify already.
>
> The purpose of the "feature notes" declaration is instead to
> distinguish between git and fast-import backends that do not support
> notemodify. In git "feature notes" will be a no-op while in other
> current fast-import backends it will error out with a clear error
> message.
So in summary, don't use "feature notes" because it would fail with
old gits, but do use "feature notes" because it will fail for non-git?
Isn't that a bit backwards? I mean, a tool author would either just
use it and say "if it doesn't read this, upgrade your git" or run
echo feature notes | scm fast-import
to test, and use notes depending on success. In both cases old gits
will be regarded as incompatible. Or am I missing something?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [1.8.0] Remote tag namespace
From: Marc Branchaud @ 2011-02-02 19:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre
In-Reply-To: <AANLkTim4qOiF=3GMixZuWJs=cqcAtawtgkKzLiVdBhuZ@mail.gmail.com>
On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud<marcnarc@xiplink.com> wrote:
>>> Config branch.*.globalTags (perhaps takes a pattern?) may be defined
>>> to create refs/tags/* in addition to refs/remote-tags/<remote>/* when
>>> fetching tags.
>>
>> I may be getting into the weeds prematurely here, but why put the config item
>> under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't
>> see a need for this. I'd rather have the rev-parse machinery search in
>> remote tag namespaces if it can't find anything local.
>
> Ahh.. yeah it's remote.*.globalTags. I don't know, some people might
> find current behavior useful. So instead of dropping it entirely, I'd
> limit it to certain remotes.
IMHO, it's best not to assume what people might want. Better to wait
for someone to ask for something specific.
[ ...snip... ]
> When tags are put in remote namespace (wherever it actually is),
> git-tag must learn -r like git-branch. I think option name change for
> -a is too late though. When "git-ng" rewrite project comes (that is
> after libgit2 replaces git core), we may have everything consistent
> again.
I think we could start by making "git tag -A" a synonym for "git tag -a"
with a verbose warning when "-a" is used that it'll soon gain a
different meaning.
Also, during the transition "git tag -a" without any other options could
(without the big warning) list all local and remote tags (like "git
branch -a") and if someone wanted to make an annotated tag of the
current tip they could do "git tag -A" or "git tag -a HEAD".
M.
^ permalink raw reply
* untracked symlinks are less precious than untracked files?
From: Johannes Sixt @ 2011-02-02 19:25 UTC (permalink / raw)
To: git
While I was poking around in t6035-merge-dir-to-symlink.sh, I noticed this:
diff --git a/t/t6035-merge-dir-to-symlink.sh b/t/t6035-merge-dir-to-symlink.sh
index 92e02d5..46b401b 100755
--- a/t/t6035-merge-dir-to-symlink.sh
+++ b/t/t6035-merge-dir-to-symlink.sh
@@ -5,21 +5,22 @@ test_description='merging when a directory was replaced with
a symlink'
test_expect_success SYMLINKS 'create a commit where dir a/b changed to
symlink' '
mkdir -p a/b/c a/b-2/c &&
> a/b/c/d &&
> a/b-2/c/d &&
> a/x &&
git add -A &&
git commit -m base &&
git tag start &&
rm -rf a/b &&
- ln -s b-2 a/b &&
+ # ln -s b-2 a/b &&
+ >a/b &&
git add -A &&
git commit -m "dir to symlink"
'
test_expect_success SYMLINKS 'keep a/b-2/c/d across checkout' '
git checkout HEAD^0 &&
git reset --hard master &&
git rm --cached a/b &&
git commit -m "untracked symlink remains" &&
git checkout start^0 &&
With this change, where a symlink is replaced by a regular file, the 'git
checkout start^0' fails. At this time, a/b is untracked. When it is a
symlink, it is replaced by a directory. When it is a file, the test fails:
error: The following untracked working tree files would be overwritten by
checkout:
a/b
Is it by design that symlinks are less precious than files, or is it an
oversight?
-- Hannes
^ permalink raw reply related
* Re: [PATCH (version C) 1/2] gitweb: Prepare for splitting gitweb
From: "Alejandro R. Sedeño" @ 2011-02-02 19:08 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <1296579016-13356-4-git-send-email-jnareb@gmail.com>
On 2/1/2011 11:50 AM, Jakub Narebski wrote:
> Prepare gitweb for being split into modules that would be installed
> in gitweblibdir, by default alongside gitweb in 'lib/' subdirectory.
>
> Gitweb would search first in 'lib/' subdirectory from where it is
> installed, via
>
> use lib __DIR__.'/lib';
>
> (This allow for tests to work with source version of gitweb without
> changes.) Then it searches in $(gitweblibdir) directory (set during
> build time), by default "$(gitwebdir)/lib", via
>
> use lib "++GITWEBLIBDIR++";
>
> "++GITWEBLIBDIR++" is set to appropriate value during build time
> (generating gitweb.cgi). This allows to select where to install
> gitweb modules via 'gitweblibdir' build time configuration variable
I would personally prefer to see this path taken, as it seems the most
flexible and would fulfill a use case I have.
I maintain a build of git in an AFS volume at MIT. One of its uses is
symlinking to the current gitweb.cgi to instantly deploy a gitweb in a
shared hosting environment (example: http://git.scripts.mit.edu/).
__DIR__ would point to the directory containing a user symlink to
gitweb, which would allow users to add their own libraries, while
++GITWEBLIBDIR++ would allow the standard gitweb libraries to be hosted
at a common path without placing additional burdens on the user at
upgrade time.
-Alejandro
^ permalink raw reply
* Re: [1.8.0] git-stash invocation changes
From: Thomas Rast @ 2011-02-02 18:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <vpqtygmwbee.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:
> >> Proposal:
> >>
> >> 1. Change 'git stash <not-a-stash-command>' to give a usage message
> >> instead of using <not-a-stash-command> as the stash message.
> >
> > Oh please, yes, please do this. We should have done this long, long
> > ago. Its easy enough to train your fingers or fix your scripts to say
> > `git stash save list` rather than `git stash lsit` once stash errors
> > out and gives you a usage message once.
>
> Err, hasn't this been fixed long ago already?
Oh, you're actually right. I have totally missed this, and should
obviously have tested first.
Still, I think the change to 'git stash -p' is also worthwhile.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] post-receive-email: suppress error if description file missing
From: Junio C Hamano @ 2011-02-02 18:36 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Ralf Hemmecke, git
In-Reply-To: <20110202174242.GA12470@atcmail.atc.tcs.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> ---
> contrib/hooks/post-receive-email | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index f99ea95..71f2b47 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -709,7 +709,7 @@ if [ -z "$GIT_DIR" ]; then
> exit 1
> fi
>
> -projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
> +projectdesc=$(sed -ne '1p' "$GIT_DIR/description 2>/dev/null")
I suspect that you would want to have the redirection outside the dq pair,
but other than that, well spotted.
You forgot to sign-off, though ;-)
> # Check if the description is unchanged from it's default, and shorten it to
> # a more manageable length if it is
> if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> --
> 1.7.3.4
^ permalink raw reply
* Re: [1.8.0] git-stash invocation changes
From: Matthieu Moy @ 2011-02-02 18:15 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Thomas Rast, Junio C Hamano, git
In-Reply-To: <AANLkTimu=drR+4v+B_aB+Y4jVqzaBghh1XYSZoACsBry@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:
>> Proposal:
>>
>> 1. Change 'git stash <not-a-stash-command>' to give a usage message
>> instead of using <not-a-stash-command> as the stash message.
>
> Oh please, yes, please do this. We should have done this long, long
> ago. Its easy enough to train your fingers or fix your scripts to say
> `git stash save list` rather than `git stash lsit` once stash errors
> out and gives you a usage message once.
Err, hasn't this been fixed long ago already?
$ git stash not-a-stash-command
Usage: git stash list [<options>]
or: git stash show [<stash>]
or: git stash drop [-q|--quiet] [<stash>]
or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: git stash branch <branchname> [<stash>]
or: git stash [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]]
or: git stash clear
$ git stash save --no-such-option
error: unknown option for 'stash save': --no-such-option
To provide a message, use git stash save -- '--no-such-option'
Usage: [...]
Only this could be seen as a problem:
$ git stash save this-is-not-a-stash-name
Saved working directory and index state On master: this-is-not-a-stash-name
in particular, it is wrt:
Thomas Rast <trast@student.ethz.ch> writes:
> 2. Change 'git stash -p <args>' to treat the <args> as filename
> arguments similar to add -p. Possibly add a -m option that lets
> you specify a message anyway, if desired.
I'm not a user of "stash with messages" myself, so I can't say how
annoying the migration would be, but -m "message" sounds good to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Q on "index-pack: smarter memory usage during delta resolution, 2008-10-17"
From: Junio C Hamano @ 2011-02-02 18:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In find_unresolved_deltas(), there are two loops that walk the range of deltas[]
array that potentially share the same base object. One loop for ref-delta
looks like this:
for (i = ref_first; i <= ref_last; i++) {
struct object_entry *child = objects + deltas[i].obj_no;
if (child->real_type == OBJ_REF_DELTA) {
struct base_data result;
resolve_delta(child, base, &result);
if (i == ref_last && ofs_last == -1)
free_base_data(base);
find_unresolved_deltas(&result, base);
}
}
I was wondering what happens when the entry at ref_last was a false match
(i.e. the "union delta_base" happened to have the same 20-byte pattern but
was of a wrong kind).
The other loop for ofs-delta has the same "if (i == ofs_last)" condition.
Admittedly this is rather hard to trigger (you have to find an object
as a ofs-delta base object, and then come up with another object whose
object name is the same as the offset of the first base object followed
by bunch of '\0' and use it as a ref-delta base), and even if it did, it
will only retain the memory for slightly longer time in the function.
Is a patch along the following line worth doing, I wonder.
-- >8 --
Subject: index-pack: group the delta-base array entries also by type
Entries in the delta_base array are only grouped by the bytepattern in
the delta_base union, some of which have 20-byte object name of the base
object (i.e. base for REF_DELTA objects), while others have sizeof(off_t)
bytes followed by enough NULs to fill 20-byte. The loops to iterate
through a range inside this array still needs to inspect the type of the
delta, and skip over false hits.
Group the entries also by type to eliminate the potential of false hits.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/index-pack.c | 61 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 40 insertions(+), 21 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 8dc5c0b..1b5d83a 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -391,7 +391,18 @@ static void *get_data_from_pack(struct object_entry *obj)
return data;
}
-static int find_delta(const union delta_base *base)
+static int compare_delta_bases(const union delta_base *base1,
+ const union delta_base *base2,
+ enum object_type type1,
+ enum object_type type2)
+{
+ int cmp = type1 - type2;
+ if (cmp)
+ return cmp;
+ return memcmp(base1, base2, UNION_BASE_SZ);
+}
+
+static int find_delta(const union delta_base *base, enum object_type type)
{
int first = 0, last = nr_deltas;
@@ -400,7 +411,8 @@ static int find_delta(const union delta_base *base)
struct delta_entry *delta = &deltas[next];
int cmp;
- cmp = memcmp(base, &delta->base, UNION_BASE_SZ);
+ cmp = compare_delta_bases(base, &delta->base,
+ type, objects[delta->obj_no].type);
if (!cmp)
return next;
if (cmp < 0) {
@@ -413,9 +425,10 @@ static int find_delta(const union delta_base *base)
}
static void find_delta_children(const union delta_base *base,
- int *first_index, int *last_index)
+ int *first_index, int *last_index,
+ enum object_type type)
{
- int first = find_delta(base);
+ int first = find_delta(base, type);
int last = first;
int end = nr_deltas - 1;
@@ -543,11 +556,13 @@ static void find_unresolved_deltas(struct base_data *base,
union delta_base base_spec;
hashcpy(base_spec.sha1, base->obj->idx.sha1);
- find_delta_children(&base_spec, &ref_first, &ref_last);
+ find_delta_children(&base_spec,
+ &ref_first, &ref_last, OBJ_REF_DELTA);
memset(&base_spec, 0, sizeof(base_spec));
base_spec.offset = base->obj->idx.offset;
- find_delta_children(&base_spec, &ofs_first, &ofs_last);
+ find_delta_children(&base_spec,
+ &ofs_first, &ofs_last, OBJ_OFS_DELTA);
}
if (ref_last == -1 && ofs_last == -1) {
@@ -559,24 +574,24 @@ static void find_unresolved_deltas(struct base_data *base,
for (i = ref_first; i <= ref_last; i++) {
struct object_entry *child = objects + deltas[i].obj_no;
- if (child->real_type == OBJ_REF_DELTA) {
- struct base_data result;
- resolve_delta(child, base, &result);
- if (i == ref_last && ofs_last == -1)
- free_base_data(base);
- find_unresolved_deltas(&result, base);
- }
+ struct base_data result;
+
+ assert(child->real_type == OBJ_REF_DELTA);
+ resolve_delta(child, base, &result);
+ if (i == ref_last && ofs_last == -1)
+ free_base_data(base);
+ find_unresolved_deltas(&result, base);
}
for (i = ofs_first; i <= ofs_last; i++) {
struct object_entry *child = objects + deltas[i].obj_no;
- if (child->real_type == OBJ_OFS_DELTA) {
- struct base_data result;
- resolve_delta(child, base, &result);
- if (i == ofs_last)
- free_base_data(base);
- find_unresolved_deltas(&result, base);
- }
+ struct base_data result;
+
+ assert(child->real_type == OBJ_OFS_DELTA);
+ resolve_delta(child, base, &result);
+ if (i == ofs_last)
+ free_base_data(base);
+ find_unresolved_deltas(&result, base);
}
unlink_base_data(base);
@@ -586,7 +601,11 @@ static int compare_delta_entry(const void *a, const void *b)
{
const struct delta_entry *delta_a = a;
const struct delta_entry *delta_b = b;
- return memcmp(&delta_a->base, &delta_b->base, UNION_BASE_SZ);
+
+ /* group by type (ref vs ofs) and then by value (sha-1 or offset) */
+ return compare_delta_bases(&delta_a->base, &delta_b->base,
+ objects[delta_a->obj_no].type,
+ objects[delta_b->obj_no].type);
}
/* Parse all objects and return the pack content SHA1 hash */
^ permalink raw reply related
* [PATCH] post-receive-email: suppress error if description file missing
From: Sitaram Chamarty @ 2011-02-02 17:42 UTC (permalink / raw)
Cc: Ralf Hemmecke, git
---
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index f99ea95..71f2b47 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -709,7 +709,7 @@ if [ -z "$GIT_DIR" ]; then
exit 1
fi
-projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
+projectdesc=$(sed -ne '1p' "$GIT_DIR/description 2>/dev/null")
# Check if the description is unchanged from it's default, and shorten it to
# a more manageable length if it is
if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
--
1.7.3.4
^ permalink raw reply related
* (unknown),
From: Kamol Siesan @ 2011-02-02 17:31 UTC (permalink / raw)
To: git
^ permalink raw reply
* Re: [1.8.0] git-stash invocation changes
From: Shawn Pearce @ 2011-02-02 17:35 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201102021823.19559.trast@student.ethz.ch>
On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:
> Proposal:
>
> 1. Change 'git stash <not-a-stash-command>' to give a usage message
> instead of using <not-a-stash-command> as the stash message.
Oh please, yes, please do this. We should have done this long, long
ago. Its easy enough to train your fingers or fix your scripts to say
`git stash save list` rather than `git stash lsit` once stash errors
out and gives you a usage message once.
> Migration plan:
>
> In 1.7.5, give a loud warning for both syntaxes.
>
> In 1.8.0, switch them as described.
Just fix it. I can't imagine anyone cares enough that `git stash
blah` stops working without first saying save.
--
Shawn.
^ permalink raw reply
* [1.8.0] git-stash invocation changes
From: Thomas Rast @ 2011-02-02 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
Proposal:
1. Change 'git stash <not-a-stash-command>' to give a usage message
instead of using <not-a-stash-command> as the stash message.
2. Change 'git stash -p <args>' to treat the <args> as filename
arguments similar to add -p. Possibly add a -m option that lets
you specify a message anyway, if desired.
Rationale:
The first one has long been a pet peeve of others, too. It makes the
stash command prone to typo accidents and such.
The second one was my own fault, and breaks the symmetry with the rest
of the -p family.
Risks:
Users trained to either usage will obviously have to retrain their
fingers. Scripts may also have to be changed, but if anything they
probably use a 'git stash; do_something; git stash pop' pattern which
would not be affected. (I also suspect most scripts using this
pattern forget to check whether there is anything to stash, and thus
are broken if there isn't.)
Migration plan:
In 1.7.5, give a loud warning for both syntaxes.
In 1.8.0, switch them as described.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Santi Béjar @ 2011-02-02 16:19 UTC (permalink / raw)
To: Johan Herland
Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy,
Nicolas Pitre
In-Reply-To: <201102021651.21669.johan@herland.net>
On Wed, Feb 2, 2011 at 4:51 PM, Johan Herland <johan@herland.net> wrote:
> On Wednesday 02 February 2011, Santi Béjar wrote:
>> On Wednesday 02 February 2011, Johan Herland wrote:
>> > Proposal:
>> >
>> > Currently, git stores remote refs in the local repo by default as
>> > follows:
>> >
>> > Remote repo -> Local repo
>> > ---------------------------------------------------------
>> > HEAD refs/remotes/$remote/HEAD (implicit)
>> > refs/heads/* refs/remotes/$remote/*
>> > refs/tags/* refs/tags/* (implicit, autofollow)
>> > refs/replace/* (TBD)
>> > refs/notes/* (TBD)
>> >
>> > Instead, we should change the default ref mappings into the
>> > following:
>> >
>> > Remote repo -> Local repo
>> > --------------------------------------------------
>> > HEAD refs/remotes/$remote/HEAD
>> > refs/heads/* refs/remotes/$remote/heads/*
>> > refs/tags/* refs/remotes/$remote/tags/*
>> > refs/replace/* refs/remotes/$remote/replace/*
>> > refs/notes/* refs/remotes/$remote/notes/*
>>
>> [...]
>>
>> > - We might want to generalize the handling of "$remote/$head" into
>> > allowing shorthands like "$remote/$tag", "$remote/$replace" and
>> > "$remote/$note" as well (provided, of course, that they match
>> > unambiguously).
>>
>> [...]
>>
>> > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local
>> > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match.
>> > If no local tag is found, we look up the tag name in all configured
>> > remotes (using the method described in [1]). If the tag name exists
>> > in one or more remotes, and those remotes all agree on its ultimate
>> > object name (after applying e.g. ^{commit} or whatever is
>> > appropriate in the context of the lookup), then we also have an
>> > unambiguous match. However, if the tag name exists in multiple
>> > remotes, and they do NOT all agree on its ultimate object name,
>> > then the shorthand tag name is ambiguous and the lookup fails. The
>> > user can always resolve this ambiguity by creating a local tag
>> > (refs/tags/v1.7.4) pointing to the desired object.
>>
>> And the other way around. What would be the output of "git name-rev"
>> , "git describe", "--decorate", and such? $remote/tags/$tag?
>> $remote/$tag? $tag?
>>
>> I would say $remote/$tag for "git name-rev" and "--decorate" but $tag
>> for "git describe" as it is usually used to create files, i.e.
>> git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do
>> not expect to have an / in the "git describe" output, at least in the
>> default output (in contrast with the --all flag).
>
> Thanks for raising an important point.
>
> I don't buy the file name creation argument, as 'describe' is used from
> many different contexts, and file name creation is nowhere documented
> as one of its primary objectives.
Yes, I know it is used from many different contexts, but one important
one is the creation of the tar files, even git.git's Makefile assumes
this. But as at the end we agree...
>
> Still, the objective of 'describe' is to create a human-readable string
> that tries to say something meaningful about a commit in relation to
> its preceding history, while at the same time uniquely identifying the
> commit. The "uniquely identifying" part is taken care of by
> the "-g<SHA1>" part of the output, while the initial "<tagname>-<n>"
> part makes it human-friendly. Therefore, we only care that the
> <tagname> is fairly unambiguous in the mind of the reader. From this
> perspective, which of the alternatives makes more sense? I would
> disqualify "$remote/$tag" and "$remote/tags/$tag", since the $remote
> name is repo-specific, and 'describe' output is often passed around
> between multiple developers/repos. Hence, I think that "$tag" is a good
> choice for 'describe'. If "$tag" is ambiguous in the current repo, then
> an "ambiguous tag" tag warning can be printed, but I would still
> use "$tag".
>
> When it comes to 'name-rev' and '--decorate', those are (AFAICS) much
> more repo-specific, and seldom passed between users. Also, they don't
> have the "-g<SHA1>" part from the 'describe' output. Hence, in this
> case, I consider unique identification (unambiguity) much more
> important than not displaying $remote names. Therefore, I'd propose
> using the shortest unambiguous alternative.
I agree. Something like this I had in mind :)
>
>> Another point to consider is if we want a default remote for tags, a
>> config tags.defaultRemote (TBD), defaulting to origin, specifying the
>> default remote for tags. There would be a hierarchy: local tags,
>> default remote tags, remote tags. With this if one tag is on multiple
>> remote the tag from the default remote always wins.
>>
>> In this way all the tag related input/output would no change much.
>> For example all the decoration would be $tag instead of origin/tag.
>
> Agreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to
> bikeshed) may be a valuable addition. Another way to achieve this would
> be to explicitly copy tags from the preferred remote (e.g. origin)
> directly into refs/tags. I.e. in addition to the (new) default tag
> refspec
>
> +refs/tags/*:refs/remotes/origin/tags/*
>
> you could add an _additional_ refspec
>
> refs/tags/*:refs/tags/*
>
> that would also copy all of origin's tags directly into your local tag
> namespace.
Yes, you always can add this refspec but I don't want to pollute my
"strict" local tags. And moreover with the config tags.preferredRemote
you can change from one preferred remote to another just changing a
config.
> Thanks for the feedback! :)
Thanks for the proposal!
HTH,
Santi
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-02 15:51 UTC (permalink / raw)
To: Santi Béjar
Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy,
Nicolas Pitre, johan
In-Reply-To: <AANLkTimqQtLB--7pwwTALmcchnNCX0nm4Rfx8w1gp74T@mail.gmail.com>
On Wednesday 02 February 2011, Santi Béjar wrote:
> On Wednesday 02 February 2011, Johan Herland wrote:
> > Proposal:
> >
> > Currently, git stores remote refs in the local repo by default as
> > follows:
> >
> > Remote repo -> Local repo
> > ---------------------------------------------------------
> > HEAD refs/remotes/$remote/HEAD (implicit)
> > refs/heads/* refs/remotes/$remote/*
> > refs/tags/* refs/tags/* (implicit, autofollow)
> > refs/replace/* (TBD)
> > refs/notes/* (TBD)
> >
> > Instead, we should change the default ref mappings into the
> > following:
> >
> > Remote repo -> Local repo
> > --------------------------------------------------
> > HEAD refs/remotes/$remote/HEAD
> > refs/heads/* refs/remotes/$remote/heads/*
> > refs/tags/* refs/remotes/$remote/tags/*
> > refs/replace/* refs/remotes/$remote/replace/*
> > refs/notes/* refs/remotes/$remote/notes/*
>
> [...]
>
> > - We might want to generalize the handling of "$remote/$head" into
> > allowing shorthands like "$remote/$tag", "$remote/$replace" and
> > "$remote/$note" as well (provided, of course, that they match
> > unambiguously).
>
> [...]
>
> > [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local
> > tag (refs/tags/v1.7.4) is found, then we have an unambiguous match.
> > If no local tag is found, we look up the tag name in all configured
> > remotes (using the method described in [1]). If the tag name exists
> > in one or more remotes, and those remotes all agree on its ultimate
> > object name (after applying e.g. ^{commit} or whatever is
> > appropriate in the context of the lookup), then we also have an
> > unambiguous match. However, if the tag name exists in multiple
> > remotes, and they do NOT all agree on its ultimate object name,
> > then the shorthand tag name is ambiguous and the lookup fails. The
> > user can always resolve this ambiguity by creating a local tag
> > (refs/tags/v1.7.4) pointing to the desired object.
>
> And the other way around. What would be the output of "git name-rev"
> , "git describe", "--decorate", and such? $remote/tags/$tag?
> $remote/$tag? $tag?
>
> I would say $remote/$tag for "git name-rev" and "--decorate" but $tag
> for "git describe" as it is usually used to create files, i.e.
> git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do
> not expect to have an / in the "git describe" output, at least in the
> default output (in contrast with the --all flag).
Thanks for raising an important point.
I don't buy the file name creation argument, as 'describe' is used from
many different contexts, and file name creation is nowhere documented
as one of its primary objectives.
Still, the objective of 'describe' is to create a human-readable string
that tries to say something meaningful about a commit in relation to
its preceding history, while at the same time uniquely identifying the
commit. The "uniquely identifying" part is taken care of by
the "-g<SHA1>" part of the output, while the initial "<tagname>-<n>"
part makes it human-friendly. Therefore, we only care that the
<tagname> is fairly unambiguous in the mind of the reader. From this
perspective, which of the alternatives makes more sense? I would
disqualify "$remote/$tag" and "$remote/tags/$tag", since the $remote
name is repo-specific, and 'describe' output is often passed around
between multiple developers/repos. Hence, I think that "$tag" is a good
choice for 'describe'. If "$tag" is ambiguous in the current repo, then
an "ambiguous tag" tag warning can be printed, but I would still
use "$tag".
When it comes to 'name-rev' and '--decorate', those are (AFAICS) much
more repo-specific, and seldom passed between users. Also, they don't
have the "-g<SHA1>" part from the 'describe' output. Hence, in this
case, I consider unique identification (unambiguity) much more
important than not displaying $remote names. Therefore, I'd propose
using the shortest unambiguous alternative.
> Another point to consider is if we want a default remote for tags, a
> config tags.defaultRemote (TBD), defaulting to origin, specifying the
> default remote for tags. There would be a hierarchy: local tags,
> default remote tags, remote tags. With this if one tag is on multiple
> remote the tag from the default remote always wins.
>
> In this way all the tag related input/output would no change much.
> For example all the decoration would be $tag instead of origin/tag.
Agreed, tags.defaultRemote (or tags.preferredRemote if I'm allowed to
bikeshed) may be a valuable addition. Another way to achieve this would
be to explicitly copy tags from the preferred remote (e.g. origin)
directly into refs/tags. I.e. in addition to the (new) default tag
refspec
+refs/tags/*:refs/remotes/origin/tags/*
you could add an _additional_ refspec
refs/tags/*:refs/tags/*
that would also copy all of origin's tags directly into your local tag
namespace.
Thanks for the feedback! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Marking file as non-binary
From: Matthieu Moy @ 2011-02-02 15:05 UTC (permalink / raw)
To: Maaartin; +Cc: git
In-Reply-To: <iibrce$a8g$1@dough.gmane.org>
Maaartin <grajcar1@seznam.cz> writes:
> For whatever reason, git claims that my foo.cpp (c++ source) is
> binary,
There is probably a null character in your source ('\0'). You usually
don't want that, regardless of Git.
> *.cpp diff=true text=true
*.cpp diff
works for me. Otherwise, "git log -p -a".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Marking file as non-binary
From: Maaartin @ 2011-02-02 14:57 UTC (permalink / raw)
To: git
For whatever reason, git claims that my foo.cpp (c++ source) is binary,
which means I see no diff when doing git log -p. I already tried putting
*.cpp diff=true text=true
in .gitattributes in maybe 20 different variations, but it doesn't help
at all. I've checked the filename for typos, etc. Today is a day when
really nothing works here.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Santi Béjar @ 2011-02-02 13:27 UTC (permalink / raw)
To: Johan Herland
Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy,
Nicolas Pitre
In-Reply-To: <201102020322.00171.johan@herland.net>
On Wed, Feb 2, 2011 at 3:21 AM, Johan Herland <johan@herland.net> wrote:
> On Wednesday 02 February 2011, Sverre Rabbelier wrote:
>> On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote:
>> > i.e., make refs/remotes/* an actual mirror of selected parts of the
>> > remote's refs/ hierarchy. And then figure out sane rules for merging
>> > those namespaces into the ref lookup procedure.
>>
>> Jeff, Nguy, are either of you interested in writing up a new/modifying
>> this proposal to be about namespacing everything?
>
> Here's my go at phrasing this in a proposal format. Feel free to revise and
> resend:
>
+1
>
> Proposal:
>
> Currently, git stores remote refs in the local repo by default as follows:
>
> Remote repo -> Local repo
> ---------------------------------------------------------
> HEAD refs/remotes/$remote/HEAD (implicit)
> refs/heads/* refs/remotes/$remote/*
> refs/tags/* refs/tags/* (implicit, autofollow)
> refs/replace/* (TBD)
> refs/notes/* (TBD)
>
> Several users report that they are confused by the difference in how heads
> and tags are mapped, and by the implicit mappings that are not mentioned in
> the configured refspecs. Also, as users want to share ever more different
> types of refs (replace refs and notes refs have been discussed recently),
> the existing ref mappings (aka. refspecs) do not suggest a natural/intuitive
> mapping for the new ref types.
>
> Instead, we should change the default ref mappings into the following:
>
> Remote repo -> Local repo
> --------------------------------------------------
> HEAD refs/remotes/$remote/HEAD
> refs/heads/* refs/remotes/$remote/heads/*
> refs/tags/* refs/remotes/$remote/tags/*
> refs/replace/* refs/remotes/$remote/replace/*
> refs/notes/* refs/remotes/$remote/notes/*
[...]
> - We might want to generalize the handling of "$remote/$head" into allowing
> shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as
> well (provided, of course, that they match unambiguously).
[...]
> [2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag
> (refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local
> tag is found, we look up the tag name in all configured remotes (using the
> method described in [1]). If the tag name exists in one or more remotes, and
> those remotes all agree on its ultimate object name (after applying e.g.
> ^{commit} or whatever is appropriate in the context of the lookup), then we
> also have an unambiguous match. However, if the tag name exists in multiple
> remotes, and they do NOT all agree on its ultimate object name, then the
> shorthand tag name is ambiguous and the lookup fails. The user can always
> resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing
> to the desired object.
And the other way around. What would be the output of "git name-rev" ,
"git describe", "--decorate", and such? $remote/tags/$tag?
$remote/$tag? $tag?
I would say $remote/$tag for "git name-rev" and "--decorate" but $tag
for "git describe" as it is usually used to create files, i.e.
git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do
not expect to have an / in the "git describe" output, at least in the
default output (in contrast with the --all flag).
Another point to consider is if we want a default remote for tags, a
config tags.defaultRemote (TBD), defaulting to origin, specifying the
default remote for tags. There would be a hierarchy: local tags,
default remote tags, remote tags. With this if one tag is on multiple
remote the tag from the default remote always wins.
In this way all the tag related input/output would no change much. For
example all the decoration would be $tag instead of origin/tag.
HTH,
Santi
^ permalink raw reply
* Re: [Bug] Permissions of temp file created in git's sha1_file.c correct?
From: Daniel Höpfl @ 2011-02-02 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <m3vd128uz7.fsf@localhost.localdomain>
On Wed, 02 Feb 2011 04:47:20 -0800 (PST), Jakub Narebski <jnareb@gmail.com>
wrote:
> That is why there is `core.fileMode` config variable, see git-config(1)
> manpage:
I saw (and liked) that option but I do not want to use the executable bit
on my "FAT-compatible" file system for other things anyways.
> Didin't git detect that it was on such filesystem?
I did not create the repository on the device, it was simply copied onto
the volume.
One `git init` later: Git detects that the filesystem knows about the
executable flag and sets filemode = true. (On a real FAT, it would be set
to false, of course).
> Not true. Whether file can be renamed or deleted is governed by
> permissions in directory that contains given file, not the file itself
> (at least on POSIX). If I understand things correctly, of course.
OK, then that's a reason to fix my implementation. (Done.)
I still think that a file that is to be written to should not be created
without the right to do so.
> Note that git doesn't store full permissions, in particular read/write
> permissions, only executable bit and "is symlink" thing.
Executable is all I need. Since there was only one bit left in the FAT
directory entries, my file system uses this bit to store the executable
flag. Writeable is derived from/mapped to !readonly. That's all I changed,
compared to a normal FAT.
Thanks for the very fast answer,
Daniel
^ permalink raw reply
* Re: Tracking empty directories
From: Kevin P. Fleming @ 2011-02-02 12:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov, git,
Shawn Pearce
In-Reply-To: <AANLkTikkymYmnXh7XB1SM8br_oK-YmAJYfkwjTuLzr+f@mail.gmail.com>
On 02/01/2011 09:54 PM, Nguyen Thai Ngoc Duy wrote:
> On Wed, Feb 2, 2011 at 2:03 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>>> To add, one would use "git update-index --add".
>>
>> Porcelain version could be "git add -N<directory>", don't you agree?
>
> "git add" is recursive, with or without -N. What I worry is user
> accidentally "git add -N<dir>" where<dir> is not empty, which adds
> everything in<dir>.
>
>>> The magic disappears when you register a file within that directory;
>>> to tell git you want to keep it, one would mkdir and
>>> "git update-index --add" again. Once it's working, we can think about
>>> if there is a need for making that last step automatic after all
>>> (my guess: "no"). ;-)
>>
>> Hmmm... could we use mechanism similar to assume-unchanged to mark
>> directory as explicitely tracked, and that git should not remove it
>> when it becomes empty?
>
> I think git-attr suits better, more persistent. Although if you insist
> the directory must stay, why not just put a hidden file in there?
That's what I do now... in fact, since the empty directory needs to
exist in checkouts *and* be empty, adding a .gitignore file with content
'*' works quite well.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org
^ permalink raw reply
* Re: [Bug] Permissions of temp file created in git's sha1_file.c correct?
From: Jakub Narebski @ 2011-02-02 12:47 UTC (permalink / raw)
To: Daniel Höpfl; +Cc: git
In-Reply-To: <5dfd4de157546244c86acd52564247ce@kloeckner.org>
Daniel Höpfl <daniel@hoepfl.de> writes:
> Hello,
>
> I recently (very recently: yesterday) started using git. I switched from
> Bazaar, that required me to have a file system that supports the executable
> flag (as it always stores this flag based on what the file system says).
> FAT does not support the executable flag.
That is why there is `core.fileMode` config variable, see git-config(1)
manpage:
core.fileMode
If false, the executable bit differences between the index and the
working copy are ignored; useful on broken filesystems like FAT. See
git-update-index(1).
The default is true, except git-clone(1) or git-init(1) will probe
and set core.fileMode false if appropriate when the repository is
created.
Didin't git detect that it was on such filesystem?
[...]
> I think that my file system is right (of course ;-) ): A file that is not
> writable must not be renamed (arguable as the name could be seen as the
> content of the containing directory) and it must not be deleted.
Not true. Whether file can be renamed or deleted is governed by
permissions in directory that contains given file, not the file itself
(at least on POSIX). If I understand things correctly, of course.
Note that git doesn't store full permissions, in particular read/write
permissions, only executable bit and "is symlink" thing.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] vcs-svn: Introduce svnload, a dumpfile producer
From: Erik Faye-Lund @ 2011-02-02 12:43 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Jonathan Nieder, David Barr, Sverre Rabbelier,
Junio C Hamano
In-Reply-To: <20110202025320.GB11339@kytes>
On Wed, Feb 2, 2011 at 3:53 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
> Hi Erik,
>
> Erik Faye-Lund writes:
>> A very superficial review, because I don't have much time, and don't
>> know the surrounding code well. Sorry about that.
>
> Thanks. I have to often switch back and fourth between GNU-style (for
> Subversion) and Linux-style (for Git), so please bear with my silly
> style errors.
>
That's completely fair :)
>> On Tue, Feb 1, 2011 at 3:26 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
>> > + if (!val) die("Malformed author line");
>> > + if (!(tz_off = strrchr(val, ' '))) goto error;
>> > + *tz_off++ = '\0';
>> > + if (!(t = strrchr(val, ' '))) goto error;
>>
>> style: use
>> "if (x)
>> do_stuff();"
>> instead of
>> "if (x) do_stuff();"
>
> This was intentional -- I'm only using it when do_stuff() is 'goto
> error'. I thought it looked nicer that way.
>
This is still not the style we use in git:
$ git grep "if (" | grep goto | wc -l
0
$ git grep -B1 "if (" | grep goto | wc -l
33
^ permalink raw reply
* [Bug] Permissions of temp file created in git's sha1_file.c correct?
From: Daniel Höpfl @ 2011-02-02 12:15 UTC (permalink / raw)
To: git
Hello,
I recently (very recently: yesterday) started using git. I switched from
Bazaar, that required me to have a file system that supports the executable
flag (as it always stores this flag based on what the file system says).
FAT does not support the executable flag.
To make a long story short: I modified Apple's FAT kernel extension to
support both, executable and the writable flag. With this file system, I
was not able to push a change to the repository that is stored on a volume
using the file system. I tracked the problem down to one changeset:
<http://git.kernel.org/?p=git/git.git;a=commit;h=5256b006312e4d06e11b49a8b128e9e550e54f31>
introduces the line "fd = git_mkstemp_mode(buffer, 0444);" in sha1_file.c.
This line creates a temporary file that has reading rights for everyone but
no writing rights. I was astonished that it is possible to actually write
to a file you do not have write permission on. My file system driver does
not allow any change on read-only files except changing rights. Especially
it refuses to rename or delete the file. Both is tried some lines after the
file creation (move_temp_to_file, called when returning from
write_loose_object), resulting in an error that aborts the push.
I think that my file system is right (of course ;-) ): A file that is not
writable must not be renamed (arguable as the name could be seen as the
content of the containing directory) and it must not be deleted.
Do anyone agree? If so, my suggestion is to replace both occurrences of
"0444" in sha1_file.c by "0644" (or better
"S_IRUSR|S_IWUSR|S_IWGRP|S_IWOTH", or even "0600"/"S_IRUSR|S_IWUSR"). The
changed rights are changed at the end of move_temp_to_file anyways and
allowing the owner to write to the file is probably not a security issue.
Bye,
Daniel
^ permalink raw reply
* [1.8.0] Tracking empty directories
From: Jakub Narebski @ 2011-02-02 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
See "Tracking empty directories" subthread on git mailing list,
starting with
http://thread.gmane.org/gmane.comp.version-control.git/165655/focus=165831
The idea is for git to be able to track empty directories without the
.keepme (or empty .gitignore) file trick. This was one of the most
requested features is native support for tracking empty directories,
with 35.2% support (from those who answered question) in
"Git User's Survey 2010":
https://git.wiki.kernel.org/index.php/GitSurvey2010#17._Which_of_the_following_features_would_you_like_to_see_implemented_in_git.3F
There were some concerns about *backwards compatibility* of this
feature, see for example this email (which I would summarize here).
http://thread.gmane.org/gmane.comp.version-control.git/165655/focus=165847
That's why it is in 1.8.0 proposals.
The problem with backward compatibility is twofold. First and more
important is while git supports empty tree object (it has it hardcoded
for some time, as it is necessary e.g. for initial diff, or merging
unrelated branches without common ancestor), and there is no problem
with entry for empty tree in a tree object
040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
there is (supposedly) problem when checking out such tree (see email
referenced above) with an old git.
Second is that tracking empty directories would require extension to the
git index (storing trees in index, like we store submodules)... but that
is purely local matter.
There is also issue with pre-change git automatically removing empty
directories, but that is probably matter for pre-commit hook to check,
or pre-receive hook in publishing repository.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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