Hi all,
consider this example:
$ mkdir gittest
$ cd gittest
$ git init
Initialized empty Git repository in d:/gittest/.git/
$ touch f1
$ git add f1
$ git commit commit -m "first commit"
[master (root-commit) e6f935e] first commit
0 files changed
create mode 100644 f1
$ touch f2
$ git checkout e
Signed-off-by: Orgad Shaneh
---
git-submodule.sh | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index aac575e..dd57abb 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -266,6 +266,11 @@ cmd_add()
repo=$
From: Michael Haggerty
It doesn't, so mark the test as failing.
Signed-off-by: Michael Haggerty
---
t/t-basic.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index ccb5435..7347fb8 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -450,6
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
abspath.c| 4 +++-
t/t-basic.sh | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/abspath.c b/abspath.c
index f04ac18..5d62430 100644
--- a/abspath.c
+++ b/abspath.c
@@ -123,7 +123,9 @@ const char *abso
From: Michael Haggerty
It doesn't, so mark the test as failing.
Signed-off-by: Michael Haggerty
---
t/t-basic.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 5963a6c..363e190 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -454,6
From: Michael Haggerty
I really just wanted to tidy up filter_refs(), but I've been sucked
into a cascade of recursive yak shaving. This is my first attempt to
pop the yak stack.
I want to use real_path() for making the handling of
GIT_CEILING_DIRECTORIES more robust, but I noticed that it is b
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
abspath.c| 3 +++
t/t-basic.sh | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/abspath.c b/abspath.c
index 5d62430..3e8325c 100644
--- a/abspath.c
+++ b/abspath.c
@@ -35,6 +35,9 @@ const char *real_pat
From: Michael Haggerty
These tests already pass, but make sure they don't break in the
future.
Signed-off-by: Michael Haggerty
---
It would be great if somebody would check whether these tests pass on
Windows, and if not, give me a tip about how to fix them.
t/t-basic.sh | 11 +++
From: Michael Haggerty
There is currently a bug: if passed an absolute top-level path that
doesn't exist (e.g., "/foo") it incorrectly interprets the path as a
relative path (e.g., returns "$(pwd)/foo"). So mark the test as
failing.
Signed-off-by: Michael Haggerty
---
t/t-basic.sh | 12 ++
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
abspath.c| 5 -
t/t-basic.sh | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/abspath.c b/abspath.c
index 3e8325c..0e1cd7f 100644
--- a/abspath.c
+++ b/abspath.c
@@ -45,8 +45,11 @@ const char *real
Angelo Borsotti writes:
>"It updates the named paths in the working tree from the index file or
>from a named ..."
It checks out the contents of the named paths out of either the
index or out of the tree-ish and stores that to a file in the
working tree. The working tree is not consult
Marco Stornelli writes:
> I don't have thunderbird now but actually it's really simple:
>
> Subject:
> To:
> Cc:
> $SEP
The above is not a very useful "example" to advance this discussion,
I have to say. For one, where is your Oggetto? Are these fields
the only ones you will ever see? Are the
It finds three commits that has older commit timestamp than the
newest commit timestamp among its ancestor in our history; all of
these are a direct child of a commit that is older (i.e. the clock
skew lasts for only one hop).
commit gen timestamp skew gen ancestor
ed19f36 28
On Tue, Sep 4, 2012 at 9:55 AM, Junio C Hamano wrote:
> Perhaps like this?
Looks good. I was going to complain that this patch applied to
git-checkout.txt only but I just saw git-add.txt also mentions about
quoting wildcards. So I'm good.
> diff --git i/Documentation/git-checkout.txt w/Documenta
Poor man's getitimer(), simply based on alarm().
Currently needed on HP NonStop ("#ifdef __TANDEM"),
which does provide "struct itimerval", but no setitimer().
Alarm times are rounded up to the next full second.
Signed-off-by: Joachim Schmitz
---
Revert/remove my previous 2 patches for this fir
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> Sent: Tuesday, September 04, 2012 12:31 PM
> To: 'Junio C Hamano'
> Cc: 'git@vger.kernel.org'
> Subject: RE: [PATCH v2] Support for setitimer() on platforms lacking it
>
>
> Poor man's getitimer(), simply based on alarm().
>
> Currently
fetch does printf("%-*s", width, "foo") where "foo" can be a utf-8
string, but width is in bytes, not columns. For ASCII it's fine as one
byte takes one column. For utf-8, this may result in misaligned ref
summary table.
Introduce gettext_width() function that returns the string length in
columns
2012/9/4 Junio C Hamano :
> Marco Stornelli writes:
>
>> I don't have thunderbird now but actually it's really simple:
>>
>> Subject:
>> To:
>> Cc:
>> $SEP
>
> The above is not a very useful "example" to advance this discussion,
> I have to say. For one, where is your Oggetto?
1) Where is your O
Hi, Git
Change this:
# git status
# On branch yandex_mail_new_api
# Your branch is ahead of 'origin/yandex_mail_new_api' by 2 commits.
#
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Friday, August 24, 2012 9:47 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; 'Erik Faye-Lund'
> Subject: Re: [PATCH v2] Support non-WIN32 system lacking poll() while keeping
> the WIN32 part intact
>
> "Joachim Schmitz" writes:
>
> >
On Tue, Sep 4, 2012 at 7:25 PM, Коньков Евгений wrote:
> sot this allow:
> git diff 1 same asgit diff a1.txt
> git diff 2 same asgit diff a2.txt
>
> git add 1same asgit add a1.txt
> in case there are may be files with such names I may appply option -s,fo
On Sat, Sep 1, 2012 at 1:11 PM, Torsten Bögershausen wrote:
> diff --git a/parse-options.c b/parse-options.c
> index c1c66bd..5840c18 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -476,7 +476,7 @@ int parse_options(int argc, const char **argv, const char
> *prefix,
>
On Sun, Sep 2, 2012 at 7:12 AM, Adam Spiers wrote:
> diff --git a/dir.c b/dir.c
> index 57a5d11..3a532d5 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -509,22 +509,24 @@ static void prep_exclude(struct dir_struct *dir, const
> char *base, int baselen)
> dir->basebuf[baselen] = '\0';
> }
>
> -/
On Sun, Sep 2, 2012 at 7:12 AM, Adam Spiers wrote:
> extern void path_exclude_check_init(struct path_exclude_check *, struct
> dir_struct *);
> extern void path_exclude_check_clear(struct path_exclude_check *);
> +extern struct exclude *path_excluded_1(struct path_exclude_check *, const
> char
On Sun, Sep 2, 2012 at 7:12 AM, Adam Spiers wrote:
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -273,7 +273,7 @@ static int add_files(struct dir_struct *dir, int flags)
> fprintf(stderr, _(ignore_error));
> for (i = 0; i < dir->ignored_nr; i++)
>
Hi,
if I clone a SVN repository with --preserve-empty-dirs it terminates at some
point with i.e. following error:
folder/subfolder was not found in commit
2dcb008c220f5f6fe33700c9e7deb0c8fa2b8607 (r4)
I tracked things down to the following problem:
- r1: Create a directory with subdirectory with
Hi Duy,
the semantics of "git checkout -- '*'" is quite clear because there is
no expansion done by the shell. The wildcard is passed to git checkout,
that interprets is properly.
That of "git checkout -- *" is the problem when the directory is empty.
Note that this happens with the shell that is
Angelo Borsotti writes:
> $ mkdir gittest
> $ cd gittest
> $ git init
> Initialized empty Git repository in d:/gittest/.git/
At this point, the working tree presumably is empty.
> $ touch f1
> $ git add f1
> $ git commit commit -m "first commit"
> [master (root-commit) e6f935e] first commit
>
Am 04.09.2012 09:31, schrieb Orgad Shaneh:
> Signed-off-by: Orgad Shaneh
Before the "Signed-off-by" is the place where you should have
explained why this would be a worthwhile change ;-)
To me this looks like you make the default noisier and require an
explicit "-q" to make it quiet again. There
Nguyen Thai Ngoc Duy writes:
> On Tue, Sep 4, 2012 at 9:55 AM, Junio C Hamano wrote:
>> Perhaps like this?
>
> Looks good. I was going to complain that this patch applied to
> git-checkout.txt only but I just saw git-add.txt also mentions about
> quoting wildcards. So I'm good.
Ok, with a log m
Marco Stornelli writes:
> 2012/9/4 Junio C Hamano :
>
>> I would expect, at least when you are responding to an existing
>> message, some of them are filled already (and if so, I think appp.sh
>> wants to know exactly how, for example, has RFC2047 quoting already
>> applied, or are we supposed to
Junio C Hamano writes:
> Now we have f1 and f2 in the working tree.
>
>> $ git checkout e6f9 -- *
>
> That is the same as "git checkout e6f935e -- f1 f2", as the shell
> expanded "*" into "f1" and "f2".
>
>> error: pathspec 'f2' did not match any file(s) known to git.
>>
>> Note the error.
>
> Ye
Angelo Borsotti writes:
> That of "git checkout -- *" is the problem when the directory is empty.
> Note that this happens with the shell that is shipped with git (in the
> windows distro). A note in the documentation could help the user
> to understand this.
Passing unmatched glob intact to the
"Joachim Schmitz" writes:
>> If you cannot re-trigger the timer, then you will see "20%" shown
>> after one second, silence for 4 seconds and then "done", for an
>> operation that takes 5 seconds. Which is not the end of the world,
>> though. It does not affect correctness.
>
> That does seem t
Nguyen Thai Ngoc Duy writes:
> On Sat, Sep 1, 2012 at 1:11 PM, Torsten Bögershausen wrote:
>> diff --git a/parse-options.c b/parse-options.c
>> index c1c66bd..5840c18 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -476,7 +476,7 @@ int parse_options(int argc, const char **argv, co
Nguyen Thai Ngoc Duy writes:
> On Sun, Sep 2, 2012 at 7:12 AM, Adam Spiers wrote:
>> extern void path_exclude_check_init(struct path_exclude_check *, struct
>> dir_struct *);
>> extern void path_exclude_check_clear(struct path_exclude_check *);
>> +extern struct exclude *path_excluded_1(struc
Before this, git cherry-pick -x resulted in messages like this:
Message of cherry-picked commit
(cherry picked from commit 871e293c9acbeaacce59dcd98fab6028f552f5be)
Which is not the recommended way to write commit messages. When the
commit message ends with a Signed-off-by, it's less bad.
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, September 04, 2012 6:58 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; 'Johannes Sixt'
> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
>
> "Joachim Schmitz" writes:
>
> >> If you cannot re-trigger
Nguyen Thai Ngoc Duy writes:
>> +static void output_exclude(const char *path, struct exclude *exclude)
>> +{
>> + char *type = exclude->to_exclude ? "excluded" : "included";
>> + char *bang = exclude->to_exclude ? "" : "!";
>> + char *dir = (exclude->flags & EXC_FLAG_MUSTBEDIR)
Коньков Евгений writes:
> # git status
> # On branch yandex_mail_new_api
> # Your branch is ahead of 'origin/yandex_mail_new_api' by 2 commits.
> #
> # Changes not staged for commit:
> # (use "git add ..." to update what will be committed)
> # (use "git checkout -- ..." to discard changes in
mhag...@alum.mit.edu writes:
> From: Michael Haggerty
>
> I really just wanted to tidy up filter_refs(), but I've been sucked
> into a cascade of recursive yak shaving. This is my first attempt to
> pop the yak stack.
Thanks.
> Please note that both absolute_path("") and real_path("") used to
mhag...@alum.mit.edu writes:
> From: Michael Haggerty
>
> These tests already pass, but make sure they don't break in the
> future.
>
> Signed-off-by: Michael Haggerty
> ---
>
> It would be great if somebody would check whether these tests pass on
> Windows, and if not, give me a tip about how t
"Joachim Schmitz" writes:
>> Only with the observation of "clone", I cannot tell if your timer is
>> working. You can try repacking the test repository you created by
>> your earlier "git clone" with "git repack -a -d -f" and see what
>> happens.
>
> It does update the counter too.
Yeah, that w
Robin Stocker writes:
> if (opts->record_origin) {
> + /* Some implementations don't terminate message with
> final \n, so add it */
> + if (msg.message[strlen(msg.message)-1] != '\n')
> + strbuf_addch(&msgbuf, '\n
Junio C Hamano writes:
> "Joachim Schmitz" writes:
>
>>> Only with the observation of "clone", I cannot tell if your timer is
>>> working. You can try repacking the test repository you created by
>>> your earlier "git clone" with "git repack -a -d -f" and see what
>>> happens.
>>
>> It does upd
Am 04.09.2012 19:23, schrieb Joachim Schmitz:
>> From: Junio C Hamano [mailto:gits...@pobox.com]
>> Only with the observation of "clone", I cannot tell if your timer is
>> working. You can try repacking the test repository you created by
>> your earlier "git clone" with "git repack -a -d -f" and s
Junio C Hamano writes:
> mhag...@alum.mit.edu writes:
>
>> Please note that both absolute_path("") and real_path("") used to
>> return the current directory followed by a slash. I believe that this
>> was a bug, and that it is more appropriate for both functions to
>> reject the empty string. T
Il 04/09/2012 17:49, Junio C Hamano ha scritto:
Marco Stornelli writes:
2012/9/4 Junio C Hamano :
I would expect, at least when you are responding to an existing
message, some of them are filled already (and if so, I think appp.sh
wants to know exactly how, for example, has RFC2047 quoting a
Hi Junio,
These patches are from another unfinished branch. However, this
time I can't remember why it's unfinished! ;-)
ATB,
Ramsay Jones
Ramsay Jones (5):
path.c: Remove the 'git_' prefix from a file scope function
path.c: Don't discard the return value of vsnpath()
path.c: Use vsnpath(
In particular, the git_vsnpath() function, despite the 'git_' prefix
suggesting otherwise, is (correctly) declared with file scope.
Signed-off-by: Ramsay Jones
---
path.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/path.c b/path.c
index 66acd24..9eb5333 100644
---
The current implementation of git_path() is essentially the same as
that of vsnpath(), with two minor differences. First, git_path()
currently insists that the git directory path is no longer than
PATH_MAX-100 characters in length. However, vsnpath() does not
attempt this arbitrary 100 character r
In addition to updating the two xstrdup(git_path("...")) call sites
with git_pathdup(), we also fix a memory leak by freeing the memory
allocated to the ADD_EDIT.patch 'file' in the edit_patch() function.
Signed-off-by: Ramsay Jones
---
bisect.c | 2 +-
builtin/add.c | 3 ++-
2 files chang
The git_snpath() and git_pathdup() functions both use the (static)
function vsnpath() in their implementation. Also, they both discard
the return value of vsnpath(), which has the effect of ignoring the
side effect of calling cleanup_path() in the non-error return path.
In order to ensure that th
In addition to updating the xstrdup(mkpath(...)) call sites with
mkpathdup(), we also fix a memory leak (in merge_3way()) caused by
neglecting to free the memory allocated to the 'base_name' variable.
Signed-off-by: Ramsay Jones
---
builtin/branch.c | 2 +-
builtin/clone.c | 4 ++--
builti
Hi Thomas,
The current pu branch is *very* broken on cygwin; practically every
test fails. A git-bisect session points to:
$ git bisect good
a4f6670277d5dc0b082139efe162100c6d7a91b8 is the first bad commit
commit a4f6670277d5dc0b082139efe162100c6d7a91b8
Author: Thomas Gummerer
Signed-off-by: Ramsay Jones
---
read-cache.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index b69dd05..211b971 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1204,9 +1204,11 @@ static int index_changed(struct stat st_old, struct stat
st_new)
int
Signed-off-by: Ramsay Jones
---
Hi Thomas,
Passing the 'struct stat' parameters by value, while not *wrong*, looks
somewhat odd to my eyes. As I said before, feel free to ignore this one.
ATB,
Ramsay Jones
read-cache.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletion
Signed-off-by: Ramsay Jones
---
Hi Thomas,
I note that index_changed(), which has no side effects, is called with
unchanged parameters twice each time around the loop. I was about to
suggest saving the result of a single call and using it in both places ...
However, on first sight, it looks l
Marco Stornelli writes:
> kernel, load the patch and send, really easy. So I don't think it's a
> regression, it's only a change in the work flow.
Any change that forces the user to change an established work flow
supporteed by the existing tool we gave them _is_ a regression, even
if the person
Ramsay Jones writes:
> These patches are from another unfinished branch. However, this
> time I can't remember why it's unfinished! ;-)
That scares me. Perhaps you found some hard-to-debug problem but
didn't have time to follow it through, or something?
;-)
Thanks.
>
> ATB,
> Ramsay Jones
>
Hi,
figuring out what the behavior is by guessing how a command is implemented and
what are its interactions with the shell is a bit hard for the user:
s/he should instead
get it from the documentation.
I tried to figure it out from the examples I have done, and as you
see, I did not get it
quite
On 04.09.12 19:19, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Sat, Sep 1, 2012 at 1:11 PM, Torsten Bögershausen wrote:
>>> diff --git a/parse-options.c b/parse-options.c
>>> index c1c66bd..5840c18 100644
>>> --- a/parse-options.c
>>> +++ b/parse-options.c
>>> @@ -476,7 +476,7 @
Torsten Bögershausen writes:
> This leads to 2 questions:
> a) Do we want the reencode feature in git, so that I continue to work on it?
>From a performance point of view that would probably OK:
>The "git status" on a linux tree was slightly slower on my PC when
> measured with time.
>
Am 31.08.2012 00:26, schrieb Jeff King:
> Ping on this stalled discussion.
Sorry, I got distracted by other stuff again. I did some experiments,
though, and here's a preliminary result.
> It seems like there are two separate issues here:
>
>1. Knowing the encoding of pathnames in the reposi
Ramsay Jones writes:
> The current implementation of git_path() is essentially the same as
> that of vsnpath(), with two minor differences. First, git_path()
> currently insists that the git directory path is no longer than
> PATH_MAX-100 characters in length. However, vsnpath() does not
> attemp
Angelo Borsotti writes:
> The issue here is that the paths must denote filenames that are
> present in the index
> or tree-ish, so, wildcards are misleading since they would instead be
> interpreted
> with respect to the working directory.
When you are talking to a shell (and you almost never di
Ramsay Jones writes:
> The git_snpath() and git_pathdup() functions both use the (static)
> function vsnpath() in their implementation. Also, they both discard
> the return value of vsnpath(), which has the effect of ignoring the
> side effect of calling cleanup_path() in the non-error return pat
René Scharfe writes:
> But now for the patch, which is a bit confusing as well. I'm curious to
> hear about results for more platforms, extractors and character classes.
> Based on that we can see if we need to generate the extra fields instead
> of relying on the new flag.
Thanks for keeping t
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, September 04, 2012 8:47 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; 'Johannes Sixt'
> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
>
> Junio C Hamano writes:
>
> > "Joachim Schmitz" writes:
>
Junio C Hamano writes:
> Instead of naming a rev after a tip that is topologically closest,
> use the tip that is the oldest one among those which contain the
> rev.
>
> The semantics "name-rev --weight" would give us is closer to what
> people expect from "describe --contains".
>
> Note that thi
"Joachim Schmitz" writes:
>> From: Junio C Hamano [mailto:gits...@pobox.com]
>> Sent: Tuesday, September 04, 2012 8:47 PM
>> To: Joachim Schmitz
>> Cc: git@vger.kernel.org; 'Johannes Sixt'
>> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
>>
>> Junio C Hamano writes:
>
Dear l10n team members,
New "git.pot" is generated from v1.7.12-146-g16d26 in the master branch.
l10n: Update git.pot (2 new, 4 removed messages)
Generate po/git.pot from v1.7.12-146-g16d26, and there are 2 new,
4 removed l10n messages.
* 2 new messages are added at lines:
From: "Junio C Hamano"
Sent: Tuesday, September 04, 2012 9:44 PM
Angelo Borsotti writes:
The issue here is that the paths must denote filenames that are
present in the index
or tree-ish, so, wildcards are misleading since they would instead be
interpreted
with respect to the working directory
Andreas Schwab writes:
> You can set up (the git mirror of) the public repository as a remote in
> the private repository and git cherry-pick the commits you want to copy
> over.
Now why didn't I think of that!? :)
Thanks for helping an old bumbler along. :)
-Dave
--
"Philip Oakley" writes:
> A comment about the need to quote wild cards would certainly be of
> advantage to many Windows users who won't have used a shell in that
> way before.
>
> Plus I suspect that a large fraction of basic unix/linux users will
> have never really considered the difference be
The "?" character can be present in a CVS tag name, but git's
bad_ref_char does not allow question marks in git tags. If
git-cvsimport encounters a CVS tag with a question mark, it will error
and refuse to continue the import beyond that point.
When importing CVS tags, strip "?" characters from th
Ken Dreyer writes:
> The "?" character can be present in a CVS tag name, but git's
> bad_ref_char does not allow question marks in git tags. If
> git-cvsimport encounters a CVS tag with a question mark, it will error
> and refuse to continue the import beyond that point.
>
> When importing CVS ta
Certain characters such as "?" can be present in a CVS tag name, but
git does not allow these characters in tags. If git-cvsimport
encounters a CVS tag that git cannot handle, cvsimport will error and
refuse to continue the import beyond that point.
When importing CVS tags, strip all the inappropr
Ken Dreyer writes:
> Certain characters such as "?" can be present in a CVS tag name, but
> git does not allow these characters in tags. If git-cvsimport
> encounters a CVS tag that git cannot handle, cvsimport will error and
> refuse to continue the import beyond that point.
>
> When importing C
2012/9/4 Junio C Hamano :
> Marco Stornelli writes:
>
>> kernel, load the patch and send, really easy. So I don't think it's a
>> regression, it's only a change in the work flow.
>
> Any change that forces the user to change an established work flow
> supporteed by the existing tool we gave them _
80 matches
Mail list logo
