On Tue, Aug 6, 2013 at 8:36 AM, Junio C Hamano wrote:
> Antoine Pelisse writes:
> Quoting that part I was asking about again:
>
>> +# check and upgrade old organization
>> +hg_path = os.path.join(shared_path, '.hg')
>> +if os.path.exists(shared_path) and not os.path.exists
Junio C Hamano wrote:
>>> After reading what the whole function does, I think the purpose of
>>> this function is to take gc-lock (with optionally force). Perhaps a
>>> name along the lines of "lock_gc", "gc_lock", "lock_repo_for_gc",
>>> would be more appropriate.
>>
>> The whole point of this ex
In Perforce, View setting of p4 client can describe
-//depot/project/files/*.xls //client/project/files/*.xls
to exclude Excel files.
But "git p4 --use-client-spec" cannot support '*'.
In git-p4.py, "map_in_client" method analyzes View setting and return
client file path.
So I modify the method
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> [...]
>
> The other comments mostly make sense.
>
>> After reading what the whole function does, I think the purpose of
>> this function is to take gc-lock (with optionally force). Perhaps a
>> name along the lines of "lock_gc", "gc_lock",
Am 8/5/2013 16:23, schrieb Duy Nguyen:
> close() is added in commit_lock_file(), before rename(), by 4723ee9
> (Close files opened by lock_file() before unlinking. - 2007-11-13),
> which is needed by Windows. But doesn't that create a gap between
> close() and rename() on other platforms where anot
Thanks. Queued this at the tip of 'pu'. There seem to be some
fallouts found in the test suite, though.
--
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
Antoine Pelisse writes:
> On Mon, Aug 5, 2013 at 11:02 PM, Junio C Hamano wrote:
>> Antoine Pelisse writes:
>> Is the untold
>> and obvious-to-those-who-are-familiar-with-this-codepath assumption
>> that it is guaranteed that there is at most one "*/clone/.hg" under
>> shared_path?
>
> No, ther
On Mon, Aug 5, 2013 at 11:02 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
> Is the untold
> and obvious-to-those-who-are-familiar-with-this-codepath assumption
> that it is guaranteed that there is at most one "*/clone/.hg" under
> shared_path?
No, there is no such assumption.
That is why
This reverts commit 888611dd5d407775245d574a3dc5c01b5963a5ba. This is
because, in the re-engineered log view, scrolling the log with the
arrows now updates the diff in the diff view when the screen is
split. This resembles the earlier behaviour, and is also what users of
software like Mutt (which u
This is a second iteration. This handles the following:
- remove unneeded comments
- remove unneeded pager_request calls
- rename update_commit_ref to recalculate_commit_context
Now, the only thing missing is the recalculation of commits when the
line number is changed. The trouble there is that
This commit introduces and uses the log_select function to find the
correct commit in the unsplit log view. In the log view, if one
scrolls down across a commit line, the current commit (as displayed in
the status bar) gets updated, but not so when scrolling upward across
a commit. The log_select f
In the log view, when scrolling across a commit, the diff view should
automatically switch to the commit whose context the cursor is on in
the log view. This commit changes things to catch the REQ_ENTER in the
log view and handle recalculation of the commit and diff display from
log_request, rather
Dear Jonas,
Thanks for the patient review.
On Mon, Aug 05, 2013 at 11:27:44PM -0400, Jonas Fonseca wrote:
> On Fri, Aug 2, 2013 at 8:23 PM, Kumar Appaiah
> wrote:
> > This commit introduces and uses the log_select function to find the
> > correct commit in the unsplit log view. In the log view,
On Fri, Aug 2, 2013 at 8:23 PM, Kumar Appaiah wrote:
> These set of patches refactor the log view to provide a behaviour that
> is quite similar to, say, e-mail with Mutt. The key improvements are:
>
> - The current commit is inferred based on the context. For example, if
> you focus on the comm
On Fri, Aug 2, 2013 at 8:23 PM, Kumar Appaiah wrote:
> diff --git a/tig.c b/tig.c
> index 72f132a..dd4b0f4 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -4427,11 +4454,30 @@ log_open(struct view *view, enum open_flags flags)
> static enum request
> log_request(struct view *view, enum request request,
On Fri, Aug 2, 2013 at 8:23 PM, Kumar Appaiah wrote:
> In the log view, when scrolling across a commit, the diff view should
> automatically switch to the commit whose context the cursor is on in
> the log view. This commit changes things to catch the REQ_ENTER in the
> log view and handle recalcu
On Fri, Aug 2, 2013 at 8:23 PM, Kumar Appaiah wrote:
> This commit introduces and uses the log_select function to find the
> correct commit in the unsplit log view. In the log view, if one
> scrolls down across a commit line, the current commit (as displayed in
> the status bar) gets updated, but
Martin Fick wrote:
> I hope
> that someone more familiar with git gc than me might take
> this on some day. :)
More likely scenario: someone who is unfamiliar with it will read and
patch it little by little :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
This is the rough explanation I wrote down after reading it:
So, the problem is that my .git/objects/pack is polluted with little
packs everytime I fetch (or push, if you're the server), and this is
problematic from the perspective of a overtly (naively) aggressive gc
that hammers out all fragment
Duy Nguyen wrote:
> Good point. I think that is because gc does not check if gc is already
> running. Adding such a check should not be too hard. I think gc could
> save its pid in $GIT_DIR/auto-gc.pid. The next auto-gc checks this, if
> the pid is valid, skip auto-gc.
Check. I also talked about
On Mon, Aug 5, 2013 at 8:59 AM, Brian Gernhardt
wrote:
>
> The URL included in the header appears to vary from curl version to
> curl version. Since we only care about the final few lines, only test
> them. However, make sure the blank line after the header is still
> included to make sure there
On Aug 5, 2013, at 15:56, Junio C Hamano wrote:
"Kyle J. McKay" writes:
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http. to the value with the most specific URL in the
configuration.
Signed-off-by: Jeff King
Signed-off-by:
Eric Sunshine writes:
>> The problem exists with and without the incomplete line. The comment
>> mentioning "incomplete line" and "wc" was inserted to explain why it
>> was necessary to add one to the result of wc, which might not
>> otherwise be obvious.
>
> Would the comment be clearer if phras
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 first release candidate v1.8.4-rc1 has been tagged; only
regression fixes and l10n updates from now on.
You can find the changes described
"Kyle J. McKay" writes:
> Use the urlmatch_config_entry() to wrap the underlying
> http_options() two-level variable parser in order to set
> http. to the value with the most specific URL in the
> configuration.
>
> Signed-off-by: Jeff King
> Signed-off-by: Kyle J. McKay
> Signed-off-by: Junio
Antoine Pelisse writes:
> From: Felipe Contreras
>
> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
> making the shared repository '.git/hg', which is already used before
> that patch, so clones that happened before that patch, fail after that
> patch, because there's no
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 3:12 PM, Antoine Pelisse wrote:
>> $ git clone hg::~/my/repository && cd repository && git fetch
>>
>> Fix that by using python os.path.expanduser method.
>
> Shouldn't that be the job of the shell? (s/~/$HOME/)
On Mon, Aug 5, 2013 at 3:12 PM, Antoine Pelisse wrote:
> The current code fixes the path to make it absolute when cloning, but
> doesn't consider tilde expansion, so that scenario fails throwing an
> exception because /home/myuser/~/my/repository doesn't exists:
>
> $ git clone hg::~/my/reposi
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http. to the value with the most specific URL in the
configuration.
Signed-off-by: Jeff King
Signed-off-by: Kyle J. McKay
Signed-off-by: Junio C Hamano
---
This version of 4/6 moves
The current code fixes the path to make it absolute when cloning, but
doesn't consider tilde expansion, so that scenario fails throwing an
exception because /home/myuser/~/my/repository doesn't exists:
$ git clone hg::~/my/repository && cd repository && git fetch
Fix that by using python os.p
On Mon, Aug 5, 2013 at 9:31 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 2:22 PM, Antoine Pelisse wrote:
>> From: Felipe Contreras
>>
>> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
>> making the shared repository '.git/hg', which is already used before
>> that
On Mon, Aug 5, 2013 at 3:35 PM, Eric Sunshine wrote:
> On Mon, Aug 5, 2013 at 3:29 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> A bounds checking bug allows the X in -LX to extend one line past the
>>> end of file. For example, given a file with 5 lines, -L6 is accepted as
>>> valid
On Mon, Aug 5, 2013 at 3:29 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> A bounds checking bug allows the X in -LX to extend one line past the
>> end of file. For example, given a file with 5 lines, -L6 is accepted as
>> valid. Demonstrate this problem.
>>
>> While here, also add tests
On Mon, Aug 5, 2013 at 2:22 PM, Antoine Pelisse wrote:
> From: Felipe Contreras
>
> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
> making the shared repository '.git/hg', which is already used before
> that patch, so clones that happened before that patch, fail after tha
From: Felipe Contreras
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial
Eric Sunshine writes:
> A bounds checking bug allows the X in -LX to extend one line past the
> end of file. For example, given a file with 5 lines, -L6 is accepted as
> valid. Demonstrate this problem.
>
> While here, also add tests to check that the remaining cases of X and Y
> in -LX,Y are han
From: Felipe Contreras
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial
Thomas Rast writes:
> The reflog walking logic (git log -g) replaces the true parent list
> with the preceding commit in the reflog. This results in bogus commit
> diffs when combined with options such as -p; the diff is against the
> reflog predecessor, not the parent of the commit.
>
> Save th
Stefan Beller writes:
> This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
> 2011-09-27).
>
> This commit introduces a change for the users, after this patch
> you can pass one of the config level flags multiple times:
> Before:
> $ git config --global --global --list
>
Stefan Beller writes:
> This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
> 2011-09-27). hash-object is a plumbing layer command, so better
> not change the input/output behavior for now.
>
> Unfortunately we have these lines relying on the count up mechanism of
> OPT_BOOLEAN
On Monday, August 05, 2013 11:34:24 am Ramkumar Ramachandra
wrote:
> Martin Fick wrote:
> > https://gerrit-review.googlesource.com/#/c/35215/
>
> Very cool. Of what I understood:
>
> So, the problem is that my .git/objects/pack is polluted
> with little packs everytime I fetch (or push, if you'r
Junio C Hamano wrote:
> [...]
The other comments mostly make sense.
> After reading what the whole function does, I think the purpose of
> this function is to take gc-lock (with optionally force). Perhaps a
> name along the lines of "lock_gc", "gc_lock", "lock_repo_for_gc",
> would be more appro
Nguyễn Thái Ngọc Duy writes:
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 6be6c8d..1f33908 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -167,11 +167,66 @@ static int need_to_gc(void)
> return 1;
> }
>
> +static int gc_running(int force)
Sounds like a bool asking "Is a GC
Hello all,
Our team is proud to announce SubGit 2.0.0 release! New version is
available for download at SubGit web site at http://subgit.com/
SubGit lets one to set up a bi-directional Git-SVN mirror, and thus it
allows users to choose freely between Subversion and Git version control
systems. Su
Brian Gernhardt writes:
> compat/apple-common-crypto.h uses die() in one of its macros, but was
> included in git-compat-util.h before the definition of die.
>
> Fix by simply moving the relevant block after the die/error/warning
> declarations.
Puzzled. What needs fixing???
Ahh, that one is n
Brian Gernhardt writes:
> It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was
> set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see
> 3ef2bca) so make sure that the appropriate libraries are always set.
>
> Signed-off-by: Brian Gernhardt
> ---
> Makefile | 4
Thanks.
--
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
Martin Fick wrote:
> https://gerrit-review.googlesource.com/#/c/35215/
Very cool. Of what I understood:
So, the problem is that my .git/objects/pack is polluted with little
packs everytime I fetch (or push, if you're the server), and this is
problematic from the perspective of a overtly (naively)
Junio C Hamano writes:
> wor...@alum.mit.edu (Dale R. Worley) writes:
>
>> Commit 52749 fixes a bug regarding testing the return of an open()
>> call for success/failure. Improve the testsuite test for that fix by
>> removing the helper program 'test-close-fd-0' and replacing it with
>> the shel
Duy Nguyen writes:
> close() is added in commit_lock_file(), before rename(), by 4723ee9
> (Close files opened by lock_file() before unlinking. - 2007-11-13),
> which is needed by Windows. But doesn't that create a gap between
> close() and rename() on other platforms where another process can
>
Peter Krefting writes:
> Peter Krefting:
>
>> -/* U+FFFE and U+ are guaranteed non-characters. */
>> -if ((codepoint & 0x1e) == 0xfffe)
>> +/* U+xxFFFE and U+xx are guaranteed non-characters. */
>> +if ((codepoint & 0xe) == 0xfffe)
>
Duy Nguyen writes:
> On Sun, Aug 4, 2013 at 12:26 AM, brian m. carlson
> wrote:
>> The test file that the UTF-16 rejection test looks for is missing, but this
>> went
>> unnoticed because the test is expected to fail anyway; as a consequence, the
>> test fails because the file containing the co
Christian Couder writes:
> Hi,
>
> On Sat, Aug 3, 2013 at 5:13 PM, Philip Oakley wrote:
>> A recent comment http://stackoverflow.com/a/18027030/717355 on a question I
>> asked two years ago about 'grafts' and 'replace' indicates that users think
>> that 'git replace' can't replace a merge commit
Thanks.
--
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
Thanks, will apply after fixing whitespace damage to the patch.
--
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
Mark Levedahl writes:
> I have been using this patch since Ramsey first sent it, have noticed
> no trouble over that time but all of my work is with filemode=true
> (has been since I started using git as Cygwin is a secondary platform
> for me and interoperability with repos on Linux is an absolu
Thomas Rast writes:
> Hiroshige Umino writes:
>
>> As "git cherry-pick -" or "git merge -" is convenient to
>> switch back to or merge the previous branch,
>> "git cherry-pick -" is abbreviation of "git cherry-pick @{-1}"
>> to pick up a commit from the previous branch conveniently.
>
> The firs
wor...@alum.mit.edu (Dale R. Worley) writes:
> Commit 52749 fixes a bug regarding testing the return of an open()
> call for success/failure. Improve the testsuite test for that fix by
> removing the helper program 'test-close-fd-0' and replacing it with
> the shell redirection '<&-'. (The redir
Thanks Brian,
Reviewed-by: Jeremy Huddleston Sequoia
On Aug 5, 2013, at 8:59, Brian Gernhardt wrote:
> It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was
> set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see
> 3ef2bca) so make sure that the appropriate libr
Thanks Brian,
Reviewed-by: Jeremy Huddleston Sequoia
On Aug 5, 2013, at 8:59, Brian Gernhardt wrote:
> compat/apple-common-crypto.h uses die() in one of its macros, but was
> included in git-compat-util.h before the definition of die.
>
> Fix by simply moving the relevant block after the die/
From: "Christian Couder"
Hi,
On Sat, Aug 3, 2013 at 5:13 PM, Philip Oakley
wrote:
A recent comment http://stackoverflow.com/a/18027030/717355 on a
question I
asked two years ago about 'grafts' and 'replace' indicates that users
think
that 'git replace' can't replace a merge commit. The docum
Jonathan Nieder writes:
> Signed-off-by: Jonathan Nieder
> ---
> I'm not thrilled with the wording. This can probably be explained
> more simply. Ideas?
Some random thoughts on text, both before and after this patch.
- The first stentence in this paragraph up to the semicolon is
irreleva
compat/apple-common-crypto.h uses die() in one of its macros, but was
included in git-compat-util.h before the definition of die.
Fix by simply moving the relevant block after the die/error/warning
declarations.
Signed-off-by: Brian Gernhardt
---
Not sure if this is the best place to move it t
It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was
set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see
3ef2bca) so make sure that the appropriate libraries are always set.
Signed-off-by: Brian Gernhardt
---
Makefile | 4 +++-
1 file changed, 3 insertions(+),
The URL included in the header appears to vary from curl version to
curl version. Since we only care about the final few lines, only test
them. However, make sure the blank line after the header is still
included to make sure there are no extra cookie lines.
Signed-off-by: Brian Gernhardt
---
A few changes recently broke my build on Mac 10.8, possibly because I have a
more strict set of warnings/errors enabled. The first two handle minor
problems with the use of APPLE_COMMON_CRYPTO, which was expanded for use in
imap-send but had a couple of problems.
The last is likely due to curl ve
Junio C Hamano wrote:
> I am a bit hesitant to dismiss with "It's not the right model", as
> the original of accessing the repository from two terminals while
> one clearly is being accessed busily by gc falls into the same
> category.
As to why I think it makes sense: garbage collecting unreferen
Tony Finch wrote:
>
> For example, go to https://git.csx.cam.ac.uk/i/ucs/git/git.git/tree
> and click on the gitweb subdirectory which takes you to
> https://git.csx.cam.ac.uk/i/ucs/git/git.git/tree/HEAD:/gitweb
> then click on [git/git.git] to go back, which takes you to
> https://git.csx.cam.ac.
Thanks.
--
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
Thanks.
--
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
Background:
You cam make the same URL work for gitwe and git clone as described in
git-http-backend(1). It says:
To serve gitweb at the same url, use a ScriptAliasMatch to only
those URLs that git http-backend can handle, and forward the rest
to gitweb:
ScriptAliasMatch \
On Mon, Aug 5, 2013 at 11:21 AM, René Scharfe wrote:
> Sub-test 42 of t8001 and t8002 ("blame -L :literal") fails on NetBSD
> with the following verbose output:
>
> git annotate -L:main hello.c
> Author F (expected 4, attributed 3) bad
> Author G (expected 1, attributed 1)
Piotr Krukowiecki writes:
> Isn't the howto documentation intended (mainly/also) for the users of git,
> not the developers?
And they have *.html version for that exact version, no?
We used not to bother running asciidoc to Documentation/howto, so
the *.txt versions had to be exposed to the end
Duy Nguyen writes:
> I worry less about this. It's not the right model to have two machines
> modify the same shared repository (gc --auto is only triggered when we
> think there are new objects) even though I think we support it.
I am a bit hesitant to dismiss with "It's not the right model", a
Sub-test 42 of t8001 and t8002 ("blame -L :literal") fails on NetBSD
with the following verbose output:
git annotate -L:main hello.c
Author F (expected 4, attributed 3) bad
Author G (expected 1, attributed 1) good
This is not caused by different behaviour of git blame or
Jonathan Nieder writes:
> $ git log --encoding
> fatal: Option '--encoding' requires a value
> $ git rev-list --encoding
> fatal: Option '--encoding' requires a value
>
> The argument to --encoding has always been mandatory. Unfortunately
> manpages like git-rev-list(1), git-log(1), and git-
Thomas Rast writes:
> Junio C Hamano writes:
>
>> * tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
>> - log: use true parents for diff even when rewriting
>>
>> Output from "git log --full-diff -- " looked strange,
>> because comparison was done with the previous ancestor that touch
close() is added in commit_lock_file(), before rename(), by 4723ee9
(Close files opened by lock_file() before unlinking. - 2007-11-13),
which is needed by Windows. But doesn't that create a gap between
close() and rename() on other platforms where another process can
replace .lock file with somethi
This may happen when `git gc --auto` is run automatically, then the
user, to avoid wait time, switches to a new terminal, keeps working
and `git gc --auto` is started again because the first gc instance has
not clean up the repository.
This patch tries to avoid multiple gc running, especially in -
Peter Krefting:
- /* U+FFFE and U+ are guaranteed non-characters. */
- if ((codepoint & 0x1e) == 0xfffe)
+ /* U+xxFFFE and U+xx are guaranteed non-characters. */
+ if ((codepoint & 0xe) == 0xfffe)
+ ret
Jakub Narębski wrote:
> On Tue, Jul 2, 2013 at 6:24 PM, Tony Finch wrote:
>
> > On the repository summary page, leave the whole owner line out if
> > the repo does not have an owner, rather than displaying a labelled
> > empty field..
>
> Note that if $omit_owner is true, whole _column_ is skippe
Jakub Narębski wrote:
> > - -values => ['commit', 'grep', 'author',
> > 'committer', 'pickaxe']) .
> > + -values => ['commit', 'grep', 'author',
> > 'committer', 'pickaxe']) .
>
> Nb. what changed here (in line above)?
Whoops, tab damag
Thank you, I'll test with the newer version.
---
kenorb
On 5 August 2013 12:09, John Keeping wrote:
> On Mon, Aug 05, 2013 at 12:01:44PM +0100, Rafal W. wrote:
>> Hi,
>> When applying patch via git, it is doing sometimes SEGV.
>> Please find more details in the attached crash logs.
>
> This look
On Mon, Aug 05, 2013 at 12:01:44PM +0100, Rafal W. wrote:
> Hi,
> When applying patch via git, it is doing sometimes SEGV.
> Please find more details in the attached crash logs.
This looks like the issue fixed by commit 212eb96 (apply: carefully
strdup a possibly-NULL name, 2013-06-21), which is i
Hi,
When applying patch via git, it is doing sometimes SEGV.
Please find more details in the attached crash logs.
---
kenorb
git_2013-07-08-150841_kenorbs-MacBook-Air.crash
Description: Binary data
git_2013-07-08-173513_kenorbs-MacBook-Air.crash
Description: Binary data
git_2013-07-08-201624_
Hi,
On Sat, Aug 3, 2013 at 5:13 PM, Philip Oakley wrote:
> A recent comment http://stackoverflow.com/a/18027030/717355 on a question I
> asked two years ago about 'grafts' and 'replace' indicates that users think
> that 'git replace' can't replace a merge commit. The documentation doesn't
> have
Stefan Beller writes:
> Hello,
>
> I'd like to rewrite the repack shell script in C.
> So I tried the naive approach reading the man page and
> the script itself and write C program by matching each block/line
> of the script with a function in C
You should add one step here: check that tests
Junio C Hamano writes:
> Thanks both. Perhaps we should do something like this?
>
> -- >8 --
> Subject: builtin/rm.c: consolidate error reporting for removing submodules
Sounds good, yes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubsc
On Sun, Aug 04, 2013 at 11:14:40AM -0700, Jonathan Nieder wrote:
> Alexey Shumkin wrote:
> > On Fri, Aug 02, 2013 at 04:23:38PM -0700, Jonathan Nieder wrote:
>
> >> 1. Log messages use the configured log output encoding, which is
> >> meant to be whatever encoding works best with local termin
89 matches
Mail list logo
