On 02/13/2015 11:06 AM, Zheng Zhang wrote:
> I was running some test with Git 1.8.4.5, then I accidentally met a
> problem that leaded to the following error,
>
>>> error: refs/heads/develop does not point to a valid object!
>
> Turns out that the sha in refs/heads/develop is a bad object id, thi
On 02/13/2015 10:53 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Now back to the real world. Currently, if R is changed *through* a
>> symbolic reference S, then the reflogs for both R and S are updated, but
>> not the reflogs for any other symbolic references that might point at R.
Stefan Beller writes:
> On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> 41 bytes is the exact number of bytes needed for having the returned
>>> hex string represented. 50 seems to be an arbitrary number, such
>>> that there are no benefits from alignment
On Fri, Feb 13, 2015 at 12:19:27PM -0800, Junio C Hamano wrote:
The first one is a replay of Kyle's workaround for older versions of
Getopt::Long that did not take "--no-option" to negate a boolean
option "--option". The second one revert the workarounds made to
the test script over time, and sh
On Fri, Feb 13, 2015 at 11:36:24AM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > A remote helper is currently only told about the 'check-connectivity',
> > 'cloning', and 'update-shallow' options when it supports the 'fetch'
> > command, but not when it supports 'import' instead.
>
>
Daniel Finnie writes:
> Do you have any comments on why the path in --exclude-from= is
> relative to the project root?
Not really.
Because ls-files was designed to be used by Porcelain scripts, and
because the first thing Porcelain scripts are expected to do is to
learn the prefix and then cd t
On Fri, Feb 13, 2015 at 1:56 PM, Stefan Beller wrote:
>
> As I could not find any documentation on the
> magical 50 in the early days, I cc'd Linus
> in case there is something I did not think of yet.
Nothing magical, it's just "rounded up from 40 + NUL character".
Linus
Hello Junio,
in theory it speeds up, because the preprocessor has less work to do.
In practice I don't know how much and this seems also irrelevant
criterion for accepting this patch.
Greetings
Dilyan
On 13.02.2015 22:15, Junio C Hamano wrote:
> Дилян Палаузов writes:
>
>> deheader (git://g
On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> 41 bytes is the exact number of bytes needed for having the returned
>> hex string represented. 50 seems to be an arbitrary number, such
>> that there are no benefits from alignment to certain address boundaries.
Michael Haggerty writes:
> Now back to the real world. Currently, if R is changed *through* a
> symbolic reference S, then the reflogs for both R and S are updated, but
> not the reflogs for any other symbolic references that might point at R.
> If R is changed directly, then no symref's reflogs
Stefan Beller writes:
> 41 bytes is the exact number of bytes needed for having the returned
> hex string represented. 50 seems to be an arbitrary number, such
> that there are no benefits from alignment to certain address boundaries.
Yes, with s/seems to be/is/;
This comes from e83c5163 (Initi
Hi Junio,
Thanks for the info and backstory. I didn't realize that the paths in
the file specified by --exclude-from would be relative to the project
root. That makes my original use case kind of silly (it's a long
story, but I was curious which files were ignored by a subset of my
.gitignore fi
41 bytes is the exact number of bytes needed for having the returned
hex string represented. 50 seems to be an arbitrary number, such
that there are no benefits from alignment to certain address boundaries.
Signed-off-by: Stefan Beller
---
hex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Дилян Палаузов writes:
> deheader (git://gitorious.org/deheader/deheader.git) found out that
> some .c files #include twice one and the same header file.
>
> This patch removes such occurrences and hence speeds up the compilation.
Does it speed up? By how much? Any numbers?
I do not see any
Am 12.02.2015 um 14:21 schrieb Erik Friesen:
> Sorry, I don't know what this TOP posting problem is, and hitting
> reply only replies to the last sender. If you prefer, and you have
> some regular bugtracker, I could use that instead of email posting.
>
> To repro-
> Set up git user on local lin
Junio C Hamano writes:
> ... It does not make sense to allow where you are
> to affect behaviour of the command, i.e. in these two invocations of
> ls-files:
>
> git ls-files -X /var/tmp/exclude -i
> cd example && git ls-files -X /var/tmp/exclude -i
>
> if the same line in /var/tmp
Daniel Finnie writes:
> My question deals with the --exclude-from option to git-ls-files.
You will be fine if you remember that these plumbing commands work
by first cd'ing to the top-level of the working tree (and adjust the
paths given from the command line by prefixing the prefix to them).
T
On Feb 13, 2015, at 12:19, Junio C Hamano wrote:
The first one is a replay of Kyle's workaround for older versions of
Getopt::Long that did not take "--no-option" to negate a boolean
option "--option". The second one reverts the workarounds made to
the test script over time, and should break if
The first one is a replay of Kyle's workaround for older versions of
Getopt::Long that did not take "--no-option" to negate a boolean
option "--option". The second one revert the workarounds made to
the test script over time, and should break if the first one does
not work well for older Getopt::L
From: "Kyle J. McKay"
Only Perl version 5.8.0 or later is required, but that comes with
an older Getopt::Long (2.32) that does not support the 'no-'
prefix. Support for that was added in Getopt::Long version 2.33.
Since the help only mentions the 'no-' prefix and not the 'no'
prefix, add explic
These were done to work around older versions of Getopt::Long that
did not take negation of a boolean "--option" as "--no-option" (but
they happily took "--nooption").
I am inclined to squash this into the previous one.
Signed-off-by: Junio C Hamano
---
t/t9001-send-email.sh | 10 +-
1
On 02/13/2015 08:12 PM, Junio C Hamano wrote:
> [...]
> As we are trying to see a way to move forward to do the right thing
> around reflog, I was wondering if locking only the symbolic ref is a
> sensible endgame. "The right thing" being:
>
>When a symbolic ref S points at underlying ref R,
On Fri, Feb 13, 2015 at 11:30:53AM -0800, Junio C Hamano wrote:
> > This case collapses nicely if we make a slight tweak to your proposed
> > behavior (or maybe this is what you meant). If there are multiple
> > authors listed, we behave as if none was listed. That would leave the
> > authorship a
Mike Hommey writes:
> A remote helper is currently only told about the 'check-connectivity',
> 'cloning', and 'update-shallow' options when it supports the 'fetch'
> command, but not when it supports 'import' instead.
Sounds sensible.
Does the same issue exist for export vs push or do they happ
Jeff King writes:
> On Thu, Feb 12, 2015 at 03:32:37PM -0800, Junio C Hamano wrote:
>
>> > It also raises a question for the proposal in this thread: if there are
>> > multiple "Author:" lines, which one do we take? The first, or the last?
>>
>> I was siding with David's "pay attention to in-buf
Karsten Blees writes:
> Am 13.02.2015 um 00:38 schrieb Junio C Hamano:
>>
>> We do have sec/nsec fields in cache_time structure, so I have
>> nothing against updating the msysGit port to fill that value.
Having said that, we do not enable the NSEC stuff by default on Unix
for a reason. I'd exp
I encountered some unexpected behavior with Git today and was hoping
to either a) clear up my misconception or b) make a bug report.
My question deals with the --exclude-from option to git-ls-files. It
appears that paths passed to this option are relative to the root of
the repository, not your c
Stefan Beller writes:
> On Fri, Feb 13, 2015 at 10:26 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano wrote:
>>>
We convinced ourselves that not locking the symref is wrong, but
have we actually convinced us that not locking
On Fri, Feb 13, 2015 at 10:26 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano wrote:
>>
>>> We convinced ourselves that not locking the symref is wrong, but
>>> have we actually convinced us that not locking the underlying ref,
>>> as long
Michael Haggerty writes:
> On 02/12/2015 06:32 PM, Junio C Hamano wrote:
>> On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty
>> wrote:
>>> Instead, verify the reference's old value if and only if old_sha1 is
>>> non-NULL.
>>>
>>> ...
>>> @@ -3664,9 +3664,6 @@ int ref_transaction_update(struct
Stefan Beller writes:
> On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano wrote:
>
>> We convinced ourselves that not locking the symref is wrong, but
>> have we actually convinced us that not locking the underlying ref,
>> as long as we have a lock on the symref, is safe?
>>
>> To protect you, t
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I also realized that Git's current policy is probably not tenable if one
>> process is re-seating a symref at the same time as another process is
>> expiring its reflog. The "git reflog expire HEAD" might grab
Michael Haggerty writes:
> I also realized that Git's current policy is probably not tenable if one
> process is re-seating a symref at the same time as another process is
> expiring its reflog. The "git reflog expire HEAD" might grab
> "refs/heads/master.lock" then start rewriting "logs/HEAD". M
On Fri, Feb 13, 2015 at 8:26 AM, Michael Haggerty wrote:
>
> What is the best way forward?
>
> Switching to holding only "HEAD.lock" while updating "logs/HEAD" is the
> right solution, but it would introduce an incompatibility with old
> versions of Git and libgit2 (and maybe JGit?) Probably nobod
On 02/12/2015 06:32 PM, Junio C Hamano wrote:
> On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty
> wrote:
>> Instead, verify the reference's old value if and only if old_sha1 is
>> non-NULL.
>>
>> ...
>> @@ -3664,9 +3664,6 @@ int ref_transaction_update(struct ref_transaction
>> *transaction,
>>
Let's say I have a submodule set to directory "foo". If I remove this
submodule in 1 commit (git rm -f foo) and then in a 2nd commit after
that, physically commit those files, the next person that does a `git
submodule update --recursive` results in failure because it says it
can't overwrite files.
On 02/12/2015 07:04 PM, Stefan Beller wrote:
> On Thu, Feb 12, 2015 at 8:52 AM, Michael Haggerty
> wrote:
>> However, another important question is whether other Git implementations
>> have copied this unusual locking policy. If so, that would be a reason
>> not to change it. I just pinged the li
Dear Professor
I would like to ask you if you have uploaded your Invited Paper in our
conferences
in Vienna, Austria, March 15-17, 2015: www.inase.org
Invited Authors have a special privileged position in the conference program
with
double time for their presentation. The number of Invited Pap
deheader (git://gitorious.org/deheader/deheader.git) found out that
some .c files #include twice one and the same header file.
This patch removes such occurrences and hence speeds up the compilation.
Signed-off-by: Дилян Палаузов
---
builtin/fetch.c| 1 -
trailer.c | 1 -
transport
On 02/12/2015 10:54 PM, Jeff King wrote:
> On Mon, Feb 09, 2015 at 10:12:42AM +0100, Michael Haggerty wrote:
>
>> if (!(flags & EXPIRE_REFLOGS_DRY_RUN)) {
>> +/*
>> + * It doesn't make sense to adjust a reference pointed
>> + * to by a symbolic ref based on
On 2015/02/13 3:58AM Joachim Schmitz wrote:
>Jeff King peff.net> writes:
> > On Fri, Feb 13, 2015 at 02:44:03AM -0500, Jeff King wrote:
> > On Thu, Feb 12, 2015 at 03:31:12PM -0500, Randall S. Becker wrote:
> >
>
>> Hmm, today I learned something new about ksh. Apparently when you use
>> the "fu
After taking 1.5 years "vacation" from pack v4, I plan to do something
about it again. Will post more when I have some patches to discuss.
Only one question for now (forgive me if I asked already, it's been
quite some time)
I think pack v4 does not deliver its best promise that walking a tree
is s
On Fri, Feb 13, 2015 at 5:57 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> These patches are on top of what's in 'pu'. They add
>> --ignore-other-worktrees and make a note about current submodule
>> support status. I don't think submodule support is ready yet even
>> with Max Kir
Hi,
I was running some test with Git 1.8.4.5, then I accidentally met a
problem that leaded to the following error,
> > error: refs/heads/develop does not point to a valid object!
Turns out that the sha in refs/heads/develop is a bad object id, this
happened after merging a branch X to branch de
On Thu, Feb 12, 2015 at 12:32:45PM +, Daniel Devlin wrote:
> tag_contents =
> "object f849f9e28c7f36a826d4b451efb16516c0c3acc2\ntype #{type}\ntag #
> {tagname}\ntagger #{username} <#{email}> #{Time.new.to_i} +\n\n#{message}"
> [...]
> executecommand = "printf \"#{tag_contents}\" | git mkt
On do, 2015-02-12 at 14:57 -0800, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > These patches are on top of what's in 'pu'. They add
> > --ignore-other-worktrees and make a note about current submodule
> > support status. I don't think submodule support is ready yet even
> > with Ma
Jeff King peff.net> writes:
>
> On Fri, Feb 13, 2015 at 02:44:03AM -0500, Jeff King wrote:
>
> > On Thu, Feb 12, 2015 at 03:31:12PM -0500, Randall S. Becker wrote:
> >
> Hmm, today I learned something new about ksh. Apparently when you use
> the "function" keyword to define a function like:
On Fri, Feb 13, 2015 at 02:44:03AM -0500, Jeff King wrote:
> On Thu, Feb 12, 2015 at 03:31:12PM -0500, Randall S. Becker wrote:
>
> > On the NonStop port, we found that trap was causing an issue with test
> > success for t5570. When start_git_daemon completes, the shell (ksh,bash) on
> > this p
48 matches
Mail list logo
