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
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 44cc742a8ca17b9c279be4cc195a93a6ef7a
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
---
Documentation/git-pull.txt | 5 ++---
1 file changed, 2 insertions(+)
Sebastian Schuberth 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", thou
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
---
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
On Thu, Mar 26, 2015 at 1:54 AM, Junio C Hamano wrote:
> Paul Tan 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 thing
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 pr
Paul Tan 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
meaningless statem
follows:
* Make 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, co
ependencies, the rewritten C code should
>> not
>> depend on other libraries or executables other than what is already available
>> to git builtins.
>
> Perhaps misphrased; see below.
In this case I was thinking of "making git depend on another project".
(e.g, usi
Paul Tan 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 object, index a
oudly, feel free to ignore.
>> A general advice: if time allows, try 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 apo
sier and shorter to do any final polishing and review for
merging.
> A general advice: if time allows, try 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"
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 executi
On Mon, Mar 23, 2015 at 6:18 PM, Duy Nguyen 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" w
On Sat, Mar 21, 2015 at 8:23 PM, Paul Tan 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
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 insp
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 tests[2] which should at least provide a good
>> starting point fo
nally 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 tests[2] which should at least provide a good
> starting point
trivially shared (without requiring major refactoring) should be part
> of the project, otherwise lots of code may be duplicated and cause
> code bloat. The obvious one would be fork_point() in this patch, which
> is copied from the merge-base builtin and not accessible because it
> has
oring) should be part
of the project, otherwise lots of code may be duplicated and cause
code bloat. The obvious one would be fork_point() 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
funct
Hi,
On Thu, Mar 19, 2015 at 6:26 AM, Junio C Hamano wrote:
> 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 {
>> +
than that would
require 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 genera
On Wed, Mar 18, 2015 at 9:58 PM, 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 "gc" should ha
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
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 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 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
When converting a script into a builtin, we usually 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
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 -
ve 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
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 d
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 to
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 f
eviewing easier 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 s
> 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.
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
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 thi
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 scenario I've encountered, the commit hash
and the patch ID of those comm
On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
> Maybe I'm lacking the distinction regarding what I'm being specific about.
>
> In both examples, I'm asking it specifically to rebase in changes from
> the remote "upstream" and a named branch at that location. I'm giving
> git the sam
Maybe I'm lacking the distinction regarding what I'm being specific about.
In both examples, I'm asking it specifically to rebase in changes from
the remote "upstream" and a named branch at that location. I'm giving
git the same information, it's just interpreting it differently - and
I'm not unde
John Keeping writes:
> git-rebase assumes that if you give an explicit upstream then you want
> precisely what you asked for. From git-rebase(1):
>
> If either or --root is given on the command line,
> then the default is `--no-fork-point`, otherwise the default is
> `--fork-p
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:
> >>
>
ion of git, but it wasn't fixed.
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 wrote:
> On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote:
>> I'm seeing unexpected behavior between "git pull
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-bran
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 h
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
Hi Junio,
The following changes since commit 15598cf41beed0d86cd2ac443e0f69c5a3b40321:
Git 2.3.0-rc2 (2015-01-27 14:39:53 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 7471cf88f54990831fe2fd84160350fe432a7b76:
l10n:
On Thu, Jan 29, 2015 at 3:26 PM, Junio C Hamano wrote:
> Subject: Documentation/git-remote.txt: stress that set-url is not for
> triangular
>
> It seems to be a common mistake to try using a single remote
> (e.g. 'origin') to fetch from one place (i.e. upstream) while
> pushing to another (i.e. y
Dick writes:
> I guess the git remote set-url --push command should contain some warning
> about this.
Perhaps something like this would be good enough for a starter.
-- >8 --
Subject: Documentation/git-remote.txt: stress that set-url is not for triangular
It seems to be a common mistake to t
Thanks Junio! I should use git config remote.pushDefault thanks for pointing
me in the right direction.
I guess the git remote set-url --push command should contain some warning
about this.
gr
Dick
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to ma
fig remote.pushDefault mine
git push --all;# to publish to ../right.git
to set things up. Then
edit && git commit && git other-commands && ...
git push ;# updates ../right.git
to publish his work. Updating from 'left' would go like this:
e "blessed repository" and
>> pushes to the "developer public" repository.
>>
>> When the "blessed repository" has the same branch name as the "developer
>> public" repository git pull seems to drop commits.
>>
>> I'v
sitory.
>
> When the "blessed repository" has the same branch name as the "developer
> public" repository git pull seems to drop commits.
>
> I've create a test script to demonstrate, left is the blessed repository,
> right.git is the developer public a
me as the "developer
public" repository git pull seems to drop commits.
I've create a test script to demonstrate, left is the blessed repository,
right.git is the developer public and right is the developer private
repository.
rm -rf left/ right/ right.git/
git init left
cd le
ings. That's why we always put related settings inside the
> .gitignore file. But while I will change it, git will not track the
> changes of the file, but .gitignore. That's why I used the first
> thread command. But when the time the came to take a `git pull`, I got
>
t related settings inside the .gitignore file. But while I will
change it, git will not track the changes of the file, but .gitignore. That's
why I used the first thread command. But when the time the came to take a `git
pull`, I got to know about the mess. What should be the ideal decision
On Fri, Jan 23, 2015 at 2:26 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Assuming you want to ignore less than the upstream project (delete some
>> lines from .gitignore) it get's tricky in my opinion.
>
> Why? Doesn't info/exclude allow negative ignore patterns?
I used negative patt
Stefan Beller writes:
> Assuming you want to ignore less than the upstream project (delete some
> lines from .gitignore) it get's tricky in my opinion.
Why? Doesn't info/exclude allow negative ignore patterns?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
pendix to the .gitignore file because that file
is rather obvious to find (it's printed when git pull modifies it,
'ls' just find it,
you'd not look into .git/info/exclude by chance)
Assuming you want to ignore less than the upstream project (delete some
lines from .gitignore)
Stefan Beller writes:
>> Ok. How should I then ignore any local changes to the .gitignore
>> file ? And while taking pull, git should skip this file ?
>
> Look at .git/info/exclude
Good answer for ".gitignore". In general, you do not "ignore local
changes" to tracked paths.
> I found https://h
On Fri, Jan 23, 2015 at 10:35 AM, Arup Rakshit
wrote:
> On Friday, January 23, 2015 11:31:40 AM you wrote:
>> Arup Rakshit writes:
>>
>> > I asked git not to track any changes to the file .gitignore. To do
>> > so I did use the command - git update-index --assume-unchanged
>> > .gitignore.
>>
>>
On Friday, January 23, 2015 11:31:40 AM you wrote:
> Arup Rakshit writes:
>
> > I asked git not to track any changes to the file .gitignore. To do
> > so I did use the command - git update-index --assume-unchanged
> > .gitignore.
>
> You are not asking Git to do anything. You promised Git that y
Arup Rakshit writes:
> I asked git not to track any changes to the file .gitignore. To do
> so I did use the command - git update-index --assume-unchanged
> .gitignore.
You are not asking Git to do anything. You promised Git that you
will make no changes to .gitignore, and then broke that promis
-forwarded.
# (use "git pull" to update your local branch)
#
nothing to commit, working directory clean
[arup@sztukajedzenia]$ git pull origin MajorUpgrade
>From rubyxcube.co.uk:sztuka-jedzenia/sztukajedzenia
* branchMajorUpgrade -> FETCH_HEAD
Updating 59a1c07..d7b9cd3
er
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 627736ca799edacf13881da7e671964a0afb94b8:
Git 2.3.0-rc1 (2015-01-20 17:35:41 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 1e607449135792dd117bd528432fc1fbc1115667:
l10n:
Hi Junio,
Please pull l10n update to maint branch.
The following changes since commit b260d265e189728b26e50506ac6ffab6a7d588da:
Git 2.2 (2014-11-26 13:18:34 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po maint
for you to fetch changes up to ff51f5619d52410
Hi Junio,
Please pull again in order to merge Catalan translation.
Now l10n for Git 2.2.0 is almost completed.
bg.po : 2296 translated messages.
ca.po : 2296 translated messages.
de.po : 2293 translated messages, 2 untranslated messages.
fr.po : 22
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
Hi Junio,
Translations for German is ready, please pull.
The following changes since commit 6c31a5e94af1036bb29da8a75f1e735e662aee92:
l10n: Updated Bulgarian translation of git (2296t,0f,0u) (2014-11-02
19:11:08 +0200)
are available in the git repository at:
git://github.com/git-l10n/git-p
Jiang Xin writes:
> Please pull the following git l10n updates.
>
> The following changes since commit 4ace7ff4557350b7e0b57d024a2ea311b332e01d:
>
> Git 2.2.0-rc0 (2014-10-31 11:57:23 -0700)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po master
>
> for you to
Hi Junio,
Please pull the following git l10n updates.
The following changes since commit 4ace7ff4557350b7e0b57d024a2ea311b332e01d:
Git 2.2.0-rc0 (2014-10-31 11:57:23 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 6c31a
Good evening,
I am having difficulties with "git pull" command. Couple days ago it
worked perfectly, no problem. Now this command just runs, and does
"nothing" without any output.
I discovered that it is actually doing something and within one or two
hours it finishes succ
Hi Junio,
Please pull German l10n updates to the maint branch, and
merge them back to the master branch later.
The following changes since commit 96db324a73fdada6fbe7b63221986f8f18cc63b0:
Merge git://github.com/git-l10n/git-po (2014-08-29 10:18:22 -0700)
are available in the git repository at
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
Hi Junio,
Please pull the following l10n updates to the maint branch.
The following changes since commit 869951babc24fef5c5cd58f86baefc25b6ed3765:
l10n: de.po: improve message when switching branches (2014-08-23
19:17:38 +0200)
are available in the git repository at:
git://github.com/git-l
Jiang Xin writes:
> The following changes since commit 49f1cb93a2f11845cfa2723611a729d3d7f02f0d:
>
> Git 2.1.0-rc0 (2014-07-27 15:22:22 -0700)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po
>
> for you to fetch changes up to f7fbc357f863ecc5323f3fcf2fc9cbf2aa
I'm sorry this pull request is late for git v2.1.0. I should send it out
yesterday night using the network of my new house, but after 2
weeks' business travel and home moving, I'm a bit lazy.
And German translation is still under review, so it is not included
in this pull request.
The following
Hello,
$ git pull --rebase=false
Already up-to-date.
$ git pull --rebase=true
Current branch v3.5 is up to date.
$ git pull --rebase=preserve
Successfully rebased and updated refs/heads/v3.5.
The last one being particularly misleading as nothing was actually
changed.
git version 1.9.3
Hi,
in our workflow commits can be removed from from the tip of the branch
in the
central repo. After this git pull --rebase on the "client" side may "lose"
commits, because the rewinding takes place without an fast-forwarding.
$ git log --oneline master #
On 2014-07-11 12.49, Ronald Bos wrote:
> Hi all,
>
> I am running git on Windows 8.1 (with all the latest updates installed), and
> it consequently crashes when I run "git pull" in my cloned working copy.
>
> I attached a screen shot of the message window (it is in D
Hi all,
I am running git on Windows 8.1 (with all the latest updates installed),
and it consequently crashes when I run "git pull" in my cloned working copy.
I attached a screen shot of the message window (it is in Dutch...)
This is my git version:
$ git --version
git version 1.9.4
On Thu, Jul 10, 2014 at 03:33:47PM +1000, Sam McLeod wrote:
> 'For already up-to-date repos return "Already up-to-date" which is the
> same message git pull returns.'
Please send your patches inline as a single body part, as generated by
"git format-patch"
As per: https://github.com/git/git/pull/100
'For already up-to-date repos return "Already up-to-date" which is the
same message git pull returns.'
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution w
301 - 400 of 584 matches
Mail list logo
