Hi Junio,
This pull request fixes typo of commit " l10n: fr.po v1.6.0 round 1 ..."
(should replace 1.6.0 to 2.6.0), and also includes new updates from
Ralf. I also create a signed tag (l10n-2.6.0-rnd2+de) for this.
Would you please pull the following git l10n updates.
The following changes
On Mon, Aug 03, 2015 at 05:21:43PM +0200, Per Cederqvist wrote:
If you run:
git config pager.pull true
in the hope of getting the output of git pull via a pager, you are
in for a surpise the next time you run git pull --rebase and it has
to rebase your work. It will fail
On Sun, Aug 09, 2015 at 07:42:38PM -0400, Jeff King wrote:
It looks like the use of a pager is fooling our should we colorize the
diff check when generating the patches. Usually we check isatty(1) to
see if we should use color, so git format-patch patches does the
right thing. But if a pager
Junio C Hamano gits...@pobox.com writes:
On Thu, Jul 30, 2015 at 11:31 AM, Joey Hess i...@joeyh.name wrote:
I think this comes down to a lack of quoting where git-pull runs
git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
$@ was passed through to git-fetch, but now
In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'
This also seems to work in 2.4.6, but in 2.5.0, the option parser
does something weird, apparently looking inside the quoted parameter
and parsing parameters in there:
error: unknown option `foo'
usage: git fetch [options] [repository
On Thu, Jul 30, 2015 at 11:31 AM, Joey Hess i...@joeyh.name wrote:
I think this comes down to a lack of quoting where git-pull runs
git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
$@ was passed through to git-fetch, but now there is a $upload_pack
which is passed without being
I think this comes down to a lack of quoting where git-pull runs
git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
$@ was passed through to git-fetch, but now there is a $upload_pack
which is passed without being quoted.
--
see shy jo
signature.asc
Description: Digital signature
Joey Hess i...@joeyh.name writes:
In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'
This also seems to work in 2.4.6, but in 2.5.0, the option parser
does something weird, apparently looking inside the quoted parameter
and parsing parameters in there:
error: unknown option `foo
Hi Junio,
The following changes since commit 961abca02c532626df631c851688ec433095d93d:
Merge tag 'l10n-2.5.0-rnd1' of git://github.com/git-l10n/git-po
(2015-07-13 15:37:24 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.5.0-rnd2
for you to fetch
On Fri, Jun 19, 2015 at 4:13 AM, Junio C Hamano gits...@pobox.com wrote:
I didn't look carefully, but does that mean 04/19 has the what if
you start from a subdirectory and are still using the scripted one?
issue we discussed recently for am?
It does, but git-pull.sh does not care about the
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cleverer
Paul Tan pyoka...@gmail.com writes:
This is a re-roll of [v3]. It squashes in Ramsay's patch fix some sparse
warnings, and fixes the use-before-free reported by Duy. Thanks a lot for
dealing with my mess :-).
Other than that, there are no other changes as I'm working on the git-am side
of
://thread.gmane.org/gmane.comp.version-control.git/269258
[v2] http://thread.gmane.org/gmane.comp.version-control.git/270639
[v3] http://thread.gmane.org/gmane.comp.version-control.git/271614
git-pull is a commonly executed command to check for new changes in the
upstream repository
The following changes since commit 9eabf5b536662000f79978c4d1b6e4eff5c8d785:
Git 2.4.2 (2015-05-26 13:49:59 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.4-maint-de-updates
for you to fetch changes up to
This is a re-roll of [v2]. Thanks Junio, Stefan for the reviews last round.
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
[v2] http://thread.gmane.org/gmane.comp.version-control.git/270639
git-pull is a commonly executed command to check for new changes
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cleverer
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
On Wed, Jun 10, 2015 at 9:56 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
+enum rebase_type {
+ REBASE_INVALID = -1,
+ REBASE_FALSE = 0,
+ REBASE_TRUE,
+ REBASE_PRESERVE
+};
+
+/**
+ * Parses the value of --rebase, branch.*.rebase or
Paul Tan pyoka...@gmail.com writes:
Hmph, it is somewhat surprising that we do not have such a helper
already. Wouldn't we need this logic to implement $branch@{upstream}
syntax?
Right, the @{upstream} syntax is implemented by branch_get_upstream()
in remote.c. It, however, does not check
On Wed, Jun 10, 2015 at 10:44 PM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
Hmph, it is somewhat surprising that we do not have such a helper
already. Wouldn't we need this logic to implement $branch@{upstream}
syntax?
Right, the @{upstream} syntax is
Paul Tan pyoka...@gmail.com writes:
so it's more or less a direct translation of the shell script, and we
can be sure it will have the same behavior. I'm definitely in favor of
switching this to use remote_find_tracking(), the question is whether
we want to do it in this patch or in a future
Paul Tan pyoka...@gmail.com writes:
+/**
+ * Returns remote's upstream branch for the current branch. If remote is
NULL,
+ * the current branch's configured default remote is used. Returns NULL if
+ * `remote` does not name a valid remote, HEAD does not point to a branch,
+ * remote is not
Paul Tan pyoka...@gmail.com writes:
+enum rebase_type {
+ REBASE_INVALID = -1,
+ REBASE_FALSE = 0,
+ REBASE_TRUE,
+ REBASE_PRESERVE
+};
+
+/**
+ * Parses the value of --rebase, branch.*.rebase or pull.rebase. If value is
a
+ * false value, returns REBASE_FALSE. If
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cleverer
This is a re-roll of [v1]. Thanks Johannes, Stefan and Junio for the reviews
last round.
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
git-pull is a commonly executed command to check for new changes in the
upstream repository and, if there are, fetch
as you
provided more than one refspec. git-pull will not be able to handle a
rebased upstream. I do not think it is fatal enough that we should
error() or die(), as e.g. the first refspec may be a wildcard refspec
that matches nothing, and the second refspec that matches one merge
head
()`.
Yeah, it should be changed to get_tracking_branch(), since it is
different from get_merge_branch().
One thing that is not clear at all to me is whether
git pull --rebase origin master next
would error out as expected, or simply rebase to `origin/master`.
In git-pull.sh, for the rebase
Hi,
On Tue, May 19, 2015 at 3:21 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
This series rewrites git-pull.sh into a C builtin, thus improving its
performance and portability. It is part of my GSoC project to rewrite
git-pull
and git-am into builtins[2
in SCRIPT_SH in the Makefile will generate 2
targets to ./git-pull (they will clobber each other). For GNU Make,
the last defined target will win, so in this case it just happens that
git-pull.sh will win because the build targets for the shell scripts
are defined after the build targets
This is a re-roll of [1].
This patch series improves test coverage of git-pull.sh, and is part of my
GSoC project to rewrite git-pull into a builtin. Improving test coverage
helps to prevent regressions that could occur due to the rewrite.
Thanks Junio, Johannes and Stefan for the reviews last
Paul Tan pyoka...@gmail.com writes:
This is a re-roll of [1].
This patch series improves test coverage of git-pull.sh, and is part of my
GSoC project to rewrite git-pull into a builtin. Improving test coverage
helps to prevent regressions that could occur due to the rewrite.
Thanks Junio
This series directly depends on the changes made in jc/merge and
pt/pull-tests. The commit messages assume that the behavioral changes
proposed in pt/pull-log-n, pt/pull-tags-error-diag, pt/pull-ff-vs-merge-ff,
and [1] have been introduced.
git-pull is a commonly executed command to check for new
This is a re-roll of [1]. This series depends on jc/merge.
This patch series improves test coverage of git-pull.sh, and is part of my
GSoC project to rewrite git-pull into a builtin. Improving test coverage
helps to prevent regressions that could occur due to the rewrite.
This re-roll includes
Hi Junio,
On Fri, May 8, 2015 at 4:15 AM, Junio C Hamano gits...@pobox.com wrote:
I do not think touching this test which does not have anything to do
with git pull in your series is sensible at all, and you shouldn't
flip test_expect_success temporarily to _expect_failure, if that is
what
Since git fetch . does not update any refs, git pull . side is
equivalent to calling git merge side.
As such, replace the call to git-pull with a call to git-merge to reduce
the dependence on git-pull's functionality to reduce irrelevant test
breakage when git-pull is rewritten to C.
Signed-off
Hi Junio,
On 2015-04-20 21:28, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
This is primarily note-to-self; even though I haven't got around
bisecting yet, I think I know I did some bad change myself.
git pull $URL $tag seems to:
* fail to invoke the editor without
\ $merge_head
+ eval=$eval FETCH_HEAD
;;
esac
eval exec $eval
as we seem to special-case the name FETCH_HEAD. It assumes that
git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
but that seems safe.
Unfortunately, git merge's parsing of FETCH_HEAD forgets
eval=$eval $gpg_sign_args
- eval=$eval -m \\$merge_name\ $merge_head
+ eval=$eval FETCH_HEAD
;;
esac
eval exec $eval
as we seem to special-case the name FETCH_HEAD. It assumes that
git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
but that seems
in git-pull,
but that seems safe.
Unfortunately, git merge's parsing of FETCH_HEAD forgets that we
may be creating an Octopus. Otherwise the above should work well.
That sounds like a bug we should fix regardless.
But I am not sure how it should behave. git fetch $there A B C
followed
Junio C Hamano gits...@pobox.com writes:
This is primarily note-to-self; even though I haven't got around
bisecting yet, I think I know I did some bad change myself.
git pull $URL $tag seems to:
* fail to invoke the editor without --edit.
* show the summary merge log message twice.
We
On Sat, Apr 18, 2015 at 06:39:20PM -0700, Junio C Hamano wrote:
This is primarily note-to-self; even though I haven't got around
bisecting yet, I think I know I did some bad change myself.
git pull $URL $tag seems to:
* fail to invoke the editor without --edit.
* show the summary merge
is the same as what we do in git-pull,
but that seems safe. Unfortunately we still have to compute $merge_head
ourselves here for the git pull --rebase case.
I agree that this is a better choice. My concern with your other
suggestion is that it looks like it wouldn't honor the --no-edit flag
-pull,
but that seems safe. Unfortunately we still have to compute $merge_head
ourselves here for the git pull --rebase case.
I agree that this is a better choice. My concern with your other
suggestion is that it looks like it wouldn't honor the --no-edit flag or
GIT_MERGE_AUTOEDIT=no. That might
This is primarily note-to-self; even though I haven't got around
bisecting yet, I think I know I did some bad change myself.
git pull $URL $tag seems to:
* fail to invoke the editor without --edit.
* show the summary merge log message twice.
--
To unsubscribe from this list: send the line
Thanks, all.
--
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
Hi, Junio
The following changes since commit 6ae0d972664134b82a6dd164a01e8adbebeaffe3:
Git 2.4.0-rc1 (2015-04-02 12:46:06 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.4.0-rnd2
for you to fetch changes up to
Before this path, the also sounded as if preserve was doing a rebase
as additional work that true would not do. Clarify this by saying
still instead of also.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(+), 2
Sebastian Schuberth sschube...@gmail.com writes:
Before this path, the also sounded as if preserve was doing a rebase
as additional work that true would not do. Clarify this by saying
still instead of also.
I agree that the original also is confusing. I however wonder if
we even want still,
Thanks; this time I do not see whitespace breakages ;-)
Will queue with a minimum tweak of the log message.
--
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
Before this path, the also sounded as if preserve was doing a rebase
as additional work that true would not do. Clarify this by omitting the
also and rewording the sentence a bit.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/git-pull.txt | 5 ++---
1 file changed, 2
it clear that zero spawning of processes is an ideal -- it
doesn't have to be so in practice.
* Swap rewrite of git-pull and git-am in timeline. It is better to push
the first patch to the mailing list as soon as possible.
* Make it clear that as part of refactoring, commonly recurring patterns
Paul Tan pyoka...@gmail.com writes:
I think it's still good to have the ideal in mind though (and whoops I
forgot to put in the word ideal in the text).
Using or not using fork is merely one of the trade-offs we can make.
If all other things are equal, no fork is better than a fork is a
On 24.03.2015 17:37, Paul Tan wrote:
I'm applying for git in the Google Summer of Code this year. For my
project, I propose to rewrite git-pull.sh and git-am.sh into fast
optimized C builtins. I've already hacked up a prototype of a builtin
git-pull in [1], and it showed a promising 8x
On Thu, Mar 26, 2015 at 1:54 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
I think it's still good to have the ideal in mind though (and whoops I
forgot to put in the word ideal in the text).
Using or not using fork is merely one of the trade-offs we can
On Mon, Mar 23, 2015 at 6:18 PM, Duy Nguyen pclo...@gmail.com wrote:
Could you share these changes? I'm just wondering if we can add kcov
support to the test suite.
In this case it's more of an embarrassing hack, as I just needed a way
to make git run kcov outdir git-pull.sh whenever git pull
(thus the use of should not),
but git-pull and git-am are relatively simple so there should be no
need for that,
We can see that the C version requires much more lines compared to the shell
pipeline,...
That is something you would solve by introducing reusable code in
run_command API, isn't
Hi all,
I'm applying for git in the Google Summer of Code this year. For my
project, I propose to rewrite git-pull.sh and git-am.sh into fast
optimized C builtins. I've already hacked up a prototype of a builtin
git-pull in [1], and it showed a promising 8x improvement in execution
time
to contribute to discussions and
review other than your own patches. It's nice to feel integrated in the
community and not the GSoC student working alone at home ;-).
Yeah I apologize for not participating in the list so actively because
writing the git-pull prototype and the proposal took a fair chunk
Paul Tan pyoka...@gmail.com writes:
..., I propose the following requirements for the rewritten code:
1. No spawning of external git processes. This is to support systems with high
``fork()`` or process creation overhead, and to reduce redundant IO by
taking advantage of the internal
your own patches. It's nice to feel integrated in the
community and not the GSoC student working alone at home ;-).
Yeah I apologize for not participating in the list so actively because
writing the git-pull prototype and the proposal took a fair chunk of
my time.
Don't apologize, you're doing
Hi Paul,
On 2015-03-22 18:39, Paul Tan wrote:
The code coverage tools can help here as well. The kcov output clearly
shows which options of git-pull are currently not being tested. But
yes, I agree that the test suite shouldn't be relied too much on
compared to code inspection and review
On Sat, Mar 21, 2015 at 8:23 PM, Paul Tan pyoka...@gmail.com wrote:
I see git already has gcov support. For shell scripts, maybe kcov[1]
could be used. With some slight code changes, I managed to generate a
report for the git-pull tests[2] which should at least provide a good
starting point
git already has gcov support. For shell scripts, maybe kcov[1]
could be used. With some slight code changes, I managed to generate a
report for the git-pull tests[2] which should at least provide a good
starting point for how the tests can be improved.
While it is often a tempting idea to make
because it
has static linkage. The project should, at the very least, allow the
function to be shared between git-pull and git-merge-base, as well as
to modify the function so that it can fail without die()-ing.
Yes, I agree wholeheartedly. But I like your choice to strike a balance for the
sake
. With some slight code changes, I managed to generate a
report for the git-pull tests[2] which should at least provide a good
starting point for how the tests can be improved.
While it is often a tempting idea to make test suites as thorough as possible,
there lies a true danger herein. True war story
Hi,
On Thu, Mar 19, 2015 at 6:26 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com 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
an experienced understanding of all the possible important
inputs to be tested, which I personally feel would make the project
quite tedious.
I see git already has gcov support. For shell scripts, maybe kcov[1]
could be used. With some slight code changes, I managed to generate a
report for the git-pull
() in this patch, which
is copied from the merge-base builtin and not accessible because it
has static linkage. The project should, at the very least, allow the
function to be shared between git-pull and git-merge-base, as well as
to modify the function so that it can fail without die()-ing.
Regards
On Wed, Mar 18, 2015 at 9:58 PM, John Keeping j...@keeping.me.uk 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 pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one
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 my
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 months ago
if the first
step is an almost one-to-one translation to `run_command*()`-based builtins.
Plus, it is rewarding to have concise steps that can be completed in a timely
manner.
+/* NOTE: git-pull.sh only supports --log and --no-log, as opposed to what
+ * man git-pull says. */
+static int
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
:
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 the output is
Already up to date
but since today it prints
Auto
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com 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
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, Дилян Палаузов
dilyan.palau...@aegee.org wrote:
Hello,
# git gc --auto
Auto
On Wed, Mar 18, 2015 at 8:53 PM, Дилян Палаузов
dilyan.palau...@aegee.org 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
On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов
dilyan.palau...@aegee.org 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 ?
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com 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.
move the old script
to contrib/examples/.
+static const char * const builtin_pull_usage[] = {
+ N_(git pull [-n | --no-stat] [--[no-]commit] [--[no-]squash]
[--[no-]ff|--ff-only] [--[no-]rebase|--rebase=preserve] [-s strategy]...
[fetch-options] repo head...),
I know we have many
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 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 the
On Wed, Mar 18, 2015 at 6:27 PM, Jeff King p...@peff.net 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
Paul Tan pyoka...@gmail.com 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,
+
On Thu, Mar 19, 2015 at 4:04 AM, Jeff King p...@peff.net 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 pclo...@gmail.com wrote:
If not, I made some mistake in
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
impact
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 each pack
On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King p...@peff.net 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,
On Thu, Mar 19, 2015 at 11:20 AM, Jeff King p...@peff.net 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 p...@peff.net wrote:
Keeping a file that says I ran gc at time T, and there were still N
objects left over is probably the
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.
True.
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 expire, but
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King p...@peff.net 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
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 pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one mistake,
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
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
On Tue, Mar 03, 2015 at 03:54:05PM -0800, Mike Botsko wrote:
Thanks, that clarifies a lot.
I only have two follow-up questions:
In your branch example, how does git determine that C/D have been
rewritten and need to be replaced with their current versions
existing upstream? In this
Hello,
I'm seeing unexpected behavior between git pull --rebase and git
rebase commands, which are supposed to be (and always described as)
synonymous:
git pull --rebase upstream our-branch-name
and
git fetch upstream
git rebase upstream/our-branch-name
We have a situation where the upstream
behavior between git pull --rebase and git
rebase commands, which are supposed to be (and always described as)
synonymous:
git pull --rebase upstream our-branch-name
and
git fetch upstream
git rebase upstream/our-branch-name
We have a situation where the upstream/our-branch-name
On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote:
I'm seeing unexpected behavior between git pull --rebase and git
rebase commands, which are supposed to be (and always described as)
synonymous:
git pull --rebase upstream our-branch-name
and
git fetch upstream
git rebase
.
I assume he was incorrect in that git rebase uses --fork-point by default?
On Tue, Mar 3, 2015 at 1:09 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote:
I'm seeing unexpected behavior between git pull --rebase and git
rebase commands, which
201 - 300 of 502 matches
Mail list logo
