Hallo,
Ich heisse Jensen. Ich bin auf git interessiert. Haette gern von Euch
gehoert.
Gruss aus den Staaten,
--
Cal Dershowitz
aka Merrill Jensen in real life
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 07/13/2016 12:20 AM, Joey Hess wrote:
Torsten Bögershausen wrote re jh/clean-smudge-annex:
The thing is that we need to check the file system to find .gitatttibutes,
even if we just did it 1 nanosecond ago.
So the .gitattributes is done 3 times:
-1 would_convert_to_git_filter_fd(
-2 assert
On Thu, Jul 14, 2016 at 01:36:52AM +0300, ervion wrote:
> It is in fact the case, that git fetch output is scrubbed, sorry I did not
> notice previously.
> But (on my device: git version 2.9.0 arch linux) git push is not.
> $ git push origin --all
Maybe this?
-- >8 --
Subject: [PATCH] push: anon
I completely agree that it is not a head-on-fire kind of problem, there
are ways to avoid it.
Simply nice to have.
It is in fact the case, that git fetch output is scrubbed, sorry I did
not notice previously.
But (on my device: git version 2.9.0 arch linux) git push is not.
$ git push origin
On Wed, Jul 13, 2016 at 03:41:01PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> >>> I think Shawns proposal to have a receive.maxCommandBytes is a
> >>> good way for an overall upper bound, but how does it stop us from
> >>> going forward with this series?
> >>
> >> If we were to do
Stefan Beller writes:
>>> I think Shawns proposal to have a receive.maxCommandBytes is a
>>> good way for an overall upper bound, but how does it stop us from
>>> going forward with this series?
>>
>> If we were to do maxcommandbytes, then max_options would become
>> irrelevant, no?
>
> Maybe?
>
On 07/12/2016 02:24 PM, Duy Nguyen wrote:
Just thinking out loud. I've been thinking about this more about this.
After the move from signal-based to unix socket for communication, we
probably are better off with a simpler design than the shm-alike one
we have now.
What if we send everything over
Junio C Hamano schrieb:
Bergi writes:
when nothing is staged in the index then `git commit` warns about this
fact with either "nothing to commit, working directory clean" or "no
changes added to commit".
However, `git commit --amend --no-edit` will happily record a new
commit that differs in n
Junio C Hamano writes:
> It is somewhat disturbing that nobody seems to be regularly building
> on 32-bit platforms these days, which is the only reason I can think
> of why this was never reported until it hit a maintenance track.
> This should have been caught last week at f6a729f3 (Merge branc
Jehan Pagès writes:
> ... A better naming should
> have been called --invert-matches, or even just --invert.
> And the man description should definitely be completed, IMO.
Renaming the options would not work well without harming existing
users, but a patch to update the documentation is certainl
Hi,
On Wed, Jul 13, 2016 at 7:37 PM, Junio C Hamano wrote:
> Jehan Pagès writes:
>
>>> I think --author=someone greps the "author " field in the commit
>>> object looking for the hit with "someone", and your request asks to
>>> show commits that either do not have "something" or was not written
Hi git
http://beabuyer.org/smell.php?cat=qcugur1unp6m3q98
Rgds
Harsh
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Johannes Schindelin writes:
>> I was hoping to hear from you sooner and do v2.9.2 with your t0006
>> workaround with lazy-prereq changes from Peff (i.e. "Makes sense!"
>> above), so that you do not have to do two releases in a row
>> (i.e. skipping v2.9.1 saying "Git for Windows skipped that one
Benjamin Fritsch writes:
> I read the Changelog for 2.9 and couldn’t find any reference to changed key
> handling. Is there anything that I can add to the `git clone` command to get
> the old behavior?
I do not think this has much to do with the version of Git, unless
you are getting an update
Bergi writes:
> when nothing is staged in the index then `git commit` warns about this
> fact with either "nothing to commit, working directory clean" or "no
> changes added to commit".
> However, `git commit --amend --no-edit` will happily record a new
> commit that differs in nothing than its c
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This was just a quick fix, intended to allow me to release Git for Windows
> > v2.9.1 in a timely manner (which is now delayed for other reasons).
> > ...
> >> You'll need to adjust check_show as I did in m
Hey all,
We recently upgraded from Git 2.8 to 2.9 and saw an issue when there are
multiple keys added to my ssh-agent.
I have two keys.
- KeyA (my company that has access to the repository I want to clone)
- KeyB (just my personal key with access to my personal stuff)
Having both keys in loade
Johannes Schindelin writes:
> How about this one instead (which is part of the time_t-may-be-int64
> branch on https://github.com/dscho/git which I still have to complete, as
> some unsigned longs still slipped out of my previous net)? It strikes me
> as much more robust:
Hmm, sorry, I do not se
Hi,
We have a perforce structure at work that looks like this:
//depot/basic/{main,branch1,branch2}/component{1,2}
//depot/extra/{main,branch1,branch2}/extra{1,2}
I'm trying to create 3 branches, i.e. main/branch1/branch2, with all
sub-components together, i.e. component1/component2/extra1/extra
Hi Duy,
On Wed, 13 Jul 2016, Duy Nguyen wrote:
> On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin
> wrote:
> >
> > On Tue, 12 Jul 2016, Duy Nguyen wrote:
> >
> >> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote:
> >> > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote:
> >> >
> >
Hello,
when nothing is staged in the index then `git commit` warns about this
fact with either "nothing to commit, working directory clean" or "no
changes added to commit".
However, `git commit --amend --no-edit` will happily record a new commit
that differs in nothing than its commit date fro
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Tue, 12 Jul 2016, Junio C Hamano wrote:
> >
> >> Jeff King writes:
> >>
> >> > In case it wasn't clear, I was mostly guessing there. So I dug a bit
> >> > further, and indeed, I am wrong. Linux never b
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > Definitely keep that paragraph. I am quite familiar with the test
> > helper and it was not the outcome I initially expected.
> >
> >> +test_lazy_prereq 64BIT_TIME '
> >> + case "$(test-date show:iso 99)" in
On wo, 2016-07-13 at 20:26 +0300, ervion wrote:
> One possibility for this in git is to save remote in the
> https://username:passw...@domain.com/repo.git format.
This is not recommended. Git has credential helpers to help you store
passwords outside the git configuration.
Which then makes your
On Wed, Jul 13, 2016 at 11:09 AM, Junio C Hamano wrote:
> ervion writes:
>
>> Sometimes using ssh is not possible and saving https password in plain
>> text to disk may be desireable
>> (in case of encrypted disk it would be equivalent security with
>> caching password in memory).
>>
>> One possi
ervion writes:
> Sometimes using ssh is not possible and saving https password in plain
> text to disk may be desireable
> (in case of encrypted disk it would be equivalent security with
> caching password in memory).
>
> One possibility for this in git is to save remote in the
> https://username
On Wed, Jul 13, 2016 at 10:52 AM, Stefan Beller wrote:
> On Wed, Jul 13, 2016 at 10:32 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
* sb/push-options (2016-07-12) 5 commits
- add a test for push options
- push: accept push options
- SQUASH???
>>>
>>> Squash? I do
On Wed, Jul 13, 2016 at 10:32 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> * sb/push-options (2016-07-12) 5 commits
>>> - add a test for push options
>>> - push: accept push options
>>> - SQUASH???
>>
>> Squash? I do not find a squashable commit in what you pushed,
>> do you intend
Sometimes using ssh is not possible and saving https password in plain
text to disk may be desireable
(in case of encrypted disk it would be equivalent security with caching
password in memory).
One possibility for this in git is to save remote in the
https://username:passw...@domain.com/rep
On Wed, Jul 13, 2016 at 5:16 PM, Duy Nguyen wrote:
> On Tue, Jul 12, 2016 at 9:45 PM, Christian Couder
> wrote:
>> On Tue, Jul 12, 2016 at 5:12 PM, Duy Nguyen wrote:
>>>
>>> No. People could create an index file anywhere in theory. So you don't
>>> know how many index files there are.
>>
>> Mayb
Duy Nguyen writes:
> On the subject of truncation, there is something else I should note.
> The field sd_size in struct stat_data is 32 bits, so large files will
> overflow it too, regardless of platforms. I did not do anything
> because I checked and double checked and was pretty sure we did not
On Wed, Jul 13, 2016 at 6:56 PM, Junio C Hamano wrote:
> * nd/pack-ofs-4gb-limit (2016-07-13) 7 commits
> - fsck: use streaming interface for large blobs in pack
> - pack-objects: do not truncate result in-pack object size on 32-bit systems
> - index-pack: correct "offset" type in unpack_entry_
> * sb/push-options (2016-07-12) 5 commits
> - add a test for push options
> - push: accept push options
> - SQUASH???
Squash? I do not find a squashable commit in what you pushed,
do you intend to squash the first 2 patches instead?
> - receive-pack: implement advertising and receiving push
Jehan Pagès writes:
>> I think --author=someone greps the "author " field in the commit
>> object looking for the hit with "someone", and your request asks to
>> show commits that either do not have "something" or was not written
>> by "someone", I would guess.
>
> Note that I can still see commi
Stefan Beller writes:
>> * sb/push-options (2016-07-12) 5 commits
>> - add a test for push options
>> - push: accept push options
>> - SQUASH???
>
> Squash? I do not find a squashable commit in what you pushed,
> do you intend to squash the first 2 patches instead?
$ git log --oneline --first
Hi,
On Wed, Jul 13, 2016 at 7:04 PM, Junio C Hamano wrote:
> Jehan Pagès writes:
>
>>> git log --author=someone --invert-grep --grep=something
>>
>> But it does not work. Actually it looks like it just returns
>> everything (as though I had done a simple `git log`).
>
> Do you see a commit that
Hello,
> $ git version
> git version 2.5.5
Tested on a Fedora 23.
You can combine `git log --author=someone --grep=something` to have
all commits by "someone" where "something" can be grepped. If I want
all commits by someone where "something" is not grepped, I would
expect this command to retur
Jehan Pagès writes:
>> git log --author=someone --invert-grep --grep=something
>
> But it does not work. Actually it looks like it just returns
> everything (as though I had done a simple `git log`).
Do you see a commit that is by "someone" and has "something" in it
in the output from the comman
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
It turns out that v2.9.1 had tests
Johannes Schindelin writes:
> On Tue, 12 Jul 2016, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > In case it wasn't clear, I was mostly guessing there. So I dug a bit
>> > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t
>> > on i386 because of the ABI headaches.
>>
Nguyễn Thái Ngọc Duy writes:
> A diff from nd/pack-ofs-4gb-limit can explain the changes better than
> me.
>
> I did not add PRIdMAX or similar because that carries a risk to exotic
> platforms that people rarely test. Just casting to unsigned should be
> fine.
Looks very sensible. Thanks.
--
Idea taken and code refactored from [1]:
The intent of this patch series is to separate the index-helper logic
from the Watchman logic. With very large repos, the percentage of time
required to read the index from disk becomes a much smaller percentage
of the overall time. The Watchman logic pro
Jeff King writes:
> Definitely keep that paragraph. I am quite familiar with the test
> helper and it was not the outcome I initially expected.
>
>> +test_lazy_prereq 64BIT_TIME '
>> +case "$(test-date show:iso 99)" in
>> +*" -> 2038-"*)
>> +# on this platform, unsigne
On Wed, Jul 13, 2016 at 9:21 AM, Matthieu Moy
wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +`gitdir`::
>> + The environment variable `GIT_DIR` must match the following
>> + pattern for files to be included. The pattern can contain
>> + standard globbing wildcards and two additional ones
Johannes Schindelin writes:
> This was just a quick fix, intended to allow me to release Git for Windows
> v2.9.1 in a timely manner (which is now delayed for other reasons).
> ...
>> You'll need to adjust check_show as I did in my earlier patch.
>
> Makes sense!
Hmph, so what is your preferred
> On 12 Jul 2016, at 00:45, Joey Hess wrote:
>
> This adds new smudgeToFile and cleanFromFile filter commands,
> which are similar to smudge and clean but allow direct access to files on
> disk.
>
> This interface can be much more efficient when operating on large files,
> because the whole fil
Use the right type for offsets in this case, off_t, which makes a
difference on 32-bit systems with large file support, and change
formatting code accordingly.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/index-pack.c | 7 ---
1 file changed, 4 insertions(+)
On 32 bit systems with large file support, unsigned long is 32-bit
while the two offsets in the subtraction expression (pack-objects has
the exact same expression as in sha1_file.c but not shown in diff) are
in 64-bit. If an in-pack object is larger than 2^32 len/datalen is
truncated and we get a m
This field, filled by sha1_object_info() contains the on-disk size of
an object, which could go over 4GB limit of unsigned long on 32-bit
systems. Use off_t for it instead and update all callers.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/cat-file.c | 4 ++--
On 07/10/2016 05:09 PM, Duy Nguyen wrote:
> On Fri, Jun 3, 2016 at 11:03 PM, Michael Haggerty
> wrote:
>> Since the that ref-iterator [1] changes seem to have gotten a positive
>> reception, let's try to keep up the momentum. I hope I'm not
>> overloading the review pipeline...
>>
>> I think all
unpack_entry_data() receives an off_t value from unpack_raw_entry(),
which could be larger than unsigned long on 32-bit systems with large
file support. Correct the type so truncation does not happen. This
only affects bad object reporting though.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by
A typical diff will not show what's going on and you need to see full
functions. The core code is like this, at the end of of write_one()
e->idx.offset = *offset;
size = write_object(f, e, *offset);
if (!size) {
e->idx.offset = recursing;
ret
A diff from nd/pack-ofs-4gb-limit can explain the changes better than
me.
I did not add PRIdMAX or similar because that carries a risk to exotic
platforms that people rarely test. Just casting to unsigned should be
fine.
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 55eac75..b08bc8b 100644
-
On 32-bit systems with large file support, one entry could be larger
than 4GB and overflow "len". Correct it so we can unpack a full entry.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/index-pack.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletion
For blobs, we want to make sure the on-disk data is not corrupted
(i.e. can be inflated and produce the expected SHA-1). Blob content is
opaque, there's nothing else inside to check for.
For really large blobs, we may want to avoid unpacking the entire blob
in memory, just to check whether it prod
On Tue, Jul 12, 2016 at 9:45 PM, Christian Couder
wrote:
> On Tue, Jul 12, 2016 at 5:12 PM, Duy Nguyen wrote:
>>
>> No. People could create an index file anywhere in theory. So you don't
>> know how many index files there are.
>
> Maybe when an index file is created, its path and its sharedindex
On Tue, Jul 12, 2016 at 10:40 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This is a special SHA1. Let's keep it at one place, easier to replace
>> later when the hash change comes, easier to recognize. Start with an
>> underscore to reduce the chances somebody may override it w
On Tue, Jul 12, 2016 at 10:49 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index c2676e8..2d50640 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -380,6 +380,13 @@ static int update_one(struct cache_tree *it,
>>
On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On Tue, 12 Jul 2016, Duy Nguyen wrote:
>
>> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote:
>> > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote:
>> >
>> >> I'm not opposed to letting one worktree see everythi
Hi,
On Tue, 12 Jul 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > In case it wasn't clear, I was mostly guessing there. So I dug a bit
> > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t
> > on i386 because of the ABI headaches.
>
> X-< (yes, I knew).
>
> > That
Instant cash Loan with same day payout on all kinds of Loan are available at
Quick Financial Home were loan is offered at 2% per annul. Email:
quickloa...@foxmail.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More maj
Instant cash Loan with same day payout on all kinds of Loan are available at
Quick Financial Home were loan is offered at 2% per annul. Email:
quickloa...@foxmail.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More maj
Jeff King writes:
> On Wed, Jul 13, 2016 at 09:21:37AM +0200, Matthieu Moy wrote:
>
>> > +static int prepare_include_condition_pattern(struct strbuf *pat)
>> > +{
>> > + int prefix = 0;
>> > +
>> > + /* TODO: maybe support ~user/ too */
>> > + if (pat->buf[0] == '~' && is_dir_sep(pat->buf[1]))
Hi Peff,
On Tue, 12 Jul 2016, Jeff King wrote:
> On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote:
>
> > [PATCH] Work around test failures due to timestamps being unsigned long
> >
> > Git's source code refers to timestamps as unsigned longs. On 32-bit
> > platforms, as well
Hi Duy,
On Tue, 12 Jul 2016, Duy Nguyen wrote:
> On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote:
> > On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > On Tue, 12 Jul 2016, Andreas Schwab wrote:
> >> >
> >> >> Johannes Schindelin
Hi Andreas,
On Tue, 12 Jul 2016, Andreas Schwab wrote:
> Johannes Schindelin writes:
>
> > On Tue, 12 Jul 2016, Andreas Schwab wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> >> PRIuMAX isn't compatible with time_t.
> >> >
> >> > That statement is wrong.
> >>
> >> No, it isn't. PRIuMA
On Wed, Jul 13, 2016 at 04:26:53AM -0400, Jeff King wrote:
> On Fri, Jul 08, 2016 at 01:38:55PM +0300, Kirill Smelkov wrote:
>
> > > - we will not compute the same write order (which is based on
> > > traversal order), leading to packs that have less efficient cache
> > > characteristics
On Tue, Jul 12, 2016 at 10:08:08PM +0300, Kirill Smelkov wrote:
> > Or are we fine with my arguments about recency order staying the same
> > when using bitmap reachability index for object graph traversal, and this
> > way the patch is fine to go in as it is?
>
> Since there is no reply I assume
On Fri, Jul 08, 2016 at 01:38:55PM +0300, Kirill Smelkov wrote:
> > - we will not compute the same write order (which is based on
> > traversal order), leading to packs that have less efficient cache
> > characteristics
>
> I agree the order can be not exactly the same. Still if origina
Hi Duy,
On Tue, 12 Jul 2016, Duy Nguyen wrote:
> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote:
> > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote:
> >
> >> I'm not opposed to letting one worktree see everything, but this move
> >> makes it harder to write new scripts (or new buil
Hi Jeff,
[please note that top-posting is discouraged on this mailing list]
On Tue, 12 Jul 2016, Jeff Hostetler wrote:
> Thanks for the feedback. I like the overall direction of your
> suggestions. Going for a porcelain V2 feels better than piling
> onto verbose. I think that would also give
Hi Junio,
On Tue, 12 Jul 2016, Junio C Hamano wrote:
> On Tue, Jul 12, 2016 at 6:16 AM, Johannes Schindelin
> wrote:
> >
> > On Mon, 11 Jul 2016, Junio C Hamano wrote:
> >
> >> [New Topics]
> >>
> >> [...]
> >
> > What about http://thread.gmane.org/gmane.comp.version-control.git/299050?
>
> Not
Hi Pranit,
On Wed, Jul 13, 2016 at 12:35 AM, Pranit Bauva wrote:
> Hey Junio,
>
> A small mistake got unnoticed by me which Lars recently pointed out.
> The naming convention is "git_path_" and underscore
> instead of spaces.
It's a good thing to resend when you find mistakes, but please use a
v
On Wed, Jul 13, 2016 at 09:21:37AM +0200, Matthieu Moy wrote:
> > +static int prepare_include_condition_pattern(struct strbuf *pat)
> > +{
> > + int prefix = 0;
> > +
> > + /* TODO: maybe support ~user/ too */
> > + if (pat->buf[0] == '~' && is_dir_sep(pat->buf[1])) {
> > + struct
Nguyễn Thái Ngọc Duy writes:
> +`gitdir`::
> + The environment variable `GIT_DIR` must match the following
> + pattern for files to be included. The pattern can contain
> + standard globbing wildcards and two additional ones, `**/` and
> + `/**`, that can match multiple path compo
75 matches
Mail list logo
