* [PATCH 02/11] Fix declare variable at mid of function
From: Frank Li @ 2009-08-17 16:01 UTC (permalink / raw)
To: git, msysgit; +Cc: Johannes.Schindelin, Frank Li
In-Reply-To: <1250524872-5148-1-git-send-email-lznuaa@gmail.com>
Some compiler such as MSVC can't support declear variable at mid of funtion at c file.
Signed-off-by: Frank Li <lznuaa@gmail.com>
---
compat/mingw.c | 16 ++++++++++++----
help.c | 3 ++-
run-command.c | 2 ++
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index bed4178..75c74b1 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -123,13 +123,17 @@ int mingw_open (const char *filename, int oflags, ...)
{
va_list args;
unsigned mode;
+ int fd;
+
va_start(args, oflags);
mode = va_arg(args, int);
va_end(args);
if (!strcmp(filename, "/dev/null"))
filename = "nul";
- int fd = open(filename, oflags, mode);
+
+ fd = open(filename, oflags, mode);
+
if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
DWORD attrs = GetFileAttributes(filename);
if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
@@ -580,10 +584,11 @@ static char **get_path_split(void)
static void free_path_split(char **path)
{
+ char **p = path;
+
if (!path)
return;
- char **p = path;
while (*p)
free(*p++);
free(path);
@@ -1108,9 +1113,11 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out)
#undef signal
sig_handler_t mingw_signal(int sig, sig_handler_t handler)
{
+ sig_handler_t old;
+
if (sig != SIGALRM)
return signal(sig, handler);
- sig_handler_t old = timer_fn;
+ old = timer_fn;
timer_fn = handler;
return old;
}
@@ -1197,8 +1204,9 @@ struct dirent *mingw_readdir(DIR *dir)
if (dir->dd_handle == (long)INVALID_HANDLE_VALUE && dir->dd_stat == 0)
{
+ DWORD lasterr;
handle = FindFirstFileA(dir->dd_name, &buf);
- DWORD lasterr = GetLastError();
+ lasterr = GetLastError();
dir->dd_handle = (long)handle;
if (handle == INVALID_HANDLE_VALUE && (lasterr != ERROR_NO_MORE_FILES)) {
errno = err_win_to_posix(lasterr);
diff --git a/help.c b/help.c
index 6c46d8b..399b0b4 100644
--- a/help.c
+++ b/help.c
@@ -127,7 +127,7 @@ static int is_executable(const char *name)
return 0;
#ifdef __MINGW32__
- /* cannot trust the executable bit, peek into the file instead */
+{ /* cannot trust the executable bit, peek into the file instead */
char buf[3] = { 0 };
int n;
int fd = open(name, O_RDONLY);
@@ -140,6 +140,7 @@ static int is_executable(const char *name)
st.st_mode |= S_IXUSR;
close(fd);
}
+}
#endif
return st.st_mode & S_IXUSR;
}
diff --git a/run-command.c b/run-command.c
index ff3d8e2..d1df7ab 100644
--- a/run-command.c
+++ b/run-command.c
@@ -123,6 +123,7 @@ int start_command(struct child_process *cmd)
exit(127);
}
#else
+{
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
const char **sargv = cmd->argv;
char **env = environ;
@@ -186,6 +187,7 @@ int start_command(struct child_process *cmd)
dup2(s1, 1), close(s1);
if (s2 >= 0)
dup2(s2, 2), close(s2);
+}
#endif
if (cmd->pid < 0) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH 01/11] Fix build failure at VC because function declare use old style at regex.c
From: Frank Li @ 2009-08-17 16:01 UTC (permalink / raw)
To: git, msysgit; +Cc: Johannes.Schindelin, Frank Li
regerror declare function argument type after function define.
Signed-off-by: Frank Li <lznuaa@gmail.com>
---
compat/regex/regex.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 5ea0075..5728de1 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -4852,11 +4852,7 @@ regexec (preg, string, nmatch, pmatch, eflags)
from either regcomp or regexec. We don't use PREG here. */
size_t
-regerror (errcode, preg, errbuf, errbuf_size)
- int errcode;
- const regex_t *preg;
- char *errbuf;
- size_t errbuf_size;
+regerror (int errcode, const regex_t * preg, char * errbuf,size_t errbuf_size)
{
const char *msg;
size_t msg_size;
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: "make quick-install-man" broke recently
From: Junio C Hamano @ 2009-08-17 15:57 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Junio C Hamano, Jacob Helwig, Linus Torvalds, Kjetil Barvik,
git@vger.kernel.org
In-Reply-To: <861vna8qj6.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> It's good to know I wasn't hallucinating, in any case. :)
Thanks.
^ permalink raw reply
* [PATCH] read-tree: Fix regression with creation of a new index file.
From: Alexandre Julliard @ 2009-08-17 15:35 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd
Reading the index into an empty file has been broken by
5a56da58060e50980fab0f4c38203a25440d1530, since it causes the existing
index to always be loaded first, and dies if it's an empty file:
$ GIT_INDEX_FILE=`mktemp` git read-tree master
fatal: index file smaller than expected
It breaks for instance committing from git.el. This patch reverts to the
previous behavior of only loading the index when merging it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
builtin-read-tree.c | 10 ++++++----
t/t1009-read-tree-new-index.sh | 25 +++++++++++++++++++++++++
2 files changed, 31 insertions(+), 4 deletions(-)
create mode 100755 t/t1009-read-tree-new-index.sh
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 9c2d634..14c836b 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -113,13 +113,15 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
argc = parse_options(argc, argv, unused_prefix, read_tree_options,
read_tree_usage, 0);
- if (read_cache_unmerged() && (opts.prefix || opts.merge))
- die("You need to resolve your current index first");
-
prefix_set = opts.prefix ? 1 : 0;
if (1 < opts.merge + opts.reset + prefix_set)
die("Which one? -m, --reset, or --prefix?");
- stage = opts.merge = (opts.reset || opts.merge || prefix_set);
+
+ if (opts.reset || opts.merge || opts.prefix) {
+ if (read_cache_unmerged() && (opts.prefix || opts.merge))
+ die("You need to resolve your current index first");
+ stage = opts.merge = 1;
+ }
for (i = 0; i < argc; i++) {
const char *arg = argv[i];
diff --git a/t/t1009-read-tree-new-index.sh b/t/t1009-read-tree-new-index.sh
new file mode 100755
index 0000000..59b3aa4
--- /dev/null
+++ b/t/t1009-read-tree-new-index.sh
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+test_description='test read-tree into a fresh index file'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo one >a &&
+ git add a &&
+ git commit -m initial
+'
+
+test_expect_success 'non-existent index file' '
+ rm -f new-index &&
+ GIT_INDEX_FILE=new-index git read-tree master
+'
+
+test_expect_success 'empty index file' '
+ rm -f new-index &&
+ > new-index &&
+ GIT_INDEX_FILE=new-index git read-tree master
+'
+
+test_done
+
--
1.6.4.181.g3f2ea.dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH 0/6] "git commit --dry-run" updates
From: Junio C Hamano @ 2009-08-17 15:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jeff King
In-Reply-To: <200908171201.43343.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> If it's not too much work, it would be nice to somehow detect if -u
> can have any influence at all. For example,
>
> $ git status bar
> # Not currently on any branch.
> nothing to commit (use -u to show untracked files)
>
> is a bit misleading if 'bar' is tracked because adding a -u won't make
> any difference.
It is an issue shared with the original "git status". Running
git init
>file
git add file
git commit -m initial
git status -uno
will give the same "use -u to show" message.
The thing is, "use -u to show" is because you told git not to check if
there is any untracked file. Whoever added -uno wanted not to run the
recursive read_directory() to find them.
The message says "you told me not to check about untracked files, so I can
not show you any, because I did not check; if you want, please use -u to
tell me to check so that I can show them to you".
It is not about "we know that there are untracked files but you told me
not to show it, so I am not telling". We simply do not know at the point
we give that message. In other words, conditional removal of that message
is fundamentally incompatible with the use of -uno.
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Jakub Narebski @ 2009-08-17 16:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0908161002460.8306@pacific.mpi-cbg.de>
On Sun, 16 Aug 2009, Johannes Schindelin wrote:
> On Sun, 16 Aug 2009, Jakub Narebski wrote:
>> On Sat, 15 Aug 2009, Junio C Hamano wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>>>> Hmmm... this looks like either argument for introducing --full
>>>>>> option to git-checkout (ignore CE_VALID bit, checkout everything,
>>>>>> and clean CE_VALID (?))...
>>>>>>
>>>>>> ...or for going with _separate_ bit for partial checkout, like in
>>>>>> the very first version of this series, which otherwise functions
>>>>>> like CE_VALID, or is just used to mark that CE_VALID was set using
>>>>>> sparse.
>>>
>>> How would a separate bit help? Just like you need to clear CE_VALID
>>> bit to revert the index into a normal (or "non sparse") state somehow,
>>> you would need to have a way to clear that separate bit anyway.
>>>
>>> A separate bit would help only if you want to handle assume-unchanged
>>> and sparse checkout independently. But my impression was that the
>>> recent lstat reduction effort addressed the issue assume-unchanged
>>> were invented to work around in the first place.
>>
>> Well, if we assume that we don't need (don't want) to handle
>> assume-unchanged and sparse checkout independently, then of course the
>> idea of having separate or additional bit for sparse doesn't make sense.
>
> For the shallow/graft issue, we had a similar discussion. Back then, I
> was convinced that shallow commits and grafted commits were something
> fundamentally different, and my recent patch to pack-objects shows that:
> shallow commits do not have the real parents in the current repository,
> and that makes them different from other grafted commits.
>
> Now, if you want to say that assume-unchanged and sparse are two
> fundamentally different things, I would be interested in some equally
> convincing argument as for the shallow/graft issue.
>
> There is a fundamental difference, I grant you that: the working directory
> does not contain the "sparse'd away" files while the same is not true for
> assume-unchanged files.
>
> But does that matter? The corresponding files are still in the index and
> the repository.
>
> IOW under what circumstances would you want to be able to discern between
> assume-unchanged and "sparse'd away" files in the working directory?
>From what I understand it, assume-unchanged is performance optimization.
Sparse checkout is about files which are (assumed to) not be in working
directory, which means that they have to be assume-unchanged for git to
not try to access working area version of files which aren't there.
$GIT_DIR/info/sparse (or how it would be named; the name 'sparse'
doesn't tell us whether patterns are about the files that are checked
out, or are about files which are not present in working directory)
is about specifying which files to checkout with "git checkout --sparse"
(or core.sparse / checkout.sparse = true).
> I could _imagine_ that you'd want a tool that allows you to change the
> focus of the sparse checkout together with the working directory.
> Example: you have a sparse checkout of Documentation/ and now you want to
> have t/, too. Just changing .git/info/sparse will not be enough.
>
> The question is if the tool to change the "sparseness" [*1*] should not
> change .git/info/sparse itself; if it does not, it would be good to be
> able to discern between the "assume-unchanged" and "sparse'd away" files.
>
> Although it might be enough to traverse the index and check the presence
> of the assume-unchanged files in the working directory to determine which
> files are sparse, and which ones are merely assume-unchanged.
There are quite a few possibilities: file can be marked "sparse" in
index (which also implies also marking it "assume-unchanged", if
"assume-unchanged" doesn't work alone as "sparse" index bit) or not,
file can match 'no-checkout' pattern in $GIT_DIR/info/sparse or not,
file can be present in working directory or not:
* match no-checkout
- assume-unchanged
+ present in working directory
+ absent from working directory
- no assume-unchanged
+ present
+ absent
* doesn't match no-checkout
- assume-unchanged
+ present
+ absent
- no assume-unchanged
+ present
+ absent
> Footnote [*1*]: I think we need some nice and clear nomenclature here.
> Any English wizards with a good taste of naming things?
English is not my native language, but what about:
$GIT_DIR/info/
no-checkout
exclude-checkout
workdir-exclude
ignore-change
assume-unchanged
ghosts
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: Steven Noonan @ 2009-08-17 15:44 UTC (permalink / raw)
To: Giuseppe Scrivano
Cc: Pádraig Brady, Bug-coreutils, Linus Torvalds,
Git Mailing List
In-Reply-To: <8763cmemsa.fsf@master.homenet>
On Mon, Aug 17, 2009 at 3:51 AM, Giuseppe Scrivano<gscrivano@gnu.org> wrote:
> Pádraig Brady <P@draigBrady.com> writes:
>
>> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586
>> -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE=1
>
> thanks. I did again all tests on my machine using these same options.
> I repeated each test 6 times and I took the median without consider the
> first result. Except the first run that it is not considered, I didn't
> report a big variance on results of the same test.
>
>
> gcc 4.3.3
>
> gnulib sha1: real 0m2.543s
> gnulib sha1 lookup: real 0m1.906s (-25%)
> linus's sha1: real 0m2.468s (-3%)
> linus's sha1 no asm: real 0m2.289s (-9%)
>
>
> gcc 4.4.1
>
> gnulib sha1: real 0m3.386s
> gnulib sha1 lookup: real 0m3.110s (-8%)
> linus's sha1: real 0m1.701s (-49%)
> linus's sha1 no asm: real 0m1.284s (-62%)
>
>
> I don't see such big differences in asm generated by gcc 4.4.1 and gcc
> 4.3.3 to explain this performance difference, what I noticed immediately
> is that in the gcc-4.4 generated asm there are more "lea" instructions
> (+30%), but I doubt this is the reason of these poor results. Anyway, I
> haven't yet looked much in details.
>
> Cheers,
> Giuseppe
Interesting. I compared Linus' implementation to the public domain one
by Steve Reid[1], which is used in OpenLDAP and a few other projects.
Anyone with some experience testing these kinds of things in a
statistically sound manner want to try it out? In my tests, I got
this:
(average of 5 runs)
Linus' sha1: 283MB/s
Steve Reid's sha1: 305MB/s
- Steven
[1] http://gpl.nas-central.org/SYNOLOGY/x07-series/514_UNTARED/source/openldap-2.3.11/libraries/liblutil/sha1.c
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Junio C Hamano @ 2009-08-17 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0908171101090.4991@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The scenario is this: the repository contains a file that users are
> supposed to change, but not commit to (only the super-intelligent inventor
> of this scenario is allowed to). As this repository is originally a
> subversion one, there is no problem: people just do not switch branches.
>
> But this guy uses git-svn, so he does switch branches, and to avoid
> committing the file by mistake, he marked it assume-unchanged. Only that
> a branch switch overwrites the local changes.
If it is a problem that a branch switch overwrites the local changes in
assume-unchanged file, perhaps that is what this person needs to change?
Let's step back a bit and think.
Local changes in git do not belong to any particular branch. They belong
to the work tree and the index. Hence you (1) can switch from branch A to
branch B iff the branches do not have difference in the path with local
changes, and (2) have to stash save, switch branches and then stash pop if
you have local changes to paths that are different between branches you
are switching between.
How should assume-unchanged play with this philosophy?
I'd say that assume-unchanged is a promise you make git that you won't
change these paths, and in return to the promise git will give you faster
response by not running lstat on them. Having changes in such paths is
your problem and you deserve these chanegs to be lost. At least, that is
the interpretation according to the original assume-unchanged semantics.
If some paths should not be committed, I'd say it should be handled by a
pre commit hook, and not assume-unchanged.
Is checking with "diff --cached" on the paths and either erroring out (or
better yet resetting the problematic paths in the index) an option?
^ permalink raw reply
* Re: Using VC build git (split patch)
From: Erik Faye-Lund @ 2009-08-17 15:25 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysGit, Johannes Schindelin
In-Reply-To: <1976ea660908170814q30c316aek20d44e67bba4a3ab@mail.gmail.com>
On Mon, Aug 17, 2009 at 5:14 PM, Frank Li<lznuaa@gmail.com> wrote:
>> Then use send-email, which IS supported in msysgit.
>
> gmail require ssl. ssl.pm miss when I use send-email in msysgit. I
> have submit bug at msysgit
Have a look at http://code.google.com/p/msysgit/wiki/UsingSendEmail to
find out how to use send-email from Windows.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Continue git clone after interruption
From: Shawn O. Pearce @ 2009-08-17 15:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tomasz Kontusz, git
In-Reply-To: <alpine.DEB.1.00.0908171430010.4991@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 17 Aug 2009, Tomasz Kontusz wrote:
>
> > is anybody working on making it possible to continue git clone after
> > interruption? It would be quite useful for people with bad internet
> > connection (I was downloading a big repo lately, and it was a bit
> > frustrating to start it over every time git stopped at ~90%).
>
> Unfortunately, we did not have enough GSoC slots for the project to allow
> restartable clones.
>
> There were discussions about how to implement this on the list, though.
Unfortunately, those of us who know how the native protocol works
can't come to an agreement on how it might be restartable. If you
really read the archives on this topic, you'll see that Nico and I
disagree about how to do this. IIRC Nico's position is, it isn't
really possible to implement a restart.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Johannes Schindelin @ 2009-08-17 15:19 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0908170741v210e7f4et9f1c68bc9a81ca65@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2127 bytes --]
Hi,
On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:
> On Mon, Aug 17, 2009 at 8:35 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > The problem of course is that the other branch has an ancient version
> > of that file (which should _not_ overwrite the current, modified
> > version!), i.e. "git diff HEAD..other -- file" does not come empty.
> >
> > As 'file' is assume-unchanged, zinnnng, the file gets "updated".
>
> Then it is a bug. Assume-unchanged as in reading is good.
> Assume-unchanged in writing sounds scary. Something like this should
> fix it (not well tested though). It's on top of my series, but you can
> adapt it to 'next' or 'master' easily.
No.
The purpose of 'assume-unchanged' is to tell Git that it has no business
checking that the file is unchanged. It should _assume_ that it is
unchanged. That's what this flag says.
So do you agree that assume-changed is not quite similar enough to sparse
to use the same bit?
> > Another use case: documentation. I do not have that use case yet, but
> > I know about people who do.
>
> Translators usually checkout one or two files (I am Vietnamese
> Translation Coordinator of GNOME, but well... I check them all out. I
> suppose "normal" translators would not want to do like I do.)
Exactly.
echo /Documentation/ > .git/info/sparse
Remember: the documentation contributors are the least programming-savvy
contributors of any project.
> > Specifying what you _want_ to have checked out is much more
> > straight-forward here than the opposite.
>
> I think it depends on type of projects. For documentation projects, you
> may want a few files. For software projects, usually you need everything
> _except_ a few big directories. For WebKit, it's a bunch of test data
> that I don't care about. Firmware in hardware-related projects or media
> files in game projects fall in the same category. I don't have strong
> opinion on this. Either include or exclude is fine to me.
Okay, let me just ask: if you have a sparse checkout, what would you think
I mean when I talk about the "sparse files"?
Ciao,
Dscho
^ permalink raw reply
* Re: Using VC build git (split patch)
From: Frank Li @ 2009-08-17 15:14 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysGit, Johannes Schindelin
In-Reply-To: <40aa078e0908170619r3d325e0csee466446df474302@mail.gmail.com>
> Then use send-email, which IS supported in msysgit.
gmail require ssl. ssl.pm miss when I use send-email in msysgit. I
have submit bug at msysgit
best regards
Frank Li
^ permalink raw reply
* Re: bbchop & Wikipedia's Bayesian search theory page
From: Ealdwulf Wuffinga @ 2009-08-17 14:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908161907580.8306@pacific.mpi-cbg.de>
On Sun, Aug 16, 2009 at 6:13 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> I tried to find some documentation for Bayesian search theory, but it
> seems those ridiculous Wikipedia admins struck once again, in their
> mission to reduce the world's intellect to their own.
It looks like it is still there to me:
http://en.wikipedia.org/wiki/Bayesian_search_theory
It looks like github has included a ')' on the end when html-ifying
the link inthe README, making it into a dead link. I'll fix that.
The wikipedia article is still not amazing,though. Unfortunately most
of the online descriptions
of Bayesian Search Theory, such as:
http://www.sarinz.com/index.cfm/3,112,261/landsearchmethodsreview.pdf
seem to go heavily into the minutia of search-and-rescue, which while
interesting, is not
relevant to git.
However, although I got the idea of bbchop from search theory, it is
not necessary to know much
of search theory in order to understand bbchop. The basic algorithm is
very simple:
At each step, test the commit for which the expected gain of information (about
the location of the bug) is greatest.
That is basically all I got from search theory so far - the
calculation of the probability of the
bug existing in each location is standard bayesian probability theory,
which maybe you already
know. If not, a very readable reference is:
http://www.inference.phy.cam.ac.uk/mackay/itila/book.html (free on-line book).
So all the code does is compute N entropies and pick the best. Most of the
complexity is introduced by:
- calculating the N entropies without calculating N^2 probabilities
- calculations over a DAG.
Ealdwulf
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Nguyen Thai Ngoc Duy @ 2009-08-17 14:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908171524150.4991@intel-tinevez-2-302>
On Mon, Aug 17, 2009 at 8:35 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:
>
>> On Mon, Aug 17, 2009 at 4:08 PM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>> > Turns out that somebody on IRC had a problem that requires to have
>> > sparse'd out files which _do_ have working directory copies.
>> >
>> > So just having the assume-changed bit may not be enough.
>> >
>> > The scenario is this: the repository contains a file that users are
>> > supposed to change, but not commit to (only the super-intelligent
>> > inventor of this scenario is allowed to). As this repository is
>> > originally a subversion one, there is no problem: people just do not
>> > switch branches.
>> >
>> > But this guy uses git-svn, so he does switch branches, and to avoid
>> > committing the file by mistake, he marked it assume-unchanged.
>>
>> Hmm.. never thought of this use before. If he does not want to commit by
>> mistake, should he add to-be-committed changes to index and do "git
>> commit" without "-a" (even better, do "git diff --cached" first)?
>
> You probably agree that this would be a _very_ fragile setup. Very easy
> to make mistakes.
>
> But we try to get away from that, don't we? Git had a reputation to be
> easy fsck up for long enough.
Well.. of course I don't want Git to keep that reputation :-)
>> > Only that a branch switch overwrites the local changes.
>>
>> I don't think branch switch overwrites changes in this case. Whenever
>> Git is to touch worktree files, it ignores assumed-unchanged bit and
>> does lstat() to make sure worktree files are up to date.
>
> Well, it does there, thankyouverymuch.
>
> The problem of course is that the other branch has an ancient version of
> that file (which should _not_ overwrite the current, modified version!),
> i.e. "git diff HEAD..other -- file" does not come empty.
>
> As 'file' is assume-unchanged, zinnnng, the file gets "updated".
Then it is a bug. Assume-unchanged as in reading is good.
Assume-unchanged in writing sounds scary. Something like this should
fix it (not well tested though). It's on top of my series, but you can
adapt it to 'next' or 'master' easily.
diff --git a/unpack-trees.c b/unpack-trees.c
index eb47676..7b9ddf6 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -538,7 +538,9 @@ static int verify_uptodate_1(struct cache_entry *ce,
{
struct stat st;
- if (o->index_only || o->reset || ce_uptodate(ce))
+ if (o->index_only || o->reset ||
+ /* we are going to update worktree, don't trust ce_uptodate if
it is CE_VALID'd */
+ (!(ce->ce_flags & CE_VALID) && ce_uptodate(ce)))
return 0;
if (!lstat(ce->name, &st)) {
>> > I suggested the use of the sparse feature, and mark this file (and
>> > this file alone) as sparse'd-out.
>>
>> Sparse checkout only removes a file if its assume-unchanged bit
>> changes from 0 to 1.
>
> The problem is not removing, but overwriting.
>
> And in this respect, 'assume-unchanged' is a very different beast from
> 'sparse'. I am growing more and more convinced that you cannot just reuse
> the assume-unchanged bit.
And assume-unchanged bit could get lost during index merging, which
may cause unexpected effect if sparse checkout bases off
assume-unchanged. Let me think more of it tonight.
>> If it's already 1, it does not care whether there is a corresponding
>> file in worktree. So something like this should work:
>>
>> git checkout my-branch
>> git update-index --assume-unchanged that-special-file
>> echo that-special-file > .git/info/sparse
>> # edit that-special-file
>> git commit -a
>> # do whatever you want, git pull/checkout/read-tree... won't touch
>> that-special-file because it's assume-unchanged already
>
> ... except if you changed .git/info/sparse and a formerly sparse'd-out
> file is overwritten by "pull". Not good.
Again, I think it's a bug.
>> > Is this an intended usage scenario? Then we cannot reuse the
>> > assume-changed bit [*1*].
>>
>> It'd be great if people tell us all the scenarios they have. My use
>> could be too limited.
>
> The use case I would have is where a collaborator wants to work only on
> one subdirectory and the top-level directory. All other subdirectories
> are of no interest to him.
>
> Another use case: documentation. I do not have that use case yet, but I
> know about people who do.
Translators usually checkout one or two files (I am Vietnamese
Translation Coordinator of GNOME, but well... I check them all out. I
suppose "normal" translators would not want to do like I do.)
> Specifying what you _want_ to have checked out
> is much more straight-forward here than the opposite.
I think it depends on type of projects. For documentation projects,
you may want a few files. For software projects, usually you need
everything _except_ a few big directories. For WebKit, it's a bunch of
test data that I don't care about. Firmware in hardware-related
projects or media files in game projects fall in the same category. I
don't have strong opinion on this. Either include or exclude is fine
to me.
--
Duy
^ permalink raw reply related
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Lars Hjemli @ 2009-08-17 14:40 UTC (permalink / raw)
To: Ali Polatel; +Cc: git
In-Reply-To: <20090817135651.GA4570@harikalardiyari>
On Mon, Aug 17, 2009 at 15:56, Ali Polatel<polatel@gmail.com> wrote:
> $subject.
> git version 1.6.4
>
> Here's what gdb has to say about it:
>
> 2456 alip@harikalardiyari> gdb --args git clone http://git.savannah.gnu.org/cgit/xboard.git
>...
> Getting pack 06483273097cbac210f10a4bd43324ae660053e6
> which contains 74e24bdc2ec3f275da63ca1396a773e7043cb9e9
>
> Program received signal SIGSEGV, Segmentation fault.
This is the http clone interface generated by cgit, and a quick test
gives me an identical segfault, while `git clone
http://git.sv.gnu.org/r/xboard.git` succeeds. I can only guess, but
maybe this has something to do with caching in cgit:
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/info/packs
P pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
P pack-06483273097cbac210f10a4bd43324ae660053e6.pack
P pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
>pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.idx
>pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.idx
$ git verify-pack -v pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
[snip]
non delta: 115 objects
chain length = 1: 64 objects
chain length = 2: 57 objects
chain length = 3: 16 objects
chain length = 4: 10 objects
chain length = 5: 7 objects
chain length = 6: 1 object
pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack: ok
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-06483273097cbac210f10a4bd43324ae660053e6.pack
>pack-06483273097cbac210f10a4bd43324ae660053e6.pack
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-06483273097cbac210f10a4bd43324ae660053e6.idx
>pack-06483273097cbac210f10a4bd43324ae660053e6.idx
$ git verify-pack -v pack-06483273097cbac210f10a4bd43324ae660053e6.pack
[snip]
74e24bdc2ec3f275da63ca1396a773e7043cb9e9 blob 921 286 12694
[snip]
non delta: 233 objects
chain length = 1: 86 objects
chain length = 2: 74 objects
chain length = 3: 47 objects
chain length = 4: 8 objects
chain length = 5: 5 objects
chain length = 6: 1 object
pack-06483273097cbac210f10a4bd43324ae660053e6.pack: ok
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack
>pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack
$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.idx
>pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.idx
$ git verify-pack -v pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack
[snip]
non delta: 1139 objects
chain length = 1: 454 objects
chain length = 2: 349 objects
chain length = 3: 301 objects
chain length = 4: 235 objects
chain length = 5: 179 objects
chain length = 6: 96 objects
chain length = 7: 52 objects
chain length = 8: 37 objects
chain length = 9: 21 objects
chain length = 10: 6 objects
chain length = 11: 5 objects
chain length = 12: 1 object
chain length = 13: 2 objects
chain length = 14: 1 object
chain length = 15: 2 objects
chain length = 16: 1 object
chain length = 17: 1 object
chain length = 18: 2 objects
chain length = 19: 1 object
chain length = 20: 1 object
chain length = 21: 1 object
chain length = 22: 1 object
chain length = 23: 2 objects
chain length = 24: 2 objects
chain length = 25: 1 object
chain length = 26: 1 object
chain length = 27: 1 object
chain length = 28: 1 object
chain length = 29: 1 object
chain length = 30: 1 object
chain length = 31: 1 object
chain length = 32: 1 object
chain length = 33: 2 objects
chain length = 34: 3 objects
chain length = 35: 2 objects
chain length = 36: 1 object
chain length = 37: 1 object
chain length = 38: 1 object
chain length = 39: 2 objects
chain length = 40: 3 objects
chain length = 41: 1 object
chain length = 42: 2 objects
chain length = 43: 1 object
chain length = 44: 1 object
chain length = 45: 2 objects
chain length = 46: 1 object
pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack: ok
Hmm, the packs looks ok so maybe the problem is related to our usage
of libcurl after all...
--
larsh
^ permalink raw reply
* Re: sparse support in pu
From: Peter Harris @ 2009-08-17 14:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyen Thai Ngoc Duy, Johannes Sixt, skillzero, git
In-Reply-To: <alpine.DEB.1.00.0908171522510.4991@intel-tinevez-2-302>
On Mon, Aug 17, 2009 at 9:23 AM, Johannes Schindelin wrote:
> On Mon, 17 Aug 2009, Peter Harris wrote:
>> On Mon, Aug 17, 2009 at 8:29 AM, Johannes Schindelin wrote:
>> > If I want to have a sparse checkout, I know which files I _want_.
>>
>> That's funny. I have a git tree that would benefit from sparse checkout.
>> I know which path I _don't_ want. Specifying all the paths I want would
>> be a rather longer (and more error-prone) list. I suspect it would be
>> best to support both.
>
> Yes, I agree, but the common case is for people to know what they are
> working on, right?
I would presume so, but anecdotal "evidence" points the other way. I
don't have a statistically significant number of samples. Maybe it
should have been asked in the Git User's Survey? ;-)
>> Does sparse use the same parser as .gitignore? (I guess not, if it
>> handles trailing slashes differently?) If so, it would be trivial to
>> turn "exclude path" into "exclude all but path" (or vice-versa) with:
>>
>> *
>> !path
>
> That was the idea behind my suggestion to allow .gitignore syntax. And
> indeed, that is what happened.
Excellent. In that case, I don't care which way around the default is.
Thanks,
Peter Harris
^ permalink raw reply
* Re: "make quick-install-man" broke recently
From: Randal L. Schwartz @ 2009-08-17 14:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jacob Helwig, Linus Torvalds, Kjetil Barvik, git@vger.kernel.org
In-Reply-To: <7vhbw72ap3.fsf@alter.siamese.dyndns.org>
>>>>> "Junio" == Junio C Hamano <gitster@pobox.com> writes:
Junio> Merlyn noticed that Documentation/install-doc-quick.sh no longer correctly
Junio> removes old installed documents when the target directory has a leading
Junio> path that is a symlink. It turns out that "checkout-index --prefix" was
Junio> broken by recent b6986d8 (git-checkout: be careful about untracked
Junio> symlinks, 2009-07-29).
It's good to know I wasn't hallucinating, in any case. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Johannes Schindelin @ 2009-08-17 14:22 UTC (permalink / raw)
To: Ali Polatel, Tay Ray Chuan; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908171616340.4991@intel-tinevez-2-302>
Hi,
On Mon, 17 Aug 2009, Johannes Schindelin wrote:
> On Mon, 17 Aug 2009, Ali Polatel wrote:
>
> > Here's what gdb has to say about it:
> >
> > [...]
>
> Here's what valgrind has to say about it (with a current 'next' +
> patches):
>
> ==25434== Invalid read of size 8
> ==25434== at 0x407433: process_object_response (http-walker.c:91)
> ==25434== by 0x405713: finish_active_slot (http.c:657)
> ==25434== by 0x40448F: process_curl_messages (http.c:119)
> ==25434== by 0x40546A: step_active_slots (http.c:571)
> ==25434== by 0x4080E8: fetch_object (http-walker.c:476)
> ==25434== by 0x408316: fetch (http-walker.c:526)
> ==25434== by 0x42876C: loop (walker.c:176)
> ==25434== by 0x428C65: walker_fetch (walker.c:287)
> ==25434== by 0x40401F: main (remote-curl.c:111)
Oops, forgot the more important part:
==25434== Address 0x87a7bd0 is 0 bytes inside a block of size 64 free'd
==25434== at 0x4C265AF: free (vg_replace_malloc.c:323)
==25434== by 0x4075F5: release_object_request (http-walker.c:128)
==25434== by 0x408022: abort_object_request (http-walker.c:452)
==25434== by 0x4080D7: fetch_object (http-walker.c:470)
==25434== by 0x408316: fetch (http-walker.c:526)
==25434== by 0x42876C: loop (walker.c:176)
==25434== by 0x428C65: walker_fetch (walker.c:287)
==25434== by 0x40401F: main (remote-curl.c:111)
Seems that an object request is aborted, but the slot, and therefore the
callback, is called nevertheless. Tay, does that ring a bell?
Ciao,
Dscho
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: Nicolas Pitre @ 2009-08-17 14:20 UTC (permalink / raw)
To: George Spelvin; +Cc: bdonlan, johnflux, P, art.08.09, git, Linus Torvalds
In-Reply-To: <20090817072315.4314.qmail@science.horizon.com>
On Mon, 17 Aug 2009, George Spelvin wrote:
> If it helps anyone resolve license issues, here's a from-FIPS-180-2
> implementation that's placed in the public domain. That should be
> compatible with any license.
>
> It uses Linus's and Artur's performance ideas, and some of Linus' macro
> ideas (in the rotate implementation), but tries to be textually different.
> Is there anything recognizable that anyone cares to clam copyright to?
>
> It's not quite 100% finished, as I haven't benchmarked it against Linus's
> code yet, but it's functionally correct.
>
> It's also clean with -W -Wall -Wextra.
>
> TODO: Check if an initial copy to w[] is faster on i386 (less register
> pressure).
>
> /*
> * Secure Hash Algorith SHA-1, as published in FIPS PUB 180-2.
> *
> * This implementation is in the public domain. Copyright abandoned.
> * You may do anything you like with it, including evil things.
> *
> * This is a rewrite from scratch, based on Linus Torvalds' "block-sha1"
> * from the git mailing list (August, 2009). Additional optimization
> * ideas cribbed from
> * - Artur Skawina (x86, particularly P4, and much benchmarking)
> * - Nicilas Pitre (ARM)
Please be careful to spell my name correctly.
Nicolas
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Johannes Schindelin @ 2009-08-17 14:17 UTC (permalink / raw)
To: Ali Polatel; +Cc: git
In-Reply-To: <20090817135651.GA4570@harikalardiyari>
Hi,
On Mon, 17 Aug 2009, Ali Polatel wrote:
> Here's what gdb has to say about it:
>
> [...]
Here's what valgrind has to say about it (with a current 'next' +
patches):
==25434== Invalid read of size 8
==25434== at 0x407433: process_object_response (http-walker.c:91)
==25434== by 0x405713: finish_active_slot (http.c:657)
==25434== by 0x40448F: process_curl_messages (http.c:119)
==25434== by 0x40546A: step_active_slots (http.c:571)
==25434== by 0x4080E8: fetch_object (http-walker.c:476)
==25434== by 0x408316: fetch (http-walker.c:526)
==25434== by 0x42876C: loop (walker.c:176)
==25434== by 0x428C65: walker_fetch (walker.c:287)
==25434== by 0x40401F: main (remote-curl.c:111)
Ciao,
Dscho
^ permalink raw reply
* git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Ali Polatel @ 2009-08-17 13:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 6516 bytes --]
$subject.
git version 1.6.4
Here's what gdb has to say about it:
2456 alip@harikalardiyari> gdb --args git clone http://git.savannah.gnu.org/cgit/xboard.git
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
(gdb) run
Starting program: /usr/bin/git clone http://git.savannah.gnu.org/cgit/xboard.git
[Thread debugging using libthread_db enabled]
Initialized empty Git repository in /usr/src/alip/xboard/.git/
[New Thread 0x7f382f0566f0 (LWP 28121)]
got 6db08230fafeb8a5fd163689e0225608bac64169
walk 6db08230fafeb8a5fd163689e0225608bac64169
Getting alternates list for http://git.savannah.gnu.org/cgit/xboard.git
got 94a064d8ab2c5e91d542015dd7307924b20ce729
got a72effb29a1f88097fa34240d35380128c3c84c8
got 6cab23ba23301b578d4995f3c889e574ea4b9e99
Getting pack list for http://git.savannah.gnu.org/cgit/xboard.git
Getting index for pack 720d634dfc5e7511332c1e6851f7c5c5f88e7af2
Getting index for pack 06483273097cbac210f10a4bd43324ae660053e6
Getting index for pack a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6
Getting pack 720d634dfc5e7511332c1e6851f7c5c5f88e7af2
which contains a91f883e599185408c2e868458fc870b45f90647
walk a91f883e599185408c2e868458fc870b45f90647
walk 94a064d8ab2c5e91d542015dd7307924b20ce729
walk 6cab23ba23301b578d4995f3c889e574ea4b9e99
got ceb25797d2bdef03233071092e73d7cdf750a63d
got 00f19ab354710c1f41deba65b92af335317b25e5
walk 00f19ab354710c1f41deba65b92af335317b25e5
got 5195908348d5a926726de5d5447a27febd58b0c5
got c7646fb352bb0f7a286e991d893604190d6144bb
got b24e950f7c4105d99cb16959934231ee041e2b4e
Getting pack a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6
which contains 94a9ed024d3859793618152ea559a168bbcbb5e2
got b72e3e511a5aecf63c36ec720d819babc4a32e80
got 96872f2a88d025fb298254d7215b0a2a46ab2517
got 0a785501c2a0af15b29498dc5304d4f78e464724
got 41c83fb406c79f7482de0a63b3a41d7cdc5d9930
got 8f5adeee096e8325a77f4d0f1198c6de3e5c8c4d
got eb8df7d39eaa78cbba8ea6d43e48a9d5565f85c4
got af0c6fb67a21096bde685ebbb442089e158eaab7
got 81d056612386f3bfbb2d954b1776b385b77b0354
got 2ec8546ca81919b50458f2dfee0fb04deb909732
got fd3b1e187f4711df4b2b9be7a538e5e7a6a9d974
got 15bb2bd5db019f4b5873ff47a81876bf744fe3b7
got d0f226bee1b67eecf307cc625925a0aa6b7543ec
got 266e77e80239db82c6c9c74190b172bb4eb9aa2d
got a546658f7c58b1f72e13d038efc77347060ddcb6
got 87f71b2afc316dc18ed39ec5e0eba041b9bc850e
got c89673fe13e92003dd53fc590b682f4bae229a0f
got 71d706e2cd500e15b0b3fcccaba5530a85173759
got a0978a0f361032a670dc644752dae210a2b3d1e8
got 17463be1dd790b3c8e64eaae95135add449e82db
got 8b401ae12b0e72fe9b03ea1b08b2e4cb89378a8d
got 6cdb7dfebf13e58ce8bbca0a2890057694eee073
got f997ac9797b7427a2c3e3abf8dd95bc2df2bf028
got 7d80cb4c3eb366e28f542b095f958289b4a719e3
got 40fb9ce5458e0df6f33160d7392a8b56aa0e1501
got f945dbf2bcef821a53120501b0a06fc0388a2d5c
got c7b87e2a937e0e83a6f6347649e38c1e4636c14a
got b5b9c2fdb4f3964777c3a3f2f92d2784430feddd
got 0d4b26f7ca8c3108d839e9e339adecb8d1395aad
got b2fcec6a8916695ecb5f1007db2e7fc504d23d05
got 82957eb41b19cd497b761c42cebb4580bddd6baf
got 394a9fdac5b251114074c8bea117c5676fd7caa5
got 9c345f61dd8eaf6c5fb45cc90bb133227609608a
got f02507f1df2b2fc9e999d89b2003ef80b92fae8b
got 5806d53acedf3633d17151c1dd3d0f7316dc3264
got 460073895fc709ae6844800bbe61300bf51a0154
got d4c3dbec93edfd27c52775178ba11242ded59193
got e777067113c5726d1706f266de057aa7361dbec5
got 46e2b200ccb840dfab62258434570c840ebebfa1
got f020f22a9ab9e88c6585d8b204aa8ce016a291e5
got 02c9ec3643c6eb94212be431c72a11f03b4e5b1a
got 0657847b19f925d8af5f450c78dda46f8ae5f7d0
got 05af22bd8201f75fb9718382a3307eda68d5e976
got 427cd7d5dfc211ccd962a18bc9666c72a7966b79
got 77d5bf31108026eb97c6b8e288c9d6d092b767dd
got 22737c1f642d614a14045c72a648bfb0fbfbf9da
got b95f2d1475ce464e507d4dbaf2e3af8f6b6f9a48
got f718239d651c2476ff8b7abff7940d2054f44e4f
got ba30dcb13a69fd3b82a10da5456e47b448d4bcc9
got 83d0f555a7dad1d410761ec89273d795f038860c
got 562609284c1f98090bd14dfddbbe2a4991d1e5a8
got d9a98ef891407dd11863ff5e2553ff79aa24d32e
got 0ae04cca10cea96e05c7d4c261aa5d3b208a0b47
got db9e377a69a3d6bd4a8256d00dca3bee680a6a2a
got 1e1e01c9481a519faffbaf6c645dfa8017cabdb5
got 6cd5f80a6aa0390d2412db7d49427ce845d7c946
got b5381c9bfd883c7a84167b022a64c5ca0385930d
got cd0415a4adb0af252cfdf588323a5814a249e90c
got 2a574b7641b9c0f6414b9943695391b6b8252a54
got 5d662edd417ae9f858cb374e03f09a7639b2c03d
got 2bae494f2cf9486b771c706a1eec6217e46ce778
got 8f84481839d7eeb3e0b0da0088b3093742b546cd
got a6d954d86827b3d3777c186d836f4b533602e567
walk 83d0f555a7dad1d410761ec89273d795f038860c
walk 2bae494f2cf9486b771c706a1eec6217e46ce778
Getting pack 06483273097cbac210f10a4bd43324ae660053e6
which contains 74e24bdc2ec3f275da63ca1396a773e7043cb9e9
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f382f0566f0 (LWP 28121)]
0x00000000004ada21 in process_object_response (callback_data=<value optimized out>) at http-walker.c:93
93 http-walker.c: No such file or directory.
in http-walker.c
(gdb) thread apply all bt
Thread 1 (Thread 0x7f382f0566f0 (LWP 28121)):
#0 0x00000000004ada21 in process_object_response (callback_data=<value optimized out>) at http-walker.c:93
#1 0x00000000004ab3e3 in process_curl_messages () at http.c:657
#2 0x00000000004ab475 in step_active_slots () at http.c:571
#3 0x00000000004add95 in fetch (walker=0x13d3b50, sha1=<value optimized out>) at http-walker.c:476
#4 0x00000000004a74e3 in walker_fetch (walker=0x13d3b50, targets=4, target=<value optimized out>, write_ref=0x0,
write_ref_log_details=<value optimized out>) at walker.c:176
#5 0x00000000004a0e46 in fetch_objs_via_curl (transport=0x20, nr_objs=4, to_fetch=0x13d5780) at transport.c:375
#6 0x000000000049feab in transport_fetch_refs (transport=0x13d4300, refs=<value optimized out>) at transport.c:1064
#7 0x0000000000416a05 in cmd_clone (argc=<value optimized out>, argv=<value optimized out>, prefix=<value optimized out>)
at builtin-clone.c:513
#8 0x0000000000404391 in handle_internal_command (argc=2, argv=0x7fff89c74b10) at git.c:246
#9 0x000000000040453d in main (argc=2, argv=0x7fff89c74b10) at git.c:438
(gdb)
--
Regards,
Ali Polatel
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Using VC build git (split patch)
From: Johannes Schindelin @ 2009-08-17 13:43 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Frank Li, git, msysGit
In-Reply-To: <40aa078e0908170619r3d325e0csee466446df474302@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, Erik Faye-Lund wrote:
> On Mon, Aug 17, 2009 at 3:13 PM, Frank Li<lznuaa@gmail.com> wrote:
> > I try to use git format-patch -M --stdout origin/master | git
> > imap-send to send patch directly according to guide.
> > But imap-send has not ported to msysgit.
>
> Then use send-email, which IS supported in msysgit.
Yes, I would appreciate inline patches. Otherwise it is pretty awkward
and time-consuming to quote your patch when I comment on it.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Johannes Schindelin @ 2009-08-17 13:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0908170549w26b008bdhe67f113a58ecb4eb@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3893 bytes --]
Hi,
On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:
> On Mon, Aug 17, 2009 at 4:08 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > Turns out that somebody on IRC had a problem that requires to have
> > sparse'd out files which _do_ have working directory copies.
> >
> > So just having the assume-changed bit may not be enough.
> >
> > The scenario is this: the repository contains a file that users are
> > supposed to change, but not commit to (only the super-intelligent
> > inventor of this scenario is allowed to). As this repository is
> > originally a subversion one, there is no problem: people just do not
> > switch branches.
> >
> > But this guy uses git-svn, so he does switch branches, and to avoid
> > committing the file by mistake, he marked it assume-unchanged.
>
> Hmm.. never thought of this use before. If he does not want to commit by
> mistake, should he add to-be-committed changes to index and do "git
> commit" without "-a" (even better, do "git diff --cached" first)?
You probably agree that this would be a _very_ fragile setup. Very easy
to make mistakes.
But we try to get away from that, don't we? Git had a reputation to be
easy fsck up for long enough.
> > Only that a branch switch overwrites the local changes.
>
> I don't think branch switch overwrites changes in this case. Whenever
> Git is to touch worktree files, it ignores assumed-unchanged bit and
> does lstat() to make sure worktree files are up to date.
Well, it does there, thankyouverymuch.
The problem of course is that the other branch has an ancient version of
that file (which should _not_ overwrite the current, modified version!),
i.e. "git diff HEAD..other -- file" does not come empty.
As 'file' is assume-unchanged, zinnnng, the file gets "updated".
> > I suggested the use of the sparse feature, and mark this file (and
> > this file alone) as sparse'd-out.
>
> Sparse checkout only removes a file if its assume-unchanged bit
> changes from 0 to 1.
The problem is not removing, but overwriting.
And in this respect, 'assume-unchanged' is a very different beast from
'sparse'. I am growing more and more convinced that you cannot just reuse
the assume-unchanged bit.
> If it's already 1, it does not care whether there is a corresponding
> file in worktree. So something like this should work:
>
> git checkout my-branch
> git update-index --assume-unchanged that-special-file
> echo that-special-file > .git/info/sparse
> # edit that-special-file
> git commit -a
> # do whatever you want, git pull/checkout/read-tree... won't touch
> that-special-file because it's assume-unchanged already
... except if you changed .git/info/sparse and a formerly sparse'd-out
file is overwritten by "pull". Not good.
> Anyway I would not recommend this. the versions of that-special-file in
> worktree and and in index will diverse. When you unmark assume-unchanged
> (be it sparse checkout or plain assume-unchanged), you may have already
> forgot what changes you made to this file and "git diff" would not help.
My point is that we should take the current implementation as Dictated By
The Dear Lord, but change it if the limitation is too severe.
And I do contend that 'assume-unchanged' is dissimilar enough from
'sparse' to merit a change.
> > Is this an intended usage scenario? Then we cannot reuse the
> > assume-changed bit [*1*].
>
> It'd be great if people tell us all the scenarios they have. My use
> could be too limited.
The use case I would have is where a collaborator wants to work only on
one subdirectory and the top-level directory. All other subdirectories
are of no interest to him.
Another use case: documentation. I do not have that use case yet, but I
know about people who do. Specifying what you _want_ to have checked out
is much more straight-forward here than the opposite.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse support in pu
From: Johannes Schindelin @ 2009-08-17 13:23 UTC (permalink / raw)
To: Peter Harris; +Cc: Nguyen Thai Ngoc Duy, Johannes Sixt, skillzero, git
In-Reply-To: <eaa105840908170552m3eaf0f92j523ddad98dd67a3@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, Peter Harris wrote:
> On Mon, Aug 17, 2009 at 8:29 AM, Johannes Schindelin wrote:
> > If I want to have a sparse checkout, I know which files I _want_.
>
> That's funny. I have a git tree that would benefit from sparse checkout.
> I know which path I _don't_ want. Specifying all the paths I want would
> be a rather longer (and more error-prone) list. I suspect it would be
> best to support both.
Yes, I agree, but the common case is for people to know what they are
working on, right?
> Does sparse use the same parser as .gitignore? (I guess not, if it
> handles trailing slashes differently?) If so, it would be trivial to
> turn "exclude path" into "exclude all but path" (or vice-versa) with:
>
> *
> !path
That was the idea behind my suggestion to allow .gitignore syntax. And
indeed, that is what happened.
Ciao,
Dscho
^ permalink raw reply
* Re: Using VC build git (split patch)
From: Erik Faye-Lund @ 2009-08-17 13:19 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysGit, Johannes Schindelin
In-Reply-To: <1976ea660908170613ibb9a0fdr7ba630671a6b735f@mail.gmail.com>
On Mon, Aug 17, 2009 at 3:13 PM, Frank Li<lznuaa@gmail.com> wrote:
> I try to use git format-patch -M --stdout origin/master | git
> imap-send to send patch directly according to guide.
> But imap-send has not ported to msysgit.
Then use send-email, which IS supported in msysgit.
While we're on that subject; I guess we should add some documentation
(a wiki page or something?) on how to use it, as some (simple) setup
on the client side is required for msmtp.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ 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