* Re: Let me ask again: How do we import patches from non-git sources?
From: J. Bruce Fields @ 2007-06-12 18:13 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <1181665653.4194.24.camel@zealous.synapsedev.com>
On Tue, Jun 12, 2007 at 09:27:33AM -0700, Marc Singer wrote:
> On Wed, 2007-06-06 at 13:54 -0400, J. Bruce Fields wrote:
> > Based on my notes from the last time I needed to feed a bunch of
> > non-mbox, non-git-produced patches into git-am, the hard part was
> > figuring out how it split a file into separate messages; my notes say:
> >
> > "Finds lines begining with "From " and ending with "hh:mm:ss
> > yyyy". See builtin-mailsplit code for more details."
> >
> > Other than that, I think it just needs and From: and Subject: lines to
> > get author and first-line of the commit. the git-am man page has some
> > documentation of this. It could probably use more.
> >
>
> I'm not sure that I understand your response.
>
> git-am complains that it cannot find an email address, but raw patches
> seldom have these. So, either we could use another command, or it would
> be handy if we could supply the email address to git-am (or some other
> data it needs so that it can split the patch.) I suppose the mistaken
> assumption is that the patch source in an email instead of already being
> a nice clean patch.
I think it's intentional. You need some standard format git-am can use
to split out the patches and find the comments and the authorship
information (for the Author: field on the commit), so why not just use
something like mbox?
And it could provide some fallback for the "Author:" information in the
case where it didn't find that, but we wouldn't want that to be the
default if it meant risking silently losing authorship information. I
suppose an "--author" option to git-am might be convenient sometimes.
But personally I always just add those headers by hand (or with a
script). It's not that hard; I the minimum required is just three
lines, I think:
From git-owner@vger.kernel.org Tue jun 12 11:43:40 2007
From: someone <someone@example.com>
Subject: [PATCH] do something
Do something complicated.
---
diff a/foo b/foo
...
And often I need different authors on different patches anyway, so
git-am --author wouldn't help.
Of course if you've just got one patch to import, you can git-apply and
then commit.
--b.
(PS: Standard practice around here is to leave people on the To: and/or
Cc: lines when you reply, and for me at least that'd be easier.)
^ permalink raw reply
* Re: Port forwarding
From: Alex Riesen @ 2007-06-12 18:12 UTC (permalink / raw)
To: Claudio Scordino; +Cc: git
In-Reply-To: <466EBB1B.9060405@gmail.com>
Claudio Scordino, Tue, Jun 12, 2007 17:26:19 +0200:
>
> However, I don't know how make git-clone go on a port different than the
> default (9418).
>
git clone git://server:port/~cloud/project/
^ permalink raw reply
* Re: Port forwarding
From: Linus Torvalds @ 2007-06-12 18:08 UTC (permalink / raw)
To: Claudio Scordino; +Cc: git
In-Reply-To: <466EBB1B.9060405@gmail.com>
On Tue, 12 Jun 2007, Claudio Scordino wrote:
>
> how can I specify the port in git-clone when cloning from a server running
> git-daemon ?
Just doing
git clone git://hostname:port/repo/path/name
should be fine.
> I need to set port forwarding from a public server to a private server.
> The public server, however, already hosts a git-daemon on port 9418.
> So, I have to use a different port for the forwarding.
>
> My idea is to let the public server listen on a different port (e.g. 9419) and
> make it redirect all the incoming connections to the port 9418 of the private
> server.
I would argue that it probably makes more sense to make the _private_
server listen to another port (fewer people who need to use the :<port>
syntax). But hey, that's a matter of taste.
> However, I don't know how make git-clone go on a port different than the
> default (9418).
See above. The obvious thing should "just work".
Linus
^ permalink raw reply
* Re: Problem with a push
From: Linus Torvalds @ 2007-06-12 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git, plexq
In-Reply-To: <7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com>
On Tue, 12 Jun 2007, Junio C Hamano wrote:
>
> I think what we might want to do around this area are:
>
> - Don't change anything, if the command line says refspec, or
> the remote has push refspec specified.
>
> - When doing 'matching refs', do it only under refs/heads/.
I think these both are "obviously good".
> - Ship with a receive-pack hook that attempts a 3-way merge
> update when the currently checked out branch is updated.
Well, if it wasn't a fast-forward, then the user did a push with "git push
-f", which implies _replacing_ the currently checked out branch.
So by three-way, I assume you mean the "git checkout -m" behaviour, and a
fast-forward. What about a non-fast-forward (ie "git push -f"?) Should
that imply "git checkout -f" semantics on the receiving side? That would
kind of be sensible.
Linus
^ permalink raw reply
* [PATCH 3/3] gitview: Catch exception from rindex
From: Aneesh Kumar K.V @ 2007-06-12 17:59 UTC (permalink / raw)
To: git; +Cc: Aneesh Kumar K.V
In-Reply-To: <392459374618773353ea560d021dd3211d143d86.1181671162.git.aneesh.kumar@gmail.com>
If we have really short read the input buffer will not
have a new line and rindex with through the ValueError
exception. Handle the same gracefully
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 01128f4..4f39ddd 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -421,8 +421,13 @@ class AnnotateWindow(object):
self.prev_read = ""
if (buffer[len(buffer) -1] != '\n'):
- self.prev_read = buffer[buffer.rindex("\n"):(len(buffer))]
- buffer = buffer[0:buffer.rindex("\n")]
+ try:
+ newline_index = buffer.rindex("\n")
+ except ValueError:
+ newline_index = 0
+
+ self.prev_read = buffer[newline_index:(len(buffer))]
+ buffer = buffer[0:newline_index]
for buff in buffer.split("\n"):
annotate_line = re.compile('^([0-9a-f]{40}) (.+) (.+) (.+)$')
--
1.5.2.1.239.g75d8-dirty
^ permalink raw reply related
* Re: [PATCH] Edit user manual for grammar
From: J. Bruce Fields @ 2007-06-12 17:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200706121643.19837.andyparkins@gmail.com>
On Tue, Jun 12, 2007 at 04:43:19PM +0100, Andy Parkins wrote:
> - "last-resort" is two words, not a conjoined word, it doesn't require
> the hyphen
Right, but when you've got a couple words functioning together to modify
a following noun, the hyphen's pretty standard: "rosy-fingered dawn".
Is this case an exception? I suspect it's fine either way....
> - "method of" is vulgar, "method for" is nicer
Reference?
> - "recovery" becomes "recovering" from Steve Hoelzer's original version
> of this patch
> - "if you want" is nicer as "if you wish"
> - "you may" should be "you can"; "you may" is "you have permission to"
> rather than "you can"'s "it is possible to"
Fair enough, thanks.
What we really need is a complete recovery tutorial to stick in here
someplace. (One day git complains about a corrupt pack file. What do
you do?) What's been stopping me from doing it, besides time, is no
idea how to come up with a good example to work with.
--b.
^ permalink raw reply
* Port forwarding
From: Claudio Scordino @ 2007-06-12 15:26 UTC (permalink / raw)
To: git
Hi all,
how can I specify the port in git-clone when cloning from a server running
git-daemon ?
The issue is the following.
I need to set port forwarding from a public server to a private server.
The public server, however, already hosts a git-daemon on port 9418.
So, I have to use a different port for the forwarding.
My idea is to let the public server listen on a different port (e.g. 9419) and
make it redirect all the incoming connections to the port 9418 of the private
server.
However, I don't know how make git-clone go on a port different than the default
(9418).
Many thanks in advance,
Claudio
^ permalink raw reply
* Re: [RFC][PATCH 10/10] Sparse: fix a "symbol 'weak_match' shadows an earlier one" warning
From: Ramsay Jones @ 2007-06-12 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vr6olh7pb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>> ---
>> connect.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/connect.c b/connect.c
>> index da89c9c..d4051dd 100644
>> --- a/connect.c
>> +++ b/connect.c
>> @@ -179,7 +179,6 @@ static int count_refspec_match(const char *pattern,
>> for (weak_match = match = 0; refs; refs = refs->next) {
>> char *name = refs->name;
>> int namelen = strlen(name);
>> - int weak_match;
>>
>> if (namelen < patlen ||
>> memcmp(name + namelen - patlen, pattern, patlen))
>
> This one is an obvious bug.
Indeed ;-)
Also, I'm guessing it does not bring your machine down like a house of cards.
... Essentially, it makes weak matches
> ignored. Unfortunately this has been hiding a larger bug in the
> caller of this function. I am refactoring the mess right now.
>
Great. Hopefully it will also address the cygwin issue.
ATB
Ramsay Jones
^ permalink raw reply
* Re: [RFC][PATCH 00/10] Sparse: Git's "make check" target
From: Ramsay Jones @ 2007-06-12 17:37 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, GIT Mailing-list, linux-sparse
In-Reply-To: <466A5204.6060200@freedesktop.org>
Josh Triplett wrote:
> Ramsay Jones wrote:
>> fix most of those problems. (the output from "make check" was about 16k
>> lines at one point!). Git also tickled a bug in sparse 0.2, which resulted
>> in some 120+ lines of bogus warnings; that was fixed in version 0.3 (commit
>> 0.2-15-gef25961). As a result, sparse version 0.3 + my patches, elicits 106
>> lines of output from "make check".
>
> One note about using Sparse with Git: you almost certainly don't want to pass
> -Wall to sparse, and current Git passes CFLAGS to Sparse which will do exactly
> that. -Wall turns on all possible Sparse warnings, including nitpicky
> warnings and warnings with a high false positive rate.
I have to say that, my initial reaction, was to disagree; I certainly want to
pass -Wall to sparse! Why not? Did you have any particular warnings in mind?
(I haven't noticed any that were nitpicky or had a high false positive rate!)
... You should start from
> the default set of Sparse warnings, and add additional warnings as desired, or
> turn off those you absolutely can't live with.
Why not "-Wall -Wno-nitpicky -Wno-false-positive" ;-)
... Current Sparse from Git (post
> 0.3, after commit e18c1014449adf42520daa9d3e53f78a3d98da34) has a change to
> cgcc to filter out -Wall, so you can pass -Wall to GCC but not Sparse.
Yes, I noticed that. Again, I'm not sure I agree.
I didn't comment on that patch, because my exposure to sparse is very limited.
So far I've only run it on git, so I can hardly claim any great experience with
the output from sparse. However, 105 lines of output (which represents 71 warnings)
for 72,974 lines of C (in 179 .c files) did not seem at all unreasonable.
>> [Note: As far as the NULL pointer warnings are concerned, I don't much care either
>> way. I just used that as an example (also note patch 02). Having said that, I
>> do think that the "NULL is the only one true null pointer" brigade need to
>> chill out a little; in fact I remember when 0 was the *only* null pointer.]
>
> And at one point prototypes didn't exist either. :)
Yes, but that was actually an improvement to the language ;-)
(As I say above, I don't really care about the NULL pointer example; I hope
the main point was not lost)
All the Best,
Ramsay Jones
^ permalink raw reply
* [PATCH 2/2] gitview: run blame with -M and -C
From: Aneesh Kumar K.V @ 2007-06-12 17:35 UTC (permalink / raw)
To: git; +Cc: Aneesh Kumar K.V
In-Reply-To: <392459374618773353ea560d021dd3211d143d86.1181669428.git.aneesh.kumar@gmail.com>
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
pass -M and -C option to git-blame so that blame browsing
works when the data is copied over from other files.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 286e974..01128f4 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -530,7 +530,7 @@ class AnnotateWindow(object):
self.add_file_data(filename, commit_sha1, line_num)
- fp = os.popen("git blame --incremental -- " + filename + " " + commit_sha1)
+ fp = os.popen("git blame --incremental -M -C -C -- " + filename + " " + commit_sha1)
flags = fcntl.fcntl(fp.fileno(), fcntl.F_GETFL)
fcntl.fcntl(fp.fileno(), fcntl.F_SETFL, flags | os.O_NONBLOCK)
self.io_watch_tag = gobject.io_add_watch(fp, gobject.IO_IN, self.data_ready)
--
1.5.2.1.239.g75d8-dirty
^ permalink raw reply related
* [PATCH 1/2] gitview: Fix the blame interface.
From: Aneesh Kumar K.V @ 2007-06-12 17:35 UTC (permalink / raw)
To: git; +Cc: Aneesh Kumar K.V
The async reading from the pipe was skipping some of the
input lines. Fix the same by making sure that we add the
partial content of the previous read to the newly read
data.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 098cb01..286e974 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -352,6 +352,7 @@ class AnnotateWindow(object):
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_border_width(0)
self.window.set_title("Git repository browser annotation window")
+ self.prev_read = ""
# Use two thirds of the screen by default
screen = self.window.get_screen()
@@ -401,7 +402,11 @@ class AnnotateWindow(object):
def data_ready(self, source, condition):
while (1):
try :
- buffer = source.read(8192)
+ # A simple readline doesn't work
+ # a readline bug ??
+ buffer=""
+ buffer = source.read(100)
+
except:
# resource temporary not available
return True
@@ -411,6 +416,14 @@ class AnnotateWindow(object):
source.close()
return False
+ if (self.prev_read != ""):
+ buffer = self.prev_read + buffer
+ self.prev_read = ""
+
+ if (buffer[len(buffer) -1] != '\n'):
+ self.prev_read = buffer[buffer.rindex("\n"):(len(buffer))]
+ buffer = buffer[0:buffer.rindex("\n")]
+
for buff in buffer.split("\n"):
annotate_line = re.compile('^([0-9a-f]{40}) (.+) (.+) (.+)$')
m = annotate_line.match(buff)
@@ -419,7 +432,8 @@ class AnnotateWindow(object):
m = annotate_line.match(buff)
if not m:
continue
- filename = m.group(2)
+ else:
+ filename = m.group(2)
else:
self.commit_sha1 = m.group(1)
self.source_line = int(m.group(2))
--
1.5.2.1.239.g75d8-dirty
^ permalink raw reply related
* Re: [PATCH] Introduce light weight commit annotations
From: Johannes Schindelin @ 2007-06-12 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7v4plf5qxp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
> With the normal tree parser, the lookup for
> "refs/annotations/commit:??/?{38}" you have in your code would open one
> tree (the commit's tree), find the one with leading 2 hexdigits you
> would want among up to 256 entries with linear search (see
> tree-walk.c::find_tree_entry()), open that entry which is another tree,
> and do the same linear search to find the entry with the remaining 38
> hexdigits. Finding annotation for commit 0000abcd... is much less
> expensive than ffff4567...
Okay, I did not find a proper solution. commit->file name via "s/../&\//g"
is too ugly. But then, I really hope that packv4 becomes unvapourware at
some stage (for other reasons), and that _should_ help these issues.
Hmm.
Ciao,
Dscho
^ permalink raw reply
* Re: Problem with a push
From: Junio C Hamano @ 2007-06-12 17:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andy Parkins, git, plexq
In-Reply-To: <alpine.LFD.0.98.0706120800430.14121@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> IOW, the notion of "remote" refs really logically implies a mirror image,
> exactly like you have it set up in your config: what is a local ref in one
> repository is a remote ref in another. But that's not what the default
> "git push" semantics are: it just matches refs directly, without that
> mirroring.
>
> And the _reason_ for it doing that are obviously historical: we didn't use
> to have the notion of "remotes", so back when I did that, it made sense.
> It just doesn't make sense any more.
There are two aspects of this issue. If "matching refs"
semantics makes sense, and if pushing refs/remotes makes sense.
I think the above description risks confusing new people by
sounding as if you are saying no to the former question.
"Pushing to the ref of the same path" makes _PERFECT_ sense even
today for a push into a bare repository used for publishing.
It only is not the right thing to do 50% of the time when you
are pushing into a live repository.
And I everyday use an example of why "matching refs" makes sense
for the other 50% of "push into a live repository" case. When I
work on git.git, the second-from-final step every day is to push
into a live repository I have at k.org for final build in an
environment different from what I use for development. I do
"matching refs" push, go there and "git reset --hard" to update
the working tree to build all four branches (there is the issue
that I am too lazy to install receive-pack hook in the live
repository to do that reset --hard to sync the working tree for
me, but that is a separate issue).
So it is not like "matching refs" is always wrong. It is wrong
in some cases, and is perfectly good in some other cases.
What does not make sense AT ALL is to push what you keep under
refs/remotes/ to outside. This issue actually has existed from
the very beginning, and we had a specific instruction that said
"remove 'refs/heads/origin' from your published repository
otherwise you will confuse yourself with push". This was before
separate-remote layout was invented and refs/heads/origin was
the remote tracking branch for the 'master' at the other side.
Back when you did the original "send-pack", there was nothing
outside of refs/{heads,tags}, so historically it made sense to
say "ALL matching", but even then we had to be careful about
'heads/origin'. Now it does not make sense anymore(I am saying
that not-renaming is OK but sending refs/remotes is Bad, which
is quite different from what you said).
Probably we should not do push anything other than refs/heads/
when we do "matching refs"
I think what we might want to do around this area are:
- Don't change anything, if the command line says refspec, or
the remote has push refspec specified.
- When doing 'matching refs', do it only under refs/heads/.
- Ship with a receive-pack hook that attempts a 3-way merge
update when the currently checked out branch is updated.
Additionally we can give an option to "git clone" (or "git
remote add") to arrange the cross-push configuration for
mothership-satellite Andy showed in the clone's .git/config;
but I think that is a separate issue.
^ permalink raw reply
* Re: git-fetch, was Re: [PATCH] Port git-tag.sh to C.
From: Daniel Barkalow @ 2007-06-12 16:51 UTC (permalink / raw)
To: Julian Phillips
Cc: Johannes Schindelin, Carlos Rica,
=?X-UNKNOWN?Q?Kristian_H=F8gsberg?=, git
In-Reply-To: <Pine.LNX.4.64.0706121427410.18585@reaper.quantumfyre.co.uk>
On Tue, 12 Jun 2007, Julian Phillips wrote:
> On Tue, 12 Jun 2007, Johannes Schindelin wrote:
>
> > How about pushing them onto repo.or.cz as a fork of git.git?
>
> I'd quite like to see these changes too - since I haven't finished the fetch
> work yet, and I don't want to duplicate effort ;)
I'll put it up on my server this evening; I forgot to push the latest
version from my laptop to somewhere I can get it.
> (It seems that the closer I get to a working fetch the less time I spend on it
> ... :$)
My efforts have similarly stagnated, but the GSoC talk reminded me that a
third person could take over. Although the series I just posted adds
branch config parsing, which is helpful for making fetch clean, even if it
doesn't make it closer to working completely.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: Marc Singer @ 2007-06-12 16:27 UTC (permalink / raw)
To: git
In-Reply-To: <20070606175458.GH12774@fieldses.org>
On Wed, 2007-06-06 at 13:54 -0400, J. Bruce Fields wrote:
> Based on my notes from the last time I needed to feed a bunch of
> non-mbox, non-git-produced patches into git-am, the hard part was
> figuring out how it split a file into separate messages; my notes say:
>
> "Finds lines begining with "From " and ending with "hh:mm:ss
> yyyy". See builtin-mailsplit code for more details."
>
> Other than that, I think it just needs and From: and Subject: lines to
> get author and first-line of the commit. the git-am man page has some
> documentation of this. It could probably use more.
>
I'm not sure that I understand your response.
git-am complains that it cannot find an email address, but raw patches
seldom have these. So, either we could use another command, or it would
be handy if we could supply the email address to git-am (or some other
data it needs so that it can split the patch.) I suppose the mistaken
assumption is that the patch source in an email instead of already being
a nice clean patch.
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: Johannes Schindelin @ 2007-06-12 16:14 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200706121643.19837.andyparkins@gmail.com>
Hi,
On Tue, 12 Jun 2007, Andy Parkins wrote:
> My apologies for jumping on your patch, but when I read the context of
> your change, I couldn't resist fixing some things around it too.
You sound like you address somebody personally. However, your "To:" only
contains the list. Netiquette?
Ciao,
Dscho
^ permalink raw reply
* [BUG] 75d8ff1 fails on SunOS 5.9 (missing hsterror) from ba505322
From: Randal L. Schwartz @ 2007-06-12 16:13 UTC (permalink / raw)
To: git
CC fetch-pack.o
fetch-pack.c: In function `get_pack':
fetch-pack.c:532: warning: int format, pid_t arg (arg 3)
LINK git-fetch-pack
Undefined first referenced
symbol in file
hstrerror libgit.a(connect.o)
ld: fatal: Symbol referencing errors. No output written to git-fetch-pack
collect2: ld returned 1 exit status
make: *** [git-fetch-pack] Error 1
I suspect this broke in ba505322 when connect.c added hsterror().
Yes, bumping to g18bece works fine. So it looks like we need a compat
hsterror(), or it should be removed or ifdef'ed somehow. Paging Alex Riesen?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] Edit user manual for grammar
From: Andy Parkins @ 2007-06-12 15:43 UTC (permalink / raw)
To: git
In-Reply-To: <588192970706120518p201b52fdi9ed48896278b9f3e@mail.gmail.com>
- "last-resort" is two words, not a conjoined word, it doesn't require
the hyphen
- "method of" is vulgar, "method for" is nicer
- "recovery" becomes "recovering" from Steve Hoelzer's original version
of this patch
- "if you want" is nicer as "if you wish"
- "you may" should be "you can"; "you may" is "you have permission to"
rather than "you can"'s "it is possible to"
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
My apologies for jumping on your patch, but when I read the context of your
change, I couldn't resist fixing some things around it too.
Documentation/user-manual.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 7eaafa8..d62ccd0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1527,9 +1527,9 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
-------------------------------------------------
Dangling objects are not a problem. At worst they may take up a little
-extra disk space. They can sometimes provide a last-resort method of
-recovery lost work--see <<dangling-objects>> for details. However, if
-you want, you may remove them with gitlink:git-prune[1] or the --prune
+extra disk space. They can sometimes provide a last resort method for
+recovering lost work--see <<dangling-objects>> for details. However, if
+you wish, you can remove them with gitlink:git-prune[1] or the --prune
option to gitlink:git-gc[1]:
-------------------------------------------------
--
1.5.2.1.134.gd166e
^ permalink raw reply related
* Mail after commit
From: Claudio Scordino @ 2007-06-12 15:32 UTC (permalink / raw)
To: git
Hi all.
To have an email sent after every commit, I've put the following command in
.git/hooks/post-commit:
rm -f /tmp/git-commit.patch ; git-format-patch --stdout -s `git log
--pretty=oneline | awk '{print $1}' | sed -n '2p'` > /tmp/git-commit.patch ;
git-send-email --no-signed-off-by-cc --to XXX --from YYY /tmp/git-commit.patch
; rm -f /tmp/git-commit.patch
and it works, indeed.
However, it's quite tricky.
Doesn't exist any way to make it simpler ?
Regards,
Claudio
^ permalink raw reply
* Re: Problem with a push
From: Linus Torvalds @ 2007-06-12 15:07 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, plexq
In-Reply-To: <200706121007.17044.andyparkins@gmail.com>
On Tue, 12 Jun 2007, Andy Parkins wrote:
>
> I agree its odd, but is it really true that one (I) shouldn't be doing it?
No, it's definitely not a hard rule, and it's perfectly fine to push any
refs at all, including remotes.
It's just that we probably shouldn't do it by *default*.
There's another slight detail to this story, which is what caused Alex to
notice in the first place: we tried to push to something that was a
symref, which actually caused *another* ref to update. Again, there's
nothing wrong about that theoretically (it's what symrefs are there for!),
but again, it's probably something we shouldn't do by default.
So there's a big difference between:
- git _can_ do it, and it's perfectly sane to do when you know what you
are doing and have a very specific issue.
and
- git not only _can_ do it, but will do it even when you didn't
explicitly tell it to do that..
> Can I tell you what I'm doing, and check that it's not crazy...
>
> I have my laptop and my desktop computer; I use both for development.
> I've set them so that they are symmetric...
>
> laptop:.git/config
> [remote "desktop"]
> url = ssh://blah blah blah
> fetch = refs/heads/*:refs/remotes/desktop/*
> push = refs/heads/*:refs/remotes/laptop/*
>
> desktop:.git/config
> [remote "laptop"]
> url = ssh://blah blah blah
> fetch = refs/heads/*:refs/remotes/laptop/*
> push = refs/heads/*:refs/remotes/desktop/*
>
> This is very handy, as git-push on one does the same as git-fetch on the
> other. Have I made a glaring mistake by pushing to a remote ref?
I think this is perfectly sane, exactly because you did it explicitly, and
partly exactly *because* you explicitly don't do what git push does by
default (which is to update the "remote" refs remotely with what are the
remote refs locally!).
IOW, the notion of "remote" refs really logically implies a mirror image,
exactly like you have it set up in your config: what is a local ref in one
repository is a remote ref in another. But that's not what the default
"git push" semantics are: it just matches refs directly, without that
mirroring.
And the _reason_ for it doing that are obviously historical: we didn't use
to have the notion of "remotes", so back when I did that, it made sense.
It just doesn't make sense any more.
Junio: I suspect this is really an area worth changing semantics in, the
same way we changed the semantics for the defaults for "git pull". And I
suspect it will confuse a lot fewer people, because fewer people depend on
the default behaviour of "git push".
Linus
^ permalink raw reply
* Re: Watchpoints
From: Johannes Schindelin @ 2007-06-12 14:21 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git
In-Reply-To: <19f34abd0706120651m2cfab331te0976eddb479b88c@mail.gmail.com>
Hi,
On Tue, 12 Jun 2007, Vegard Nossum wrote:
> A lot of kernel developers consider purely-syntactic changes (ie. fixing
> whitespace issues) to be noisy/disruptive. Therefore, even when such
> changes are for the better (according to the coding style, etc), they do
> not usually make it to the "mainline".
FWIW I don't think that there are that many developers who think
whitespace fixes are useless. For example, Git recently saw a small series
which did nothing _except_ white space fixes.
And I can see the value of it. Just take your home as an example. You are
used to a certain order of things there. I, for one, have a routine where
I go when coming home, and where I expect my wine bottle to be. If that
bottle is somewhere else, I have to find it first. It's just a tiny itch,
but a real one.
The same applies to source code: when I am hacking on Git, I expect things
in a certain layout, and find my way easily through that. If there are
some things I am not used to (yes, even a missing space after an "if"), it
takes away my attention briefly from what I want to do. It's just a tiny
itch, but a real one.
If tiny itches add up, they become larger ones. And soon you have a real
problem.
So, if somebody tells you that code style does not matter, ignore her. She
has no clue about how people tick, really.
Ciao,
Dscho
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Alex Riesen @ 2007-06-12 14:12 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706112346.13628.simon@lst.de>
On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
> Ooops, indeed. Makes me realizes that I've never actually submitted files with
> spaces in the name :). For now I've quoted them with double quotes like in
> the other places, which is better than nothing. Thanks for spotting!
Running 'p4 print' the code also does not check for code "error",
and there may be other places which have to check for errors.
BTW, I have never seen code "text". It is always "binary" for file data,
for text files the type in code-stat element is just set to "text".
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Shawn O. Pearce @ 2007-06-12 13:53 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Linus Torvalds, Git Mailing List
In-Reply-To: <e5bfff550706120427g7ad9d38bpc34d9ea284ace693@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > (1) Are you emulating CVS-like "a file has an identity, and we
> > follow its changes" model? How does it handle file split,
> > merge, and code movement in general?
> >
>
> It uses 'git rev-list HEAD -- <path>' to get the list of revisions
> that modified a path,
So apparently yes, qgit is emulating CVS. And yet much better things
exist (git-blame).
> I really would like to keep it like that because it is the way 'git'
> works, and I would feel uncomfortable in filtering out git results, it
> seems quite fragile to me.
Its not "the way git works". Its just one way of looking at the data
in the object database. And its not as accurate or as interesting
as what git-blame does.
> This means that file splits, merges, renames etc.. are handled as much
> as they are handled in git. IOW *if* 'git rev-list HEAD -- <path>'
> returns a list of revisions taking in account all of the above, so it
> will, automatically, do qgit.
>
> BTW _currentlly_ git-rev-list does not do that.
And it may never do it. Most of the split/merge code is actually
in git-blame and is probably too CPU intensive to slam into the
middle of git-rev-list as a path limiter operator. But renames
*might* someday be included.
> Going from oldest to newest has this advantage:
It is unclear why you aren't just using `git blame --incremental`.
git-blame running in two passes (with and without -M -C -C) can yield
some very interesting results on files, like Git's own revision.c.
And with the new -w flag that Junio just added, there's even more
interesting possibilities...
;-)
--
Shawn.
^ permalink raw reply
* Watchpoints
From: Vegard Nossum @ 2007-06-12 13:51 UTC (permalink / raw)
To: git
Hello,
A lot of kernel developers consider purely-syntactic changes (ie.
fixing whitespace issues) to be noisy/disruptive. Therefore, even when
such changes are for the better (according to the coding style, etc),
they do not usually make it to the "mainline".
It has been suggested that such syntactic changes be performed and
submitted only when related (nearby) semantic changes are performed at
the same time. This is hard to do, however; the developers who want to
make semantic changes are not necesarily the same as those who want to
make syntactic changes, and thus they may not even realize their
opportunity to fix, for example, whitespace issues which exist the
function they are changing.
I introduce the concept of watchpoints. In this particular case, a
watchpoint is the record of a line (or lines) in a file which has some
issue that is not serious enough to warrant a change on its own, but
could be changed in the future if a nearby change was made. More
generally, a watchpoint can "watch" a specific part of a file for
changes in the future.
The point is that git can track a set of watchpoints so that
watchpoint line-numbers stay in sync with the actual file contents.
Adding a line to the beginning a file should probably jump up all the
watchpoint line-numbers for that file. Now, git may also check
to-be-applied patches for changes that touch a watched line.
Does this sound like a viable or even useful idea for a file tracker?
Kind regards,
Vegard Nossum
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 13:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Lars Hjemli, Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <200706121540.52753.Josef.Weidendorfer@gmx.de>
On Tuesday 12 June 2007, Josef Weidendorfer wrote:
> IMHO sharing of the admin submodule repository should even be possible
> if I have a clone of kdelibs and kdebase independent of the big
> KDE superproject.
>
> It would be nice to allow submodule.<name>.repopath configs globally
> in ~/.gitconfig, and cloning kdelibs should automatically do the
> right thing, ie. use the already available admin repo for the kdelibs
> clone.
I just realize that this should be already possible now by setting
submodule.<name>.url in ~/.gitconfig. It could automatically
use "git-clone -l -s -n ..." if the URL is local.
Josef
^ permalink raw reply
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