Finding a great pair of silver anklet bracelets is possible, regardless of
the size of your budget. Sometimes when young people achieve certain things
in life, personalized gifts pick up to compliment them for their
accomplishment. Sometimes young people do things like graduate from
school.[url=h
On Mon, Mar 25, 2013 at 1:05 PM, Nguyễn Thái Ngọc Duy wrote:
> The story goes back to 94bc671 (Add directory pattern matching to
> attributes - 2012-12-08). Before this commit, directories are passed
> to path_matches without the trailing slash. This is fine for matching
> pattern "subdir" with "f
The series looks good, but I can't test it because it does not apply
anywhere here.
Am 3/23/2013 14:31, schrieb John Keeping:
> Currently the difftool --dir-diff tests may or may not use symlinks
> depending on the operating system on which they are run. In one case
> this has caused a test failu
Am 3/24/2013 16:15, schrieb John Keeping:
> Subject: [PATCH] difftool: don't overwrite modified files
>
> After running the user's diff tool, git-difftool will copy any files
> that differ between the working tree and the temporary tree. This is
> useful when the user edits the file in their diff
Am 23.03.2013 17:28, schrieb Ilya Kulakov:
> The `git submodule` commands seem to ignore modules which paths contain
> unicode characters.
>
> Consider the following steps to reproduce the problem:
>
> 1. Create a directory with name that contains at least one unicode character
> (e.g. "ûñ
Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
> I find this behavior very inconsistent and annoying. Why would I want
> to commit the submodule change immediately? Maybe I want to batch it
> up with other changes and stage it at a later time. Why should I have
> to unstage them manually now
Jens Lehmann wrote:
> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
>> I find this behavior very inconsistent and annoying. Why would I want
>> to commit the submodule change immediately? Maybe I want to batch it
>> up with other changes and stage it at a later time. Why should I have
>> to
Fredrik Gustafsson wrote:
> If core.preload is set to a non-zero value, every time a git command is
> executed, git status will be runned in the background if the value of
> core.preload is lower than the number of seconds since last run.
Counting the number of seconds since the last run is gross.
On Mon, Mar 25, 2013 at 02:20:31PM +0700, Duy Nguyen wrote:
> On second thought, maybe we should not pass path "subdir/" at all.
> Instead we create a fake dtype based on the trailing slash and pass it
> down to attr.c:fill() -> path_matches(), just like how
> last_exclude_matching_from_list() is c
Junio C Hamano writes:
> Thomas Rast writes:
>
>> So here's a nonrecursive version. Dijkstra is probably turning over
>> in his grave as we speak.
>>
>> I *think* I actually got it right.
>
> You seem to have lost the "if we cannot get delta base, this object
> is BAD" check where you measure t
It turns out that the presence of SECURITYSESSIONID is not sufficient
for detecting the presence of a GUI under Mac OS X. SECURITYSESSIONID
appears to only be set when the user has Screen Sharing enabled.
Disabling Screen Sharing and relaunching the shell showed that the
variable was missing, at l
On Mon, Mar 25, 2013 at 08:26:52AM +0100, Johannes Sixt wrote:
> The series looks good, but I can't test it because it does not apply
> anywhere here.
It's built on top of da/difftool-fixes, is there some problem that stops
it applying cleanly on top of that?
> Am 3/23/2013 14:31, schrieb John Ke
On Mon, Mar 25, 2013 at 08:41:59AM +0100, Johannes Sixt wrote:
> Am 3/24/2013 16:15, schrieb John Keeping:
> > Subject: [PATCH] difftool: don't overwrite modified files
> >
> > After running the user's diff tool, git-difftool will copy any files
> > that differ between the working tree and the tem
Just a small heads-up for people using Emacs. 24.4 has inotify
support, and magit-inotify.el [1] has already started using it. From
initial impressions, I'm quite impressed with it.
[1]: https://github.com/magit/magit/blob/master/contrib/magit-inotify.el
--
To unsubscribe from this list: send th
On Sun, Mar 24, 2013 at 02:29:40PM -0700, David Aguilar wrote:
> This makes me wonder whether the modifiable mode should be made
> more explicit, either in the documentation or via a flag.
>
> Imagine if --dir-diff also honored --edit and --no-edit flags.
>
> Right now --edit is the default. If
Am 3/25/2013 11:35, schrieb John Keeping:
> On Mon, Mar 25, 2013 at 08:26:52AM +0100, Johannes Sixt wrote:
>> The series looks good, but I can't test it because it does not apply
>> anywhere here.
>
> It's built on top of da/difftool-fixes, is there some problem that stops
> it applying cleanly on
On Mon, Mar 25, 2013 at 5:44 PM, Ramkumar Ramachandra
wrote:
> Just a small heads-up for people using Emacs. 24.4 has inotify
> support, and magit-inotify.el [1] has already started using it. From
> initial impressions, I'm quite impressed with it.
Have you tried it? From a quick look, it seems
On Mon, Mar 25, 2013 at 11:59:12AM +0100, Johannes Sixt wrote:
> Am 3/25/2013 11:35, schrieb John Keeping:
> > On Mon, Mar 25, 2013 at 08:26:52AM +0100, Johannes Sixt wrote:
> >> The series looks good, but I can't test it because it does not apply
> >> anywhere here.
> >
> > It's built on top of d
Duy Nguyen wrote:
> On Mon, Mar 25, 2013 at 5:44 PM, Ramkumar Ramachandra
> wrote:
>> Just a small heads-up for people using Emacs. 24.4 has inotify
>> support, and magit-inotify.el [1] has already started using it. From
>> initial impressions, I'm quite impressed with it.
>
> Have you tried it?
On Sun, Mar 24, 2013 at 3:23 PM, Jeff King wrote:
> On Sun, Mar 24, 2013 at 08:01:33PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> On Sun, Mar 24, 2013 at 7:31 PM, Jeff King wrote:
>> >
>> > I don't have details on the KDE corruption, or why it wasn't detected
>> > (if it was one of the cases I me
David Aguilar writes:
> This makes me wonder whether the modifiable mode should be made
> more explicit, either in the documentation or via a flag.
>
> Imagine if --dir-diff also honored --edit and --no-edit flags.
>
> Right now --edit is the default. If we had foreseen these various
> edge case
On Mon, Mar 25, 2013 at 09:43:23AM -0400, Jeff Mitchell wrote:
> > But I haven't seen exactly what the corruption is, nor exactly what
> > commands they used to clone. I've invited the blog author to give more
> > details in this thread.
>
> The syncing was performed via a clone with git clone --
On Mon, Mar 25, 2013 at 9:56 PM, Jeff King wrote:
> There are basically three levels of transport that can be used on a
> local machine:
>
> 1. Hard-linking (very fast, no redundancy).
>
> 2. Byte-for-byte copy (medium speed, makes a separate copy of the
> data, but does not check the int
On 24.03.13 03:49, Eric Sunshine wrote:
> On Sat, Mar 23, 2013 at 8:40 AM, Torsten Bögershausen wrote:
>> Subject: [PATCH] Make core.sharedRepository work under cygwin 1.7
[..]
>
> s/failes/fails/
>
Thanks for review,
I will send a new patch in a minute.
It is actually 2 patches,
- The fix as d
When core.sharedRepository is used, set_shared_perm() in path.c
needs lstat() to return the correct POSIX permissions.
The default for cygwin is core.ignoreCygwinFSTricks = false, which
means that the fast implementation in do_stat() is used instead of lstat().
lstat() under cygwin uses the Windo
Sebastian Götte writes:
> Signed-off-by: Sebastian Götte
> ---
> commit.c| 54 ++
> commit.h| 9
> gpg-interface.h | 6 ++
> pretty.c| 67
> +
> 4 files ch
On Mon, Mar 25, 2013 at 10:31:04PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Mon, Mar 25, 2013 at 9:56 PM, Jeff King wrote:
> > There are basically three levels of transport that can be used on a
> > local machine:
> >
> > 1. Hard-linking (very fast, no redundancy).
> >
> > 2. Byte-for-byte cop
optimize set_shared_perm() in path.c:
- sometimes the chown() function is called even when not needed.
(This can be provoced by running t1301, and adding some debug code)
Save a chmod from 400 to 400, or from 600->600 on these files:
.git/info/refs+
.git/objects/info/packs+
Ramkumar Ramachandra writes:
> Configuration from test_config does not last beyond the end of the
> current test assertion, making each test easier to think about in
> isolation.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> t/t5520-pull.sh | 22 +-
> 1 file changed, 9 ins
René Scharfe writes:
> Am 24.03.2013 05:55, schrieb Junio C Hamano:
>> So I like your change for readability, but for GCC 4.4.5 we still
>> need the unnecessary initialization.
>
> Hrm, perhaps we can make it even simpler for the compiler.
And the result is even simpler for human readers, I'd ha
Johannes Sixt writes:
> Am 3/24/2013 16:15, schrieb John Keeping:
> ...
>> +for my $file (keys %worktree) {
>> next if $symlinks && -l "$b/$file";
>> next if ! -f "$b/$file";
>>
>> -my $diff = compare("$b/$file", "$workdir/$file");
>> -if ($
Nguyễn Thái Ngọc Duy writes:
> In checkout_paths() we do this
>
> - for all updated items, call match_pathspec
> - for all items, call match_pathspec (inside unmerge_cache)
> - for all items, call match_pathspec (for showing "path .. is unmerged)
> - for updated items, call match_pathspec an
On Mon, Mar 25, 2013 at 11:56 AM, Jeff King wrote:
> On Mon, Mar 25, 2013 at 10:31:04PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Mon, Mar 25, 2013 at 9:56 PM, Jeff King wrote:
>> > There are basically three levels of transport that can be used on a
>> > local machine:
>> >
>> > 1. Hard-linkin
Kevin Bracey writes:
> Commit 718135e improved the merge error reporting for the resolve
> strategy's merge conflict and permission conflict cases, but led to a
> malformed "ERROR: in myfile.c" message in the case of a file added
> differently.
>
> This commit reverts that change, and uses an al
Junio C Hamano writes:
> Kevin Bracey writes:
>
>> Commit 718135e improved the merge error reporting for the resolve
>> strategy's merge conflict and permission conflict cases, but led to a
>> malformed "ERROR: in myfile.c" message in the case of a file added
>> differently.
>>
>> This commit r
Junio C Hamano writes:
> Actually, this one is even better, I think. Again on top of your
> two patches applied on 'maint'.
Scratch that one. The "if test -z "$1"" block needs to be moved a
bit higher, like this (the log message can stay the same):
diff --git a/git-merge-one-file.sh b/git-mer
Kevin Bracey writes:
> Minor change from v3: that version moved initialisation of src1 higher up,
> detaching it from its associated comment. This move was only required by
> earlier versions, so v4 leaves src1 in its original position.
The "funny filename" comment was from b539c5e8fbd3 (git-mer
Ramkumar Ramachandra writes:
> Git 2.0 is coming soon, so I'm excited about breaking a lot of
> backward compatibility ;)
Don't.
I lack the sense of humor normal people seem to have, so even with
the smiley, anybody making such a comment will be thrown into my "do
not pay attention to them" box
Paul Campbell writes:
> Don't explicitly use the Bash shell but allow the system to provide a
> hopefully POSIX compatible shell at /bin/sh.
>
> Signed-off-by: Paul Campbell
> ---
>
> Only the system's I was able to test this on (Debian squeeze) /bin/sh is
> the dash shell.
>
> contrib/subtree/
I was on a branch (local tracked with remote), and I wanted to checkout
a remote branch so did:
$git co myRemoteBranch
and got a message that a lot of jar files were being untracked (files
were locked). I had a server running that had some of the jar files
locked, so it could not update a
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Git 2.0 is coming soon, so I'm excited about breaking a lot of
>> backward compatibility ;)
>
> Don't.
push.default is the necessary exception?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to m
This is a fixed version of the initial patch, plus a two-patch
implementation of a recursion-free unpack_entry. (I narrowly resisted
using "unrecursify" to describe it.)
I wrote:
> Junio C Hamano writes:
>
>> The stack/recursion is used _only_ for error recovery, no? If we do
>> not care about
packed_object_info() and packed_delta_info() were mutually recursive.
The former would handle ordinary types and defer deltas to the latter;
the latter would use the former to resolve the delta base.
This arrangement, however, leads to trouble with threaded index-pack
and long delta chains on plat
Similar to the recursion in packed_object_info(), this leads to
problems on stack-space-constrained systems in the presence of long
delta chains.
We proceed in three phases:
1. Dig through the delta chain, saving each delta object's offsets and
size on an ad-hoc stack.
2. Unpack the base obje
The delta base cache lookup and test were shared. Refactor them;
we'll need both parts again. Also, we'll use the clearing routine
later.
Signed-off-by: Thomas Rast
---
sha1_file.c | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git
"show --show-signature" doesn't currently use the gpg.program setting. Commit
signing, tag signing, and tag verification currently use this setting properly,
so the logic has been added to handle it here as well.
Signed-off-by: Hans Brigman
---
builtin/log.c | 4 +++-
1 file changed, 3 insert
thomas writes:
> Junio C Hamano writes:
>
>> The following comment is also lost but...
>>
>>> - /* We choose to only get the type of the base object and
>>> -* ignore potentially corrupt pack file that expects the delta
>>> -* based on a base with a wrong size. This saves tons of
>>>
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>> Git 2.0 is coming soon, so I'm excited about breaking a lot of
>>> backward compatibility ;)
>>
>> Don't.
>
> push.default is the necessary exception?
A while ago there was a discussion of changes of the "If
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>>> Ramkumar Ramachandra writes:
>
Git 2.0 is coming soon, so I'm excited about breaking a lot of
backward compatibility ;)
>>>
>>> Don't.
>>
>> push.default is the necessary exception?
>
> A while ago there wa
Ramkumar Ramachandra writes:
> I'm talking about slightly better defaults at the porcelain level,
> at most.
If a change does not even have to break backward compatibilty, that
is a regular enhancement and independent from 2.0, no?
--
To unsubscribe from this list: send the line "unsubscribe gi
Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
>>> I find this behavior very inconsistent and annoying. Why would I want
>>> to commit the submodule change immediately? Maybe I want to batch it
>>> up with other chang
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> I'm talking about slightly better defaults at the porcelain level,
>> at most.
>
> If a change does not even have to break backward compatibilty, that
> is a regular enhancement and independent from 2.0, no?
Okay, I'm confused: why are you
Ramkumar Ramachandra wrote:
> Okay, I'm confused: why are you waiting for 2.0 to change push.default
> then? Isn't that just a "slightly better default at the porcelain
> level" and hence a "regular enhancement"?
No. Among other aspects, "git push" is used heavily by scripts.
--
To unsubscribe
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> Okay, I'm confused: why are you waiting for 2.0 to change push.default
>> then? Isn't that just a "slightly better default at the porcelain
>> level" and hence a "regular enhancement"?
>
> No. Among other aspects, "git push" is used heavil
Ramkumar Ramachandra wrote:
> This whole "backward compatibility" thing is not black-or-white: it's
> shades of gray. Can I ask about how "backward incompatible" the other
> suggestions I listed were, just so I get a rough idea of your scale?
It depends on how important the change is and how pai
On Mon, Mar 25, 2013 at 1:17 PM, Junio C Hamano wrote:
> Subject: [PATCH] merge-one-file: force content conflict for "both side added"
> case
s/both side/both sides/
> Historically, we tried to be lenient to "both side added, slightly
Ditto.
> differently" case and as long as the files can be
Commit ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) added the
-S option and documented it in the command usage. Then commit 098bbdc3
(Add -S, --gpg-sign option to manpage of "git commit", 2012-10-21)
documented it in the porcelain manpage. Use wording from the porcelain
to document the
Jeff King writes:
> On Sat, Mar 23, 2013 at 09:00:05PM -0700, Junio C Hamano wrote:
>
>> On Thu, Mar 21, 2013 at 4:13 AM, Jeff King wrote:
>> >
>> > According to 47ec794, this initialization is meant to
>> > squelch an erroneous uninitialized variable warning from gcc
>> > 4.0.1. That version i
Jens Lehmann wrote:
> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
>> In my opinion, the 'git submodule add ' form is broken, because
>> it doesn't relocate the object store of the submodule repository (a
>> bug that we need to fix?).
>
> I don't think it is broken. Leaving the .git directory
Jeff King writes:
> We _do_ see a problem during the checkout phase, but we don't propagate
> a checkout failure to the exit code from clone. That is bad in general,
> and should probably be fixed. Though it would never find corruption of
> older objects in the history, anyway, so checkout shoul
On Mon, Mar 25, 2013 at 01:01:59PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > We _do_ see a problem during the checkout phase, but we don't propagate
> > a checkout failure to the exit code from clone. That is bad in general,
> > and should probably be fixed. Though it would never f
Brad King writes:
> Commit ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) added the
> -S option and documented it in the command usage. Then commit 098bbdc3
> (Add -S, --gpg-sign option to manpage of "git commit", 2012-10-21)
> documented it in the porcelain manpage. Use wording from th
On Mon, Mar 25, 2013 at 12:32:50PM -0400, Jeff Mitchell wrote:
> I think what was conflating the issue in my testing is that with
> --mirror it implies --bare, so there would be checking of the objects
> when the working tree was being created, hence --mirror won't show the
> error a normal clone
On Mon, Mar 25, 2013 at 11:13 AM, John Szakmeister wrote:
>
> Here's an updated patch.
Thank you for it. For what it's worth:
Acked-by: Christian Couder
> I also noticed that git-bisect.sh is
> also trying to determine if a GUI is present by looking for
> SECURITYSESSIONID as well. I wonder i
I started these patches with the intent of improving clone's behavior
on corrupt objects, but my testing uncovered some other nastiness,
including two infinite loops in the streaming code!. Yikes.
I think 1-7 are good. We might want to tweak the die() behavior of patch
8, but I think it should com
On 03/25/2013 04:06 PM, Junio C Hamano wrote:
> Brad King writes:
>
>> Commit ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) added the
>> -S option and documented it in the command usage. Then commit 098bbdc3
>> (Add -S, --gpg-sign option to manpage of "git commit", 2012-10-21)
>> docume
We call read_istream, but never check its return value for
errors. This can lead to us looping infinitely, as we just
keep trying to write "-1" bytes (and we do not notice the
error, as we simply check that write_in_full reports the
same number of bytes we fed it, which of course is also -1).
Sign
It's possible for read_istream to return an error, in which
case we just end up in an infinite loop (aside from EOF, we
do not even look at the result, but just feed it straight
into our running hash).
Signed-off-by: Jeff King
---
I didn't actually trigger this code path in any of my tests, but I
The filter istream pulls data from an "upstream" stream,
running it through a filter function. However, we did not
properly notice when the upstream filter yielded an error,
and just returned what we had read. Instead, we should
propagate the error.
Signed-off-by: Jeff King
---
I don't know if we
The read_istream_loose function loops on inflating a chunk of data
from an mmap'd loose object. We end the loop when we run out
of space in our output buffer, or if we see a zlib error.
We need to treat Z_BUF_ERROR specially, though, as it is not
fatal; it is just zlib's way of telling us that we
We do not have many tests for handling corrupt objects. This
new test at least checks that we detect a byte error in a
corrupt blob object while streaming it out with cat-file.
Signed-off-by: Jeff King
---
t/t1060-object-corruption.sh | 34 ++
1 file changed, 34 i
When we are streaming an index blob to disk, we store the
error from stream_blob_to_fd in the "result" variable, and
then immediately overwrite that with the return value of
"close". That means we catch errors on close (e.g., problems
committing the file to disk), but miss anything which
happened b
We try not to let corruption pass unnoticed over fetches and
clones. For the most part, this works, but there are some
broken corner cases, including:
1. We do not detect missing objects over git-aware
transports. This is a little hard to test, because the
sending side will actually co
When clone is populating the working tree, it ignores the
return status from unpack_trees; this means we may report a
successful clone, even when the checkout fails.
When checkout fails, we may want to leave the $GIT_DIR in
place, as it might be possible to recover the data through
further use of
When we fetch from a remote, we do a revision walk to make
sure that what we received is connected to our existing
history. We do not do the same check for clone, which should
be able to check that we received an intact history graph.
The upside of this patch is that it will make clone more
resili
Brad King writes:
> Commit ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) added the
> -S option and documented it in the command usage. Then commit 098bbdc3
> (Add -S, --gpg-sign option to manpage of "git commit", 2012-10-21)
> documented it in the porcelain manpage. Use wording from th
Commit ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) added the
-S option but documented it in the command usage without indicating that
the value is optional and forgot to mention it in the manpage. Later
commit 098bbdc3 (Add -S, --gpg-sign option to manpage of "git commit",
2012-10-21) d
On Mon, Mar 25, 2013 at 12:50:54PM -0700, Junio C Hamano wrote:
> >> transport.c: In function 'get_refs_via_rsync':
> >> transport.c:127:29: error: 'cmp' may be used uninitialized in this
> >> function [-Werror=uninitialized]
> >> transport.c:109:7: note: 'cmp' was declared here
> >>
> >> gcc (Ub
Jeff King wrote:
> We do not have many tests for handling corrupt objects. This
> new test at least checks that we detect a byte error in a
> corrupt blob object while streaming it out with cat-file.
Thanks.
[...]
> +# convert "1234abcd" to ".git/objects/12/34abcd"
> +obj_to_file() {
> + ech
On Mon, Mar 25, 2013 at 02:10:38PM -0700, Jonathan Nieder wrote:
> > +# convert "1234abcd" to ".git/objects/12/34abcd"
> > +obj_to_file() {
> > + echo "$(git rev-parse --git-dir)/objects/$(git rev-parse "$1" | sed
> > 's,..,&/,')"
> > +}
>
> Maybe this would be clearer in multiple lines?
>
>
On Mon, Mar 25, 2013 at 01:03:52PM -0500, Hans Brigman wrote:
> "show --show-signature" doesn't currently use the gpg.program setting.
> Commit signing, tag signing, and tag verification currently use this setting
> properly, so the logic has been added to handle it here as well.
Please wrap y
On Mon, Mar 25, 2013 at 4:22 PM, Jeff King wrote:
> diff --git a/entry.c b/entry.c
> index 17a6bcc..002b2f2 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -126,8 +126,10 @@ static int streaming_write_entry(struct cache_entry *ce,
> char *path,
> fd = open_output_fd(path, ce, to_tempfile);
>
On Mon, Mar 25, 2013 at 05:35:51PM -0400, Eric Sunshine wrote:
> On Mon, Mar 25, 2013 at 4:22 PM, Jeff King wrote:
> > diff --git a/entry.c b/entry.c
> > index 17a6bcc..002b2f2 100644
> > --- a/entry.c
> > +++ b/entry.c
> > @@ -126,8 +126,10 @@ static int streaming_write_entry(struct cache_entry
Hi!
Today I've discovered that on the build server my home directory was empty.
A post-mortem analysis showed that the git-clean command I've added to my
kernel build script
is the evil doer.
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working d
Jeff King wrote:
> When we are streaming an index blob to disk, we store the
> error from stream_blob_to_fd in the "result" variable, and
> then immediately overwrite that with the return value of
> "close".
Good catch.
[...]
> --- a/entry.c
> +++ b/entry.c
> @@ -126,8 +126,10 @@ static int stre
John Szakmeister writes:
> It turns out that the presence of SECURITYSESSIONID is not sufficient
> for detecting the presence of a GUI under Mac OS X. SECURITYSESSIONID
> appears to only be set when the user has Screen Sharing enabled.
> Disabling Screen Sharing and relaunching the shell showed
After running the user's diff tool, git-difftool will copy any files
that differ between the working tree and the temporary tree. This is
useful when the user edits the file in their diff tool but is wrong if
they edit the working tree file while examining the diff.
Instead of copying uncondition
Hi,
Richard Weinberger wrote:
> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
> changing the
> current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
GIT_DIR is explicitly set.
In git versions including the patch 2c
On Mon, Mar 25, 2013 at 02:39:34PM -0700, Jonathan Nieder wrote:
> > --- a/entry.c
> > +++ b/entry.c
> > @@ -126,8 +126,10 @@ static int streaming_write_entry(struct cache_entry
> > *ce, char *path,
> > fd = open_output_fd(path, ce, to_tempfile);
> > if (0 <= fd) {
> > result
Johannes Sixt writes:
> Am 3/25/2013 11:35, schrieb John Keeping:
>> On Mon, Mar 25, 2013 at 08:26:52AM +0100, Johannes Sixt wrote:
>>> The series looks good, but I can't test it because it does not apply
>>> anywhere here.
>>
>> It's built on top of da/difftool-fixes, is there some problem that
Jeff King writes:
> I wonder, though, what made you look at this. It did not come up in my
> list of -Wuninitialized warnings. Did it get triggered by one of the
> other gcc versions?
No, but the function in question has that questionable construct
written by somebody who does not understand lin
Jonathan Nieder writes:
> In git versions including the patch 2cd83d10bb6b (setup: suppress
> implicit "." work-tree for bare repos, 2013-03-08, currently in "next"
> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
> behavior.
WAT?
--
To unsubscribe from this list: send the
Jonathan Nieder writes:
> Richard Weinberger wrote:
>
>> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
>> changing the
>> current working directory all the time.
>
> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
> GIT_DIR is explicitly set.
And it
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> In git versions including the patch 2cd83d10bb6b (setup: suppress
>> implicit "." work-tree for bare repos, 2013-03-08, currently in "next"
>> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
>> behavior.
>
> WAT?
Is that fa
Am 25.03.2013 23:06, schrieb Junio C Hamano:
Jonathan Nieder writes:
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
G
Junio C Hamano wrote:
>I do not
> know how things will break when the end user sets and exports it to
> the environment, and I do not think we would want to make any
> promise on how it works.
That's a reasonable desire, and it means it'
Richard Weinberger wrote:
> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?
> I've always set only GIT_DIR because it just worked (till today...).
chdir-ing into the git repo without setting any GIT_* vars is probably
the simplest way to go.
--
To unsubscribe from t
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> In git versions including the patch 2cd83d10bb6b (setup: suppress
>>> implicit "." work-tree for bare repos, 2013-03-08, currently in "next"
>>> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
Richard Weinberger writes:
> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?
> I've always set only GIT_DIR because it just worked (till today...).
That means you never run your script inside a subdirectory ;-)
If your $GIT_DIR is tied to a single working tree, a
On Mon, Mar 25, 2013 at 3:13 PM, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
>>I do not
>> know how things will break when the end user sets and exports it to
>> the environment, and I do not think we would want to make any
>> promis
1 - 100 of 124 matches
Mail list logo
