This is to force running the test suite with file-watcher with
$ mkdir /tmp/watcher
$ chmod 700 /tmp/watcher
$ git-file-watcher /tmp/watcher/
then open another terminal and run
$ export GIT_TEST_WATCHED=2 GIT_TEST_WATCHER=2
$ export GIT_TEST_WATCHER_PATH=/tmp/watcher
$ make test
TIM
test-file-watcher is a simple chat program to talk to file
watcher. Typically you would write something like this
cat >expect <'
>hello
ok
EOF
test-file-watcher . actual
and test-file-watcher will execute the commands and get responses. If
all go well, "actual" should be the same as "ex
This is more of an issue in development than in production. When a
file-watcher related test fails, the daemon may be left hanging. When
you rerun the same test, old $TRASH_DIRECTORY is wiped out and no one
can communicate with the old daemon any more. Make the old daemon quit
after 5 minutes in su
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls-files.txt | 1 +
builtin/ls-files.c | 14 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index c0856a6..bdb17a5 100644
--- a/Do
When file watcher is active via GIT_TEST_WATCHER_PATH, `ls-files -v`
output may be different (e.g. "H" becomes "W"). Disable file watcher
in those cases.
We could make ls-files turn 'W' back to 'H' for these cases, but not
sure it's worth the effort. The intention of running with
GIT_TEST_WATCHER_
The next patch wants to ignore CE_VALID under some condition but not
really clears it. Centralizing its access makes such a change easier.
Not all "ce_flags & CE_VALID" is converted though. The tests that
really mean _bit_ CE_VALID remains so. The tests that mean "ignore
worktree" are converted.
Similar to t7513, system inotify is taken out to give us better
controlled environment.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
file-watcher-lib.c | 21 ++--
t/t7514-file-watcher-lib.sh (new +x) | 190 +++
test-file-watcher.c |
"struct dir" manages inotify file descriptor and forms a tree. "struct
file" manages a file. When a file is watched, all dirs up to the file
is watched. Any changes on a directory impacts all subdirs and files.
The way data structure is made might be inotify-specific. I haven't
thought of how othe
Signed-off-by: Nguyễn Thái Ngọc Duy
---
file-watcher.c | 142 -
1 file changed, 141 insertions(+), 1 deletion(-)
diff --git a/file-watcher.c b/file-watcher.c
index d0762e6..5867942 100644
--- a/file-watcher.c
+++ b/file-watcher.c
@@ -260,6
If GIT_TEST_WATCHED is set to a non-zero value, Git still uses file
watcher if configured. But it does lstat() anyway and notifies the
user if a file is changed but the file watcher said otherwise.
Note that there is a race condition. Changed paths are retrieved at
time X, then refresh and validat
We want to watch files that are never changed because lstat() on those
files is a wasted effort. So we sort unwatched files by date and start
adding them to the file watcher until it barfs (e.g. hits inotify
limit).
Note that we still do lstat() on these new watched files because they
could have c
watch_entries() is a lot of computation and could trigger a lot more
lookups in file-watcher. Normally after the first set of watches are
in place, we do not need to update often. Moreover if the number of
entries is small, the overhead of file watcher may actually slow git
down.
This patch only a
When some paths are watched, they are added to the "watched" list in
file watcher. When a path in this list is updated, the path is moved
to "changed" list and no longer watched.
With this patch we have a complete path exchanging picture between git
and file-watcher:
1) Hand shake
2) Get the lis
This is to avoid spreading #ifdef HAVE_INOTIFY around and keep most
code compiled even if it's never active.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
config.mak.uname | 1 +
git-compat-util.h | 43 +++
2 files changed, 44 insertions(+)
diff --git a/confi
read_cache() connects to the file watcher, specified by
filewatcher.path config, and performs basic hand shaking. CE_WATCHED
is cleared if git and file watcher have different views on the index
state.
All send/receive calls must be complete within a limited time to avoid
a buggy file-watcher hang
This will be used as signature to know if the index has changed.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 1 +
read-cache.c | 7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 7a836b1..f14d535 100644
--- a/cache.h
+++ b/cache.h
@@ -27
This bit is basically "dynamic CE_VALID". It marks entries that are
being watched by the incoming file-watcher. When an index is loaded,
file watcher is contacted and the list of updated paths is retrieved.
These paths will have CE_WATCHED cleared and lstat() will be called on
them. Those that hav
If CE_WATCHED is set, CE_VALID is controlled by CE_WATCHED and will be
cleared bfore writing to disk. Users of --assume-unchanged therefore
need to clear CE_WATCHED to avoid this side effect.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/update-index.c | 12
read-cache.c
In daemon mode, stdout and stderr are saved in $WATCHER/log.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-file-watcher.txt | 2 ++
cache.h| 1 +
daemon.c | 30 --
file-watcher.c |
Signed-off-by: Nguyễn Thái Ngọc Duy
---
file-watcher.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/file-watcher.c b/file-watcher.c
index 91f4cfe..9c639ef 100644
--- a/file-watcher.c
+++ b/file-watcher.c
@@ -56,6 +56,26 @@ static void accept_connect
git-file-watcher is a daemon (*) that watches file changes and tells
git about them. The intent is to avoid lstat() calls at index refresh
time, which could be a lot on big working directory.
The actual monitoring needs support from OS (inotify, FSEvents,
FindFirstChangeNotification or kqueue) and
Signed-off-by: Nguyễn Thái Ngọc Duy
---
credential-cache--daemon.c | 2 +-
unix-socket.c | 5 +++--
unix-socket.h | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
index 390f194..1b995a9 100644
Access to the unix socket $WATCHER/socket is covered by $WATCHER's
permission. While the file watcher does not carry much information,
repo file listing is sometimes not something you want other users to
see. Make sure $WATCHER has 0700 permission to stop unwanted access.
Signed-off-by: Nguyễn Thá
I'm happy with this now. The only things left are applying ewah on the
watch index extension and maybe improve lookup performance a bit. The
former needs jk/pack-bitmap graduated. The latter is not urgent. Oh
and maybe address "BUGS" section (more like known limitations) in
git-file-watcher.txt.
F
This version is also gentler than its friend packet_read_line()
because it's designed for side channel I/O that should not abort the
program even if the channel is broken.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h| 1 +
pkt-line.c | 35 +++
pkt-line.h |
"buffer" is a local variable in some other functions. Rename the
global one to make it less confusing.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pkt-line.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/pkt-line.c b/pkt-line.c
index bc63b3b..eac45ad 100644
--- a/pk
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h| 1 +
pkt-line.c | 15 +++
pkt-line.h | 1 +
wrapper.c | 26 ++
4 files changed, 43 insertions(+)
diff --git a/cache.h b/cache.h
index dc040fb..718e32b 100644
--- a/cache.h
+++ b/cache.h
@@ -1231,6 +1231,7
On Sun, Feb 2, 2014 at 11:35 PM, Martin Erik Werner
wrote:
> diff --git a/setup.c b/setup.c
> index a2e60ab..230505c 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -86,11 +86,23 @@ char *prefix_path_gently(const char *prefix, int len,
> const char *orig = path;
> char *sanitized;
>
On Sun, Feb 02, 2014 at 03:04:59PM -0800, David Aguilar wrote:
> I think you're looking for "git merge-base".
>
> If you do `git merge-base HEAD origin/master`
> and its result is equal to `git rev-parse HEAD`
> then you know that master is an ancestor of origin/master
> and can be trivially fast-
John Keeping writes:
> I actually wonder if you could do this with notes and git-grep; for
> example:
>
> git grep -l keeping.me.uk refs/notes/amlog |
> sed -e 's/.*://' -e 's!/!!g'
>
> That should be relatively efficient since you're only looking at the
> current notes tree.
I added note
On Sun, Feb 02, 2014 at 09:21:56PM +1030, Adrian Johnson wrote:
> - Allow extra space in "is new" and "is separate"
> [...]
> - "!^(.*[ \t])?(is new|renames|is separate)([ \t].*)?$\n"
> + "!^(.*[ \t])?(is[ \t]+new|renames|is[ \t]+separate)([ \t].*)?$\n"
I do not know anything about Ada
On Sun, Feb 02, 2014 at 11:37:39AM +0100, David Kastrup wrote:
> So I mused: refs/heads contains branches, refs/tags contains tags. The
> respective information would likely easily enough be stored in refs/bzr
> and refs/bugs and in that manner would not pollute the "ordinary" tag
> and branch sp
On Sun, Feb 02, 2014 at 10:15:07AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > I usually start splitting a commit with "reset @^" then "add -p" back.
> > The problem is "reset @^" does not keep track of new files added in
> > HEAD, so I often end up forgetting to add new files back (
On Sun, Feb 02, 2014 at 04:15:09PM -0600, Stephen Leake wrote:
> I'm working on the DVC Emacs front-end for git
> (http://www.emacswiki.org/emacs/DistributedVersionControl), adding
> features similar to the ones I added for monotone
> (http://www.monotone.ca). I'm used to monotone and new to git, s
[+cc Joshua Jensen, who wrote 50906e0]
On Sun, Feb 02, 2014 at 07:13:04AM -0600, Reuben Hawkins wrote:
> fast-import should not use strncmp_icase.
I am not sure of that. My gut feeling is that core.ignorecase is
completely about the _filesystem_, and that git should generally be
case-sensitive i
On Sun, Feb 02, 2014 at 04:15:09PM -0600, Stephen Leake wrote:
> I always do 'fetch' and 'merge' separately, never 'pull'. So after a
> 'fetch', the DVC Emacs front end must determine what needs to happen
> next. I think there are three cases:
Doing the two steps separately is common in git, too.
I'm working on the DVC Emacs front-end for git
(http://www.emacswiki.org/emacs/DistributedVersionControl), adding
features similar to the ones I added for monotone
(http://www.monotone.ca). I'm used to monotone and new to git, so this
may seem like an odd workflow.
I always do 'fetch' and 'merge'
Hi Erez,
Erez Zilber wrote:
Thanks. I will try to use the rpm from Todd's build. BTW - if I want
to create such a build on Fedora that will create el6 packages (e.g.
git-1.8.5.3-2.el6.x86_64.rpm), what's the procedure?
Something like this (this is from memory):
# Install fedpkg
$ yum install
Thanks. I will try to use the rpm from Todd's build. BTW - if I want
to create such a build on Fedora that will create el6 packages (e.g.
git-1.8.5.3-2.el6.x86_64.rpm), what's the procedure?
Thanks,
Erez
On Thu, Jan 30, 2014 at 8:51 PM, Todd Zullinger wrote:
> Hello,
>
>
> Jonathan Nieder wrote:
On 2014-02-02 14.13, Reuben Hawkins wrote:
> fast-import should not use strncmp_icase. When it does, files with
> similar names, but different case can be lost in the import. For
> example...
>
> M 100644 :1 FileName.txt
> D Filename.txt
That seems to be wrong, shouldn't it be
D Filename.txt
M 1
Duy Nguyen writes:
> I usually start splitting a commit with "reset @^" then "add -p" back.
> The problem is "reset @^" does not keep track of new files added in
> HEAD, so I often end up forgetting to add new files back (with "add
> -p"). I'm thinking of making "reset" to do "add -N" automatical
Torsten Bögershausen writes:
> On 2014-02-01 10.14, Reuben Hawkins wrote:
>> Most case-insensitive filesystems are case-preserving. In these
>> filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
>> then rename the file to FileName.txt. That file will be accessible
>> by both fi
When symlinks in the working tree are manipulated using the absolute
path, git dereferences them, and tries to manipulate the link target
instead.
This is a regression introduced by 18e051a:
setup: translate symlinks in filename when using absolute paths
(which did not take symlinks in the work
The 'prefix_path_gently' function currently applies real_path to
everything if given an absolute path, dereferencing symlinks both
outside and inside the work tree. In order to manipulate symlinks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
Mo
One edge-case that isn't currently checked in the tests is the beginning
of the path matching the work tree, despite the target not actually
being the work tree, for example:
path = /dir/repoa
work_tree = /dir/repo
should fail since the path is outside the repo. However, if /dir/repoa
is in f
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which first checks if the
work tree is already the pref
The current behaviour of prefix_path is to return an empty string if
prefixing and absolute path that only contains exactly the work tree.
This behaviour is a potential regression point.
Signed-off-by: Martin Erik Werner
---
t/t0060-path-utils.sh | 6 ++
1 file changed, 6 insertions(+)
diff
Again!
(It seems you missed to CC me in your first reply David, please do :)
New reroll, fixing the /dir/repoa and /dir/repolink -> /dir/repo issues noted by
Duy, and adding corresponding tests. If work tree matches beginning of path but
needs further checking, it starts from the end of the work
(It seems as if the mail went only to Junio, sorry)
On 2014-02-02 16.09, Torsten Bögershausen wrote:
> On 2014-01-29 19.17, Junio C Hamano wrote:
>> But after a closer inspection, I no longer think that hunk is an
>> improvement. These new packfiles were created by pack-objects,
>> which finishes
fast-import should not use strncmp_icase. When it does, files with
similar names, but different case can be lost in the import. For
example...
M 100644 :1 FileName.txt
D Filename.txt
...would end up deleting FileName from the index during the fast-
import when strncmp_icase is used and core.ign
>
>> Another comment:
>> The "raw" comparison with '/' is probably working well on all
>> POSIX/Linux/Unix systems.
>>
>> To be more portable, the macro
>> is_dir_sep()
>> can be used:
>>
>> if (is_dir_sep(path[wtlen]))
>
> Since the path is already normalized by 'normalize_path_copy_len' which
>
On Sun, Feb 02, 2014 at 12:42:52PM +0100, David Kastrup wrote:
> John Keeping writes:
>
> > On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
> >> Duy Nguyen writes:
> >>
> >> > The file is for past commits only.
> >>
> >> > New commits can contain these info in their messages.
>
On Sun, Feb 2, 2014 at 6:13 PM, Martin Erik Werner
wrote:
> diff --git a/setup.c b/setup.c
> index 2270bd4..5817875 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -32,9 +32,11 @@ static inline int abspath_part_inside_repo(char *path)
> if (strncmp(path, work_tree, wtlen) == 0) {
>
Duy Nguyen writes:
> On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup wrote:
>> Since Git has a working facility for references that is catered to do
>> exactly this kind of mapping and already _does_, it seems like a
>> convenient path to explore.
>
> It will not scale. If you make those refs avai
On Sun, Feb 02, 2014 at 12:37:16PM +0100, Torsten Bögershausen wrote:
> On 2014-02-02 12.21, David Kastrup wrote:
> > Martin Erik Werner writes:
> >
> >> On Sun, Feb 02, 2014 at 09:19:04AM +0700, Duy Nguyen wrote:
> >>> On Sun, Feb 2, 2014 at 8:59 AM, Martin Erik Werner
> >>> wrote:
> +
On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup wrote:
> Since Git has a working facility for references that is catered to do
> exactly this kind of mapping and already _does_, it seems like a
> convenient path to explore.
It will not scale. If you make those refs available for
cloning/fetching, a
John Keeping writes:
> On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
>> Duy Nguyen writes:
>>
>> > The file is for past commits only.
>>
>> > New commits can contain these info in their messages.
>>
>> If it's not forgotten. Experience shows that things like issue numbers
>>
On 2014-02-02 12.21, David Kastrup wrote:
> Martin Erik Werner writes:
>
>> On Sun, Feb 02, 2014 at 09:19:04AM +0700, Duy Nguyen wrote:
>>> On Sun, Feb 2, 2014 at 8:59 AM, Martin Erik Werner
>>> wrote:
+ /* check if work tree is already the prefix */
+ if (strncmp(path, wor
On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
> Duy Nguyen writes:
>
> > The file is for past commits only.
>
> > New commits can contain these info in their messages.
>
> If it's not forgotten. Experience shows that things like issue numbers
> have a tendency to be omitted, a
Patch 17/17 of v4 failed to arrive in my inbox for some reason, so
I'll just reply to v3 since there's another error I noticed which is
still present in v4, plus a comment specific to v4 (see below).
On Mon, Jan 27, 2014 at 3:33 PM, Christian Couder
wrote:
> From: Eric Sunshine
>> On Sun, Jan 26
Martin Erik Werner writes:
> On Sun, Feb 02, 2014 at 09:19:04AM +0700, Duy Nguyen wrote:
>> On Sun, Feb 2, 2014 at 8:59 AM, Martin Erik Werner
>> wrote:
>> > + /* check if work tree is already the prefix */
>> > + if (strncmp(path, work_tree, wtlen) == 0) {
>> > + if (p
Duy Nguyen writes:
> On Sun, Feb 2, 2014 at 5:37 PM, David Kastrup wrote:
>> in the context of an ongoing discussion on the Emacs developer list of
>> converting the Bzr repository of Emacs, one question (with different
>> approaches) is where to put the information regarding preexisting Bazaar
On Sun, Feb 02, 2014 at 09:19:04AM +0700, Duy Nguyen wrote:
> On Sun, Feb 2, 2014 at 8:59 AM, Martin Erik Werner
> wrote:
> > + /* check if work tree is already the prefix */
> > + if (strncmp(path, work_tree, wtlen) == 0) {
> > + if (path[wtlen] == '/')
> > +
On Sun, Feb 2, 2014 at 5:37 PM, David Kastrup wrote:
> in the context of an ongoing discussion on the Emacs developer list of
> converting the Bzr repository of Emacs, one question (with different
> approaches) is where to put the information regarding preexisting Bazaar
> revision numbers and bug
- Allow extra space in "is new" and "is separate"
- Fix bug in word regex for numbers
Signed-off-by: Adrian Johnson
---
t/t4034/ada/expect | 2 +-
userdiff.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t4034/ada/expect b/t/t4034/ada/expect
index be2376e..a6
Hi,
in the context of an ongoing discussion on the Emacs developer list of
converting the Bzr repository of Emacs, one question (with different
approaches) is where to put the information regarding preexisting Bazaar
revision numbers and bug tracker ids: those are not present in the
current Git m
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
wrote:
> This is a small refactoring to prepare for the next steps.
Since this is all brand new code, wouldn't it make more sense to
structure it in this fashion in the first place when introduced in
patch 4/17? It's not clear why it should be int
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
wrote:
> It is simpler and more natural if the "git interpret-trailers"
> is made a filter as its output already goes to sdtout.
>
> Signed-off-by: Christian Couder
> ---
> diff --git a/trailer.c b/trailer.c
> index 8681aed..73a65e0 100644
> --- a
68 matches
Mail list logo
