* Re: [PATCH v2 2/5] sha1_file: remove a buggy value setting
From: Junio C Hamano @ 2011-09-06 16:26 UTC (permalink / raw)
To: Wang Hui; +Cc: git, tali
In-Reply-To: <1315304645-12009-3-git-send-email-Hui.Wang@windriver.com>
Wang Hui <Hui.Wang@windriver.com> writes:
> From: Hui Wang <Hui.Wang@windriver.com>
>
> The ent->base[] is a character array, it has pfxlen characters from
> position 0 to (pfxlen-1) to contain an alt object dir name, the
> position pfxlen should be the string terminating character '\0' and
> is deliberately set to '\0' at the previous code line. The position
> (pfxlen+1) is given to ent->name.
Correct. Do you understand why?
We temporarily NUL terminate the ent->base[] so that we can give it to
is_directory() to see if that is a directory, but the invariants for a
alternate_object_database instance after it is properly initialized by
this function are to have:
- the directory name followed by a slash in the base[] array;
- the name pointer pointing at one byte beyond the slash;
- name[2] filled with a slash; and
- name[41] terminated with NUL.
Later, has_loose_object_nonlocal() calls fill_sha1_path() with the name
pointer to fill name[0..1, 3..40] with the hexadecimal representation of
the object name, which would result in base[] array to have the pathname
for a loose object found in that alternate. The same thing happens in
open_sha1_file() to read from a loose object in an alternate.
And you are breaking one of the above invariants by removing that slash
after the directory name. These callers of fill_sha1_path() will see the
directory name, your NUL, two hex, slash, and 38 hex in base[].
How would the code even work with your patch?
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-09-06 16:11 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Michael Schubert, git, Junio C Hamano, Jeff King
In-Reply-To: <CAGdFq_jmW+VZygVj73EP_1oB5DDNp5rYZgZq+i9zf3w6BpsMYA@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 06.09.2011 16:26:
> Heya,
>
> On Tue, Sep 6, 2011 at 16:21, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> Have you ever tried to delete a remote branch?
>>
>> git branch -r -d origin/maint # workee
>> git branch -r -d remotes/origin/maint # no workee
>>
>> Without -r, it doesn't work either.
>
> Heh, I read this as "worktree" / "no worktree" at least 4 times.
>
Yes, our require_work_tree should really be renamed to
no_worktree_no_workee
The beauty of pidgin english ;)
Michael
^ permalink raw reply
* git-rebase skips automatically no more needed commits
From: Francis Moreau @ 2011-09-06 16:08 UTC (permalink / raw)
To: git
Hello,
When rebasing my current branch onto the last master one, there're
sometimes some commits which doesn't add anything anymore.
Currently git-rebase produces the following message:
nothing added to commit but untracked files present (use "git add" to track)
Would it be possible to add a new option to this command so it simply
skip the unneeded commit ?
Thanks
--
Francis
^ permalink raw reply
* Re: Question about right-only
From: Michael J Gruber @ 2011-09-06 16:08 UTC (permalink / raw)
To: mfwitten; +Cc: Tajti Ákos, git
In-Reply-To: <ec1404d75fd6461fa731f31625126884-mfwitten@gmail.com>
mfwitten@gmail.com venit, vidit, dixit 06.09.2011 17:24:
> On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
>
>> what does the right-only option of git-log actually do? The manual is
>> not too verbose about it.
>
> The documentation is indeed a bit messy, so let me rearrange it for you.
>
> From `git help rev-parse':
>
> r1...r2 is called symmetric difference of r1 and r2 and is
> defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
> the set of commits that are reachable from either one of r1 or
> r2 but not from both.
>
> Then we have this from `git help log':
>
> --left-right
> Mark which side of a symmetric diff a commit is reachable
> from. Commits from the left side [(r1 above)] are prefixed with
> < and those from the right [(r2 above)] with >...
>
> which should explain what `<' and `>' mean in the following from
> `git help log':
>
> --left-only, --right-only
> List only commits on the respective side of a symmetric
> range, i.e. only those which would be marked < resp. > by
> --left-right.
>
> This is probably most useful with the following option, described
> in `git help log':
>
> --cherry-pick
> Omit any commit that introduces the same change as another
> commit on the "other side" when the set of commits are
> limited with symmetric difference.
>
> ...
>
> For example, --cherry-pick --right-only A...B omits those
> commits from B which are in A or are patch-equivalent to a
> commit in A. In other words, this lists the + commits from
> git cherry A B. More precisely, --cherry-pick --right-only
> --no-merges gives the exact list.
>
> That is, you often run into multiple commit objects that are unique
> because of, say, differing commit dates, but that actually introduce
> the same change to the source; this combination of options is helpful
> in weeding out commits that introduce the same change.
>
> If you're still confused, don't hesitate to poke the list some more;
> the documentation is quite lacking over all topics, so don't feel
> stupid.
Feel free to improve it :)
Though, in this case, everything is in git-log's man page, except for
the definition of "symmetric range", which is a fundamental concept and
this described by git help revisions, e.g.
Would a pointer from --left-only,--right-only to --cherry-pick help?
Michael
^ permalink raw reply
* Re: [PATCH] send-email: add option -h
From: Junio C Hamano @ 2011-09-06 16:04 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20110906063236.GA4923@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Just found a few more places, so how about this on top?
Yeah, something like that, except for git-send-email bits on side instead,
perhaps. There is no poing in adding a known bad version first and then
fix with a follow-up ;-).
Also I notice that "git-pull" parses "--help-all" but does not seem to do
anything useful (it gives the one-line "Usage: " message and exits with 0)
which probably deserves a patch separate from other commands.
^ permalink raw reply
* Re: Question about right-only
From: Tajti Ákos @ 2011-09-06 15:42 UTC (permalink / raw)
To: mfwitten; +Cc: git
In-Reply-To: <ec1404d75fd6461fa731f31625126884-mfwitten@gmail.com>
Thanks four your answer, it was really great help (cleared up everything)!
Best regards,
Ákos Tajti
2011.09.06. 17:24 keltezéssel, mfwitten@gmail.com írta:
> On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
>
>> what does the right-only option of git-log actually do? The manual is
>> not too verbose about it.
> The documentation is indeed a bit messy, so let me rearrange it for you.
>
> From `git help rev-parse':
>
> r1...r2 is called symmetric difference of r1 and r2 and is
> defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
> the set of commits that are reachable from either one of r1 or
> r2 but not from both.
>
> Then we have this from `git help log':
>
> --left-right
> Mark which side of a symmetric diff a commit is reachable
> from. Commits from the left side [(r1 above)] are prefixed with
> < and those from the right [(r2 above)] with>...
>
> which should explain what `<' and `>' mean in the following from
> `git help log':
>
> --left-only, --right-only
> List only commits on the respective side of a symmetric
> range, i.e. only those which would be marked< resp.> by
> --left-right.
>
> This is probably most useful with the following option, described
> in `git help log':
>
> --cherry-pick
> Omit any commit that introduces the same change as another
> commit on the "other side" when the set of commits are
> limited with symmetric difference.
>
> ...
>
> For example, --cherry-pick --right-only A...B omits those
> commits from B which are in A or are patch-equivalent to a
> commit in A. In other words, this lists the + commits from
> git cherry A B. More precisely, --cherry-pick --right-only
> --no-merges gives the exact list.
>
> That is, you often run into multiple commit objects that are unique
> because of, say, differing commit dates, but that actually introduce
> the same change to the source; this combination of options is helpful
> in weeding out commits that introduce the same change.
>
> If you're still confused, don't hesitate to poke the list some more;
> the documentation is quite lacking over all topics, so don't feel
> stupid.
^ permalink raw reply
* Re: Question about right-only
From: mfwitten @ 2011-09-06 15:24 UTC (permalink / raw)
To: Tajti Ákos; +Cc: git
In-Reply-To: <4E6607B2.2090000@intland.com>
On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
> what does the right-only option of git-log actually do? The manual is
> not too verbose about it.
The documentation is indeed a bit messy, so let me rearrange it for you.
>From `git help rev-parse':
r1...r2 is called symmetric difference of r1 and r2 and is
defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
the set of commits that are reachable from either one of r1 or
r2 but not from both.
Then we have this from `git help log':
--left-right
Mark which side of a symmetric diff a commit is reachable
from. Commits from the left side [(r1 above)] are prefixed with
< and those from the right [(r2 above)] with >...
which should explain what `<' and `>' mean in the following from
`git help log':
--left-only, --right-only
List only commits on the respective side of a symmetric
range, i.e. only those which would be marked < resp. > by
--left-right.
This is probably most useful with the following option, described
in `git help log':
--cherry-pick
Omit any commit that introduces the same change as another
commit on the "other side" when the set of commits are
limited with symmetric difference.
...
For example, --cherry-pick --right-only A...B omits those
commits from B which are in A or are patch-equivalent to a
commit in A. In other words, this lists the + commits from
git cherry A B. More precisely, --cherry-pick --right-only
--no-merges gives the exact list.
That is, you often run into multiple commit objects that are unique
because of, say, differing commit dates, but that actually introduce
the same change to the source; this combination of options is helpful
in weeding out commits that introduce the same change.
If you're still confused, don't hesitate to poke the list some more;
the documentation is quite lacking over all topics, so don't feel
stupid.
^ permalink raw reply
* [PATCH] date.c: Parse timezone with colon as separator
From: Haitao Li @ 2011-09-06 14:56 UTC (permalink / raw)
To: git, gitster; +Cc: Haitao Li
Timezone designators including additional separator (`:`) are ignored.
Actually zone designators in below formats are all valid according to
ISO8601:2004, section 4.3.2:
[+-]hh, [+-]hhmm, [+-]hh:mm
Steps to reproduce the issue this patch fixes:
$ mkdir /tmp/test
$ cd /tmp/test
$ git init
$ echo 'timezone' > file.txt
$ git add .
$ git update-index
$ git write-tree
3e168d57e1c32a4598af134430384f0587581503
# Commit the tree returned above. Give a date with colon separated
# timezone
$ echo "Test commit" | \
TZ=UTC GIT_AUTHOR_DATE='2011-09-03T12:34:56+08:00' \
git commit-tree 3e168d57e1c32a4598af134430384f0587581503 | \
xargs git show | grep Date
Date: Sat Sep 3 12:34:56 2011 +0000
while the expected result is:
Date: Sat Sep 3 12:34:56 2011 +0800
^---
This patch teaches git recognizing zone designators with hours and
minutes separated by colon, or minutes are empty.
Signed-off-by: Haitao Li <lihaitao@gmail.com>
---
date.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/date.c b/date.c
index 896fbb4..8a94944 100644
--- a/date.c
+++ b/date.c
@@ -556,15 +556,21 @@ static int match_tz(const char *date, int *offp)
int min, hour;
int n = end - date - 1;
- min = offset % 100;
- hour = offset / 100;
+ if (n == 2 && *end == ':') {
+ hour = offset;
+ offset = strtoul(date+4, &end, 10);
+ min = offset % 100;
+ } else {
+ hour = offset / 100;
+ min = offset % 100;
+ }
/*
- * Don't accept any random crap.. At least 3 digits, and
+ * Don't accept any random crap.. At least 2 digits, and
* a valid minute. We might want to check that the minutes
* are divisible by 30 or something too.
*/
- if (min < 60 && n > 2) {
+ if (min < 60 && n > 1) {
offset = hour*60+min;
if (*date == '-')
offset = -offset;
--
1.7.5.4
^ permalink raw reply related
* Re: git-svn and mergeinfo
From: Carlos Martín Nieto @ 2011-09-06 14:28 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Michael Haggerty, git
In-Reply-To: <20110906095256.205dd5d0@robyn.woti.com>
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
On Tue, 2011-09-06 at 09:52 -0400, Bryan Jacobs wrote:
> On Tue, 06 Sep 2011 14:56:38 +0200
> Carlos Martín Nieto <cmn@elego.de> wrote:
>
> > You can also save the mergeinfo to a file, add the line, and use
> > --mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
> > blindly replacing every space with a newline is not always the right
> > option. If a merged directory contains a space, this change will break
> > the mergeinfo, even if you're properly quoting your variable or using
> > the $(cat /some/file) method.
> >
> > Cheers,
> > cmn
>
> Ah, a situation I neglected to consider! Perhaps we should revert this
> patch, since I worked up the initiative to write an
> auto-populating-mergeinfo patch for git-svn anyhow.
As it can cause regressions, I think reverting is the right option. And
since git-svn is going to learn to do it by itself, the functionality
isn't a big loss.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Sverre Rabbelier @ 2011-09-06 14:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Michael Schubert, git, Junio C Hamano, Jeff King
In-Reply-To: <4E662C6F.7000205@drmicha.warpmail.net>
Heya,
On Tue, Sep 6, 2011 at 16:21, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Have you ever tried to delete a remote branch?
>
> git branch -r -d origin/maint # workee
> git branch -r -d remotes/origin/maint # no workee
>
> Without -r, it doesn't work either.
Heh, I read this as "worktree" / "no worktree" at least 4 times.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-09-06 14:21 UTC (permalink / raw)
To: Michael Schubert; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <4E661BDE.1080204@elegosoft.com>
Michael Schubert venit, vidit, dixit 06.09.2011 15:10:
> On 08/28/2011 04:54 PM, Michael J Gruber wrote:
>> +static int match_patterns(const char **pattern, const char *refname)
>> +{
>> + if (!*pattern)
>> + return 1; /* no pattern always matches */
>> + while (*pattern) {
>> + if (!fnmatch(*pattern, refname, 0))
>> + return 1;
>> + pattern++;
>> + }
>> + return 0;
>> +}
>
> Nitpick: maybe builtin/branch.c and builtin/tag.c could share match_pattern().?
I think all commands which list refs should share code - for-each-ref,
branch, tag, replace. I suggest to unify log and for-each-ref-formats
first, the unify ref listers.
> A second thought: the printed "remotes/" prefix could be confusing for users,
> since it seems to be part of the refname. For example:
>
> $ git branch -a
> * master
> maint
> man
> remotes/origin/master
> remotes/origin/maint
> remotes/origin/man
>
> $ git branch -a --list remotes/origin*
> [no output]
>
> but
>
> $ git branch -a --list origin*
> remotes/origin/master
> remotes/origin/maint
> remotes/origin/man
>
> (Sorry in case I missed that) What's the reason you decided --list to show local
> branches only? Maybe --list could show all refnames without any extra prefix.?
I didn't decide anything here. "git branch" lists all local branches and
has been doing that forever, and "--list" is and should be a noop
without a pattern. That was the idea: -r/-a select refnames,
--list/-v/-vv activate the list mode(s), and the pattern is matched
against the selected refs.
(This is one reason why I didn't want it to be named --glob - the
pattern is a filter, not a selector.)
That being said, I find the fact that "-a --list remotes/origin/*" does
not match anything somewhat disconcerting, although it fits in with the
general idea of "git branch": it deals with branch names, not ref names.
Have you ever tried to delete a remote branch?
git branch -r -d origin/maint # workee
git branch -r -d remotes/origin/maint # no workee
Without -r, it doesn't work either.
So, the way it is it fits in with how "git branch" works, and is
different from for-each-ref (and rev-list --glob). I don't like it,
because you may have a local branch origin/maint (i.e.
refs/heads/origin/maint) which you can't distinguish from the remote
branch by a pattern, only by using or not using -r. But it's the same as
with "git branch -d", really.
Michael
^ permalink raw reply
* Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo
From: Bryan Jacobs @ 2011-09-06 14:00 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20110903084947.GA16711@dcvr.yhbt.net>
On Sat, 3 Sep 2011 08:49:47 +0000
Eric Wong <normalperson@yhbt.net> wrote:
> dcommit needs to continually rebase because it's possible somebody
> else may make a commit to the SVN repo while a git-svn user is
> dcommiting and cause a conflict the user would need to resolve in the
> working tree.
>
> At least I think that was the reason... There is also the
> "commit-diff" command in git-svn. It was the precursor to dcommit
> which requires no changes to the working tree.
>
Let me see if I've got this right.
The goal here is to commit each x~..x for each x in A..B, aborting if
the SVN tree is not in state "x~" when the diff arrives.
"commit-diff" appears to be doing exactly what "dcommit" is doing, but
iteratively for each change in linearized A..B, rebasing after each
step. This sounds correct to me, assuming that the "apply_diff" method
will correctly abort if a commit races into the upstream SVN before it
is called. So why am I seeing files added in changes on alternate
branches ending up in the working copy when I abort before apply_diff
is called for the commit which merges them into the present branch?
You can check for this yourself with my patch using the example setup I
gave earlier. You'll see files in the present/untracked state - these
interfere with rebasing the user-created-but-not-SVN-dcommited merge
onto the partially-sent-to-SVN tree.
Bryan Jacobs
^ permalink raw reply
* Re: git-svn and mergeinfo
From: Bryan Jacobs @ 2011-09-06 13:52 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Michael Haggerty, git
In-Reply-To: <1315313800.9839.10.camel@bee.lab.cmartin.tk>
On Tue, 06 Sep 2011 14:56:38 +0200
Carlos Martín Nieto <cmn@elego.de> wrote:
> You can also save the mergeinfo to a file, add the line, and use
> --mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
> blindly replacing every space with a newline is not always the right
> option. If a merged directory contains a space, this change will break
> the mergeinfo, even if you're properly quoting your variable or using
> the $(cat /some/file) method.
>
> Cheers,
> cmn
Ah, a situation I neglected to consider! Perhaps we should revert this
patch, since I worked up the initiative to write an
auto-populating-mergeinfo patch for git-svn anyhow.
Bryan Jacobs
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Michael Schubert @ 2011-09-06 13:10 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <0c487086643fbf0334140365f20fef62242b7dac.1314543252.git.git@drmicha.warpmail.net>
On 08/28/2011 04:54 PM, Michael J Gruber wrote:
> +static int match_patterns(const char **pattern, const char *refname)
> +{
> + if (!*pattern)
> + return 1; /* no pattern always matches */
> + while (*pattern) {
> + if (!fnmatch(*pattern, refname, 0))
> + return 1;
> + pattern++;
> + }
> + return 0;
> +}
Nitpick: maybe builtin/branch.c and builtin/tag.c could share match_pattern().?
A second thought: the printed "remotes/" prefix could be confusing for users,
since it seems to be part of the refname. For example:
$ git branch -a
* master
maint
man
remotes/origin/master
remotes/origin/maint
remotes/origin/man
$ git branch -a --list remotes/origin*
[no output]
but
$ git branch -a --list origin*
remotes/origin/master
remotes/origin/maint
remotes/origin/man
(Sorry in case I missed that) What's the reason you decided --list to show local
branches only? Maybe --list could show all refnames without any extra prefix.?
Thanks.
^ permalink raw reply
* Re: git-svn and mergeinfo
From: Carlos Martín Nieto @ 2011-09-06 12:56 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Michael Haggerty, git
In-Reply-To: <20110901104327.14d4dba6@robyn.woti.com>
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:
> On Thu, 01 Sep 2011 10:59:51 +0200
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> > On 08/29/2011 07:20 PM, Bryan Jacobs wrote:
> > > I have been (ab)using git-svn for committing to a central SVN
> > > repository while doing my work locally with git. To this end, I've
> > > written a set of scripts and hooks which perform squash merges
> > > locally and then dcommit them with proper svn:mergeinfo
> > > annotations. The final result is the perfect appearance of having
> > > done a native SVN merge in the central repository, while using only
> > > local git commands and gaining the full benefit of git's conflict
> > > resolution and developer convenience.
> > >
> > > However, to make this work with git 1.7.6, I needed to make *one*
> > > change to the git internals: --merge-info does not allow setting
> > > mergeinfo for more than one branch. Because it's a complete
> > > overwrite operation instead of an update, this is a serious issue
> > > preventing its use for nontrivial branches.
> > >
> > > Might I suggest adding a block like the following around line 552 of
> > > git-svn?
> > >
> > > if (defined($_merge_info))
> > > {
> > > $_merge_info =~ tr{ }{\n};
> > > }
> >
> > Naive question: why can't you pass a newline (properly quoted, of
> > course) directly within the string argument to the --mergeinfo option?
>
> The only way I know of to do that in bash is to assign the
> newline-bearing string to a variable, and then use the variable in a
> command line option. Extremely awkward.
You can also save the mergeinfo to a file, add the line, and use
--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
blindly replacing every space with a newline is not always the right
option. If a merged directory contains a space, this change will break
the mergeinfo, even if you're properly quoting your variable or using
the $(cat /some/file) method.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Daniel Stenberg @ 2011-09-06 12:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Tay Ray Chuan
In-Reply-To: <20110905222202.GA32071@elie>
On Mon, 5 Sep 2011, Jonathan Nieder wrote:
> + if (!curl_errorstr[0])
> + strlcpy(curl_errorstr,
> + curl_easy_strerror(results.curl_result),
> + sizeof(curl_errorstr));
(as libcurl hacker)
For the record, in libcurl we work on providing "extra" information in the
error buffer when there is additional info to provide that would help. In some
cases we deem there isn't (or we just to provide any) and then the generic
error message is good enough and could indeed be used like this...
--
/ daniel.haxx.se
^ permalink raw reply
* Question about right-only
From: Tajti Ákos @ 2011-09-06 11:44 UTC (permalink / raw)
To: git@vger.kernel.org
Dear List,
what does the right-only option of git-log actually do? The manual is
not too verbose about it.
Thanks in advance,
Ákos Tajti
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-06 11:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Clemens Buchacher, Sverre Rabbelier, git
In-Reply-To: <4E65F842.7080601@viscovery.net>
On 6 Sep 2011, Johannes Sixt stated:
> Am 9/6/2011 12:25, schrieb Nix:
>> OK, I'll add range checking support then!
>
> Don't forget to follow this advice noted on the POSIX page
> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html):
>
> Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are
> returned on error and are also valid returns on success, an application
> wishing to check for error situations should set errno to 0, then call
> strtol() or strtoll(), then check errno.
Oh, I've fallen into *that* trap before with math functions setting
ERANGE/EDOM. Thanks for the reminder :)
--
NULL && (void)
^ permalink raw reply
* Re: user permission / authority
From: Carlos Martín Nieto @ 2011-09-06 10:45 UTC (permalink / raw)
To: ian; +Cc: git
In-Reply-To: <1315303980991-6763296.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Tue, 2011-09-06 at 03:13 -0700, ian wrote:
> I could not find user permission or authority level. Thatis, I can restrict a
> user not to use the 'commit' function for example. Seems that everyone
> having GIT & TortoiseGIT can do any of the functions. Is there a way (or any
> other GUI)that enables these restrictions by user?
Not as far as I know, but this isn't necessary. Git is a distributed
system, so any changes that an user does only exist in their local
repository until they push the changes out to some other repository, and
with gitolite[0] you can restrict who can push to which branches.
If you just want people to be able to browse the repository, maybe
installing gitweb or cgit would fit your needs better.
[0] https://github.com/sitaramc/gitolite
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Johannes Sixt @ 2011-09-06 10:38 UTC (permalink / raw)
To: Nix; +Cc: Clemens Buchacher, Sverre Rabbelier, git
In-Reply-To: <87liu2j7c3.fsf@spindle.srvr.nix>
Am 9/6/2011 12:25, schrieb Nix:
> OK, I'll add range checking support then!
Don't forget to follow this advice noted on the POSIX page
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html):
Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are
returned on error and are also valid returns on success, an application
wishing to check for error situations should set errno to 0, then call
strtol() or strtoll(), then check errno.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-06 10:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Clemens Buchacher, Sverre Rabbelier, git
In-Reply-To: <4E65F451.4070900@viscovery.net>
On 6 Sep 2011, Johannes Sixt verbalised:
> Why so? strtol() can report overflow:
... it can?!
> ...
> If the correct value is outside the range of representable values,
> {LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX} shall be returned
> (according to the sign of the value), and errno set to [ERANGE].
I've been using it for longer than I care to imagine and I've never once
noticed that.
OK, I'll add range checking support then! following which we can detect
config value overflow on the most pathetic platform imaginable, except
that such a platform would probably not bother to set ERANGE properly ;}
Fixed patch following later today ripping out the STRTOMAX renaming and
adding proper range checking.
--
NULL && (void)
^ permalink raw reply
* [PATCH v2 4/5] sha1_file: remove relative entries limitation
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315304645-12009-4-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
link_alt_odb_entries() will be called recursively if alternates has
valid object store paths, to avoid nesting too deep, the recursive
depth is limited to 5, this limitation is reasonable and safe for
dead-loop reference situation.
There is another limitation in this function to only permit the 1st
level alternates has relative paths, the purpose of this limitation
is to avoid inaccurate result when using memcmp() directly to compare
two directory path names, e.g. "./a/b/" and "./a/c/e/../../b" should
be the same dir, but memcmp() will report they are different dirs,
this will introduce the same dir be added twice or dead-loop
reference.
Now we have new method to compare two directories and can handle both
absolute path and relative path comparison, in addition to we already
have max depth 5 limitation, we can safely remove this limitation.
Moreover removing this limitation will make below two usage workable.
usage1: base-repos has relative path in the alternates
%>git clone --reference base-repos src dest
usage2: src2 has relative path to point src1, src1 has relative path
to point src
%>git clone src2 dest
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
sha1_file.c | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 18f7fb3..98fdb0a 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -329,15 +329,10 @@ static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
}
while (cp < ep && *cp != sep)
cp++;
- if (last != cp) {
- if (!is_absolute_path(last) && depth) {
- error("%s: ignoring relative alternate object store %s",
- relative_base, last);
- } else {
- link_alt_odb_entry(last, cp - last,
- relative_base, depth);
- }
- }
+ if (last != cp)
+ link_alt_odb_entry(last, cp - last,
+ relative_base, depth);
+
while (cp < ep && *cp == sep)
cp++;
last = cp;
--
1.6.3.1
^ permalink raw reply related
* [PATCH v2 3/5] sha1_file: improve directories comparison method
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315304645-12009-3-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
In the past, to check if two directory paths are same, we use memcmp()
to directly compare their path strings, this method can't get an
accurate result if paths include ".." or "." or redundant slash, e.g.
current dir is /, "/a/b/c", "/a/b//c/d/e/../.." and "./a/b/f/../c"
should be the same dir, but current method will identify they are
different.
Now add a global function is_same_directory() to replace the old
memcmp() method, this function will change two input paths to real
path first, then normalized them and compare them.
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
abspath.c | 26 ++++++++++++++++++++++++++
cache.h | 1 +
sha1_file.c | 4 ++--
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/abspath.c b/abspath.c
index 3005aed..7717f06 100644
--- a/abspath.c
+++ b/abspath.c
@@ -138,3 +138,29 @@ const char *absolute_path(const char *path)
}
return buf;
}
+
+/* Compare two directories, if they are the same dir, return 1, otherwise
+ * return 0.
+ *
+ * The input path can be relative or absolute one, before the comparison, they
+ * will be changed to real path first, then be normalized to remove .. and
+ * redundant slash, in the end, we will compare two real and normalized paths.
+ */
+int is_same_directory(const char *dir1, const char *dir2)
+{
+ const char *real_path1, *real_path2;
+ char norm_path1[PATH_MAX], norm_path2[PATH_MAX];
+
+ real_path1 = real_path(dir1);
+ if (normalize_path_copy(norm_path1, real_path1))
+ return 0;
+
+ real_path2 = real_path(dir2);
+ if (normalize_path_copy(norm_path2, real_path2))
+ return 0;
+
+ if (strlen(norm_path1) != strlen(norm_path2))
+ return 0;
+
+ return !memcmp(norm_path1, norm_path2, strlen(norm_path1));
+}
diff --git a/cache.h b/cache.h
index e11cf6a..70056b5 100644
--- a/cache.h
+++ b/cache.h
@@ -758,6 +758,7 @@ int longest_ancestor_length(const char *path, const char *prefix_list);
char *strip_path_suffix(const char *path, const char *suffix);
int daemon_avoid_alias(const char *path);
int offset_1st_component(const char *path);
+int is_same_directory(const char *dir1, const char *dir2);
/* object replacement */
#define READ_SHA1_FILE_REPLACE 1
diff --git a/sha1_file.c b/sha1_file.c
index 5940d84..18f7fb3 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -286,12 +286,12 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
* thing twice, or object directory itself.
*/
for (alt = alt_odb_list; alt; alt = alt->next) {
- if (!memcmp(ent->base, alt->base, pfxlen)) {
+ if (is_same_directory(ent->base, alt->base)) {
free(ent);
return -1;
}
}
- if (!memcmp(ent->base, objdir, pfxlen)) {
+ if (is_same_directory(ent->base, objdir)) {
free(ent);
return -1;
}
--
1.6.3.1
^ permalink raw reply related
* [PATCH v2 1/5] sha1_file cleanup: remove redundant variable check
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315304645-12009-1-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
This variable check is always true, so it is redundant and need to be
removed.
We can't remove the init value for this variable, since removing
it will introduce building warning:
'base_len' may be used uninitialized in this function.
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
sha1_file.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f7c3408..d12a675 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -255,8 +255,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
if (!is_absolute_path(entry) && relative_base) {
/* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
+ base_len = strlen(relative_base) + 1;
entlen += base_len;
pfxlen += base_len;
}
--
1.6.3.1
^ permalink raw reply related
* [PATCH v2 5/5] t5710: add testcase for multi-level relative alternates
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315304645-12009-5-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
Since we removed "relative alternates only possible for current dir"
limitation, it is needed to change an existing testcase to make it
pass for the relative path at the second level alternates.
Add a new testcase to make it pass when it work at a 5-level relative
alternates repository and make it fail when it work at a 6-level
relative alternates repository.
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
t/t5710-info-alternate.sh | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
index ef7127c..a606a94 100755
--- a/t/t5710-info-alternate.sh
+++ b/t/t5710-info-alternate.sh
@@ -102,9 +102,26 @@ test_valid_repo'
cd "$base_dir"
test_expect_success \
- 'that relative alternate is only possible for current dir' '
+ 'that relative alternate is possible for none current dir' '
cd D &&
- ! (test_valid_repo)
+ test_valid_repo
+'
+
+cd "$base_dir"
+
+test_expect_success 'allow maxium 5 level relative alternate' \
+'echo "" > A/.git/objects/info/alternates &&
+echo "../../../A/.git/objects" > B/.git/objects/info/alternates &&
+echo "../../../B/.git/objects" > C/.git/objects/info/alternates &&
+echo "../../../C/.git/objects" > D/.git/objects/info/alternates &&
+echo "../../../D/.git/objects" > E/.git/objects/info/alternates &&
+echo "../../../E/.git/objects" > F/.git/objects/info/alternates &&
+echo "../../../F/.git/objects" > G/.git/objects/info/alternates &&
+cd F &&
+test_valid_repo &&
+cd ../G &&
+git fsck --full > fsck.err 2>&1 &&
+test `wc -l < fsck.err` != 0
'
cd "$base_dir"
--
1.6.3.1
^ 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