Hi, Junio
Please merge this commit to the maint branch.
The following changes since commit e230c568c4b9a991e3175e5f65171a566fd8e39c:
Git 1.8.4 (2013-08-23 11:49:46 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to
Jiang Xin worldhello@gmail.com writes:
Please merge this commit to the maint branch.
The following changes since commit e230c568c4b9a991e3175e5f65171a566fd8e39c:
Git 1.8.4 (2013-08-23 11:49:46 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
Le vendredi 30 août 2013 09:54:59 Junio C Hamano a écrit :
Jiang Xin worldhello@gmail.com writes:
Please merge this commit to the maint branch.
The following changes since commit
e230c568c4b9a991e3175e5f65171a566fd8e39c:
Git 1.8.4 (2013-08-23 11:49:46 -0700)
are available in
Jean-Noël AVILA jn.av...@free.fr writes:
Le vendredi 30 août 2013 09:54:59 Junio C Hamano a écrit :
Jiang Xin worldhello@gmail.com writes:
Please merge this commit to the maint branch.
The following changes since commit
e230c568c4b9a991e3175e5f65171a566fd8e39c:
Git 1.8.4
git pull . works, but git merge is the recommended
way for new users to do things. (The old description
also should have read The former is actually *not* very
commonly used.)
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/user-manual.txt | 8
1 file changed, 4
Thomas Ackermann th.ac...@arcor.de writes:
git pull . works, but git merge is the recommended
way for new users to do things. (The old description
also should have read The former is actually *not* very
commonly used.)
It does not matter that you are unaware other people use it often.
I'd
On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote:
Thomas Ackermann th.ac...@arcor.de writes:
git pull . works, but git merge is the recommended
way for new users to do things. (The old description
also should have read The former is actually *not* very
commonly used
Jonathan Nieder jrnie...@gmail.com writes:
On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote:
Thomas Ackermann th.ac...@arcor.de writes:
git pull . works, but git merge is the recommended
way for new users to do things. (The old description
also should have read The former
git pull . works, but git merge is the recommended
way for new users to do things. (The old description
also should have read The former is actually *not* very
commonly used.)
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/user-manual.txt | 15 ++-
1 file
Thomas Ackermann th.ac...@arcor.de writes:
git pull . works, but git merge is the recommended
way for new users to do things. (The old description
also should have read The former is actually *not* very
commonly used.)
I think it is probably a good idea to replace pull . in the two
later
.)
-The `git pull` command can also be given `.` as the remote repository,
-in which case it just merges in a branch from the current repository; so
-the commands
-
--
-$ git pull . branch
-$ git merge branch
be
updated to point to the latest commit from the upstream branch.)
-The `git pull` command can also be given `.` as the remote repository,
-in which case it just merges in a branch from the current repository; so
-the commands
-
--
-$ git pull
Hey,
Following up on an old thread (2008):
http://git.661346.n2.nabble.com/pull-preserve-merges-td1471688.html
I'd like to finally add a config parameter/setting to allow git pull to preserve
merges when it's rebasing. This addresses a somewhat common boundary case of a
locally merged feature
I think there's a bug in git pull. Doing a git pull in a fresh repository
without any commits removes files in the index.
Example:
$ mkdir foo
$ cd foo
$ git init
$ touch file1 file2
$ git add file1
$ ls
file1 file2
$ git pull https://github.com/sos4nt/empty.git master
$ ls
Signed-off-by: Mihai Capotă mi...@mihaic.ro
---
Documentation/git-pull.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c975743..eec4c1d 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
Mihai Capotă mi...@mihaic.ro writes:
Signed-off-by: Mihai Capotă mi...@mihaic.ro
---
Thanks.
It might be better to make it which resulted in complex conflicts,
though.
Documentation/git-pull.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Signed-off-by: Mihai Capotă mi...@mihaic.ro
---
Documentation/git-pull.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c975743..24ab07a 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
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
When I do a git pull, I am getting a messages that changes to local
files would be overwritten by a merge, but I have not changed these
files locally at all, I have not opened them in my IDE.
This happens every now and then.
1) Why does this happen?
2) How do I prevent this from happening
On 17.01.2013, at 20:29, Jay Vee wrote:
When I do a git pull, I am getting a messages that changes to local
files would be overwritten by a merge, but I have not changed these
files locally at all, I have not opened them in my IDE.
This happens every now and then.
1) Why does this happen
I added a new origin to a repository and did git pull and got this message:
* [new branch] master - origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull remote branch
If you
Dan Rosén d...@student.chalmers.se writes:
git branch --set-upstream master origin/branch
This has been fixed already in 1.8.0.1
cmn
--
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
On Thu, Oct 25, 2012 at 02:50:37PM -0400, Phil Hord wrote:
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle of an otherwise successful
On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote:
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle of an otherwise successful
Jeff King wrote:
On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote:
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle
I just ran git pull, and it suggested that I should use `git branch
--set-upstream`. Yet when I used it, git-branch told me that the flag is
deprecated. Git version 1.8.0.
tom
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few
Add Signed-off-by...
--
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
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few
Hi,
On Tue, Sep 25, 2012 at 4:15 PM, Max Horn post...@quendi.de wrote:
On 18.09.2012, at 14:40, Joachim Schmitz wrote:
From: Andreas Ericsson [mailto:a...@op5.se]
Sent: Tuesday, September 18, 2012 1:46 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from
I saw some unexpected usage output today in git pull --rebase when I
was on a detached head.
$ git pull --rebase origin BL/3.0
usage: git merge-base [-a|--all] commit commit...
or: git merge-base [-a|--all] --octopus commit...
or: git merge-base --independent commit...
or: git merge-base
On Fri, Oct 05, 2012 at 10:20:37PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
@@ -617,6 +618,8 @@ static struct commit_list
*paint_down_to_common(struct commit *one, int n, struc
one-object.flags |= PARENT1;
commit_list_insert_by_date(one,
When refactoring the merge-base computation to reduce the pairwise
O(n*(n-1)) traversals to parallel O(n) traversals, the code forgot
that timestamp based heuristics needs each commit to have been
parsed. This caused an empty git pull to spend cycles, traversing
the history all the way down
On Fri, Oct 05, 2012 at 01:34:02PM -0700, Junio C Hamano wrote:
OK, I think I am convinced myself that this patch is the right fix.
The performance regression Markus saw is in fmt-merge-message, and
it is caused by the updated remove_redundant() that is used by
get_merge_bases_many() and
Jeff King p...@peff.net writes:
@@ -617,6 +618,8 @@ static struct commit_list *paint_down_to_common(struct
commit *one, int n, struc
one-object.flags |= PARENT1;
commit_list_insert_by_date(one, list);
+ if (!n)
+ return list;
for (i = 0; i n; i++) {
Hi,
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version 1.7.12 is much quicker:
markus@x4 linux % time git pull
Already up-to-date.
git pull 0.10s user 0.02s
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version 1.7.12 is much quicker:
markus
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
From: Junio C Hamano gits...@pobox.com
乙酸鋰 ch3co...@gmail.com writes:
The order of options in git pull is not clear in the documentation
It only says
git pull [options] [repository [refspec...]]
So we have no idea which options should come first
I tried
git pull -v --no-tags --progress
synopsis ?
e.g.
git pull [pull_options] [merge_options] [fetch_options [repository
[refspec…]]
We certainly could do that, but I was hoping somebody would
volunteer to make it easier to the end users so that they do not
have to remember which one is which.
The perhaps something like
Hi,
The order of options in git pull is not clear in the documentation
It only says
git pull [options] [repository [refspec...]]
So we have no idea which options should come first
I tried
git pull -v --no-tags --progress --no-ff origin
but failed with unknown option 'no-ff'.
But if I ran
git
乙酸鋰 ch3co...@gmail.com writes:
The order of options in git pull is not clear in the documentation
It only says
git pull [options] [repository [refspec...]]
So we have no idea which options should come first
I tried
git pull -v --no-tags --progress --no-ff origin
but failed with unknown
Around 09/25/2012 05:15 PM, Max Horn scribbled:
I think there is a lot of demand for a git-hg bridge, a way to seemlessly
access a Mercurial repository as if it was a git repository. A converse to
hg-git http://hg-git.github.com/
I've already mentioned this, but such a tool already exists
On 26.09.2012, at 09:38, Georgi Chorbadzhiyski wrote:
Around 09/25/2012 05:15 PM, Max Horn scribbled:
I think there is a lot of demand for a git-hg bridge, a way to seemlessly
access a Mercurial repository as if it was a git repository. A converse to
hg-git http://hg-git.github.com/
Around 09/26/2012 11:46 AM, Max Horn scribbled:
On 26.09.2012, at 09:38, Georgi Chorbadzhiyski wrote:
Around 09/25/2012 05:15 PM, Max Horn scribbled:
I think there is a lot of demand for a git-hg bridge, a way to seemlessly
access a Mercurial repository as if it was a git repository. A
I definitely wrote git-hg for the purpose of checking out a mercurial
repo so I can develop locally against it with git and then submit
patches. Getting push support was never really a priority for me.
Someone did eventually contribute some mechanism for pushing things
back in a pull request, so I
On 09/18/2012 02:40 PM, Joachim Schmitz wrote:
From: Andreas Ericsson [mailto:a...@op5.se]
Sent: Tuesday, September 18, 2012 1:46 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
On 09/18/2012 01:22 PM, Joachim Schmitz wrote
Gelonida N wrote:
On 09/18/2012 02:40 PM, Joachim Schmitz wrote:
From: Andreas Ericsson [mailto:a...@op5.se]
Sent: Tuesday, September 18, 2012 1:46 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
On 09/18/2012 01:22 PM, Joachim Schmitz
Hi there,
On 18.09.2012, at 14:40, Joachim Schmitz wrote:
From: Andreas Ericsson [mailto:a...@op5.se]
Sent: Tuesday, September 18, 2012 1:46 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
On 09/18/2012 01:22 PM, Joachim Schmitz
From: Max Horn [mailto:post...@quendi.de]
Sent: Tuesday, September 25, 2012 4:15 PM
To: Joachim Schmitz
Cc: 'Andreas Ericsson'; git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
Hi there,
On 18.09.2012, at 14:40, Joachim Schmitz wrote:
From: Andreas
Angelo Borsotti angelo.borso...@gmail.com writes:
When it executes the git pull it spends on my computer some 30 seconds,
obviously transferring the pdf file, that then it disregards because of the
merge=binary attribute.
When a commit contains many binary files, the command spends a lot
Is there an easy way to get git to clone/pull from a Mercurial repository?
Bye, Jojo
--
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
From: Georgi Chorbadzhiyski [mailto:g...@unixsol.org]
Sent: Tuesday, September 18, 2012 2:06 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
Around 09/18/2012 02:22 PM, Joachim Schmitz scribbled:
Is there an easy way to get git
From: Andreas Ericsson [mailto:a...@op5.se]
Sent: Tuesday, September 18, 2012 1:46 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
On 09/18/2012 01:22 PM, Joachim Schmitz wrote:
Is there an easy way to get git to clone/pull from
with extra information in it.
And indeed, the actual thing I should pull is not at all for-linus,
it seems to be your tags/sound-3.6 tag.
I don't know if this is the old git pull-request breakage where it
stupidly corrects the remote branch when it verifies the branch
name, or whether it's some other
to a branch, but then the pull request clearly implies there
is a tag with extra information in it.
And indeed, the actual thing I should pull is not at all for-linus,
it seems to be your tags/sound-3.6 tag.
I don't know if this is the old git pull-request breakage where it
stupidly corrects
if this is the old git pull-request breakage where it
stupidly corrects the remote branch when it verifies the branch
name, or whether it's some other scripting problem. I think current
git versions should not mess up the tag information, if that's the
cause, but please verify.
Oops, yes, it's
On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote:
FWIW, it was an output from git-pull-request, which fell back to the
equivalent branch. Usually I check it manually but I forgot it at
this time just before going to a meeting.
This was with git 1.7.11.5. I'll check
At Thu, 13 Sep 2012 09:03:44 -0400,
Jeff King wrote:
On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote:
FWIW, it was an output from git-pull-request, which fell back to the
equivalent branch. Usually I check it manually but I forgot it at
this time just before going
Takashi Iwai ti...@suse.de writes:
I can't reproduce here. What is your exact request-pull invocation?
This question was not answerd. Did you ask request-pull to ask for
a branch to be pulled, or did you ask it to ask for the tag to be
pulled?
If the former, I would have say it is a pebcak.
Miklos Vajna vmik...@suse.cz writes:
I agree that it's a bit strange, but based on a quick search, it seems
multiple projects already advertise git pull -r (i.e. not --rebase and
not a configuration option):
http://lilypond.org/doc/v2.15/Documentation/contributor/pulling-and-rebasing
http
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Sent: Thursday, August 16, 2012 9:23 PM
Philip Oakley philipoak...@iee.org writes:
I wasn't aware of the abbreviated options capability. Is meant to
be in the man pages as I couldn't find it, or is it
On Thu, Aug 16, 2012 at 11:18:40PM -0700, Junio C Hamano gits...@pobox.com
wrote:
From: Miklos Vajna vmik...@suse.cz
Date: Thu, 16 Aug 2012 11:50:18 +0200
Subject: [PATCH] man: git pull -r is a short for --rebase
Letting the --rebase option squat on the short-and-sweet single
letter option
Miklos Vajna vmik...@suse.cz writes:
On Thu, Aug 16, 2012 at 11:18:40PM -0700, Junio C Hamano gits...@pobox.com
wrote:
From: Miklos Vajna vmik...@suse.cz
Date: Thu, 16 Aug 2012 11:50:18 +0200
Subject: [PATCH] man: git pull -r is a short for --rebase
Letting the --rebase option squat
From: Junio C Hamano gits...@pobox.com
Sent: Friday, August 17, 2012 7:19 AM
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Sent: Thursday, August 16, 2012 9:23 PM
Philip Oakley philipoak...@iee.org writes:
I wasn't aware of the abbreviated options
Philip Oakley philipoak...@iee.org writes:
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ca85d1d..75b35ce 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -22,11 +22,13 @@ unusually rich command set that provides both high-level
operations
and full
From: Junio C Hamano gits...@pobox.com
Sent: Friday, August 17, 2012 8:48 PM
Philip Oakley philipoak...@iee.org writes:
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ca85d1d..75b35ce 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -22,11 +22,13 @@ unusually
-options.txt[]
:git-pull: 1
+-r::
--rebase::
Rebase the current branch on top of the upstream branch after
fetching. If there is a remote-tracking branch corresponding to
--
1.7.7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
-pull.txt
@@ -101,6 +101,7 @@ include::merge-options.txt[]
:git-pull: 1
+-r::
--rebase::
Rebase the current branch on top of the upstream branch after
fetching. If there is a remote-tracking branch corresponding to
I am not sure if this is worth it, as it comes from a natural
..67fa5ee 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -101,6 +101,7 @@ include::merge-options.txt[]
:git-pull: 1
+-r::
--rebase::
Rebase the current branch on top of the upstream branch after
fetching. If there is a remote-tracking branch corresponding to
I am
I sent the patch as a (newcomer) friend today asked if it's intentional
that -r is undocumented in 'man git-pull'.
It is more intentional than it is by accident that we don't.
We would really think hard to avoid breaking when introducing new
options whose long name could begin with v or q
Philip Oakley philipoak...@iee.org writes:
I wasn't aware of the abbreviated options capability. Is meant to
be in the man pages as I couldn't find it, or is it described
differently?
$ git help gitcli
is the closest that comes to mind.
If it is not reachable from git help git, we may want
Junio C Hamano gits...@pobox.com writes:
We would really think hard to avoid breaking when introducing new
options whose long name could begin with v or q to avoid
breaking -v and -q that are common across commands
[today's lesson for me; do not type while eating]
Sorry.
We would
Johannes Sixt j...@kdbg.org writes:
Are you sure? This adds '-r', not '--r', i.e., the single-letter option
'r', to the documentation, which is not something we want to hide, usually.
I actually think --rebase squatting on short-and-sweet -r was an
accident, and we are saved by not endorsing
From: Junio C Hamano gits...@pobox.com
Sent: Thursday, August 16, 2012 9:23 PM
Philip Oakley philipoak...@iee.org writes:
I wasn't aware of the abbreviated options capability. Is meant to
be in the man pages as I couldn't find it, or is it described
differently?
$ git help gitcli
is the
would _always_ want to run pull --rebase, which means
you would likely have it configured and would not be typing from the
command line.
I agree that it's a bit strange, but based on a quick search, it seems
multiple projects already advertise git pull -r (i.e. not --rebase and
not a configuration
Hi Junio,
The following changes since commit 58ebd9865d2bb9d42842fbac5a1c4eae49e92859:
vcs-svn/svndiff.c: squelch false unused warning from gcc (2012-01-27
11:58:56 -0800)
are available at:
git://repo.or.cz/git/jrn.git svn-fe
The first three commits duplicate changes that are already in
On Sat, Jul 7, 2012 at 3:10 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi Junio,
The following changes since commit 58ebd9865d2bb9d42842fbac5a1c4eae49e92859:
vcs-svn/svndiff.c: squelch false unused warning from gcc (2012-01-27
11:58:56 -0800)
are available at:
David Michael Barr davidb...@google.com writes:
On Sat, Jul 7, 2012 at 3:10 AM, Jonathan Nieder jrnie...@gmail.com wrote:
...
Some of the patches had to change a little since v2 of db/vcs-svn, so
I'll be replying with a copy of the patches for reference.
David has looked the branch over and
Junio, I think this happened when you rewrote the pull/push stuff to do
shorthands..
Lately, git pull generates a lot of extra crud in the single-line commit
message, which is annoying because a lot of tools will thus actually not
show enough of the line to be valid.
For example, it used to get
branches (and not provided an exit code to
stop my script from trying the merge).
Here's what I did this morning.
1) Updated my linus branch:
$ git checkout linus git pull linus
This appeared to work just fine ... except that when I
check the status of my tree I see:
$ git status
[EMAIL PROTECTED] writes:
Aha ... is this the problem that caught me out last week (when
I ended up with 10 extra files attached to one of my commits)?
Plausible.
1) Updated my linus branch:
$ git checkout linus git pull linus
I would assume that just after git checkout linus before
Luck, Tony [EMAIL PROTECTED] writes:
What I want is to get the latest from kernel.org...linus...master
and update my .refs/heads/linus with the new SHA1.
I'd like to be able to do that without touching what is in my
index, and without changing the state of any checked out files.
If that is
Amos Waterland sent in a patch for the pre-multi-head aware
version of git pull to do this, but the code changed quite a
bit since then. If there is no argument given to pull from, and
if origin makes sense, default to fetch/pull from origin
instead of barfing.
[jc: besides, the patch by Amos
--
git-pull-script | 14 ++
3 files changed, 10 insertions(+), 85 deletions(-)
delete mode 100755 git-parse-remote
3a071a02828c71bbfdc2749d25814906cd9c8b18
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -64,7 +64,7 @@ SCRIPTS
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like '@'. Sue me.
So I drop the @ and then get:
$ git-pull-script someserver.org:/public_html/udev.git/
fatal: I
On Wed, 6 Jul 2005, Greg KH wrote:
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like '@'. Sue me.
So I drop the @ and then get:
$ git-pull-script
On Wed, Jul 06, 2005 at 01:46:27PM -0700, Greg KH wrote:
Ok, below is a patch for this. It works, but then errors out with:
bash: git-upload-pack: command not found
fatal: unexpected EOF
So I'm guessing that I have to convince the server owner to update their
version of git
On Wed, 6 Jul 2005, Greg KH wrote:
Ok, below is a patch for this. It works, but then errors out with:
bash: git-upload-pack: command not found
fatal: unexpected EOF
So I'm guessing that I have to convince the server owner to update their
version of git too?
The easiest way
On Wed, Jul 06, 2005 at 01:37:55PM -0700, Linus Torvalds wrote:
On Wed, 6 Jul 2005, Greg KH wrote:
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like
On Fri, 22 Apr 2005 [EMAIL PROTECTED] wrote:
git log seems to have problems interpreting the dates ... looking at the
commit entries, the time is right ... but it appears that git log applies
the timezone correction twice, so the changes I just applied at 14:46 PDT
look like I made them at
Executive summary: I received some alarming errors while doing
a git pull of the latest kernel from kernel.org, but it appears
that all is well. Continue reading for the gory details.
I updated my git-pasky tools this morning, by doing git pasky pull, make, make
install.
Working from a repo
Dear diary, on Thu, Apr 21, 2005 at 03:55:26PM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
Executive summary: I received some alarming errors while doing
a git pull of the latest kernel from kernel.org, but it appears
that all is well. Continue reading for the gory
Dear diary, on Fri, Apr 22, 2005 at 12:29:07AM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
I can't quite see how to manage multiple heads in git. I notice that in
your tree on kernel.org that .git/HEAD is a
Dear diary, on Fri, Apr 22, 2005 at 03:48:35AM CEST, I got a letter
where Inaky Perez-Gonzalez [EMAIL PROTECTED] told me that...
Petr Baudis [EMAIL PROTECTED] writes:
I've just added to git-pasky a possibility to refer to branches
inside of repositories by a fragment identifier:
Petr Baudis [EMAIL PROTECTED] writes:
Still, why would you escape it? My shell will not take # as a
comment start if it is immediately after an alphanumeric character.
I guess there MIGHT be some command shell implementation
that stupidly _DID_ accept # as a comment character,
even immediately
401 - 500 of 502 matches
Mail list logo
