* Re: can I get only the list of merges?
From: Linus Torvalds @ 2006-07-10 18:51 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Diego Calleja, git
In-Reply-To: <Pine.LNX.4.64.0607101103160.5623@g5.osdl.org>
On Mon, 10 Jul 2006, Linus Torvalds wrote:
>
> However, if you want a _sneaky_ way of doing it, and want a graphical
> result, and have a recent version of git, you can also just do something
> like
>
> gitk --full-history -- %%nonexistant-file%%
>
> which will give you each commit that changes that nonexistant file (there
> should be none ;), and the full commit history for those (ie all the
> merges).
Btw, a better way to do the same is probably
gitk --full-history -- a//b
which is guaranteed to not match any files and doesn't depend on just an
_unlikely_ filename. Instead, it depends on the fact that a name with a
double slash should not exist in a git archive.
(There are other possibilities too - instead of "a//a", you can just use
the filename ".git", for the same reasons - it definitely won't be tracked
by git).
Linus
^ permalink raw reply
* 2 questions on git-send-email usage
From: moreau francis @ 2006-07-10 19:00 UTC (permalink / raw)
To: git
Hi
I'm wondering what am I supposed to answer when git-send-email
is asking me :
Message-ID to be used as In-Reply-To for the first email?
I'm running this command:
$ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to foo@bar.com --compose /tmp/patch/
to write an introductory message, and all patches are sent as replies to
this introductory email sent.
I also noticed that git-send-email removes the commit message of each
patches I sent, I don't think this is the normal behaviour though. What
am I missing ?
Thanks
Francis
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqrxpai1.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> Am I missing an option to have git-log go forward in time rather than
> backward? I'd really like "git-log --pretty=short ORIG_HEAD..HEAD" to show me
> a story I can read. :)
Well, as long as you realize that that automatically means that you have
to walk the whole commit list, and you won't be able to get the
incremental output that git-log and friends normally are able to give?
But this patch should do it. With it,
git log --reverse --pretty=short ORIG_HEAD..
should do what you want.
It is _not_ possible to reverse the "gitk" view with this patch, though,
as this does _not_ reverse parenthood information.
The "--reverse" flag could possibly be renamed.
Linus
---
diff --git a/revision.c b/revision.c
index 7df9089..13a3e40 100644
--- a/revision.c
+++ b/revision.c
@@ -698,6 +698,10 @@ int setup_revisions(int argc, const char
revs->topo_order = 1;
continue;
}
+ if (!strcmp(arg, "--reverse")) {
+ revs->reverse ^= 1;
+ continue;
+ }
if (!strcmp(arg, "--parents")) {
revs->parents = 1;
continue;
@@ -921,7 +925,7 @@ int setup_revisions(int argc, const char
add_pending_object(revs, object, def);
}
- if (revs->topo_order || revs->unpacked)
+ if (revs->topo_order || revs->unpacked || revs->reverse)
revs->limited = 1;
if (revs->prune_data) {
@@ -941,6 +945,19 @@ int setup_revisions(int argc, const char
return left;
}
+static struct commit_list *reverse_commit_list(struct commit_list *p)
+{
+ struct commit_list *result = NULL;
+
+ while (p) {
+ struct commit_list *next = p->next;
+ p->next = result;
+ result = p;
+ p = next;
+ }
+ return result;
+}
+
void prepare_revision_walk(struct rev_info *revs)
{
int nr = revs->pending.nr;
@@ -968,6 +985,8 @@ void prepare_revision_walk(struct rev_in
sort_in_topological_order_fn(&revs->commits, revs->lifo,
revs->topo_setter,
revs->topo_getter);
+ if (revs->reverse)
+ revs->commits = reverse_commit_list(revs->commits);
}
static int rewrite_one(struct rev_info *revs, struct commit **pp)
diff --git a/revision.h b/revision.h
index c010a08..ff6ce44 100644
--- a/revision.h
+++ b/revision.h
@@ -32,6 +32,7 @@ struct rev_info {
remove_empty_trees:1,
simplify_history:1,
lifo:1,
+ reverse:1,
topo_order:1,
tag_objects:1,
tree_objects:1,
^ permalink raw reply related
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 19:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101151470.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> Well, as long as you realize that that automatically means that you
Linus> have to walk the whole commit list, and you won't be able to get the
Linus> incremental output that git-log and friends normally are able to give?
Wow. Yes, I think I can live with that for the application.
Linus> But this patch should do it.
Thanks!
--
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
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Paul Serice @ 2006-07-10 19:14 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20060710114117.GA62514@dspnet.fr.eu.org>
> Given than you can find gcc on pretty much everything that has a
> filesystem cache decent enough to handle git correctly, is this cost
> worth it? _That_ was the question.
I've seen this argument before. Unfortunately it seems reasonable
enough on the surface, and I actually bought into it much to may later
regret.
My experience is that gcc often produces buggy code, and if gcc is not
_the_ compiler for that platform, those bugs do not get fixed.
Specifically, I have had lots of problems with gcc and IRIX.
If you want to write portable code, you have to take into account
different operating systems _and_ different compilers. Writing your
code for just a single compiler is almost as bad as writing your code
for just a single operating system.
Paul Serice
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:20 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863bd9p9en.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> Linus> Well, as long as you realize that that automatically means that you
> Linus> have to walk the whole commit list, and you won't be able to get the
> Linus> incremental output that git-log and friends normally are able to give?
>
> Wow. Yes, I think I can live with that for the application.
It's a big deal for me, I often end up doing things like
git log -p some-random-file
to see what has happened, and getting the most recent changes basically
instantaneously (rather than waiting for the thing to traverse all of the
history) is a big deal.
If you have a fairly small archive, or you don't use pathname limiting,
the history generation is so fast that you'll never even notice. But with
the kernel, doing something like
git log drivers/serial
takes just over two seconds for me, and if I had to wait for two seconds
before the first data starts arriving, I'd go nuts.
To see this in cold hard numbers:
// Full log
[torvalds@g5 linux]$ time git log drivers/serial > /dev/null
real 0m2.267s
user 0m2.204s
sys 0m0.020s
// Simulate "get the first screenful"
[torvalds@g5 linux]$ time git log drivers/serial | head -25 > /dev/null
real 0m0.054s
user 0m0.048s
sys 0m0.008s
// Simulate "get the first screenful of reverse output"
[torvalds@g5 linux]$ time git log --reverse drivers/serial | head > /dev/null
real 0m2.218s
user 0m2.176s
sys 0m0.044s
and it's the difference between the second and the third case I wanted to
point out.
The difference between getting the first screenful in 0.054 seconds versus
it taking 2.218 seconds is quite noticeable, and one of the things I've
actually spent a fair amount of time on is to make sure that the
incremental output case is the _common_ one for all the normal operations
like "git log -p".
Linus
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 19:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101212410.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>> Wow. Yes, I think I can live with that for the application.
Linus> It's a big deal for me, I often end up doing things like
Linus> git log -p some-random-file
Linus> to see what has happened, and getting the most recent changes basically
Linus> instantaneously (rather than waiting for the thing to traverse all of the
Linus> history) is a big deal.
Well, this is for a "I'm connected to the net right now: please
refresh all of my git mirrors" script:
## (code here to cd to the right dir omitted)
git-fetch
if git-status | grep -v 'nothing to commit'
then echo UPDATE SKIPPED
else
if git-pull . origin | egrep -v 'up-to-date'
then git-log --pretty=short ORIG_HEAD..HEAD | cat
fi
fi
The log is just so I can quickly eyeball the interesting changes. The "cat"
is to keep git-log from starting a pager. (If there's a switch that does
*that* that I've overlooked, that'd be good too.)
--
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
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101212410.5623@g5.osdl.org>
On Mon, 10 Jul 2006, Linus Torvalds wrote:
>
> The difference between getting the first screenful in 0.054 seconds versus
> it taking 2.218 seconds is quite noticeable, and one of the things I've
> actually spent a fair amount of time on is to make sure that the
> incremental output case is the _common_ one for all the normal operations
> like "git log -p".
Side note: the good news is that even with the reverse generation, if you
also generate _diffs_, the diffs will be generated incrementally, so:
// Full "git log" with diffs
[torvalds@g5 linux]$ time git log -p drivers/serial > /dev/null
real 0m3.409s
user 0m3.360s
sys 0m0.052s
// First screenful of reverse git log with diffs
[torvalds@g5 linux]$ time git log -p --reverse drivers/serial | head -25 > /dev/null
real 0m2.228s
user 0m2.216s
sys 0m0.012s
// First screenful of regular git log with diffs
[torvalds@g5 linux]$ time git log -p drivers/serial | head -25 > /dev/null
real 0m0.038s
user 0m0.036s
sys 0m0.004s
here you can see how the full "git log -p" is obviously more expensive
than the full "git log" was (the diff generation adds about a second to
the full time), but because the diffs are generated incrementally as they
are shown even with "--reverse", the first screenful of the "--reverse"
case didn't get any more expensive, because we didn't generate all the
diffs up-front, just the ones we needed.
And the first screenfull of the normal case obviously stays really fast,
because both history generation _and_ diff generation is all on-the-fly.
Linus
^ permalink raw reply
* [PATCH] Allow usage of git-svnimport's -d/-D options with https
From: Diego 'Flameeyes' Pettenò @ 2006-07-10 19:34 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 384 bytes --]
While importing an SVN https repository (from SourceForge), I noticed that the
svnimport script just accepts http as url scheme to use -d/-D options, while
it seems to work fine with https too. The attached patch fixes that for me.
HTH,
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
[-- Attachment #1.2: git-svnimport-https.patch --]
[-- Type: text/x-diff, Size: 426 bytes --]
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 26dc454..9a69369 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -209,7 +209,7 @@ if($opt_d or $opt_D) {
} else {
$svn_dir = "";
}
- if ($svn_url->scheme eq "http") {
+ if ($svn_url->scheme eq "http" or $svn_url->scheme eq "https") {
use LWP::UserAgent;
$lwp_ua = LWP::UserAgent->new(keep_alive => 1, requests_redirectable => []);
} else {
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 20:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzbhntxu.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> then git-log --pretty=short ORIG_HEAD..HEAD | cat
> The log is just so I can quickly eyeball the interesting changes. The "cat"
> is to keep git-log from starting a pager. (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)
Just do
PAGER= git log --pretty=short ORIG_HEAD..HEAD
instead.
And if you didn't know about "git shortlog" already, I personally actually
find it easier to read
git log --no-merges ORIG_HEAD.. | git shortlog
which orders things by author instead. It also reverses the log messages
as it does so, so each author will have the one-liners sorted oldest to
newest the way you wanted to (so you do _not_ want to pass --reverse to
that git-shortlog invocation).
Linus
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101304210.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> And if you didn't know about "git shortlog" already, I personally actually
Linus> find it easier to read
Linus> git log --no-merges ORIG_HEAD.. | git shortlog
Linus> which orders things by author instead. It also reverses the log
Linus> messages as it does so, so each author will have the one-liners sorted
Linus> oldest to newest the way you wanted to (so you do _not_ want to pass
Linus> --reverse to that git-shortlog invocation).
See -- I *knew* there was a shorter way.
Looks like I owe you lunch. (Again? :)
--
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
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 20:24 UTC (permalink / raw)
To: Paul Serice; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <44B2A709.8020500@serice.net>
On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:
> If you want to write portable code, you have to take into account
> different operating systems _and_ different compilers. Writing your
> code for just a single compiler is almost as bad as writing your code
> for just a single operating system.
Hmmm, that was not so much about gcc-specific code than which kind of
C you want to code to, the one from 1973, the one from 1989 or the one
from 1999? I personally don't have much sympathy for the OS vendors
giving you an older standard C compiler and selling you the up-to-date
one.
OG.
^ permalink raw reply
* Re: [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Jakub Narebski @ 2006-07-10 20:25 UTC (permalink / raw)
To: git
In-Reply-To: <1152549787.8890.36.camel@josh-work.beaverton.ibm.com>
Josh Triplett wrote:
> On Mon, 2006-07-10 at 18:29 +0200, Erik Mouw wrote:
>> On Mon, Jul 10, 2006 at 06:01:48PM +0200, Johannes Schindelin wrote:
>> > please make that behaviour optional.
>>
>> Rather make it consistent with git-send-email. Principle of least
>> surprise.
>
> Well, git-send-email does not include an option to disable the threading
> headers, so consistency with git-send-email would imply not including
> any such option. I can, however, implement a --no-thread option to omit
> the headers, as well as git-send-email's --in-reply-to option to set an
> initial In-Reply-To/References. New patch series shortly.
git-send-email has three ways of sending files:
1. Chain Reply-To:, where every patch refers to earlier in series.
Ugly in threaded mail/news readers, harder to comment, but there is
no way to loose the order (e.g. if patches are not numbered *blush*)
2. No chain reply-to, with cover letter introducing patch series.
IMHO nicest format... provided there are no errors nor mistakes.
3. No chain reply-to, without cover letter. I presonally don't like
this format, YMMV.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Junio C Hamano @ 2006-07-10 20:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzbhntxu.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Well, this is for a "I'm connected to the net right now: please
> refresh all of my git mirrors" script:
>
> ## (code here to cd to the right dir omitted)
> git-fetch
> if git-status | grep -v 'nothing to commit'
git-status exits non-zero for "nothing to commit" case, so do
not grep its output, but check the status of the command, to see
if your tree is in a good shape to do a pull.
> then echo UPDATE SKIPPED
> else
> if git-pull . origin | egrep -v 'up-to-date'
> then git-log --pretty=short ORIG_HEAD..HEAD | cat
> fi
> fi
>
> The log is just so I can quickly eyeball the interesting changes.
Do we not leave ORIG_HEAD when we are already up-to-date? If so
that would be confusing... No, we do leave ORIG_HEAD no matter
what, so you do not have to have this inner if to grep
up-to-date (on the other hand, you might want to do intelligent
things when git-pull fails). So just drop the if and say
something like:
else
PAGER= ; export PAGER
git pull . origin &&
git log --pretty ORIG_HEAD..HEAD |
git shortlog
fi
> The "cat"
> is to keep git-log from starting a pager. (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)
BTW,
PAGER=cat
export PAGER
This should work as more efficiently -- see pager.c ;-)
^ permalink raw reply
* Re: 2 questions on git-send-email usage
From: Jakub Narebski @ 2006-07-10 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060710190010.94648.qmail@web25808.mail.ukl.yahoo.com>
moreau francis wrote:
> I'm wondering what am I supposed to answer when git-send-email
> is asking me :
>
> Message-ID to be used as In-Reply-To for the first email?
>
> I'm running this command:
>
> $ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to \
> foo@bar.com --compose /tmp/patch/
>
> to write an introductory message, and all patches are sent as replies to
> this introductory email sent.
Empty string (i.e. RET) should do if you don't want to attach your series of
patches somewhere in existing thread.
> I also noticed that git-send-email removes the commit message of each
> patches I sent, I don't think this is the normal behaviour though. What
> am I missing ?
Are patches formatted using git-format-patch?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgdb40s.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> ## (code here to cd to the right dir omitted)
>> git-fetch
>> if git-status | grep -v 'nothing to commit'
Junio> git-status exits non-zero for "nothing to commit" case, so do
Junio> not grep its output, but check the status of the command, to see
Junio> if your tree is in a good shape to do a pull.
No, this is deliberate. I want to see nothing if we're up to date, but if
not, I want to see *everything else* that git-status said. This nice "grep
-v" does precisely the right thing.
Junio> Do we not leave ORIG_HEAD when we are already up-to-date? If so
Junio> that would be confusing... No, we do leave ORIG_HEAD no matter
Junio> what, so you do not have to have this inner if to grep
Junio> up-to-date (on the other hand, you might want to do intelligent
Junio> things when git-pull fails). So just drop the if and say
Junio> something like:
Junio> else
Junio> PAGER= ; export PAGER
Junio> git pull . origin &&
Junio> git log --pretty ORIG_HEAD..HEAD |
Junio> git shortlog
Junio> fi
However, this is good to know.
--
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
* Items not covered by repository-layout.txt
From: Jakub Narebski @ 2006-07-10 20:46 UTC (permalink / raw)
To: git
I have noticed few files in .git/ directory which currently are not covered
(and neither is their format) by Documentation/repository-layout.txt
* COMMIT_EDITMSG (temporary file, when I decided during writing commit
message that I should change something before commit)
* FETCH_HEAD (format?)
* HEAD, ORIG_HEAD and probably some other *_HEAD
* .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
broken due to lack of signing PGP keys)
* description file
I know they are fairly obvious, but having everything that one could fing in
his/her git-core managed .git repository would be nice...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-update-ref (reflog) uses bogus author ident information
From: Jakub Narebski @ 2006-07-10 20:52 UTC (permalink / raw)
To: git
git-log reports
commit 059111c9381ce1444d17c8fc35606b0aa417ca42
Author: Jakub Narebski <jnareb@gmail.com>
Date: Sat Jul 8 18:52:35 2006 +0200
configure.ac vertical whitespace usage cleanup
git-var -l shows:
GIT_COMMITTER_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
GIT_AUTHOR_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
BUT in git/.git/logs/refs/heads/autoconf I have (broken into lines):
fe7b45a419ae62ed96148d98f6aba8710a6f6245
059111c9381ce1444d17c8fc35606b0aa417ca42
Jakub Narebski <jnareb@roke.D-201> 1152377555 +0200
commit: configure.ac vertical whitespace usage cleanu
where "roke.D-201" are results of "hostname -f" on my computer, and are
suitable _only_ for my small private local network.
Bug or a feature?
I use git 1.4.0.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Junio C Hamano @ 2006-07-10 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607101340080.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On one of my systems, the linker is not intelligent enough to link with
> pager.o (in libgit.a) when only the variable pager_in_use is needed. The
> consequence is that the linker complains about an undefined
> variable.
I do not understand this quite yet -- which executable is your
linker building when it does this?
Maybe we need ranlib?
^ permalink raw reply
* Re: Items not covered by repository-layout.txt
From: Junio C Hamano @ 2006-07-10 21:29 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8ue98$o7t$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I have noticed few files in .git/ directory which currently are not covered
> (and neither is their format) by Documentation/repository-layout.txt
>
> * COMMIT_EDITMSG (temporary file, when I decided during writing commit
> message that I should change something before commit)
> * FETCH_HEAD (format?)
> * HEAD, ORIG_HEAD and probably some other *_HEAD
> * .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
> broken due to lack of signing PGP keys)
> * description file
>
> I know they are fairly obvious, but having everything that one could fing in
> his/her git-core managed .git repository would be nice...
Yup, please make it so.
^ permalink raw reply
* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Linus Torvalds @ 2006-07-10 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v64i5b1am.fsf@assigned-by-dhcp.cox.net>
On Mon, 10 Jul 2006, Junio C Hamano wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On one of my systems, the linker is not intelligent enough to link with
> > pager.o (in libgit.a) when only the variable pager_in_use is needed. The
> > consequence is that the linker complains about an undefined
> > variable.
>
> I do not understand this quite yet -- which executable is your
> linker building when it does this?
>
> Maybe we need ranlib?
Shouldn't be needed, since we use "$(AR) rcs", where that "s" should do
the equivalent of the old-fashioned "ranlib" call.
However, that said, I think Johannes' patch is worth applying regardless,
since it's kind of sad to link in pager.o just because of a variable that
ends up never mattering (ie any program that uses "diff.c" but isn't
built-in).
Of course, once/if everything is built-in, this doesn't matter, but in the
meantime this isn't the first time we've re-organized things so that you
don't have to link in files that you don't need. After all, that was the
whole reason environment.c ended up existing in the first place..
Linus
^ permalink raw reply
* Re: Items not covered by repository-layout.txt
From: Jakub Narebski @ 2006-07-10 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wstb12x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I have noticed few files in .git/ directory which currently are not covered
>> (and neither is their format) by Documentation/repository-layout.txt
>>
>> * COMMIT_EDITMSG (temporary file, when I decided during writing commit
>> message that I should change something before commit)
>> * FETCH_HEAD (format?)
>> * HEAD, ORIG_HEAD and probably some other *_HEAD
>> * .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
>> broken due to lack of signing PGP keys)
>> * description file
>>
>> I know they are fairly obvious, but having everything that one could fing in
>> his/her git-core managed .git repository would be nice...
I have just noticed that _config_ file (!)is not covered by repository-layout.txt
> Yup, please make it so.
Could you then tell me what is the format of FETCH_HEAD and what other *_HEADs
can be seen in $GIT_DIR (MERGE_HEAD?)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Junio C Hamano @ 2006-07-10 21:44 UTC (permalink / raw)
To: josht; +Cc: git
In-Reply-To: <1152556878.8890.45.camel@josh-work.beaverton.ibm.com>
Josh Triplett <josht@us.ibm.com> writes:
> Add message_id and ref_message_id fields to struct rev_info, used in show_log
> with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
> Use these in git-format-patch to make the second and subsequent patch mails
> replies to the first patch mail.
>
> Signed-off-by: Josh Triplett <josh@freedesktop.org>
> ---
> Resend of previous patch as part of new patch series.
While I understand what you said about imap-send, I really would
feel better if this was optional. Do not change the default
output format, please.
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Junio C Hamano @ 2006-07-10 21:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Randal L. Schwartz
In-Reply-To: <Pine.LNX.4.64.0607101304210.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And if you didn't know about "git shortlog" already, I personally actually
> find it easier to read
>
> git log --no-merges ORIG_HEAD.. | git shortlog
>
> which orders things by author instead.
Yes, and you can even have '-p' between git and shortlog in the
latter command if you do want the pager ;-).
BTW, when I prepare the "What's in" messages, I often find it
more useful to have a brother of short-log command that does not
group by author but group by topic branch the commits came from.
Currently I prepare the categorized list by hand, reviewing each
commit in "master..next" shortlog output. While I do not mind
it too much since that is a good way to remind myself what are
still cooking, it would be nice to have to a command that takes:
- which branch the output is relative to (defaults
to "master");
- list of branches that are "topics";
- which branch the parts of topics have been merged to
(optional -- I'd use "next" for my use).
and for each topic:
- see if the topic branches off from another topic (for
example, the merge-tree topic branches off from the
xdiff-common topic like [*1*]); if so, state that and
use that branch point instead of "master" in the next
step;
- list commits that have not made "master" yet;
optionally, when "next" is given, limit the output
only to the ones that have made "next" already.
[Footnote]
*1*
$ git show-branch --topics master lt/xdiff-common lt/merge-tree
* [master] git-rev-list: add documentation for --parents, --no-merges
! [lt/xdiff-common] xdiff: generate "anti-diffs" aka what is common...
! [lt/merge-tree] Improved three-way blob merging code
---
+ [lt/merge-tree] Improved three-way blob merging code
+ [lt/merge-tree^] Prepare "git-merge-tree" for future work
++ [lt/xdiff-common] xdiff: generate "anti-diffs" aka what is common...
*++ [master~67] checkout -m: fix read-tree invocation
^ permalink raw reply
* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Junio C Hamano @ 2006-07-10 21:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607101429460.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 10 Jul 2006, Junio C Hamano wrote:
>>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > On one of my systems, the linker is not intelligent enough to link with
>> > pager.o (in libgit.a) when only the variable pager_in_use is needed. The
>> > consequence is that the linker complains about an undefined
>> > variable.
>>
>> I do not understand this quite yet -- which executable is your
>> linker building when it does this?
>> Maybe we need ranlib?
>
> Shouldn't be needed, since we use "$(AR) rcs",...
> ... After all, that was the
> whole reason environment.c ended up existing in the first place..
Understood and agreed to everything you said.
But I still wonder why/how it happens in Johannes's
environment...
^ 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