Hi all, thanks for providing your feedback.
On Sun, Mar 15, 2015 at 6:14 AM, Junio C Hamano wrote:
> I am not sure if this is not a premature over-engineering---I am not
> convinced that such a future need will be fulfilled by passing just
> a single default_fn this version already passes, or it
Right now we return a NULL "struct sha1file" if we encounter
an error. However, the sole caller (write_idx_file) does not
check the return value, and will segfault if we hit this
case.
One option would be to handle the error in the caller.
However, there's really nothing for it to do but die. This
Because "--graph" is about connected history while --no-walk
is about discrete points, it does not make sense to allow
giving these two options at the same time. [1]
This change makes a few calls to "show --graph" fail in
t4052, but asking to show one commit with graph is a
nonsensical thing to do
Hi
I am trying to find a way of using version control on PLC programmers like
Allen Bradley PLC. I can't find a way of this.
Could you please give me an idea if it will work with Plc programs. Which are
basically Ladder logic.
Sent from my iPad--
To unsubscribe from this list: send the line "
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
On Tue, Mar 17, 2015 at 7:18 PM, Junio C Hamano wrote:
> Dongcan Jiang writes:
>> diff --git a/t/t4052-stat-output.sh b/t/t4052-stat-output.sh
>> index b68afef..a989e8f 100755
>> --- a/t/t4052-stat-output.sh
>> +++ b/t/t4052-stat-output.sh
>> @@ -99,7 +99,7 @@ do
>> test_cmp "$expec
Dongcan Jiang writes:
> Because "--graph" is about connected history while --no-walk
> is about discrete points, it does not make sense to allow
> giving these two options at the same time. [1]
>
> This change makes a few calls to "show --graph" fail in
> t4052, but asking to show one commit with
On Tue, Mar 17, 2015 at 11:00 PM, Michael Haggerty wrote:
> Michael Haggerty (14):
> numparse: new module for parsing integral numbers
> cacheinfo_callback(): use convert_ui() when handling "--cacheinfo"
> write_subdirectory(): use convert_ui() for parsing mode
> handle_revision_opt(): use
Jeff King writes:
> But it strikes me as weird that we consider the _tips_ of history to be
> special for ignoring breakage. If the tip of "bar" is broken, we omit
> it. But if the tip is fine, and there's breakage three commits down in
> the history, then doing a clone is going to fail horribly,
Michael Haggerty writes:
> On 03/06/2015 06:08 AM, Torsten Bögershausen wrote:
>> On 03/05/2015 05:07 PM, Michael Haggerty wrote:
>>> One likely reason for fdopen() to fail is the lack of memory for
>>> allocating a FILE structure. When that happens, try freeing some
>>> memory and calling fdopen
Kenny Lee Sin Cheong writes:
> On Tue, Mar 17 2015 at 02:49:48 AM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> if (try to see if it is a revision or regvision range) {
>> /* if failed ... */
>> if (starts with '-') {
>> do the option
At my workplace, the team is using Atlassian Stash + git
We have a "Core" library that is our common code between various
projects. To avoid a single monolithic repository and to allow our
apps and tools to be modularized into their own repos, I have
considered moving Core to a subtree or submodul
On Tue, Mar 17 2015 at 02:49:48 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> if (try to see if it is a revision or regvision range) {
> /* if failed ... */
> if (starts with '-') {
> do the option thing;
> c
kara,
On Tue, Mar 17, 2015, at 17:05, Junio C Hamano wrote:
> If you check the output from
>
> git diff 30a52c1d^ 30a52c1d
>
> and find it appropriately address the problem you originally had,
> that would be wonderful, and if you can suggest further improvement,
> that is equally good.
Ind
Ryan Lortie writes:
> On Tue, Mar 17, 2015, at 16:49, Junio C Hamano wrote:
>> With more recent versions of Git, namely, the versions after
>> 30a52c1d (Merge branch 'ms/submodule-update-config-doc' into maint,
>> 2015-03-13), the documentation pages already have updated
>> descriptions around th
On Tue, Mar 17, 2015, at 16:49, Junio C Hamano wrote:
> With more recent versions of Git, namely, the versions after
> 30a52c1d (Merge branch 'ms/submodule-update-config-doc' into maint,
> 2015-03-13), the documentation pages already have updated
> descriptions around this area.
sigh.
That's what
Ryan Lortie writes:
> 'man git-submodule' contains mention (in one place) that:
>
> Setting the key submodule.$name.update to !command
> will cause command to be run.
>
> This is not documented in 'man gitmodules' (which documents the other
> possible values for the 'update' key)
Yes, th
On Tue, Mar 17, 2015, at 15:50, Jeff King wrote:
> Yeah, spelling out the security model more explicitly would be good.
Please see the attached patch.
Cheers
0001-docs-clarify-command-submodule-update-policy.patch
Description: Binary data
Christian Couder writes:
> On Tue, Mar 17, 2015 at 7:33 PM, Junio C Hamano wrote:
>> Christian Couder writes:
>>
>>> Yes, but the user is supposed to not change the "bad" pointer for no
>>> good reason.
>>
>> That is irrelevant, no? Nobody is questioning that the user is
>> supposed to judge i
Christian Couder writes:
> On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller wrote:
>> On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup wrote:
>>>
>>> "Git Annotate"?
>>
>> "Git Praise" as opposed to blame?
>> "Git Who" as a pun on the subcommand structure which doesn't always
>> follows grammar?
>
On Sun, Mar 15, 2015 at 11:18 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> I wrote something about a potential Git Rev News news letter:
>
> I read it. Sounds promising.
Thanks!
[...]
> I obviously do not know how the actual contents would look like at
> this point, but depending
Karthik Nayak writes:
> Subject: Re: [PATCH v4 2/2] sha1_file: refactor sha1_file.c to support
> 'cat-file --literally'
> Modify sha1_loose_object_info() to support 'cat-file --literally'
> by accepting flags and also make changes to copy the type to
> object_info::typename.
It would be more d
On Mon, Mar 16, 2015 at 6:06 PM, Stefan Beller wrote:
> On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup wrote:
>>
>> "Git Annotate"?
>
> "Git Praise" as opposed to blame?
> "Git Who" as a pun on the subcommand structure which doesn't always
> follows grammar?
Yeah these suggestions above are nice
On Tue, Mar 17, 2015 at 10:43 AM, Thomas Ferris Nicolaisen
wrote:
> On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder
> wrote:
>>
>> I wrote something about a potential Git Rev News news letter:
>>
>> https://github.com/git/git.github.io/pull/15
>>
>
> I would love to have/use something like this
On Tue, Mar 17, 2015 at 03:28:57PM -0400, Ryan Lortie wrote:
> The first is a question about git's basic policy with respect to things
> like this. I hope that it's safe to assume that running 'git' commands
> on repositories downloaded from potentially-hostile places will never
> result in the a
On Tue, Mar 17, 2015 at 7:33 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> On Mon, Mar 16, 2015 at 10:05 PM, Junio C Hamano wrote:
>>
>>> However, you can say "git bisect bad " (and "git bisect good
>>> " for that matter) on a rev that is unrelated to what the
>>> current bisection s
On 03/17/2015 07:48 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> When I looked around, I found scores of sites that call atoi(),
>> strtoul(), and strtol() carelessly. And it's understandable. Calling
>> any of these functions safely is so much work as to be completely
>> impractical
karaj,
'man git-submodule' contains mention (in one place) that:
Setting the key submodule.$name.update to !command
will cause command to be run.
This is not documented in 'man gitmodules' (which documents the other
possible values for the 'update' key) nor in 'man git-config' which also
On Tue, Mar 17, 2015 at 07:34:02PM +0100, Johannes Sixt wrote:
> Am 17.03.2015 um 08:28 schrieb Jeff King:
> >+test_expect_success 'create history reachable only from a bogus-named ref' '
> >+test_tick && git commit --allow-empty -m master &&
> >+base=$(git rev-parse HEAD) &&
> >+test_
Michael Haggerty writes:
> When I looked around, I found scores of sites that call atoi(),
> strtoul(), and strtol() carelessly. And it's understandable. Calling
> any of these functions safely is so much work as to be completely
> impractical in day-to-day code.
>
> git-compat-util.h has two fun
Johannes Schindelin writes:
> Therefore, I would wager a bet that just the mere conversion of a
> shell script into even a primitive `run_command()`-based builtin would
> help performance on Windows in a noticeable manner.
As you correctly allege, if a patch rewrote a shell-scripted
porcelain by
Christian Couder writes:
> On Mon, Mar 16, 2015 at 10:05 PM, Junio C Hamano wrote:
>
>> However, you can say "git bisect bad " (and "git bisect good
>> " for that matter) on a rev that is unrelated to what the
>> current bisection state is. E.g. after you mark the child of 8 as
>> "bad", the bi
Am 17.03.2015 um 08:28 schrieb Jeff King:
+test_expect_success 'create history reachable only from a bogus-named ref' '
+ test_tick && git commit --allow-empty -m master &&
+ base=$(git rev-parse HEAD) &&
+ test_tick && git commit --allow-empty -m bogus &&
+ bogus=$(git re
On di, 2015-03-17 at 13:19 -0400, Patrice Monette wrote:
>
> I did not find any config, but is there one configuration somewhere to
> preserve the real date creation by author somewhere?
No, there is no such configuration as git does not track timestamps of
files.
--
Dennis Kaarsemaker
www.kaars
Duy Nguyen writes:
> On Mon, Mar 16, 2015 at 09:05:45AM -0700, Junio C Hamano wrote:
>> The offending one came from eec3e7e4 (cache-tree: invalidate i-t-a
>> paths after generating trees, 2012-12-16), which was a fix to an
>> earlier bug where a cache-tree written out of an index with i-t-a
>> en
I have address the following question to github support and the refer me to git
documentation but I`m not too familiar with Git right now. Here`s my question:
I did not find any config, but is there one configuration somewhere to preserve
the real date creation by author somewhere?
Thanks in a
On Mon, Mar 16, 2015 at 10:05 PM, Junio C Hamano wrote:
> "Philip Oakley" writes:
>
>> From: "Junio C Hamano"
>>
>>> Hence, if you have a history that looks like this:
>>>
>>>
>>> G...1---2---3---4---6---8---B
>>>\
>>> 5---7---B
>>>
>>> it follows that 4
If an argument is there, but it can't be parsed as a non-positive
number, then die() rather than returning 0.
Signed-off-by: Michael Haggerty
---
diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 77c7acb..03cdabf 100644
--- a/diff.c
+++ b/diff.c
This adds error checking, where previously there was none. It also
disallows '+' and '-', leading whitespace, and trailing junk.
Signed-off-by: Michael Haggerty
---
revision.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index 4908e66..a6f7c2e 100
die() with an error message if the argument is not a non-negative
integer. This change tightens up parsing: '+' and '-', leading
whitespace, and trailing junk are all disallowed now.
Signed-off-by: Michael Haggerty
---
diff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
opt_arg() is never called with val set to NULL, so remove the code for
handling that eventuality (which anyway wasn't handled consistently in
the function).
Signed-off-by: Michael Haggerty
---
diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index a35067
This tightens up the parsing a bit:
* Leading whitespace is no longer allowed
* '+' and '-' are no longer allowed
It also removes the need to check separately that max_count is
non-negative.
Signed-off-by: Michael Haggerty
---
revision.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-
die() with an error message if the argument is not a non-negative
integer. This change tightens up parsing: '+' and '-', leading
whitespace, and trailing junk are all disallowed now.
Signed-off-by: Michael Haggerty
---
diff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
This shortens the code and avoids the old code's careless truncation
from unsigned long to int.
Signed-off-by: Michael Haggerty
---
diff.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/diff.c b/diff.c
index 6e3f498..77c7acb 100644
--- a/diff.c
Implement wrappers for strtol() and strtoul() that are safer and more
convenient to use.
Signed-off-by: Michael Haggerty
---
Makefile | 1 +
numparse.c | 180 +
numparse.h | 207 +
Increment "arg" when a character is consumed, not just before consuming
the next character.
Signed-off-by: Michael Haggerty
---
diff.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/diff.c b/diff.c
index 03cdabf..bc1e3c3 100644
--- a/diff.c
+++ b/diff.c
@@ -3358,14 +
The previous code used strtoul() without any checks that it succeeded.
Instead use convert_l(), in strict mode, and die() if there is an
error. This tightens up the parsing:
* Leading whitespace is no longer allowed
* '+' and '-' are no longer allowed
* Trailing junk is not allowed
Signed-off-by:
This reduces the need for "magic numbers".
Signed-off-by: Michael Haggerty
---
revision.c | 59 ++-
1 file changed, 30 insertions(+), 29 deletions(-)
diff --git a/revision.c b/revision.c
index 66520c6..25838fc 100644
--- a/revision.c
+++ b
Use convert_ui() instead of strtoul_ui() when parsing tree entries'
modes. This tightens up the parsing a bit:
* Leading whitespace is no longer allowed
* '+' and '-' are no longer allowed
Signed-off-by: Michael Haggerty
---
contrib/convert-objects/convert-objects.c | 3 ++-
1 file changed, 2 i
Their callers have been changed to use the numparse module.
Signed-off-by: Michael Haggerty
---
git-compat-util.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index a3095be..cbe7f16 100644
--- a/git-compat-util.h
+++ b/git-c
Sorry for the long email. Feel free to skip over the background info
and continue reading at "My solution" below.
This odyssey started with a typo:
$ git shortlog -snl v2.2.0..v2.3.0
14795 Junio C Hamano
1658 Jeff King
1400 Shawn O. Pearce
1109 Linus
Use convert_ui() instead of strtoul_ui() to parse the argument.
This tightens up the parsing a bit:
* Leading whitespace is no longer allowed
* '+' and '-' are no longer allowed
Signed-off-by: Michael Haggerty
---
builtin/update-index.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Mon, Mar 16, 2015 at 09:05:45AM -0700, Junio C Hamano wrote:
> The offending one came from eec3e7e4 (cache-tree: invalidate i-t-a
> paths after generating trees, 2012-12-16), which was a fix to an
> earlier bug where a cache-tree written out of an index with i-t-a
> entries had incorrect informa
The git-pull command is currently implemented by the shell script
git-pull.sh. However, git-pull.sh suffers from some problems:
* Inconsistent command line interface: since git-pull.sh does not use
git's internal parse-options API, it's command line interface is
inconsistent with other git bui
On March 17, 2015 12:21:33 PM GMT+05:30, Eric Sunshine
wrote:
>On Tue, Mar 17, 2015 at 1:16 AM, Karthik Nayak
>wrote:
>> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
>> index df99df4..1625246 100644
>> --- a/builtin/cat-file.c
>> +++ b/builtin/cat-file.c
>> @@ -323,8 +338,8 @@ static i
> C Git is not the only client that can talk to upload-pack. A buggy
> client may send both. The least we need is make sure it would not
> crash or break the server security in any way. But if we have to
> consider that, we may as well reject with a clear message, which would
> help the client writ
Hi Paul,
On 2015-03-17 01:22, Paul Tan wrote:
> On Tue, Mar 17, 2015 at 12:49 AM, Yurii Shevtsov wrote:
>
> Generally, it would be easy to convert any shell script to C by just
> using the run_command* functions (and in less lines of code), but that
> would not be taking advantage of the potenti
On Mon, Mar 16, 2015 at 11:10 PM, Dongcan Jiang wrote:
> Hi Duy,
>
> Sorry for my late response.
>
>> we need to make sure that upload-pack barf if some client sends both
>> "deepen" and
>> "depth".
>
> Actually, in my current design, when client just wants "depth", it
> sends "depth N";
> when i
On Sun, Mar 15, 2015 at 9:46 AM, Christian Couder
wrote:
>
> I wrote something about a potential Git Rev News news letter:
>
> https://github.com/git/git.github.io/pull/15
>
I would love to have/use something like this in the GitMinutes
podcast. Perhaps in addition to the very random interview fo
On Tue, Mar 17, 2015 at 09:18:26AM +0100, Patrick Steinhardt wrote:
> Is it even possible to create a new submodule without any
> upstream repository? At least `git submodule init` does not work
> without a corresponding entry in .gitmodules which the user would
> have needed to create himself manu
On Mon, Mar 16, 2015 at 08:55:03AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt writes:
>
> > I think there should be a command that is able to remove those
> > dangling repositories if the following conditions are met:
> >
> > - the submodule should not be initialized
> >
> > - the submodul
On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote:
> (+cc: Jens and Heiko, submodule experts)
> Hi,
>
> Patrick Steinhardt wrote:
>
> > This proposal is just for discussion. If there is any interest I
> > will implement the feature and send some patches.
> >
> > Currently it is hard
On Tue, Mar 17, 2015 at 03:27:50AM -0400, Jeff King wrote:
> The general strategy for these is to use for_each_rawref traversals in
> these situations. That doesn't cover _every_ possible scenario. For
> example, you could do:
>
> git clone --no-local repo.git backup.git &&
> rm -rf repo.git
When we delete a ref, we have to rewrite the entire
packed-refs file. We take this opportunity to "curate" the
packed-refs file and drop any entries that are crufty or
broken.
Dropping broken entries (e.g., with bogus names, or ones
that point to missing objects) is actively a bad idea, as it
mean
If we are repacking with "-ad", we will drop any unreachable
objects. Likewise, using "-Ad --unpack-unreachable="
will drop any old, unreachable objects. In these cases, we
want to make sure the reachability we compute with "--all"
is complete. We can do this by passing GIT_REF_PARANOIA=1 in
the en
Prune should know about broken objects at the tips of refs,
so that we can feed them to our traversal rather than
ignoring them. It's better for us to abort the operation on
the broken object than it is to start deleting objects with
an incomplete view of the reachability namespace.
Note that for
Most operations that iterate over refs are happy to ignore
broken cruft. However, some operations should be performed
with knowledge of these broken refs, because it is better
for the operation to choke on a missing object than it is to
silently pretend that the ref did not exist (e.g., if we are
c
When we are doing a destructive operation like "git prune",
we want to be extra careful that the set of reachable tips
we compute is valid. If there is any corruption or oddity,
we are better off aborting the operation and letting the
user figure things out rather than plowing ahead and
possibly de
This is a grab bag of fixes related to performing destructive operations
in a repository with minor corruption. Of course we hope never to see
corruption in the first place, but I think if we do see it, we should
err on the side of not making things worse. IOW, it is better to abort
and say "fix th
69 matches
Mail list logo
