* [PATCH] git-mailinfo: document the -n option
From: Lukas Sandström @ 2008-07-10 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lukas Sandström, Git Mailing List
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
Documentation/git-mailinfo.txt | 5 ++++-
builtin-mailinfo.c | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index cc52db3..316bcc6 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -8,7 +8,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
SYNOPSIS
--------
-'git mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
+'git mailinfo' [-k] [-u | --encoding=<encoding> | -n] <msg> <patch>
DESCRIPTION
@@ -46,6 +46,9 @@ conversion, even with this flag.
from what is specified by i18n.commitencoding, this flag
can be used to override it.
+-n::
+ Disable all charset re-coding of the metadata.
+
<msg>::
The commit log message extracted from e-mail, usually
except the title line which comes from e-mail Subject.
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index fa6e8f9..962aa34 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -960,7 +960,7 @@ static int mailinfo(FILE *in, FILE *out, int ks, const char *encoding,
}
static const char mailinfo_usage[] =
- "git-mailinfo [-k] [-u | --encoding=<encoding>] msg patch <mail >info";
+ "git-mailinfo [-k] [-u | --encoding=<encoding> | -n] msg patch <mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
--
1.5.4.5
^ permalink raw reply related
* [PATCH] tutorial: clarify "pull" is "fetch + merge"
From: Junio C Hamano @ 2008-07-10 21:01 UTC (permalink / raw)
To: git; +Cc: Ian Katz, Miklos Vajna
In-Reply-To: <dc5b80bf0807101127q63e3132fw207baf0d88db3d9d@mail.gmail.com>
The document says that a fetch with a configured remote stores what are
fetched in the remote tracking branches "Unlike the longhand form", but
there is no longhand form "fetch" demonstrated earlier.
This adds a missing demonstration of the longhand form, and a new
paragraph to explain why some people might want to fetch before pull.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/gittutorial.txt | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index e71b561..38807f3 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -306,6 +306,32 @@ is the default.)
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
+Note that in general, Alice would want her local changes committed before
+initiating this "pull". If Bob's work conflicts with what Alice did since
+their histories forked, Alice will use her working tree and the index to
+resolve conflicts, and existing local changes will interfere with the
+conflict resolution process (git will still perform the fetch but will
+refuse to merge --- Alice will have to get rid of her local changes in
+some way and pull again when this happens).
+
+Alice can peek what Bob did without merging first, using the "fetch"
+command; this allows Alice to inspect what bob did, using a special
+symbol "FETCH_HEAD", in order to determine if he has anything worth
+pulling, like this:
+
+------------------------------------------------
+$ git fetch /home/bob/myrepo master
+$ git log -p ..FETCH_HEAD
+------------------------------------------------
+
+This operation is safe even if Alice has uncommitted local changes.
+
+After inspecting what Bob did, if there is nothing urgent, Alice may
+decide to continue working without pulling from Bob. If Bob's history
+does have something Alice would immediately need, Alice may choose to
+stash her work-in-progress first, do a "pull", and then finally unstash
+her work-in-progress on top of the resulting history.
+
When you are working in a small closely knit group, it is not
unusual to interact with the same repository over and over
again. By defining 'remote' repository shorthand, you can make
@@ -315,7 +341,7 @@ it easier:
$ git remote add bob /home/bob/myrepo
------------------------------------------------
-With this, Alice can perform the first operation alone using the
+With this, Alice can perform the first part of "pull" operation alone using the
'git-fetch' command without merging them with her own branch,
using:
^ permalink raw reply related
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Linus Torvalds @ 2008-07-10 20:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Toralf Förster, git
In-Reply-To: <m3d4lledbn.fsf@localhost.localdomain>
On Thu, 10 Jul 2008, Jakub Narebski wrote:
>
> Nevertheless it _could_ be unique.
NO IT COULD NOT!
It doesn't matter if it's unique in _one_ repository. What matters is if
it is globally unique!
Otherwise, people will start sending these version numbers out in emails,
and now somethign that was unique in the senders repo is actually not
unique at the receivers side (or _is_ unique, but points to something
totally different).
So no. A revision number like "v2.6.26-rc8-227" is fundamentally and
utterly broken. No way it should ever be accepted, even as a "helpful"
thing, because it's not helpful at all. It would be a sure way to crap.
Linus
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Nicolas Pitre @ 2008-07-10 20:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Pierre Habouzit, Git ML
In-Reply-To: <20080710202919.GB3717@blimp.local>
On Thu, 10 Jul 2008, Alex Riesen wrote:
> Nicolas Pitre, Thu, Jul 10, 2008 22:26:03 +0200:
> > On Thu, 10 Jul 2008, Alex Riesen wrote:
> > >
> > > Have you ever seen what happens to Windows XP on memory shortage?
> >
> > Who said this would be enabled on Windows?
> >
>
> Windows is just an example (exaggerated one).
Don't use that example then.
> There are just systems were resources are a problem.
Then on those systems you simply have to adjust the appropriate knob.
That's why those knobs are available after all.
Nicolas
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Alex Riesen @ 2008-07-10 20:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Pierre Habouzit, Git ML
In-Reply-To: <alpine.LFD.1.10.0807101625330.12484@xanadu.home>
Nicolas Pitre, Thu, Jul 10, 2008 22:26:03 +0200:
> On Thu, 10 Jul 2008, Alex Riesen wrote:
> >
> > Have you ever seen what happens to Windows XP on memory shortage?
>
> Who said this would be enabled on Windows?
>
Windows is just an example (exaggerated one). There are just systems
were resources are a problem.
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Nicolas Pitre @ 2008-07-10 20:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Pierre Habouzit, Git ML
In-Reply-To: <20080710201352.GA3717@blimp.local>
On Thu, 10 Jul 2008, Alex Riesen wrote:
> Nicolas Pitre, Thu, Jul 10, 2008 18:21:09 +0200:
> > On Thu, 10 Jul 2008, Junio C Hamano wrote:
> > > (2) exploding memory use, suspected to be due to malloc pool
> > > fragmentation under multithreading.
> ...
> > > but I do not
> > > recall the latter issue has been addressed.
> >
> > Well, for "standard" repositories such as the Linux kernel, things
> > always worked just fine. And commit eac12e2d is apparently helping a
> > lot with the remaining odd cases. And if someone has problems due to
> > this then a simple 'git config --global pack.threads 1' would restore
> > the non threaded behavior.
>
> Have you ever seen what happens to Windows XP on memory shortage?
Who said this would be enabled on Windows?
Nicolas
^ permalink raw reply
* Re: [JGIT PATCH 2/5] Don't display passwords on the console in fetch/push output
From: Robin Rosenberg @ 2008-07-10 20:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marek Zawirski, git
In-Reply-To: <200807102056.43912.robin.rosenberg@dewire.com>
>From 99c09cf2321f36eb81043aed2fa6834811ee762b Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Thu, 10 Jul 2008 22:16:19 +0200
Subject: [PATCH] Avoid password leak from URIIsh
The toString() method is commonly used for dumping information. We
never ever want to use toString when the password is needed. By masking
out the password we avoid unintentional password leaks.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/transport/URIish.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/URIish.java b/org.spearce.jgit/src/org/spearce/jgit/transport/URIish.java
index e022e57..632c8ad 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/URIish.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/URIish.java
@@ -318,7 +318,7 @@ public class URIish {
r.append(getUser());
if (getPass() != null) {
r.append(':');
- r.append(getPass());
+ r.append("PASSWORD");
}
}
--
1.5.6.2.220.g44701
^ permalink raw reply related
* Re: THREADED_DELTA_SEARCH
From: Alex Riesen @ 2008-07-10 20:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Pierre Habouzit, Git ML
In-Reply-To: <alpine.LFD.1.10.0807101212000.12484@xanadu.home>
Nicolas Pitre, Thu, Jul 10, 2008 18:21:09 +0200:
> On Thu, 10 Jul 2008, Junio C Hamano wrote:
> > (2) exploding memory use, suspected to be due to malloc pool
> > fragmentation under multithreading.
...
> > but I do not
> > recall the latter issue has been addressed.
>
> Well, for "standard" repositories such as the Linux kernel, things
> always worked just fine. And commit eac12e2d is apparently helping a
> lot with the remaining odd cases. And if someone has problems due to
> this then a simple 'git config --global pack.threads 1' would restore
> the non threaded behavior.
Have you ever seen what happens to Windows XP on memory shortage?
It freezes *hard*. Not a good behaviour for _default_ settings.
And if someone has no problems with memory, then a simple "git config
pack.threads 100" would restore the threaded behaviour for a
repository which supposedly will never grow up.
^ permalink raw reply
* Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
From: Junio C Hamano @ 2008-07-10 20:13 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git
In-Reply-To: <7vd4llpkxq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I have not looked at your implementation, but I do not think:
Sheesh. "I *do* think"...
> - The current one is not "fully reliable"; the user needs to know what
> he is doing. You might call it "prone to user errors".
>
> - "Test this merge-base before going forward, please" will add typically
> only one round of check (if you have more merge bases between good and
> bad, you need to test all of them are good to be sure), so it is not
> "slower nor more complex".
and I think it is a reasonable thing to do.
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Junio C Hamano @ 2008-07-10 20:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Toralf Förster, git
In-Reply-To: <m3d4lledbn.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Besides, it would be nice to have some command (git-rev-parse perhaps?)
> which could take ambiguous commit-ish, and list all commit which matches
> it.
Have fun writing it and send in a patch.
^ permalink raw reply
* Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
From: Junio C Hamano @ 2008-07-10 20:02 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git
In-Reply-To: <200807102126.37567.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Yeah, in that case...
>
>> The whole idea of "bisect" relies on that idea, that any ancestor of a
>> good commit is good. Otherwise you'd have to check the commits one by
>> one, not in a bisecting manner.
Didn't we already discuss this at length?
> No, you just need to check that the merge bases between the bad rev on one
> side and each good rev on the other side are good too. And if that is the
> case, then you can be sure that bisection will point to a first bad commit.
>
> So the choice is between a simple and fast but not fully reliable bisect, or
> a more complex and slower but fully reliable bisect.
I have not looked at your implementation, but I do not think:
- The current one is not "fully reliable"; the user needs to know what
he is doing. You might call it "prone to user errors".
- "Test this merge-base before going forward, please" will add typically
only one round of check (if you have more merge bases between good and
bad, you need to test all of them are good to be sure), so it is not
"slower nor more complex".
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-10 19:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3d4lledbn.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
At Thursday 10 July 2008 21:42:53 Jakub Narebski wrote :
> Besides, it would be nice to have some command (git-rev-parse perhaps?)
> which could take ambiguous commit-ish, and list all commit which matches
> it.
Oh yes :-)
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Jakub Narebski @ 2008-07-10 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Toralf Förster, git
In-Reply-To: <7vk5ftpnek.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Toralf Förster <toralf.foerster@gmx.de> writes:
>
> > git-describe gives an informative string about the current status:
> > tfoerste@n22 ~/devel/linux-2.6 $ git describe
> > v2.6.26-rc9-56-g6329d30
> >
> > I appended those strings to the names of my UML kernel executables.
> > Unfortunately I didn't used the commit id and now I'm wondering whether git
> > could accept v2.6.26-rc9-56 as well in future.
>
> It does take v2.6.26-rc9-56-g6329d30.
>
> It will never take v2.6.26-rc9-56. The world is not linear.
Nevertheless it _could_ be unique.
Besides, it would be nice to have some command (git-rev-parse perhaps?)
which could take ambiguous commit-ish, and list all commit which matches
it.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Johannes Schindelin @ 2008-07-10 19:29 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200807102057.15063.toralf.foerster@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 309 bytes --]
Hi,
On Thu, 10 Jul 2008, Toralf Förster wrote:
> I appended those strings to the names of my UML kernel executables.
> Unfortunately I didn't used the commit id and now I'm wondering whether
> git could accept v2.6.26-rc9-56 as well in future.
If that were unambiguous, yes. But it is not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
From: Christian Couder @ 2008-07-10 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Michael Haggerty, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0807101201210.3135@eeepc-johanness>
Hi,
Le jeudi 10 juillet 2008, Johannes Schindelin a écrit :
> Hi,
>
> On Thu, 10 Jul 2008, Christian Couder wrote:
> > Before this patch, "git bisect", when it was given some good revs that
> > are not ancestor of the bad rev, didn't check if the merge bases were
> > good. "git bisect" just supposed that the user knew what he was doing,
> > and that, when he said the revs were good, he knew that it meant that
> > all the revs in the history leading to the good revs were also
> > considered good.
>
> Well, it is not completely relying on the user.
Yeah it's relying on statistics too.
> The common scenario before a bisect is this: something used to work _all
> the time_, and all of a sudden, it does not anymore.
I agree that it is the most common scenario, perhaps 95% or perhaps even 99%
or more. But mistakes and special cases happens too.
For example people can forget to apply in the trunk a fix that is in a side
branch. Or they can revert in a side branch a big buggy feature just before
making a minor release; but in the trunk the big buggy feature is still
there and may very well have introduced regressions.
> So it is expected that there is no fix in the history. Not in the
> current branch, not in the "good" branch, not wherever.
>
> In that case, you are literally guaranteed that all ancestors of a good
> commit are good, too, because if there was a bad one, there would be a
> fix, too.
Yeah, in that case...
> The whole idea of "bisect" relies on that idea, that any ancestor of a
> good commit is good. Otherwise you'd have to check the commits one by
> one, not in a bisecting manner.
No, you just need to check that the merge bases between the bad rev on one
side and each good rev on the other side are good too. And if that is the
case, then you can be sure that bisection will point to a first bad commit.
So the choice is between a simple and fast but not fully reliable bisect, or
a more complex and slower but fully reliable bisect.
Regards,
Christian.
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Junio C Hamano @ 2008-07-10 19:08 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200807102057.15063.toralf.foerster@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> writes:
> git-describe gives an informative string about the current status:
> tfoerste@n22 ~/devel/linux-2.6 $ git describe
> v2.6.26-rc9-56-g6329d30
>
> I appended those strings to the names of my UML kernel executables.
> Unfortunately I didn't used the commit id and now I'm wondering whether git
> could accept v2.6.26-rc9-56 as well in future.
It does take v2.6.26-rc9-56-g6329d30.
It will never take v2.6.26-rc9-56. The world is not linear.
^ permalink raw reply
* Re: [JGIT PATCH 2/5] Don't display passwords on the console in fetch/push output
From: Robin Rosenberg @ 2008-07-10 18:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marek Zawirski, git
In-Reply-To: <1215670403-19191-3-git-send-email-spearce@spearce.org>
torsdagen den 10 juli 2008 08.13.20 skrev Shawn O. Pearce:
> When we show the URI we just fetched or pushed against there may
> be a user password embedded in that URI, as saved in the user's
> .git/config file. We shouldn't display that in public to prying
> eyes so nulling it out will give us a copy of the URI without that
> field in it.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> .../src/org/spearce/jgit/pgm/Fetch.java | 2 +-
> .../src/org/spearce/jgit/pgm/Push.java | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java
> index c9c997e..36a0592 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java
> @@ -71,7 +71,7 @@ class Fetch extends TextBuiltin {
> return;
>
> out.print("From ");
> - out.print(tn.getURI());
> + out.print(tn.getURI().setPass(null));
We did this a while ago. Sort of patching broken stuff instead of fixing what's broken, thus we should make URIIsh.toiString
not display the password.
-- robin
^ permalink raw reply
* feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-10 18:57 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hello,
git-describe gives an informative string about the current status:
tfoerste@n22 ~/devel/linux-2.6 $ git describe
v2.6.26-rc9-56-g6329d30
I appended those strings to the names of my UML kernel executables.
Unfortunately I didn't used the commit id and now I'm wondering whether git
could accept v2.6.26-rc9-56 as well in future.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Ian Katz @ 2008-07-10 18:27 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080710164520.GZ10347@genesis.frugalware.org>
Signed-off-by: Ian Katz <ifreecarve@gmail.com>
---
Documentation/gittutorial.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index e71b561..e4248b6 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -274,7 +274,7 @@ same machine, wants to contribute.
Bob begins with:
------------------------------------------------
-$ git clone /home/alice/project myrepo
+bob$ git clone /home/alice/project myrepo
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
@@ -285,7 +285,7 @@ Bob then makes some changes and commits them:
------------------------------------------------
(edit files)
-$ git commit -a
+bob$ git commit -a
(repeat as necessary)
------------------------------------------------
@@ -293,8 +293,8 @@ When he's ready, he tells Alice to pull changes from the rep
ository
at /home/bob/myrepo. She does this with:
------------------------------------------------
-$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
@@ -312,7 +312,7 @@ again. By defining 'remote' repository shorthand, you can m
ake
it easier:
------------------------------------------------
-$ git remote add bob /home/bob/myrepo
+alice$ git remote add bob /home/bob/myrepo
------------------------------------------------
With this, Alice can perform the first operation alone using the
@@ -320,7 +320,7 @@ With this, Alice can perform the first operation alone using
the
using:
-------------------------------------
-$ git fetch bob
+alice$ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
@@ -329,7 +329,7 @@ fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob/master
+alice$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -339,14 +339,14 @@ After examining those changes, Alice
could merge the changes into her master branch:
-------------------------------------
-$ git merge bob/master
+alice$ git merge bob/master
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-$ git pull . remotes/bob/master
+alice$ git pull . remotes/bob/master
-------------------------------------
Note that git pull always merges into the current branch,
@@ -355,7 +355,7 @@ regardless of what else is given on the command line.
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
-$ git pull
+bob$ git pull
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
@@ -364,7 +364,7 @@ repository in the repository configuration, and that locatio
n is
used for pulls:
-------------------------------------
-$ git config --get remote.origin.url
+bob$ git config --get remote.origin.url
/home/alice/project
-------------------------------------
@@ -376,7 +376,7 @@ Git also keeps a pristine copy of Alice's master branch unde
r the
name "origin/master":
-------------------------------------
-$ git branch -r
+bob$ git branch -r
origin/master
-------------------------------------
@@ -384,7 +384,7 @@ If Bob later decides to work from a different host, he can s
till
perform clones and pulls using the ssh protocol:
-------------------------------------
-$ git clone alice.org:/home/alice/project myrepo
+bob$ git clone alice.org:/home/alice/project myrepo
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
--
1.5.3.7
^ permalink raw reply related
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Robin Rosenberg @ 2008-07-10 18:02 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Shawn O. Pearce, Marek Zawirski, git
In-Reply-To: <e2b179460807100831g5d62a0a8nc7e7bf2715f0b9f1@mail.gmail.com>
torsdagen den 10 juli 2008 17.31.06 skrev Mike Ralphson:
> 2008/7/7 Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
> >
> > This command allows us to create simple or annotated tags.
> > PGP signed tags are not yet supported.
> >
> > Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
>
> Apologies this will be whitespace damaged, but it's trivial.
Don't do like that again : Had to use patch -l to apply this. Why doesn't git am have that?
Anyway thanks for the fix.
-- robin
^ permalink raw reply
* Re: git pull is slow
From: Stephan Hennig @ 2008-07-10 17:44 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Johannes Sixt
In-Reply-To: <20080710155016.GC32184@machine.or.cz>
Petr Baudis schrieb:
> On Thu, Jul 10, 2008 at 05:45:14PM +0200, Stephan Hennig wrote:
>>
>> No, I'm already using git+ssh.
>
> Oh, ok. By the way, how long are you hitting this issue? Just today,
> I have upgraded the chroot Git from some anonymous 2007-12-08 version
> to the almost-latest #next.
I don't know for sure. But I think I've had the issue since I started
accessing that repository in October 2007 (then with WinGit-0.2-alpha).
Best regards,
Stephan Hennig
PS: Attached is my .git/config. Could the repositoryformatversion line
trigger some sort of dumb transfer protocol?
> [core]
> repositoryformatversion = 0
> filemode = false
> bare = false
> logallrefupdates = true
> symlinks = false
> autocrlf = false
> [remote "origin"]
> url = git+ssh://xxx@repo.or.cz/srv/git/wortliste.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Andreas Ericsson @ 2008-07-10 16:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pierre Habouzit, Git ML
In-Reply-To: <4875C1CF.1010604@viscovery.net>
Johannes Sixt wrote:
> Pierre Habouzit schrieb:
>> I'm using it in production for quite a long time now, and I wonder if
>> there is any specific reason why it's not default. Debian activated it
>> by default too a couple of weeks ago, which means that it's in
>> production on quite a large scale, and there are no issues reported
>> either. Would a patch making it default be accepted ? It's quite handy
>> given that SMP machines are really pervasive nowadays…
>
> Don't forget to turn it off in the MINGW section in the Makefile since we
> don't have pthreads on Windows.
>
I started trying that, but ran into problems almost immediately. Enabling
pthreads by default and disabling it for certain systems means we screw
over those poor sods that have their own config.mak files on systems
where there's no <pthread.h> to include, or where that header file
requires a bunch of other stuff to be in first.
On the one hand, that's not nice.
On the other hand, those who have a config.mak are probably savvy enough
figure out how to amend it disable threads as well.
Opinions? I'm all for enabling THREADED_DELTA_SEARCH by default. I've
been using it ever since v1.5.4.3-193-g833e3df when using the same
.gitconfig on all my systems became a sane thing to do and I haven't
seen any ill effects what so ever from it, but how much can we screw
the build-system in place today, and what other systems would, by
default, require the NO_PTHREADS option in the Makefile?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Miklos Vajna @ 2008-07-10 16:45 UTC (permalink / raw)
To: Ian Katz; +Cc: git
In-Reply-To: <dc5b80bf0807100912rac7b730ga1ac035057d71d64@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
On Thu, Jul 10, 2008 at 12:12:09PM -0400, Ian Katz <ifreecarve@gmail.com> wrote:
> ---
> Documentation/gittutorial.txt | 26 +++++++++++++-------------
> 1 files changed, 13 insertions(+), 13 deletions(-)
Please add your Sign-off when sending patches, see
Documentation/SubmittingPatches.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Nicolas Pitre @ 2008-07-10 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Git ML
In-Reply-To: <7vy749pxbe.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1337 bytes --]
On Thu, 10 Jul 2008, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > I'm using it in production for quite a long time now, and I wonder if
> > there is any specific reason why it's not default. Debian activated it
> > by default too a couple of weeks ago, which means that it's in
> > production on quite a large scale, and there are no issues reported
> > either. Would a patch making it default be accepted ? It's quite handy
> > given that SMP machines are really pervasive nowadays…
>
> There were two issues, IIRC.
>
> (1) resulting pack could be suboptimal, due to delta-chain getting cut
> betweeen the worker thread boundary.
>
> (2) exploding memory use, suspected to be due to malloc pool
> fragmentation under multithreading.
>
> The former was only an issue with early iterations of the code and the
> current code has much improved behaviour on this point,
I would say it is even negligible.
> but I do not
> recall the latter issue has been addressed.
Well, for "standard" repositories such as the Linux kernel, things
always worked just fine. And commit eac12e2d is apparently helping a
lot with the remaining odd cases. And if someone has problems due to
this then a simple 'git config --global pack.threads 1' would restore
the non threaded behavior.
Nicolas
^ permalink raw reply
* [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Ian Katz @ 2008-07-10 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807101654080.18205@racer>
---
Documentation/gittutorial.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index e71b561..e4248b6 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -274,7 +274,7 @@ same machine, wants to contribute.
Bob begins with:
------------------------------------------------
-$ git clone /home/alice/project myrepo
+bob$ git clone /home/alice/project myrepo
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
@@ -285,7 +285,7 @@ Bob then makes some changes and commits them:
------------------------------------------------
(edit files)
-$ git commit -a
+bob$ git commit -a
(repeat as necessary)
------------------------------------------------
@@ -293,8 +293,8 @@ When he's ready, he tells Alice to pull changes from the rep
ository
at /home/bob/myrepo. She does this with:
------------------------------------------------
-$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
@@ -312,7 +312,7 @@ again. By defining 'remote' repository shorthand, you can m
ake
it easier:
------------------------------------------------
-$ git remote add bob /home/bob/myrepo
+alice$ git remote add bob /home/bob/myrepo
------------------------------------------------
With this, Alice can perform the first operation alone using the
@@ -320,7 +320,7 @@ With this, Alice can perform the first operation alone using
the
using:
-------------------------------------
-$ git fetch bob
+alice$ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
@@ -329,7 +329,7 @@ fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob/master
+alice$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -339,14 +339,14 @@ After examining those changes, Alice
could merge the changes into her master branch:
-------------------------------------
-$ git merge bob/master
+alice$ git merge bob/master
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-$ git pull . remotes/bob/master
+alice$ git pull . remotes/bob/master
-------------------------------------
Note that git pull always merges into the current branch,
@@ -355,7 +355,7 @@ regardless of what else is given on the command line.
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
-$ git pull
+bob$ git pull
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
@@ -364,7 +364,7 @@ repository in the repository configuration, and that locatio
n is
used for pulls:
-------------------------------------
-$ git config --get remote.origin.url
+bob$ git config --get remote.origin.url
/home/alice/project
-------------------------------------
@@ -376,7 +376,7 @@ Git also keeps a pristine copy of Alice's master branch unde
r the
name "origin/master":
-------------------------------------
-$ git branch -r
+bob$ git branch -r
origin/master
-------------------------------------
@@ -384,7 +384,7 @@ If Bob later decides to work from a different host, he can s
till
perform clones and pulls using the ssh protocol:
-------------------------------------
-$ git clone alice.org:/home/alice/project myrepo
+bob$ git clone alice.org:/home/alice/project myrepo
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
--
1.5.3.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox