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 platform
Jeff King peff at 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:
snip
Hmm, today I learned something new about ksh. Apparently when you use
the function keyword to define a function like:
On do, 2015-02-12 at 14:57 -0800, Junio C Hamano wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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 mktag
[...]
On Fri, Feb 13, 2015 at 5:57 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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
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
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: Дилян Палаузов git-...@aegee.org
---
builtin/fetch.c| 1 -
trailer.c
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 expiring
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
On 02/12/2015 07:04 PM, Stefan Beller wrote:
On Thu, Feb 12, 2015 at 8:52 AM, Michael Haggerty mhag...@alum.mit.edu
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
On 02/12/2015 06:32 PM, Junio C Hamano wrote:
On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty mhag...@alum.mit.edu
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
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.
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/12/2015 06:32 PM, Junio C Hamano wrote:
On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Instead, verify the reference's old value if and only if old_sha1 is
non-NULL.
...
@@ -3664,9 +3664,6 @@ int
On Fri, Feb 13, 2015 at 10:26 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com wrote:
We convinced ourselves that not locking the symref is wrong, but
have we actually convinced us that not
Stefan Beller sbel...@google.com writes:
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com 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
On Fri, Feb 13, 2015 at 8:26 AM, Michael Haggerty mhag...@alum.mit.edu 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?)
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Jeff King p...@peff.net 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
Mike Hommey m...@glandium.org 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
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 gits...@pobox.com
---
t/t9001-send-email.sh | 10
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, and if
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
Stefan Beller sbel...@google.com writes:
On Fri, Feb 13, 2015 at 10:26 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com wrote:
We convinced ourselves that not locking the symref is wrong,
Karsten Blees karsten.bl...@gmail.com 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
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
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 as it
From: Kyle J. McKay mack...@gmail.com
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'
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::Long
Daniel Finnie d...@danfinnie.com 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
On Fri, Feb 13, 2015 at 11:36:24AM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org 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'
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
Stefan Beller sbel...@google.com 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
On Fri, Feb 13, 2015 at 1:56 PM, Stefan Beller sbel...@google.com 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.
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:
Дилян Палаузов git-...@aegee.org writes:
Junio C Hamano gits...@pobox.com 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
Michael Haggerty mhag...@alum.mit.edu 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
On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com 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
Daniel Finnie d...@danfinnie.com writes:
Do you have any comments on why the path in --exclude-from=path 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
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 linux
Дилян Палаузов git-...@aegee.org 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
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 sbel...@google.com
---
hex.c | 2 +-
1 file changed, 1
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
Stefan Beller sbel...@google.com writes:
On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com 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
On 2015/02/13 3:58AM Joachim Schmitz wrote:
Jeff King peff at 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:
snip
Hmm, today I learned something new about ksh. Apparently when you use
the
On 02/13/2015 10:53 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
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, this
48 matches
Mail list logo
