Dear Invited Author,
Have you uploaded your invited paper for our conferences in Barcelona, Spain
7-9 April 2015? If not, kindly, upload now your INVITED paper via www. inase.
org until
March 20, 2015.
We have collaboration with 36 Journals, all with Impact Factor from ISI
(Thomson Reuters)
an
Jeff King writes:
> I wondered if we could do away with the radix entirely. Wouldn't we be
> asking for base 10 most of the time? Of course, your first few patches
> show octal parsing, but I wonder if we should actually have a separate
> parse_mode() for that, since that seems to be the general
Michael Haggerty writes:
> 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 i
Michael Haggerty writes:
> 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.
Hmmm, on the surface this sound nice, but I am not sure if it is a
Michael Haggerty writes:
> Here were my thoughts:
>
> * I wanted to change the interface to look less like
> strtol()/strtoul(), so it seemed appropriate to make the names
> more dissimilar.
One reason I prefer the names in the compat-util is that it makes it
clear that what is converted int
Michael Haggerty writes:
> * It allows leading whitespace.
This might be blessing in disguise. Our friends on MacOS may be
relying on that
git cmd --abbrev="$(wc -c * It allows arbitrary trailing characters.
Which is why we have introduced strtoul_ui() and such.
> * It allows a leading
Junio C Hamano writes:
> Ah, wait.
>
> I suspect that it all cancels out.
> ...
> Now, as you mentioned, there _may_ be codepaths that uses the same
> definition of "what's in the index" as what diff-cache used to take
> before your patches, and they may be broken by removing the
> invalidation.
On Tue, Mar 17, 2015 at 05:00:02PM +0100, Michael Haggerty wrote:
> My main questions:
>
> * Do people like the API? My main goal was to make these functions as
> painless as possible to use correctly, because there are so many
> call sites.
>
> * Is it too gimmicky to encode the base togeth
On Thu, Mar 19, 2015 at 11:29:57AM +0700, Duy Nguyen wrote:
> > That omits the "N objects left over" information. Which I think may be
> > useful, because otherwise the rule is basically "don't do another gc at
> > all for X time units". That's OK for most use, but it has its own corner
> > cases.
On Thu, Mar 19, 2015 at 11:20 AM, Jeff King wrote:
> On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
>
>> On Thu, Mar 19, 2015 at 8:27 AM, Jeff King wrote:
>> > Keeping a file that says "I ran gc at time T, and there were still N
>> > objects left over" is probably the best bet. When
On Thu, Mar 19, 2015 at 12:14:53AM -0400, Jeff King wrote:
> On Thu, Mar 19, 2015 at 11:01:17AM +0900, Mike Hommey wrote:
>
> > > I don't think packing the unreachables is a good plan. They just end up
> > > accumulating then, and they never expire, because we keep refreshing
> > > their mtime at
On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
> On Thu, Mar 19, 2015 at 8:27 AM, Jeff King wrote:
> > Keeping a file that says "I ran gc at time T, and there were still N
> > objects left over" is probably the best bet. When the next "gc --auto"
> > runs, if T is recent enough, subt
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King wrote:
> Keeping a file that says "I ran gc at time T, and there were still N
> objects left over" is probably the best bet. When the next "gc --auto"
> runs, if T is recent enough, subtract N from the estimated number of
> objects. I'm not sure of the ri
On Thu, Mar 19, 2015 at 11:01:17AM +0900, Mike Hommey wrote:
> > I don't think packing the unreachables is a good plan. They just end up
> > accumulating then, and they never expire, because we keep refreshing
> > their mtime at each pack (unless you pack them once and then leave them
> > to expir
On Wed, Mar 18, 2015 at 07:27:46PM -0700, Junio C Hamano wrote:
> > I guess leaving a bunch of loose objects around longer than necessary
> > isn't the end of the world. It wastes space, but it does not actively
> > make the rest of git slower (whereas having a large number of packs does
> > impac
On Wed, Mar 18, 2015 at 6:27 PM, Jeff King wrote:
>
> Keeping a file that says "I ran gc at time T, and there were still N
> objects left over" is probably the best bet. When the next "gc --auto"
> runs, if T is recent enough, subtract N from the estimated number of
> objects. I'm not sure of the
On Wed, Mar 18, 2015 at 09:27:22PM -0400, Jeff King wrote:
> On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote:
>
> > Or we could count/estimate the number of loose objects again after
> > repack/prune. Then we can maybe have a way to prevent the next gc that
> > we know will not improve
On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote:
> Or we could count/estimate the number of loose objects again after
> repack/prune. Then we can maybe have a way to prevent the next gc that
> we know will not improve the situation anyway. One option is pack
> unreachable objects in the
On Thu, Mar 19, 2015 at 4:04 AM, Jeff King wrote:
> On Wed, Mar 18, 2015 at 02:58:15PM +, John Keeping wrote:
>
>> On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
>> > On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen wrote:
>> > > If not, I made some mistake in analyzing this and we'll
On Wed, Mar 18, 2015 at 3:20 AM, Chris Packham wrote:
> My $0.02 based on $dayjob
>
> (disclaimer I've never used subtree)
>
> On Wed, Mar 18, 2015 at 11:14 AM, Robert Dailey
> wrote:
>> At my workplace, the team is using Atlassian Stash + git
>>
>> We have a "Core" library that is our common cod
Duy Nguyen writes:
> Right. I missed this but I think this is a less important test
> because I added a new test to make sure "diff --cached" ("git
> status" to be exact) outputs the right thing when i-t-a entries
> are present.
OK.
>> If on the other hand the tests show the same result from th
Paul Tan writes:
> +/* Global vars since they are used often */
> +static char *head_name;
> +static const char *head_name_short;
> +static unsigned char head_sha1[20];
> +static int head_flags;
> +
> +enum rebase_type {
> + REBASE_FALSE = 0,
> + REBASE_TRUE = 1,
> + REBASE_PRESERVE =
On 03/18/2015 07:27 PM, Eric Sunshine wrote:
> On Tuesday, March 17, 2015, Michael Haggerty wrote:
>> Implement wrappers for strtol() and strtoul() that are safer and more
>> convenient to use.
>>
>> Signed-off-by: Michael Haggerty
>> ---
>> diff --git a/numparse.c b/numparse.c
>> new file mode 1
On March 18, 2015 6:29 PM Doug Kelly wrote:
> On Wed, Mar 18, 2015 at 2:53 PM, Randall S. Becker
> wrote:
> > On March 17, 2015 7:34 PM, Bharat Suvarna wrote:
> >> 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
On Wed, Mar 18, 2015 at 2:53 PM, Randall S. Becker
wrote:
> On March 17, 2015 7:34 PM, Bharat Suvarna wrote:
>> 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
On Wed, Mar 18, 2015 at 2:33 PM, Junio C Hamano wrote:
> What does the Icon^M try to catch, exactly? Is it a file? Is it a directory?
> Is it "anything that begins with Icon^M"?
It seems to be a special hidden file on Macs for UI convenience.
> On Apr 25, 2005, at 6:21 AM, Peter N. Lundblad wrot
On Wed, Mar 18, 2015 at 2:28 PM, Jeff King wrote:
> On Wed, Mar 18, 2015 at 05:17:16PM -0400, Jeff King wrote:
>
>> [1] The double-CR fix works because we strip a single CR from the end of
>> the line (as a convenience for CRLF systems), and then the remaining
>> CR is syntactically signif
On Sun, Feb 08, 2015 at 09:36:43AM -0800, Jens Lehmann wrote:
> I wonder if it's worth all the hassle to invent new names. Wouldn't
> it be much better to just keep a list of per-worktree configuration
> value names and use that inside the config code to decide where to
> find them for multiple wor
On Wed, Mar 18, 2015 at 05:17:16PM -0400, Jeff King wrote:
> [1] The double-CR fix works because we strip a single CR from the end of
> the line (as a convenience for CRLF systems), and then the remaining
> CR is syntactically significant. But I am surprised that quoting
> like:
>
>
After http://thread.gmane.org/gmane.comp.version-control.git/261990
the only thing which did not enter the serie is these 2 pathes.
Should be applied over the patches by link, or
ecf2ff6ace6a1cc3d55b6f917be5452b5fb0c21b in current pu.
Max Kirillov (2):
submodule refactor: use git_path_submodule
Signed-off-by: Max Kirillov
---
submodule.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/submodule.c b/submodule.c
index 34094f5..4aad3d4 100644
--- a/submodule.c
+++ b/submodule.c
@@ -122,43 +122,35 @@ void stage_updated_gitmodules(void)
s
This allows making submodules a linked workdirs.
Same as for .git, but ignores the GIT_COMMON_DIR environment variable,
because it would mean common directory for the parent repository and
does not make sense for submodule.
Also add test for functionality which uses this call.
Signed-off-by: Max
On Wed, Mar 18, 2015 at 02:06:22PM -0700, Stefan Beller wrote:
> > Where did you get that file from? We need to find whoever is
> > responsible and notify them so that these users who are having
> > the issue will be helped.
>
> Given that this is part of https://github.com/github/gitignore
> whi
On Wed, Mar 18, 2015 at 12:41 PM, Matthieu Moy
wrote:
> Similarly to the "merge doc and code", I personally prefer seeing code
> and tests in the same patch.
In this case, the patch introducing the tests is already quite long
and intricate, almost to the point of being a burden to review.
Combini
On Wed, Mar 18, 2015 at 03:48:42PM +0100, Дилян Палаузов wrote:
> #ls .git/objects/17/* | wc -l
> 30
>
> 30 * 256 = 7 680 > 6 700
>
> And now? Do I have to run git gc --aggressive ?
No, aggressive just controls the time we spend on repacking. If the
guess is correct that the objects are kept
On Wed, Mar 18, 2015 at 1:45 PM, Junio C Hamano wrote:
> On Wed, Mar 18, 2015 at 1:33 PM, Alessandro Zanardi
> wrote:
>> Here are other sources describing the issue:
>>
>> http://stackoverflow.com/questions/21109672/git-ignoring-icon-files-because-of-icon-rule
>>
>> http://blog.bitfluent.com/post
On Wed, Mar 18, 2015 at 02:58:15PM +, John Keeping wrote:
> On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
> > On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen wrote:
> > > If not, I made some mistake in analyzing this and we'll start again.
> >
> > I did make one mistake, the first
On Wed, Mar 18, 2015 at 1:33 PM, Alessandro Zanardi
wrote:
> Here are other sources describing the issue:
>
> http://stackoverflow.com/questions/21109672/git-ignoring-icon-files-because-of-icon-rule
>
> http://blog.bitfluent.com/post/173740409/ignoring-icon-in-gitignore
>
> Sorry to bother the Git
Am 17.03.2015 um 19:55 schrieb Jeff King:
+ echo $bogus >.git/refs/heads/bogus..name &&
...
I assumed the final "." in your example wasn't significant (it is not to
git), but let me know if I've run afoul of another weird restriction. :)
It was actually deliberate (with intents too compli
On March 17, 2015 7:34 PM, Bharat Suvarna wrote:
> 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.
Many PLC progr
On 03/18/2015 01:40 AM, Junio C Hamano wrote:
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
On Wed, Mar 18, 2015 at 3:04 AM, Paul Tan wrote:
> t0302 now tests git-credential-store's support for the XDG user-specific
> configuration file $XDG_CONFIG_HOME/git/credentials. Specifically:
> ---
>
> The previous version can be found at [1].
>
> [1] http://thread.gmane.org/gmane.comp.version-co
On Wed, Mar 18 2015 at 04:29:44 AM, Sundararajan R wrote:
> Teaching reset the - shorthand involves checking if any file named '-' exists.
> check_filename() is used to perform this check.
>
> When the @{-1} branch does not exist then it can be safely assumed that the
> user is referring to the fi
We do not usually end our errors with a full stop, but it
looks especially bad when you use die_errno, which adds a
colon, like:
fatal: could not create work tree dir 'foo'.: No such file or directory
Signed-off-by: Jeff King
---
Not strictly related to the other patch, but I noticed it while
On Wed, Mar 18, 2015 at 07:00:13PM +0100, Wilhelm Schuermann wrote:
> When grep is called with the --quiet option, the pager is initialized
> despite not being used. When the pager is "less", anything output by
> previous commands and not ended with a newline is overwritten.
> [...]
> This patch
On Wed, Mar 18, 2015 at 11:03:30AM -0700, Spencer Nelson wrote:
> If you’re in a shell in a directory which no longer exists (because,
> say, another terminal removed it), then getcwd() will fail, at least
> on OS X Yosemite 10.10.2. In this case, git clone will fail. That’s
> totally reasonable.
On Tuesday, March 17, 2015, Michael Haggerty wrote:
> Implement wrappers for strtol() and strtoul() that are safer and more
> convenient to use.
>
> Signed-off-by: Michael Haggerty
> ---
> diff --git a/numparse.c b/numparse.c
> new file mode 100644
> index 000..90b44ce
> --- /dev/null
> +++ b
If you’re in a shell in a directory which no longer exists (because, say,
another terminal removed it), then getcwd() will fail, at least on OS X
Yosemite 10.10.2. In this case, git clone will fail. That’s totally reasonable.
If you invoke git clone with the git clone syntax, then will
When grep is called with the --quiet option, the pager is initialized
despite not being used. When the pager is "less", anything output by
previous commands and not ended with a newline is overwritten.
$ echo -n aaa; echo bbb
aaabbb
$ echo -n aaa; git grep -q foo; echo bbb
bbb
This can be worked
Hi,
First of all, thanks a lot for working on this. I'm rather impressed to
see a working proof of concept so soon! And impressed by the quality for
a "first draft".
A few minor remaks below after a very quick look.
Paul Tan writes:
> Ideally, I think the solution is to
> improve the test suit
Sundararajan R writes:
> Subject: [v3 PATCH 2/2] reset: add tests for git reset -
This should be [PATCH v3 2/2].
"git send-email -v2" can do this for you.
Sundararajan R writes:
> +test_expect_success 'reset - with no @{-1} branch and file named - should
> succeed' '
> + test_when_finis
Similarly to the "merge doc and code", I personally prefer seeing code
and tests in the same patch.
Actually, my preference goes for a first patch that introduces the tests
with test_expect_failure for things that are not yet implemented (and
you can check that tests do not pass yet before you cod
I would personnally prefer to see this squashed with PATCH 2/4: pushing
the "bisectable history" principle a bit, the state between patches 2
and 3 could be considered broken because the code does not do what the
documentation says. And as a reviewer, I like having pieces of docs
linked to the patc
Paul Tan writes:
> + /* Write credential to the filename specified by fns->items[0], thus
> + * creating it */
Just to show I'm following: misformatted multi-line comment.
Other than that, good job!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: se
It seems like submodule isn't picking up on the work tree that I'm
specifying. In the scenario that I'm working with, I'd prefer to not
have to "cd" into a directory to update the submodules. All the other
git subcommands that I'm executing work fine with specifying the git
dir and work tree via en
Got there eventually!
$ git verify-pack --verbose bar.pack
e13e21a1f49704ed35ddc3b15b6111a5f9b34702 commit 220 152 12
03691863451ef9db6c69493da1fa556f9338a01d commit 334 227 164
... snip ...
chain length = 50: 2 objects
bar.pack: ok
Now what do I do with it :)
On 18 March 2015 at 13:33, Duy Nguy
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
> On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen wrote:
> > If not, I made some mistake in analyzing this and we'll start again.
>
> I did make one mistake, the first "gc" should have reduced the number
> of loose objects to zero. Why didn'
Hello Duy,
#ls .git/objects/17/* | wc -l
30
30 * 256 = 7 680 > 6 700
And now? Do I have to run git gc --aggressive ?
Kind regards
Dilian
On 18.03.2015 15:33, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов
wrote:
Hello,
# git gc --auto
Auto packing the repository in
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen wrote:
> If not, I made some mistake in analyzing this and we'll start again.
I did make one mistake, the first "gc" should have reduced the number
of loose objects to zero. Why didn't it.? I'll come back to this
tomorrow if nobody finds out first :)
-
On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов
wrote:
> Hello,
>
> # git gc --auto
> Auto packing the repository in background for optimum performance.
> See "git help gc" for manual housekeeping.
>
> and calls in the background:
>
> 25618 1 0 32451 884 1 14:20 ?00:00:00 git gc -
Hello,
# git gc --auto
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
and calls in the background:
25618 1 0 32451 884 1 14:20 ?00:00:00 git gc --auto
25639 25618 51 49076 49428 0 14:20 ?00:00:07 git prune
On Wed, Mar 18, 2015 at 8:53 PM, Дилян Палаузов
wrote:
> Hello,
>
> I have a local folder with the git-repository (so that its .git/config
> contains ([remote "origin"]\nurl = git://github.com/git/git.git\nfetch =
> +refs/heads/*:refs/remotes/origin/* )
>
> I do there "git pull".
>
> Usually t
Hello,
I have a local folder with the git-repository (so that its .git/config
contains ([remote "origin"]\n url = git://github.com/git/git.git\nfetch
= +refs/heads/*:refs/remotes/origin/* )
I do there "git pull".
Usually the output is
Already up to date
but since today it prints
Auto pa
On Wed, Mar 18, 2015 at 8:16 PM, Graham Hay wrote:
> I created a repo with over 1GB of images, but it works as expected
> (only pushed 3 objects).
>
> Sorry, I must have done something wrong. I put that script in
> ~/Applications, and checked it worked. Then I ran this:
>
> $ GIT_TRACE=2 PATH=~/Ap
I created a repo with over 1GB of images, but it works as expected
(only pushed 3 objects).
Sorry, I must have done something wrong. I put that script in
~/Applications, and checked it worked. Then I ran this:
$ GIT_TRACE=2 PATH=~/Applications:$PATH git push --set-upstream origin git-wtf
12:48:28
On Wed, Mar 18, 2015 at 12:57 AM, Junio C Hamano wrote:
> 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
On Wed, Mar 18, 2015 at 7:26 PM, Duy Nguyen wrote:
> It's quite a lot of work :) I created this script named "git" and put
> it in $PATH to capture input for pack-objects. You'll need to update
> "/path/to/real/git" to point to the real binary then you'll get
> /tmp/stdin
Forgot one important sen
On Mon, Mar 16, 2015 at 8:18 PM, Mike Hommey wrote:
> On Mon, Mar 16, 2015 at 05:13:25PM +0700, Duy Nguyen wrote:
>> On Mon, Mar 16, 2015 at 3:05 PM, Mike Hommey wrote:
>> > Hi,
>> >
>> > git-verify-pack's man page says the following about --stat-only:
>> >
>> >Do not verify the pack contents
If a user does git checkout HEAD -- path/to/submodule they'd expect the
submodule to be checked out to the commit that submodule is at in HEAD.
This is the most brute force possible way of try to do that, and so its
probably broken in some cases. However I'm not terribly familiar with
git's intern
On Wed, Mar 18, 2015 at 7:03 PM, Graham Hay wrote:
> Are there any commands that I can use to show exactly what it is trying to
> push?
It's a bit more than a command. If you push when GIT_TRACE is set to
2, you'll see it executes "git pack-objects" command with all its
arguments. This command e
Are there any commands that I can use to show exactly what it is trying to push?
I'll see if I can create a (public) repo that has the same problem.
Thanks for your help.
> This 10804 looks wrong (i.e. sending that many compressed objects).
> Also "80 MiB" sent at that point. If you modify just
On 18.03.2015 10:42, Jeff King wrote:
On Wed, Mar 18, 2015 at 09:11:48AM +0100, Ephrim Khong wrote:
I have a non-bare repository /home/a set up with an alternate to the bare
repository /b. Running git gc on /home/a produces below's error
[...]
git --version
git version 2.3.0
Try v2.3.2. I
On Wed, Mar 18, 2015 at 6:26 PM, Graham Hay wrote:
>> It would help if you pasted the push output. For example, does it stop
>> at 20% at the "compressing objects" line or "writing objects". How
>> many total objects does it say?
>
> It rattles through "compressing objects", and the first 20% of
>
On Tue, Mar 17, 2015 at 11:33:54PM +, Bharat Suvarna wrote:
> 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 Lad
> It would help if you pasted the push output. For example, does it stop
> at 20% at the "compressing objects" line or "writing objects". How
> many total objects does it say?
It rattles through "compressing objects", and the first 20% of
"writing objects", then slows to a crawl.
Writing obje
On Wed, Mar 18, 2015 at 5:55 PM, Graham Hay wrote:
> We have a fairly large repo (~2.4GB), mainly due to binary resources
> (for an ios app). I know this can generally be a problem, but I have a
> specific question.
>
> If I cut a branch, and edit a few (non-binary) files, and push, what
> should
We have a fairly large repo (~2.4GB), mainly due to binary resources
(for an ios app). I know this can generally be a problem, but I have a
specific question.
If I cut a branch, and edit a few (non-binary) files, and push, what
should be uploaded? I assumed it was just the diff (I know whole
compr
On Tue, Mar 17, 2015 at 9:46 PM, Junio C Hamano wrote:
> 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,
On Tue, Mar 17, 2015 at 03:54:02PM -0700, Junio C Hamano wrote:
> 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 c
On 03/18/2015 11:03 AM, Jeff King wrote:
> On Wed, Mar 18, 2015 at 10:47:40AM +0100, Michael Haggerty wrote:
>
>> But in case you have some reason that you want upload-pack.c to be
>> converted right away, I just pushed that change (plus some related
>> cleanups) to my GitHub repo [1]. The branch
On Wed, Mar 18, 2015 at 10:47:40AM +0100, Michael Haggerty wrote:
> But in case you have some reason that you want upload-pack.c to be
> converted right away, I just pushed that change (plus some related
> cleanups) to my GitHub repo [1]. The branch depends only on the first
> patch of the "numpar
On Wed, Mar 18, 2015 at 4:47 PM, Michael Haggerty wrote:
>> Thank you for doing it. I was about to write another number parser and
>> you did it :D Maybe you can add another patch to convert the only
>> strtol in upload-pack.c to parse_ui. This place should accept positive
>> number in base 10, pl
---
Makefile | 2 +-
git-rebase--interactive.sh (mode +x) | 36 +++-
git-rebase.sh| 9 ++---
3 files changed, 38 insertions(+), 9 deletions(-)
mode change 100644 => 100755 git-rebase--interactive.sh
diff --
---
builtin/checkout.c | 40 +++-
builtin/merge.c| 29 +++--
unpack-trees.c | 33 +
unpack-trees.h | 4
4 files changed, 47 insertions(+), 59 deletions(-)
diff --git a/builtin/checkout.c
---
Makefile | 2 +-
git-rebase--merge.sh (mode +x) | 34 ++
git-rebase.sh | 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
mode change 100644 => 100755 git-rebase--merge.sh
diff --git a/Makefile b/Makefile
index 93
git-rebase.sh is no longer a dependency for rebase subscripts. This
function is only used by subscripts only, which now becomes useless.
---
git-rebase.sh | 13 -
1 file changed, 13 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 86119e7..d941239 100755
--- a/git-rebase.
---
Makefile| 2 +-
builtin.h | 1 +
builtin/rebase.c (new) | 752
commit.c| 4 +-
commit.h| 4 +-
contrib/example
---
git-rebase--am.sh | 5 +
git-rebase--interactive.sh | 5 +
git-rebase--merge.sh | 5 +
git-rebase.sh | 7 +--
4 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index ab84330..399956b 100755
--- a/gi
---
Makefile| 2 +-
git-rebase--am.sh (mode +x) | 34 ++
git-rebase.sh | 11 ++-
3 files changed, 45 insertions(+), 2 deletions(-)
mode change 100644 => 100755 git-rebase--am.sh
diff --git a/Makefile b/Makefile
index 1b30
---
builtin/blame.c | 4 ++--
builtin/commit.c | 16 +---
builtin/merge.c | 3 +--
builtin/notes.c | 4 ++--
builtin/tag.c| 7 ++-
strbuf.c | 8
strbuf.h | 1 +
7 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/builtin/blame.c b/
In the spirit of sharing code proactively [1], despite my embarrassment,
this is what I got for converting git-rebase.sh to C. Note that this
is only about git-rebase.sh, not git-rebase--*.sh. Some changes in
git-rebase.sh are pushed back to git-rebase--*.sh. The idea is we
convert git-rebase.sh fi
On 03/18/2015 12:05 AM, Duy Nguyen wrote:
> 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_u
On Wed, Mar 18, 2015 at 09:11:48AM +0100, Ephrim Khong wrote:
> I have a non-bare repository /home/a set up with an alternate to the bare
> repository /b. Running git gc on /home/a produces below's error
> [...]
> > git --version
> git version 2.3.0
Try v2.3.2. It has b0a4264 (sha1_file: fix it
Hi Stephen,
On 2015-03-18 09:38, Stephen Robin wrote:
>> Paul Tan writes:
>> I would like to share this very rough prototype with everyone.
> ...
>> I started this as a just-for-fun exercise to learn about the git internal
> API
>
> I started to rewrite git-pull for similar reasons a couple of mo
Hi Paul,
thank you for this very detailed mail. It was a real pleasure to read this
well-researched document.
In the following, I will pick out only parts from the mail, in the interest of
both of our time. Please assume that I agree with everything that I do not
quote below (and even the with
> Paul Tan writes:
> I would like to share this very rough prototype with everyone.
...
> I started this as a just-for-fun exercise to learn about the git internal
API
I started to rewrite git-pull for similar reasons a couple of months ago,
but I haven't had time to complete it. It looks like
The failure case which occurs on teaching git is taught the '-' shorthand
is when there exists no branch pointed to by '@{-1}'. But, if there is a file
named - in the working tree, the user can be unambiguously assumed to be
referring to it while issuing this command.
The ambiguous case occurs wh
Teaching reset the - shorthand involves checking if any file named '-' exists.
check_filename() is used to perform this check.
When the @{-1} branch does not exist then it can be safely assumed that the
user is referring to the file '-',if any. If this file exists then it is reset
or else
a bad f
On Wed, Mar 18, 2015 at 3:04 PM, Ephrim Khong wrote:
> Without having looked into this and nd/multiple-work-trees, but with "make
> multiple checkouts aware of each other" in mind: Could this mechanism be
> re-used to make alternates aware of each other, to mitigate the dangers of
> having git gc
My $0.02 based on $dayjob
(disclaimer I've never used subtree)
On Wed, Mar 18, 2015 at 11:14 AM, Robert Dailey
wrote:
> 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 repositor
1 - 100 of 110 matches
Mail list logo
