* Re: Git manuals
From: J. Bruce Fields @ 2006-11-19 19:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Theodore Tso, linux, git
In-Reply-To: <20061119175952.GX7201@pasky.or.cz>
On Sun, Nov 19, 2006 at 06:59:52PM +0100, Petr Baudis wrote:
> On Sun, Nov 19, 2006 at 06:50:40PM CET, J. Bruce Fields wrote:
> > In fact, I'm tempted to submit a patch that just assigns a chapter
> > number to everything under Documentation/, slaps a single table of
> > contents on the front, and calls the result "the git user's manual."
> >
> > Of course, the moment people started trying to read the thing they'd
> > complain that it was a mess--some stuff referenced without being
> > introduced, other stuff introduced too many times. But then over time
> > maybe that'd force us to mold it into some sort of logical sequence.
>
> Sequencing isn't the only problem. A _manual_ is different from
> _reference documentation_ in that it does not usually describe command
> after command, but rather concept after concept. So instead of slamming
> git-*-pack commands together, you have a section "Handling Packs" where
> you try to coherently describe the commands together.
>
> Your approach is fine for something you would call "Git Reference
> Manual", but it is something really different from "The Git Book" or
> "Git User's Manual".
Yeah, of course, but I wasn't actually thinking of the man pages so much
as:
everyday.txt
tutorial.txt
tutorial-2.txt
core-tutorial.txt
howto/
hooks.txt
README
glossary.txt
etc.
^ permalink raw reply
* Re: [Fwd: Re: What's in git.git]
From: Jon Smirl @ 2006-11-19 19:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <20061119174902.GW7201@pasky.or.cz>
On 11/19/06, Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:
> > Brendan told me that he would not consider Mozilla moving to git until
> > a native Windows version is released so I just dropped the whole
> > thing. It is too much effort and they don't even really want it. They
> > are probably going to switch to SVN. I told him that SVN would end up
> > being a disaster and he got mad at me. That's when I stopped working
> > on cvs2svn/git.
>
> I see. :-(
>
> Could you please publish cvs2git in whatever state you have it so that
> someone else possibly interested could pick it up and finish the missing
> bits? It would be shame if the already done work would end up wasted.
Working on cvs2git is the wrong direction. cvs2svn has been
specifically tuned for importing into SVN and they aren't interested
in making the architectural changes that git needs.
There is a core problem in the way cvs2svn handles CVS symbols.
> I posted a three commit example of the problem.
>
> FileA has rev 1.1 and rev 1.2
> FileB has rev 1.1
> A symbol is created between A 1.1/1.2 and after B 1.1
>
> cvs2svn generated two change sets
> 1) FileA 1.1
> 2) FileB 1.1, FileA 1.2
>
> With these two change sets it is impossible to base the symbol simply,
> there is no solution without copying. cvs2svn generates the symbol
> based on #1 and copies FileB 1.1 from #2.
>
> The alternative is to output three change sets which is also a valid
> representation of the same data.
> 1) FileA 1.1
> 2) FileB 1.1
> 3) FileA 1.2
>
> Now there is a solution for the symbol, base is on change set #2. No
> copies needed.
>
> By introducing symbol dependencies (which cvs2svn does not do) you can
> force the second change set sequence to be generated.
SVN allows a label to be made by picking a commit from six months ago
with 80% of the right files in it. They then link to revisions from
later commits to build up the file set needed for the label. Doing it
this way turns every symbol into a little branch. It is fixing the
symptoms rather than fixing the problem of figuring out the correct
construction of the change sets. The SVN people seem to be perfectly
happy with these little branches and they aren't going to change
cvs2svn.
cvs2svn is a nice piece of code and a good thing to look at for
reference. It includes some excellent test cases. The author is a
Python expert and uses every last feature of the language which makes
to code hard to understand at times. He also loves to refactor things
and does so continuously. This is a major problem for any long lived
patches. If you do choose to work on cvs2svn, just fork it until you
are done developing, don't try to track the refactorings.
There are several other choices. Monotone is getting a pretty good
importer and the author is aware of the problem described above and is
writing his code to avoid it. Monotone is in C++ and make heavy use of
the Boost C++ template library. Because of this I can't tell what
their code does, it doesn't look like C++ anymore.
git is in C and has high code quality standards. I would just start
from scratch and write the importer over while referencing the
existing code. If anyone is interested in doing this I will be happy
to explain what I know about doing the import accurately and quickly.
With the right algorithms it is possible to import Mozilla CVS with
2GB memory in under an hour on a desktop machine.
Shawn has written git-fastimport. fastimport takes an input stream of
a simple language and then creates the git repository. The CVS
importer just needs to generate these commands.
With the current knowledge of issues around doing CVS import this
problem is not as hard as it used to be. Dozens of attempts have been
made at this problem, Shawn and I have looked at all of these and know
where the algorithmic mistakes are. The only big outstanding problem I
know of with import is the issue described above which no one has
coded a solution for yet.
Once a solution has been found for this problem the next problem is
detecting when a branch gets merged back into the trunk. After that I
think the problem is fully solved.
--
Jon Smirl
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Marco Costalba @ 2006-11-19 19:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611190945500.3692@woody.osdl.org>
On 11/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> So it all looks _almost_ fine..
>
> Except for this one:
>
> 10:19:04.449236 stat64(".git/objects/3a/41a48d139d1425c1d27e3fbe4f511fb7e09e94", {st_mode=S_IFREG|0444, st_size=278, ...}) = 0 <0.817989>
>
> That's a _single_ "stat64()" system call that takes almost a second to
> execute. All the rest are in the millisecond range, and sometimes a
> hundreth of a second or two. Ie doing
>
> grep -v ' <0.0[012]' tracefile_git_tree.txt
>
> on your tracefile, there's really not a lot of system calls that take a
> long time, and that one stat _really_ stands out (the others are 3 or four
> hundredths of a second, and then suddenly you have one that is 20 times
> longer than even the slowest other ones.
>
> Basically, you seem to have a _single_ object access that takes up half
> the time of the whole program.
>
But why my numbers are bad both in git, in Linux and also qgit (not
posted) local repo? If it is a single case other repos should load
fast.
> It's the object for 'refs/tags/v1.4.4-rc1' in case you care, btw.
>
> > If you want I can repack and prune, but for now I just wait to avoid
> > to corrupt this test case.
>
> What you could try to do is to re-run it a few times (cold-cache) and see
> if those numbers really are stable, and if it's always the same object
> that takes that long.
>
Right now I'm running smartctl -t long /dev/hda, I was a little bit scared ;-)
When finished I will do additional cold chache (reboot) tests.
> In fact, you could even do a simple
>
> time ls -l .git/objects/3a/41a48d139d1425c1d27e3fbe4f511fb7e09e94
>
> for the cold-cache case, and see if just even _that_ takes almost a
> second.
>
> If it _is_ stable, there's two possibilities:
>
> - you have a large and slow disk, and that one object really is way out
> there on the other side of the disk, and seeking really takes almost a
> second.
>
Its a Thinkpad 2.5 inches HD, 2 years old (IBM/Hitachi Travelstar 40GNX family)
> Quite frankly, I expected that the time when a single stat() took
> almost a second was a decade or more in the past, back in the days of
> floppy-disks. But what do I know?
>
> - your disk is failing, and ends up doing error recovery etc.
>
No recent errors are reported:
Stripped from smartctl -a /dev/hda
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 062 Pre-fail
Always - 0
2 Throughput_Performance 0x0005 100 100 040 Pre-fail
Offline - 0
3 Spin_Up_Time 0x0007 165 165 033 Pre-fail
Always - 1
4 Start_Stop_Count 0x0012 097 097 000 Old_age
Always - 4928
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail
Always - 0
8 Seek_Time_Performance 0x0005 100 100 040 Pre-fail
Offline - 0
9 Power_On_Hours 0x0012 073 073 000 Old_age
Always - 11832
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 099 099 000 Old_age
Always - 2563
191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 117
193 Load_Cycle_Count 0x0012 045 045 000 Old_age
Always - 558210
194 Temperature_Celsius 0x0002 130 130 000 Old_age
Always - 42 (Lifetime Min/Max 5/59)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age
Always - 1
197 Current_Pending_Sector 0x0022 100 100 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age
Always - 0
210 Unknown_Attribute 0x0023 100 100 001 Pre-fail
Always - 0
SMART Error Log Version: 1
ATA Error Count: 2
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 2 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
10 51 01 0f 8e a8 e4 Error: IDNF at LBA = 0x04a88e0f = 78155279
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
20 ff 01 0f 8e a8 e4 00 00:05:26.850 READ SECTOR(S)
c8 ff 01 0f 8e a8 e4 00 00:05:26.775 READ DMA
c8 ff 01 00 00 00 e0 00 00:05:26.625 READ DMA
ca 04 01 ff 52 a8 e4 00 00:03:40.575 WRITE DMA
c8 04 01 ff 52 a8 e4 00 00:03:40.275 READ DMA
Error 1 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
10 51 01 0f 8e a8 e4 Error: IDNF 1 sectors at LBA = 0x04a88e0f = 78155279
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 ff 01 0f 8e a8 e4 00 00:05:26.775 READ DMA
c8 ff 01 00 00 00 e0 00 00:05:26.625 READ DMA
ca 04 01 ff 52 a8 e4 00 00:03:40.575 WRITE DMA
c8 04 01 ff 52 a8 e4 00 00:03:40.275 READ DMA
ca 04 7d 73 49 02 e0 00 00:03:40.275 WRITE DMA
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
>
> (NOTE NOTE NOTE! There could be other reasons for that second delay. If
> the machine was under heavy load, or was running low on memory, maybe the
> long delay was just due to havign to swap things out or run other things
> instead. That's why it might be interesting to see if the number is
> "stable" in that it's always that same object..)
>
No load, no low memory: I quitted everything before to test. I will
test again as soon smartctl finishes.
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-19 19:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611191931.32193.jnareb@gmail.com>
Hi,
On Sun, 19 Nov 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > I do not understand. What paths are handled by git-shortlog?
>
> I was under (perhaps false) impression that somewhere in git-shortlog
> there is shortening of
> Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
> messages, shortening the URL part.
>
> Perhaps this was only other example of hard-coded git-for-Linux-ness.
I found it: git-shortlog.perl:28 says
$desc =~ s#/pub/scm/linux/kernel/git/#/.../#g;
And in builtin-shortlog.c:90 you can read
const char *dot3 = "/pub/scm/linux/kernel/git/";
and in lines 133--136:
while ((p = strstr(buffer, dot3)) != NULL) {
memcpy(p, "...", 3);
strcpy(p + 2, p + sizeof(dot3) - 1);
}
So, not only did I forget that git-shortlog has the path shortening, but I
also forgot that I implemented it in the builtin shortlog, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [Fwd: Re: What's in git.git]
From: Robin Rosenberg @ 2006-11-19 19:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Smirl, Shawn Pearce, Git Mailing List
In-Reply-To: <20061119174902.GW7201@pasky.or.cz>
söndag 19 november 2006 18:49 skrev Petr Baudis:
> On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:
> > Brendan told me that he would not consider Mozilla moving to git until
> > a native Windows version is released so I just dropped the whole
> > thing. It is too much effort and they don't even really want it. They
> > are probably going to switch to SVN. I told him that SVN would end up
> > being a disaster and he got mad at me. That's when I stopped working
> > on cvs2svn/git.
>
> I see. :-(
>
> Could you please publish cvs2git in whatever state you have it so that
> someone else possibly interested could pick it up and finish the missing
> bits? It would be shame if the already done work would end up wasted.
>
> > #2) git needs native Windows support, this probably includes MSVC
> > integration. There are a lot of non-technical people working on
> > Mozilla like accessibility, doc, artwork, translations, they are all
> > on Windows. Brendan explicitly ruled out cygwIn.
>
> This is sort of catch-22, we have probably no developers interested
> enough in porting Git to native Windows and it's not clear we are going
> to get any until Git runs on native Windows.
Having a usable set of git in C-format (or C++) is what it takes to get things
rolling. Make the shores of Git-land shallow with nice beaches, so it easy to
enter and you'll get people there, just out of curiosity. They'll start
improving things after a while.
Even if it is possible to run bash, python, perl and who-knows-what in native
windows it makes installing and packaging complicated. It is quite simple to
install git under cygwin for people versed in cygwin or Linux, but not for
those that have no interest in those two.
As for plugins to visual studio and othe strange things, they will come if a
practically usable core set is in place, that can be built and redestributed
without a ton of dependencies. People have used visual studio with CVS and
other tools without plugins for a long time just fine so Git will do fine
withour it for a while too. Eventually we'll have TortoiseGit. They key is a
usable subset of Git that only requires a C compiler (or C++). Other
solutions are ofcourse possible (like a C# re-implementation), but making
things native C-code is the most straightforward path that doesn't split the
code base.
^ permalink raw reply
* Re: can I remove or move a tag in a remote repository?
From: Jakub Narebski @ 2006-11-19 18:54 UTC (permalink / raw)
To: git
In-Reply-To: <87wt5rffbm.fsf@rho.meyering.net>
Jim Meyering wrote:
> When I try to push the new tags, git-push fails:
>
> $ git-push -f --tags ssh+git://git.sv.gnu.org/srv/git/coreutils master:refs/heads/master
> updating 'refs/tags/cvs-head'
> from 2fd3fd29a8b40be695bc2327c8cd3bd33e521100
> to db18f53ffb221e9957124d8af81c11a7e350ac3b
> ...
> Total 1, written 1 (delta 0), reused 0 (delta 0)
> Unpacking 1 objects
> error: denying non-fast forward; you should pull first
>
> I get the same error also when using --force.
Possibly remote side has receive.denyNonFastForwards set (it should not
I think if it is public published bare repository). But even then there
should be no fast-forward check on tags...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* can I remove or move a tag in a remote repository?
From: Jim Meyering @ 2006-11-19 18:42 UTC (permalink / raw)
To: git
Hello,
Periodically, I sync the coreutils git repository to an otherwise
read-only CVS repo, and use a cheap git tag named "cvs-head" to keep
track of the point to which the latest sync operation has run.
Then, after every sync-git-to-cvs operation, I run this:
git-tag -f -m "most recent version that has been sync'd to cvs" cvs-head $sha1
Also periodically, I push my git working dir/repo to a public place,
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=summary
-----------------
Just today, I have finally pushed tags to that public repo, including the
"cvs-head" one (before there were no tags in the remote repo). But now,
I've just done a local sync-to-cvs operation, which has resulted in
moving that tag to point to a different point in the git repo.
Here's the problem:
When I try to push the new tags, git-push fails:
$ git-push -f --tags ssh+git://git.sv.gnu.org/srv/git/coreutils master:refs/heads/master
updating 'refs/tags/cvs-head'
from 2fd3fd29a8b40be695bc2327c8cd3bd33e521100
to db18f53ffb221e9957124d8af81c11a7e350ac3b
...
Total 1, written 1 (delta 0), reused 0 (delta 0)
Unpacking 1 objects
error: denying non-fast forward; you should pull first
I get the same error also when using --force.
Perhaps I shouldn't push the cvs-head tag at all.
A few questions:
- is there a way to say "push all tags matching /COREUTILS-*/"
or to say "push all tags, except the ones on this list"?
- is there a way to remove the cvs-head tag from the remote directory?
Note: I don't have shell access there. I can request that someone
with shell access do it, but shouldn't have to resort to that.
- is there some way to make "git push" do what I want, and update the
offending tag in the remote repo?
Thanks for listening,
^ permalink raw reply
* Re: Shouldn't git-ls-files --others use $GIT_DIR?
From: Petr Baudis @ 2006-11-19 18:37 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git
In-Reply-To: <dbfc82860611190537q77c8a358m184377a21d5a3e11@mail.gmail.com>
On Sun, Nov 19, 2006 at 02:37:42PM CET, Nikolai Weibull wrote:
> If I do
>
> GIT_DIR=$HOME/projects/<project>/.git git ls-files --others
>
> from, e.g., $HOME, I get a list of all the files in $HOME and its
> subdirectories that aren't in said git repository. Shouldn't --others
> use $GIT_DIR, instead of ".", or am I missing something here?
git-ls-files --others lists untracked files in the current directory by
comparing it to the index stored in $GIT_DIR/index and listing files
present in the current directory but not in the index.
GIT_DIR is a path to the Git repository the commands should work with,
but if they work on working tree, they look at the current directory for
it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: What's in git.git
From: Jakub Narebski @ 2006-11-19 18:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611191729190.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> I do not understand. What paths are handled by git-shortlog?
I was under (perhaps false) impression that somewhere in git-shortlog
there is shortening of
Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
messages, shortening the URL part.
Perhaps this was only other example of hard-coded git-for-Linux-ness.
--
Jakub Narebski
^ permalink raw reply
* Re: Git manuals
From: Jakub Narebski @ 2006-11-19 18:16 UTC (permalink / raw)
To: git
In-Reply-To: <20061119175952.GX7201@pasky.or.cz>
Petr Baudis wrote:
> Your approach is fine for something you would call "Git Reference
> Manual", but it is something really different from "The Git Book" or
> "Git User's Manual".
By the way, does AsciiDoc support conversion to texinfo (and then to info)
format? It would be nice to have "The Git Book" aka "GUM - Git User's
Manual" in texinfo, HTML and perhaps also PDF (HTML and PDF with
graphs/images).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: Petr Baudis @ 2006-11-19 18:13 UTC (permalink / raw)
To: Sean
Cc: Git Mailing List, A Large Angry SCM, Rene Scharfe, Junio C Hamano,
Johannes Schindelin, Jeff King
In-Reply-To: <20061118150431.81076072.seanlkml@sympatico.ca>
On Sat, Nov 18, 2006 at 09:04:31PM CET, Sean wrote:
> On Sat, 18 Nov 2006 11:37:14 -0800
> A Large Angry SCM <gitzilla@gmail.com> wrote:
>
> > I disagree. If a command is install on a system, it's man
> > pages/documentation should also be installed.
>
> Well this isn't a huge issue. One point you made though that struck
> a chord is that many of the commands should probably not be in
> section 1.
The trouble is that there's no other good place where to put them. But
perhaps we can get away with putting them to section 3? After all, Perl
installs documentation for its modules to section 3 as well.
> > I'm also not convinced that there are a "large number of commands [...]
> > that should only ever be accessed as plumbing". I am convinced, however,
> > that there are a number of relatively low level commands with poor user
> > interfaces that are useful on their own.
>
> Is there really a reason for a git user to access these from the
> command line rather than a script:
>
> commit-tree, diff-files, diff-index, diff-tree, for-each-ref,
> hash-object, http-fetch, http-push, index-pack, local-fetch,
> merge-base, merge-index, merge-octopus, merge-one-file, merge-ours,
> merge-recur, merge-recursive, merge-recursive-old, merge-resolve,
> merge-stupid, merge-tree, receive-pack, runstatus, ssh-fetch, ssh-pull,
> ssh-push, ssh-upload, symbolic-ref, unpack-file, unpack-objects,
> update-ref, upload-archive, upload-pack, upload-tar, write-tree
>
> Not a complete list, and maybe i overlooked something in there
> that is needed from the command line, but for the most part
> these could be installed somewhere other than the users path.
There certainly are reasons, but the situations where it is needed is
sufficiently rare; I think that's a reason good enough, when doing
something exotic like recovery of a corrupted repository it's ok to have
to do something slightly special to execute a lowlevel command.
It has been proposed for a long time that we put the "pure plumbing"
commands to /usr/libexec/git/ or somewhere there (some say /usr/libexec/
is obsolete), and I think it would be a great move. Note that nowadays
the transition needs to be done carefully because of backwards
compatibility.
BTW, I've finally found a fine example of situation parallel to Git:
TeX! There are the core TeX commands (plumbing) and plain TeX (basic
porcelain) on top of that as well as a bunch of other macro sets (other
porcelains). Now I need to dig out The TeXbook from wherever I've put it
to see how did Knuth deal with it, documentation-wise.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 18:05 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550611190140n3277ee26v95feba26dd3348fa@mail.gmail.com>
On Sun, 19 Nov 2006, Marco Costalba wrote:
>
> Sure. File ran against git tree attached.
Ok. Nothing really strange stands out - it's a nice trace with just over
400 system calls. I'd expect it to finish in no time at all (tracing will
add some overhead, since you context switch back and forth between the
tracer and the tracee, but it's really not doing a lot, so even with
tracing it should execute almost instantaneously).
So it all looks _almost_ fine..
Except for this one:
10:19:04.449236 stat64(".git/objects/3a/41a48d139d1425c1d27e3fbe4f511fb7e09e94", {st_mode=S_IFREG|0444, st_size=278, ...}) = 0 <0.817989>
That's a _single_ "stat64()" system call that takes almost a second to
execute. All the rest are in the millisecond range, and sometimes a
hundreth of a second or two. Ie doing
grep -v ' <0.0[012]' tracefile_git_tree.txt
on your tracefile, there's really not a lot of system calls that take a
long time, and that one stat _really_ stands out (the others are 3 or four
hundredths of a second, and then suddenly you have one that is 20 times
longer than even the slowest other ones.
Basically, you seem to have a _single_ object access that takes up half
the time of the whole program.
It's the object for 'refs/tags/v1.4.4-rc1' in case you care, btw.
> If you want I can repack and prune, but for now I just wait to avoid
> to corrupt this test case.
What you could try to do is to re-run it a few times (cold-cache) and see
if those numbers really are stable, and if it's always the same object
that takes that long.
In fact, you could even do a simple
time ls -l .git/objects/3a/41a48d139d1425c1d27e3fbe4f511fb7e09e94
for the cold-cache case, and see if just even _that_ takes almost a
second.
If it _is_ stable, there's two possibilities:
- you have a large and slow disk, and that one object really is way out
there on the other side of the disk, and seeking really takes almost a
second.
Quite frankly, I expected that the time when a single stat() took
almost a second was a decade or more in the past, back in the days of
floppy-disks. But what do I know?
- your disk is failing, and ends up doing error recovery etc.
Maybe worth running "smartctl -a /dev/hda" or whatever, to see if the
disk already knows it is having problems.
Anyway, repacking will fix this, but quite frankly, you might have a
reason to be a bit nervous about that disk if I were you.
(NOTE NOTE NOTE! There could be other reasons for that second delay. If
the machine was under heavy load, or was running low on memory, maybe the
long delay was just due to havign to swap things out or run other things
instead. That's why it might be interesting to see if the number is
"stable" in that it's always that same object..)
^ permalink raw reply
* Git manuals
From: Petr Baudis @ 2006-11-19 17:59 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Theodore Tso, linux, git
In-Reply-To: <20061119175040.GB15608@fieldses.org>
On Sun, Nov 19, 2006 at 06:50:40PM CET, J. Bruce Fields wrote:
> On Fri, Nov 17, 2006 at 01:21:57PM -0500, bfields wrote:
> > On Fri, Nov 17, 2006 at 10:32:46AM -0500, Theodore Tso wrote:
> > > It would be nice if there was an easy way to direct users through the
> > > documentation in a way which makes good pedagogical sense.
> ....
> > How about this as a strawman "git user's manual" outline:
(I was briefly discussing Git Book with Junio at OLS, I think the result
was "yeah, would be nice, perhaps we can start poking it soon". I
started to think about it once again in the last few weeks.)
> In fact, I'm tempted to submit a patch that just assigns a chapter
> number to everything under Documentation/, slaps a single table of
> contents on the front, and calls the result "the git user's manual."
>
> Of course, the moment people started trying to read the thing they'd
> complain that it was a mess--some stuff referenced without being
> introduced, other stuff introduced too many times. But then over time
> maybe that'd force us to mold it into some sort of logical sequence.
Sequencing isn't the only problem. A _manual_ is different from
_reference documentation_ in that it does not usually describe command
after command, but rather concept after concept. So instead of slamming
git-*-pack commands together, you have a section "Handling Packs" where
you try to coherently describe the commands together.
Your approach is fine for something you would call "Git Reference
Manual", but it is something really different from "The Git Book" or
"Git User's Manual".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: J. Bruce Fields @ 2006-11-19 17:50 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux, git
In-Reply-To: <20061117182157.GC11882@fieldses.org>
On Fri, Nov 17, 2006 at 01:21:57PM -0500, bfields wrote:
> On Fri, Nov 17, 2006 at 10:32:46AM -0500, Theodore Tso wrote:
> > It would be nice if there was an easy way to direct users through the
> > documentation in a way which makes good pedagogical sense.
....
> How about this as a strawman "git user's manual" outline:
In fact, I'm tempted to submit a patch that just assigns a chapter
number to everything under Documentation/, slaps a single table of
contents on the front, and calls the result "the git user's manual."
Of course, the moment people started trying to read the thing they'd
complain that it was a mess--some stuff referenced without being
introduced, other stuff introduced too many times. But then over time
maybe that'd force us to mold it into some sort of logical sequence.
^ permalink raw reply
* Re: [Fwd: Re: What's in git.git]
From: Petr Baudis @ 2006-11-19 17:49 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <9e4733910611190940y147992b8mbdfac5a51f42e0fe@mail.gmail.com>
On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:
> Brendan told me that he would not consider Mozilla moving to git until
> a native Windows version is released so I just dropped the whole
> thing. It is too much effort and they don't even really want it. They
> are probably going to switch to SVN. I told him that SVN would end up
> being a disaster and he got mad at me. That's when I stopped working
> on cvs2svn/git.
I see. :-(
Could you please publish cvs2git in whatever state you have it so that
someone else possibly interested could pick it up and finish the missing
bits? It would be shame if the already done work would end up wasted.
> #2) git needs native Windows support, this probably includes MSVC
> integration. There are a lot of non-technical people working on
> Mozilla like accessibility, doc, artwork, translations, they are all
> on Windows. Brendan explicitly ruled out cygwIn.
This is sort of catch-22, we have probably no developers interested
enough in porting Git to native Windows and it's not clear we are going
to get any until Git runs on native Windows.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [Fwd: Re: What's in git.git]
From: Jon Smirl @ 2006-11-19 17:40 UTC (permalink / raw)
To: Shawn Pearce, Git Mailing List
In-Reply-To: <20061119171135.GA13054@spearce.org>
On 11/19/06, Shawn Pearce <spearce@spearce.org> wrote:
> Have you been watching the shallow clone threads?
Some friends of mine are doing a start up that is sort of like a Sonos
system but with some major differences. I've been helping them out so
I've been doing chip design and PCB layouts lately. The system also
needs some really complicated real-time, wireless mesh routing
software, I wish the OLPC 802.11s code was ready.
Brendan told me that he would not consider Mozilla moving to git until
a native Windows version is released so I just dropped the whole
thing. It is too much effort and they don't even really want it. They
are probably going to switch to SVN. I told him that SVN would end up
being a disaster and he got mad at me. That's when I stopped working
on cvs2svn/git.
The shallow clone work is being done in the wrong order to get the
Mozilla people interested.
#1) There needs to be a tool that can accurately import the
repository. cvs2svn does not do this. The good programmers working on
git could probably whip this out in a week or two if they wanted to.
cvs2svn is very close but they refuse to solve the symbol dependency
problem.
#2) git needs native Windows support, this probably includes MSVC
integration. There are a lot of non-technical people working on
Mozilla like accessibility, doc, artwork, translations, they are all
on Windows. Brendan explicitly ruled out cygwIn.
#3) Once #1 and #2 are achieved then they will care about shallow clone.
The only way I can see Mozilla moving to git is if the git community
ports the repository for them and then demonstrates that all of the
needed tools and available and working.
> ---------- Forwarded message ----------
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> To: Junio C Hamano <junkio@cox.net>
> Date: Sun, 19 Nov 2006 16:17:17 +0100 (CET)
> Subject: Re: What's in git.git
> Hi,
>
> On Sat, 18 Nov 2006, Junio C Hamano wrote:
>
> > Junio C Hamano <junkio@cox.net> writes:
> >
> > > - 'pu' has the shallow clone WIP and a half-finished rewrite of
> > > git branch in C, both by Johannes. Both needs a bit more
> > > polishing and confidence building before going into 'next',
> > > and given the recent discussion of enhancing branch
> > > management for pulls/pushes, it might be easier to drop the
> > > latter for now.
> >
> > OOPS; sorry but the latter half is entirely untrue. What's
> > there is half-done git-shortlog. Scratch everything about
> > branch management please.
>
> IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out
> the built-in mailmap which is totally specific to the Linux kernel
> development.
>
> As for shallow clone support: I am a bit underwhelmed by the enthusiasm
> to test this thing by the people I thought would be most interested. It
> really could be the case that it is not needed at all.
>
> Just for the record, though: AFAICT the shallow stuff is lacking support
> for at least pushing from/into shallow repos and it should avoid making a
> commit shallow unnecessarily. And quite likely there are a few thinkos in
> it, so it would not hurt having more test cases (notably of things I did
> not think of), and some bad-ass testing with huge amounts of commits and
> files which were added/modified identically in different commits.
>
> Ciao,
> Dscho
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Jon Smirl
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-11-19 17:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, alp, jonsmirl
In-Reply-To: <Pine.LNX.4.63.0611191547460.13772@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, Nov 19, 2006 at 04:17:17PM CET, Johannes Schindelin wrote:
> As for shallow clone support: I am a bit underwhelmed by the enthusiasm
> to test this thing by the people I thought would be most interested. It
> really could be the case that it is not needed at all.
I was underwhelmed all the same by response to my multifetch work.
Perhaps we need some better mechanism to get feedback from the
downstream users which were main requesters of the $feature (I think
that in both cases people can see how it could be useful generically but
there's not too much immediate enthusiasm for playing with it inside the
community). I think the main user of multifetch was xorg while the
primary user of shallow clones would be Mozilla, right?
It would be great if, when wishing for some large feature, they could
say something like "if this ever gets done, please prod $mailinglist and
we'll give it a stab and get you some feedback" (apparently there's
noone from there monitoring the mailing list consistently, which is
understandable though since it's not a too much low-traffic one).
Alp? (xorg) Jon? (mozilla)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: git-svn bug?
From: Eric Wong @ 2006-11-19 16:52 UTC (permalink / raw)
To: Troy Telford; +Cc: Junio C Hamano, git
In-Reply-To: <op.ti6irtilzidtg1@rygel.lnxi.com>
Troy Telford <ttelford.groups@gmail.com> wrote:
> My 'dummy' repo was imported using git-svn.
> My 'real' repo was imported using git-svnimport.
>
> Having not read any of the code, I'm just taking a wild guess; but is it
> reasonable to say that since the repository was originally imported to git
> using git-svnimport (rather than git-svn), git-svn doesn't have some of
> the data it needs to push to the remote svn repo?
Exactly, git-svn needs the git-svn-id: lines at the end of each commit
for 'commit' and 'dcommit' to work. So using a repo created by
git-svnimport will not work.
'commit-diff' will work, however it's intended as a low-level command
('commit' should be that, too).
> Would it be reasonable to use git-svn to import the SVN repository into a
> new git repo, and then rebase from the old git-svnimport'ed repo into the
> new git-svn imported one? (did that even make sense?!?)
Yes, something along those lines would work.
--
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-19 16:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejpu4r$dsk$1@sea.gmane.org>
Hi,
On Sun, 19 Nov 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Sat, 18 Nov 2006, Junio C Hamano wrote:
> >
> > IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out
> > the built-in mailmap which is totally specific to the Linux kernel
> > development.
See the 3 patches I just sent.
> If I remember correctly besides having built-in mailmap (at least in Perl
> version quite easy modificable, and updateable via Inline::Files), it also
> have built-in path shortening. And that part IIRC was not solved (although
> there was some proposal).
I do not understand. What paths are handled by git-shortlog?
Ciao,
Dscho
^ permalink raw reply
* [PATCH 3/3] shortlog: handle email addresses case-insensitively
From: Johannes Schindelin @ 2006-11-19 16:29 UTC (permalink / raw)
To: junkio, git
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-shortlog.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index afc9456..4775c11 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -34,6 +34,7 @@ static int read_mailmap(const char *file
while (fgets(buffer, sizeof(buffer), f) != NULL) {
char *end_of_name, *left_bracket, *right_bracket;
char *name, *email;
+ int i;
if (buffer[0] == '#')
continue;
if ((left_bracket = strchr(buffer, '<')) == NULL)
@@ -50,7 +51,9 @@ static int read_mailmap(const char *file
name = xmalloc(end_of_name - buffer + 1);
strlcpy(name, buffer, end_of_name - buffer + 1);
email = xmalloc(right_bracket - left_bracket);
- strlcpy(email, left_bracket + 1, right_bracket - left_bracket);
+ for (i = 0; i < right_bracket - left_bracket - 1; i++)
+ email[i] = tolower(left_bracket[i + 1]);
+ email[right_bracket - left_bracket - 1] = '\0';
path_list_insert(email, &mailmap)->util = name;
}
fclose(f);
@@ -68,6 +71,9 @@ static int map_email(char *email, char *
return 0;
*p = '\0';
+ /* downcase the email address */
+ for (p = email; *p; p++)
+ *p = tolower(*p);
item = path_list_lookup(email, &mailmap);
if (item != NULL) {
const char *realname = (const char *)item->util;
--
1.4.4.GIT
^ permalink raw reply related
* [PATCH 2/3] shortlog: read mailmap from ./.mailmap again
From: Johannes Schindelin @ 2006-11-19 16:28 UTC (permalink / raw)
To: junkio, git
While at it, remove the linux specific mailmap into
contrib/mailmap.linux.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-shortlog.c | 81 +++++++++++++++++++++++-------------------------
contrib/mailmap.linux | 40 ++++++++++++++++++++++++
2 files changed, 79 insertions(+), 42 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 26212b0..afc9456 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -22,48 +22,40 @@ static int compare_by_number(const void
return +1;
}
-static struct path_list_item mailmap_list[] = {
- { "R.Marek@sh.cvut.cz", (void*)"Rudolf Marek" },
- { "Ralf.Wildenhues@gmx.de", (void*)"Ralf Wildenhues" },
- { "aherrman@de.ibm.com", (void*)"Andreas Herrmann" },
- { "akpm@osdl.org", (void*)"Andrew Morton" },
- { "andrew.vasquez@qlogic.com", (void*)"Andrew Vasquez" },
- { "aquynh@gmail.com", (void*)"Nguyen Anh Quynh" },
- { "axboe@suse.de", (void*)"Jens Axboe" },
- { "blaisorblade@yahoo.it", (void*)"Paolo 'Blaisorblade' Giarrusso" },
- { "bunk@stusta.de", (void*)"Adrian Bunk" },
- { "domen@coderock.org", (void*)"Domen Puncer" },
- { "dougg@torque.net", (void*)"Douglas Gilbert" },
- { "dwmw2@shinybook.infradead.org", (void*)"David Woodhouse" },
- { "ecashin@coraid.com", (void*)"Ed L Cashin" },
- { "felix@derklecks.de", (void*)"Felix Moeller" },
- { "fzago@systemfabricworks.com", (void*)"Frank Zago" },
- { "gregkh@suse.de", (void*)"Greg Kroah-Hartman" },
- { "hch@lst.de", (void*)"Christoph Hellwig" },
- { "htejun@gmail.com", (void*)"Tejun Heo" },
- { "jejb@mulgrave.(none)", (void*)"James Bottomley" },
- { "jejb@titanic.il.steeleye.com", (void*)"James Bottomley" },
- { "jgarzik@pretzel.yyz.us", (void*)"Jeff Garzik" },
- { "johnpol@2ka.mipt.ru", (void*)"Evgeniy Polyakov" },
- { "kay.sievers@vrfy.org", (void*)"Kay Sievers" },
- { "minyard@acm.org", (void*)"Corey Minyard" },
- { "mshah@teja.com", (void*)"Mitesh shah" },
- { "pj@ludd.ltu.se", (void*)"Peter A Jonsson" },
- { "rmps@joel.ist.utl.pt", (void*)"Rui Saraiva" },
- { "santtu.hyrkko@gmail.com", (void*)"Santtu Hyrkk^[,Av^[(B" },
- { "simon@thekelleys.org.uk", (void*)"Simon Kelley" },
- { "ssant@in.ibm.com", (void*)"Sachin P Sant" },
- { "terra@gnome.org", (void*)"Morten Welinder" },
- { "tony.luck@intel.com", (void*)"Tony Luck" },
- { "welinder@anemone.rentec.com", (void*)"Morten Welinder" },
- { "welinder@darter.rentec.com", (void*)"Morten Welinder" },
- { "welinder@troll.com", (void*)"Morten Welinder" }
-};
-
-static struct path_list mailmap = {
- mailmap_list,
- sizeof(mailmap_list) / sizeof(struct path_list_item), 0, 0
-};
+static struct path_list mailmap = {NULL, 0, 0, 0};
+
+static int read_mailmap(const char *filename)
+{
+ char buffer[1024];
+ FILE *f = fopen(filename, "r");
+
+ if (f == NULL)
+ return 1;
+ while (fgets(buffer, sizeof(buffer), f) != NULL) {
+ char *end_of_name, *left_bracket, *right_bracket;
+ char *name, *email;
+ if (buffer[0] == '#')
+ continue;
+ if ((left_bracket = strchr(buffer, '<')) == NULL)
+ continue;
+ if ((right_bracket = strchr(left_bracket + 1, '>')) == NULL)
+ continue;
+ if (right_bracket == left_bracket + 1)
+ continue;
+ for (end_of_name = left_bracket; end_of_name != buffer
+ && isspace(end_of_name[-1]); end_of_name--)
+ /* keep on looking */
+ if (end_of_name == buffer)
+ continue;
+ name = xmalloc(end_of_name - buffer + 1);
+ strlcpy(name, buffer, end_of_name - buffer + 1);
+ email = xmalloc(right_bracket - left_bracket);
+ strlcpy(email, left_bracket + 1, right_bracket - left_bracket);
+ path_list_insert(email, &mailmap)->util = name;
+ }
+ fclose(f);
+ return 0;
+}
static int map_email(char *email, char *name, int maxlen)
{
@@ -269,6 +261,9 @@ int cmd_shortlog(int argc, const char **
argc--;
}
+ if (!access(".mailmap", R_OK))
+ read_mailmap(".mailmap");
+
if (rev.pending.nr == 1)
die ("Need a range!");
else if (rev.pending.nr == 0)
@@ -298,6 +293,8 @@ int cmd_shortlog(int argc, const char **
list.strdup_paths = 1;
path_list_clear(&list, 1);
+ mailmap.strdup_paths = 1;
+ path_list_clear(&mailmap, 1);
return 0;
}
diff --git a/contrib/mailmap.linux b/contrib/mailmap.linux
new file mode 100644
index 0000000..83927c9
--- /dev/null
+++ b/contrib/mailmap.linux
@@ -0,0 +1,40 @@
+#
+# Even with git, we don't always have name translations.
+# So have an email->real name table to translate the
+# (hopefully few) missing names
+#
+Adrian Bunk <bunk@stusta.de>
+Andreas Herrmann <aherrman@de.ibm.com>
+Andrew Morton <akpm@osdl.org>
+Andrew Vasquez <andrew.vasquez@qlogic.com>
+Christoph Hellwig <hch@lst.de>
+Corey Minyard <minyard@acm.org>
+David Woodhouse <dwmw2@shinybook.infradead.org>
+Domen Puncer <domen@coderock.org>
+Douglas Gilbert <dougg@torque.net>
+Ed L Cashin <ecashin@coraid.com>
+Evgeniy Polyakov <johnpol@2ka.mipt.ru>
+Felix Moeller <felix@derklecks.de>
+Frank Zago <fzago@systemfabricworks.com>
+Greg Kroah-Hartman <gregkh@suse.de>
+James Bottomley <jejb@mulgrave.(none)>
+James Bottomley <jejb@titanic.il.steeleye.com>
+Jeff Garzik <jgarzik@pretzel.yyz.us>
+Jens Axboe <axboe@suse.de>
+Kay Sievers <kay.sievers@vrfy.org>
+Mitesh shah <mshah@teja.com>
+Morten Welinder <terra@gnome.org>
+Morten Welinder <welinder@anemone.rentec.com>
+Morten Welinder <welinder@darter.rentec.com>
+Morten Welinder <welinder@troll.com>
+Nguyen Anh Quynh <aquynh@gmail.com>
+Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
+Peter A Jonsson <pj@ludd.ltu.se>
+Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
+Rudolf Marek <R.Marek@sh.cvut.cz>
+Rui Saraiva <rmps@joel.ist.utl.pt>
+Sachin P Sant <ssant@in.ibm.com>
+Santtu Hyrkk^[,Av^[(B <santtu.hyrkko@gmail.com>
+Simon Kelley <simon@thekelleys.org.uk>
+Tejun Heo <htejun@gmail.com>
+Tony Luck <tony.luck@intel.com>
--
1.4.4.GIT
^ permalink raw reply related
* [PATCH 1/3] shortlog: do not crash on parsing "[PATCH"
From: Johannes Schindelin @ 2006-11-19 16:28 UTC (permalink / raw)
To: junkio, git
Annoyingly, it looked for the closing bracket in the author name
instead of in the message, and then accessed the NULL pointer.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-shortlog.c | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 48a2a0b..26212b0 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -108,13 +108,15 @@ static void insert_author_oneline(struct
free(buffer);
if (!strncmp(oneline, "[PATCH", 6)) {
- char *eob = strchr(buffer, ']');
-
- while (isspace(eob[1]) && eob[1] != '\n')
- eob++;
- if (eob - oneline < onelinelen) {
- onelinelen -= eob - oneline;
- oneline = eob;
+ char *eob = strchr(oneline, ']');
+
+ if (eob) {
+ while (isspace(eob[1]) && eob[1] != '\n')
+ eob++;
+ if (eob - oneline < onelinelen) {
+ onelinelen -= eob - oneline;
+ oneline = eob;
+ }
}
}
--
1.4.4.GIT
^ permalink raw reply related
* [PATCH 0/3] Fixes for builtin shortlog
From: Johannes Schindelin @ 2006-11-19 16:27 UTC (permalink / raw)
To: junkio, git
Hi,
this series brings back support for reading .mailmap, fixes an annoying
crash, handles the email addresses case-insensitively, and removes the
in-built Linux specific mailmapping.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git
From: Jakub Narebski @ 2006-11-19 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611191547460.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sat, 18 Nov 2006, Junio C Hamano wrote:
>
>> OOPS; sorry but the latter half is entirely untrue. What's
>> there is half-done git-shortlog. Scratch everything about
>> branch management please.
>
> IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out
> the built-in mailmap which is totally specific to the Linux kernel
> development.
If I remember correctly besides having built-in mailmap (at least in Perl
version quite easy modificable, and updateable via Inline::Files), it also
have built-in path shortening. And that part IIRC was not solved (although
there was some proposal).
The shallow clone work looks promising...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-19 15:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wo0bb4z.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 18 Nov 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > - 'pu' has the shallow clone WIP and a half-finished rewrite of
> > git branch in C, both by Johannes. Both needs a bit more
> > polishing and confidence building before going into 'next',
> > and given the recent discussion of enhancing branch
> > management for pulls/pushes, it might be easier to drop the
> > latter for now.
>
> OOPS; sorry but the latter half is entirely untrue. What's
> there is half-done git-shortlog. Scratch everything about
> branch management please.
IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out
the built-in mailmap which is totally specific to the Linux kernel
development.
As for shallow clone support: I am a bit underwhelmed by the enthusiasm
to test this thing by the people I thought would be most interested. It
really could be the case that it is not needed at all.
Just for the record, though: AFAICT the shallow stuff is lacking support
for at least pushing from/into shallow repos and it should avoid making a
commit shallow unnecessarily. And quite likely there are a few thinkos in
it, so it would not hurt having more test cases (notably of things I did
not think of), and some bad-ass testing with huge amounts of commits and
files which were added/modified identically in different commits.
Ciao,
Dscho
^ 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