From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:17
On 1/26/06, Linus Torvalds [off-list ref] wrote:
If we get an error parsing the arguments, exit.
This bug found thanks to the 'demo' effect. ;-)
The workshop had a 2hr slot -- after 2hs 15, I asked Linus if he
wanted to talk about the internals. He did, and the workshop went
on... for 2 hours more. It was actually hard to get people out of the
room.
Sadly, not many people actually played along on their laptop. Those
who did got an extra bit of help to migrate their preexisting CVS/SVN
repos ;-) (thanks to Sam Vilain for all the help!)
I'll upload the presentation material soon -- very similar to the
stuff I used @ Wellington Perl Mongers. Still text-based; given all
the talk about plumbing and porcelain, I steadfastly refuse to add
imagery.
During the presentation someone mentioned errors when running
git-cvsimport which I'm keen on hearing more about.
cheers,
m
During the presentation someone mentioned errors when running
git-cvsimport which I'm keen on hearing more about.
Martin, I talked to Keith, and apparently you fixed some cvsimport problem
they had with Cairo during dinner last night? Was that something that
could have affected other people, or was it very specific to whatever
Cairo CVS insanity? I've not seen any messages from you on it..
Linus
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:17
On 1/28/06, Linus Torvalds [off-list ref] wrote:
quoted
During the presentation someone mentioned errors when running
git-cvsimport which I'm keen on hearing more about.
Martin, I talked to Keith, and apparently you fixed some cvsimport problem
they had with Cairo during dinner last night? Was that something that
could have affected other people, or was it very specific to whatever
Cairo CVS insanity? I've not seen any messages from you on it..
I've got a few small improvements to cvsimport in my laptop that I'll
push out for Junio to merge as soon as I get back to the office. I've
run "99% successful" imports of cairo and of x.org (modular and
monolithic) with all their branches and tags. It isn't literally the
20 years of commits Jim talked initially about -- cvs holds just the
last ~5 years.
The repos *are* a bit broken -- files missing (not moved, but really
missing) so some of the fixes are to make it easier to discover where
it is dying and workaround it. There are a few more things that I need
to debug in cvsimport -- there's a small delta between what I should
have and what I do have. As soon as they are 100% right I'll put them
on http://locke.catalyst.net.nz/gitweb for the X.org team to have a
look at them -- and a cronjob to keep them up to date with official
CVS.
BTW, have you still got that patch to git-merge to seed the commit msg
with conflicted files? ;-)
cheers,
m
BTW, have you still got that patch to git-merge to seed the commit msg
with conflicted files? ;-)
Nope. But it was something like the appended (totally untested, and
slightly improved).
The point being that we'd fill in a template that the committer will
hopefully edit to explain what he did to fix up the merge for each file
that had conflicts.
Linus
---
@@ -301,5 +301,9 @@ then"Automatic merge went well; stopped before committing as requested"exit0else+echo>"$GIT_DIR/MERGE_MSG"+echo"Conflicts in">"$GIT_DIR/MERGE_MSG"+git-ls-files--unmerged|cut-f2|uniq|+sed's/^.*/ \0:/'>"$GIT_DIR/MERGE_MSG"die"Automatic merge failed; fix up by hand"fi
From: Keith Packard <keithp@keithp.com> Date: 2016-06-15 22:42:17
On Sat, 2006-01-28 at 18:33 +1300, Martin Langhoff wrote:
I've got a few small improvements to cvsimport in my laptop that I'll
push out for Junio to merge as soon as I get back to the office. I've
run "99% successful" imports of cairo and of x.org (modular and
monolithic) with all their branches and tags. It isn't literally the
20 years of commits Jim talked initially about -- cvs holds just the
last ~5 years.
Yeah, X CVS is a scattered mess at present. I think it would be better
to just leave that mess alone and grab a reasonably recent chunk of it
to put into a GIT repository. Save a bunch of space too. We also haven't
quite finished all of the recovery needed to span the whole twenty years
yet.
Carl and I hacked at the tool a bit to pull apart our ChangeLog-based
commit messages; extracting email addresses and separating the commit
messages from the (now useless) list of affected files.
We're getting clean cairo imports now, there are a few weirdnesses
around branches that we've seen -- one commit appears on both the branch
and trunk for some reason.
Once we're happy with the import, I'm pretty sure we'll just switch
cairo over to git and dump the CVS bits. X.org is a harder case, for
that I suspect we'll migrate individual modules over one at a time,
perhaps starting with the core X server pieces so that I can get my work
done, have it published in the main repository and not have it also
break everyone else's X server.
I'm not sure we'll need ongoing synchronization with existing X.org CVS
for long; there aren't any other developers doing any significant
changes to this part of the system, so we can abandon the losers with no
remorse.
--
keith.packard@intel.com
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
Keith Packard [off-list ref] writes:
Once we're happy with the import, I'm pretty sure we'll just switch
cairo over to git and dump the CVS bits. X.org is a harder case, for
that I suspect we'll migrate individual modules over one at a time,
perhaps starting with the core X server pieces so that I can get my work
done, have it published in the main repository and not have it also
break everyone else's X server.
Wow....... You are switching Cairo and X.org from CVS to git?
It could be that anything is better than CVS these days, but I
have to admit that my jaw dropped after reading this, primarily
because I've have never touched anything as big as X.
Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have
more faith in git. Earlier I heard Wine folks are running git
in parallel with CVS as their dual primary SCM now, and of
course git is the primary SCM for the Linux kernel project.
For things like the source code management, it takes a new
software to be at least 10 times as good as the one that has
been used, because switching _is_ a pain no matter how well tool
helps the transition. You have to transition not just the
repository, but people who interact with it.
When the Linux kernel switched, it was not that hard to be
infinitely better than the previous one. Because the previous
one was no longer available to the kernel community; git did not
have to be 10 times better on technical merits alone when the
transition happened.
Can I hear experiences from other big projects that tried to use
git [*1*]? I suspect there are many that have tried, and I
would not be surprised at all if git did not work out well for
them. For projects that already run on a (free) SCM, I would be
very surprised if the developers find the current git 10 times
better than the SCM they have been using (probably with an
exception of CVS), unless they have very specific need, such as
parallel development of distributed nature like the Linux
kernel.
I do not do mailing list search as often as I would like to be
doing, but I have seen some projects tried and went back to CVS.
We would learn much from our failures to support them -- what
those people found lacking.
[Foornote]
*1* Please limit yourselves to reasonably well-known "it is
surprising you haven't heard of this project" kind...
Can I hear experiences from other big projects that tried to use
git [*1*]? I suspect there are many that have tried, and I
would not be surprised at all if git did not work out well for
them.
I've been playing with Gnumeric under git.
-rw-rw-r-- 1 welinder research 270M Nov 5 09:46
gnumeric/.git/objects/pack/pack-91291de5477ddd06545b052460239b3dae89ad72.pack
270M is about 40% of the cvs repository size. Given
compression I would have expected bigger savings.
Conversion isn't perfect, probably because the cvs tree has
seen some hacking over the years. (I am not posting the URL
because I don't want to kill gnome.org.)
We haven't switched yet, but I expect that we will. We are
looking for (in no particular order):
1. Offline history.
2. Patch sets and other things that'll make it easier to maintain
more than one branch.
In other words, pretty-much anything but cvs will fit the bill, :-./
M.
From: Keith Packard <keithp@keithp.com> Date: 2016-06-15 22:42:17
On Sat, 2006-01-28 at 13:08 -0800, Junio C Hamano wrote:
Keith Packard [off-list ref] writes:
quoted
Once we're happy with the import, I'm pretty sure we'll just switch
cairo over to git and dump the CVS bits. X.org is a harder case, for
that I suspect we'll migrate individual modules over one at a time,
perhaps starting with the core X server pieces so that I can get my work
done, have it published in the main repository and not have it also
break everyone else's X server.
Wow....... You are switching Cairo and X.org from CVS to git?
We're not switching 'X.org', we're switching the X server core. X.org is
now broken into many separate projects, and each one will get to choose
SCM on their own. I expect to migrate the ones I maintain and use to
git, but migration of the dead code is unlikely to ever happen (and
there's lots of dead code)
It could be that anything is better than CVS these days, but I
have to admit that my jaw dropped after reading this, primarily
because I've have never touched anything as big as X.
Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have
more faith in git. Earlier I heard Wine folks are running git
in parallel with CVS as their dual primary SCM now, and of
course git is the primary SCM for the Linux kernel project.
For things like the source code management, it takes a new
software to be at least 10 times as good as the one that has
been used, because switching _is_ a pain no matter how well tool
helps the transition. You have to transition not just the
repository, but people who interact with it.
Fortunately, there are very few people involved with any specific piece
of the X.org distribution; there's really only one or two people
actively developing the X.org core server, so that part of the migration
will be easy. Our users will be stuck, but there aren't many of them
either, and git makes just sucking the current bits pretty easy.
When the Linux kernel switched, it was not that hard to be
infinitely better than the previous one. Because the previous
one was no longer available to the kernel community; git did not
have to be 10 times better on technical merits alone when the
transition happened.
git really does look 10x better than CVS at this point; mostly social
issues are now blocking X development as weaker developers are refused
access to source code management to protect the project from damage. git
eliminates that barrier, and should let many new developers experiment
and share their results without affecting my work
Can I hear experiences from other big projects that tried to use
git [*1*]? I suspect there are many that have tried, and I
would not be surprised at all if git did not work out well for
them. For projects that already run on a (free) SCM, I would be
very surprised if the developers find the current git 10 times
better than the SCM they have been using (probably with an
exception of CVS), unless they have very specific need, such as
parallel development of distributed nature like the Linux
kernel.
Everyone *wants* parallel distributed development, CVS prevents it.
And, remember that this is *not* a huge project, the core X server is
only 2M lines of source code. We separate out all of the drivers,
libraries and applications. Doing the migration in pieces allows us to
incrementally affect developers, and repair issues without suspending
all development.
I don't know of other huge projects moving to git; it's not all that
interesting as we know the tool is stable and will scale to support our
project already. Also, hg and bzr are not ready for production use in my
opinion; hg as it appears likely a flag day will be required before 1.0,
and bzr because they didn't focus on repository format, and have
suggested that they will switch to a hash-addressed scheme at some point
in the future...
--
keith.packard@intel.com
From: Fredrik Kuivinen <hidden> Date: 2016-06-15 22:42:17
On Sat, Jan 28, 2006 at 12:53:31AM -0500, Linus Torvalds wrote:
On Sat, 28 Jan 2006, Martin Langhoff wrote:
quoted
BTW, have you still got that patch to git-merge to seed the commit msg
with conflicted files? ;-)
Nope. But it was something like the appended (totally untested, and
slightly improved).
The point being that we'd fill in a template that the committer will
hopefully edit to explain what he did to fix up the merge for each file
that had conflicts.
Would it make sense to add an optional
mergeresult <tree>
line to merge commit objects? Here <tree> is supposed to be a SHA1 of
the tree object which corresponds to the result of the automatic part
of a merge. Hence, for a given merge commit which had conflicts
"git-diff-tree <commit SHA1> <mergeresult SHA1>" would give a diff
which shows the changes that was applied to resolve the conflict.
When the recursive merge strategy is used we actually write the
'mergeresult' tree object to the object database, so this thing should
be straight forward to implement in that case. If there is interest it
could be implemented for the resolve strategy too.
I think those mergeresult lines might be useful when implementing
git-annotate across merges too. It makes it easy to distinguish
changes which came from the merged branches and changes introduced in
the merge itself.
It would not be backwards compatible with the current git though...
- Fredrik
Fortunately, there are very few people involved with any specific piece
of the X.org distribution; there's really only one or two people
actively developing the X.org core server, so that part of the migration
will be easy. Our users will be stuck, but there aren't many of them
either, and git makes just sucking the current bits pretty easy.
Not under Windows (bleh), but it's support for Cygwin is getting better
and better.
I don't know of other huge projects moving to git; it's not all that
interesting as we know the tool is stable and will scale to support our
project already. Also, hg and bzr are not ready for production use in my
opinion; hg as it appears likely a flag day will be required before 1.0,
I haven't seen any such flag day since 0.3. Repository format seems
stable, except rename and modes support (these will be added in a
compatible way I think).
0.8 release is imminent (today or tomorrow).
I personally wouldn't mind git - it's great.
The only drawback is local cloning. This operation is like 4x slower
than plain copying of the repository. Probably because it works like an
ssh clone - creates a pack, copies it, then unpacks. This is just
inefficient on a local machine.
and bzr because they didn't focus on repository format, and have
suggested that they will switch to a hash-addressed scheme at some point
in the future...
Not only that - they don't have an efficient network transfer protocol.
(they use HTTP walkers, not even supporting persistent connections and
also do too many DNS lookups)
This is very unfortunate, especially for large projects.
(branching Linux would take 3 days I think)
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
On Sun, Jan 29, 2006 at 12:18:45PM +0100, Radoslaw Szkodzinski wrote:
The only drawback is local cloning. This operation is like 4x slower
than plain copying of the repository. Probably because it works like an
ssh clone - creates a pack, copies it, then unpacks. This is just
inefficient on a local machine.
Have you tried the "-l" option for cloneing locally? It's _very_ fast,
even for my tiny little old laptop.
If you add a "-n" that will not checkout the source tree, so you can
compare the time of cloning with the checkout portion.
thanks,
greg k-h
From: Dave Jones <hidden> Date: 2016-06-15 22:42:17
On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:
> Can I hear experiences from other big projects that tried to use
> git [*1*]? I suspect there are many that have tried, and I
> would not be surprised at all if git did not work out well for
> them. For projects that already run on a (free) SCM, I would be
> very surprised if the developers find the current git 10 times
> better than the SCM they have been using (probably with an
> exception of CVS), unless they have very specific need, such as
> parallel development of distributed nature like the Linux
> kernel.
I've found switching from cvs->git even for small projects has
made me more productive. In part because it's got me away from
the 'check in to a centralised server like sourceforge' mentality,
without the need to set up a local cvs server of my own.
Adding changesets to a small project like x86info, now takes
seconds, whereas it used to take minutes of thumb-twiddling whilst
I waited for sf.net to do its thing. The ability to check in
changesets locally whilst I'm travelling, and then push them when
I have network connectivity again is also a massive productivity
win over cvs.
There's also another git usage that I doubt I'm alone in doing.
I regularly use git to import cvs trees from sourceforge etc for
random projects, because I now find browsing history of projects
with tools like gitk much nicer than any cvs tool I've used.
(cvs annotate is the only thing I really miss).
What would be really cool, would be a web page pointing to public
conversions of various projects cvs trees, so that everyone doesn't
have to keep hammering various repos to do the conversions themselves.
(Sort of a pseudo bkbits.net).
Dave
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:17
On Sun, 29 Jan 2006, Dave Jones wrote:
On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:
> Can I hear experiences from other big projects that tried to use
> git [*1*]? I suspect there are many that have tried, and I
> would not be surprised at all if git did not work out well for
> them. For projects that already run on a (free) SCM, I would be
> very surprised if the developers find the current git 10 times
> better than the SCM they have been using (probably with an
> exception of CVS), unless they have very specific need, such as
> parallel development of distributed nature like the Linux
> kernel.
I've found switching from cvs->git even for small projects has
made me more productive. In part because it's got me away from
the 'check in to a centralised server like sourceforge' mentality,
without the need to set up a local cvs server of my own.
Adding changesets to a small project like x86info, now takes
seconds, whereas it used to take minutes of thumb-twiddling whilst
I waited for sf.net to do its thing. The ability to check in
changesets locally whilst I'm travelling, and then push them when
I have network connectivity again is also a massive productivity
win over cvs.
There's also another git usage that I doubt I'm alone in doing.
I regularly use git to import cvs trees from sourceforge etc for
random projects, because I now find browsing history of projects
with tools like gitk much nicer than any cvs tool I've used.
(cvs annotate is the only thing I really miss).
I think this is the real driving factor for git adoption: it doesn't have
to be 10x better for people to use it, because individuals can use it for
interacting with CVS projects without causing anybody else any pain. It
doesn't just enable distributed development, it enables a distributed
choice of SCM, which means a much lower activation energy threshold. I
think we'll see a lot more adoption when we have a CVS daemon interface
(so projects can stop having a CVS repository, and support both sorts of
users with a git repository and have better metadata), and also if someone
sets up a place for putting git imports of CVS projects, so people will
know that other people are using git.
-Daniel
*This .sig left intentionally blank*
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
Fredrik Kuivinen [off-list ref] writes:
Would it make sense to add an optional
mergeresult <tree>
line to merge commit objects?
Two issues and a half.
(1) Not all conflicting merge cases can write a sensible
"conflicted intermediate auto-merge result". Look for cases
where we punt in git-merge-one-file.
(2) Modulo issue (1), it can be re-computed if and when needed,
so this is akin to "storing rename information in the commit
by detecting renames while merging".
(3) Depending on the direction you pull, you would have
logically the same "conflicted auto-merge result" that has
<<< === >>> delimited hunks in reverse. Which one should
you record?
And annotate would not be helped much -- if it is needed you
could recompute it at that point. Annotate needs to look at the
diff from each parent _anyway_ to assign blames.
By the way, I brought up the issue (3) because it relates to how
my latest toy "git rerere" works ;-).
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:17
On 1/30/06, Daniel Barkalow [off-list ref] wrote:
quoted
There's also another git usage that I doubt I'm alone in doing.
I regularly use git to import cvs trees from sourceforge etc for
random projects, because I now find browsing history of projects
with tools like gitk much nicer than any cvs tool I've used.
(cvs annotate is the only thing I really miss).
I think this is the real driving factor for git adoption: it doesn't have
to be 10x better for people to use it, because individuals can use it for
interacting with CVS projects without causing anybody else any pain.
IMHO, this is a killer feature of GIT. From a CVS/SVN user point of
view, it has vendor branches done right. At work, we do that with
Moodle, Elgg, EPrints and GForge. And the list is growing. That's why
I'm working on the toolchain to make interop with CVS smooth so I can
land patches in upstream projects where I have cvs access.
cheers,
m
From: Mike McCormack <hidden> Date: 2016-06-15 22:42:17
Daniel Barkalow wrote:
I think we'll see a lot more adoption when we have a CVS daemon interface
(so projects can stop having a CVS repository, and support both sorts of
users with a git repository and have better metadata), and also if someone
sets up a place for putting git imports of CVS projects, so people will
know that other people are using git.
The Wine project is using a GIT repository which is mirrored into CVS.
Alexandre wrote scripts to mirror GIT commits into CVS, so developers
can use whichever they're more comfortable with, and the CVS repository
remains up to date.
We've found that patch submitters using GIT tend to send multiple
patches per day, and that those using CVS tend to send a patch or two
occasionally or just keep up to date with the source.
Mike
From: Carl Baldwin <hidden> Date: 2016-06-15 22:42:17
Junio,
You don't seem to give git enough credit. I am a hardware engineer with
many softwareish responsibilities. One of those is to keep up to date
with the many commercial and free SCM type tools that are available.
Git has become my SCM tool of choice for many reasons.
- Anyone can install and fire it up without license/contract hassles.
- The infrastructure barriers to getting a project started with git are
about as low as they can be.
- Geographically distributed teams even inside a corporation are
becoming more common. Git's repository design meets this need
perfectly.
- The repository is also to designed to be inherently safe from
data-loss and corruption even in the face of concurrent writes due to
each objects' immutable nature.
- While on the subject of the repository. Good job keeping it simple.
I was able to learn pretty much all there is to know from a technical
stand-point about the objects and refs directories in an afternoon.
It follows a principle I always work toward myself. "Make it simple
enough that there are obviously no difficiencies rather than making it
complicated so that there are no obvious difficiencies."
- In my opinion git is flexible enough to support just about any
development/build/release flow that one can think of. Most of the
free tools (including subversion and arch) make branching and merging
--- on which most of these flows rely --- way too heavy-weight. Git
shows how light-weight it can be.
Not only can parallel development happen easily between
users/repositories but parallel development is trivial even within the
same repository. I think your 'pu' system illustrates how powerful
it can be. I myself have had up to four concurrent branches where I
implemented four different features in parallel in the same repository
easily switching between them. It was almost too easy to bring them
together using merge as each one finished.
I was just reading through an article on how to choose an SCM last
week and I kept thinking how git could be used to meet almost every
one (if not all) of the needs discussed.
- Git supports enough network protocols to make it immediately useful in
about any situation with firewalls and such. This is where it leaves
monotone behind.
The biggest hurdle that I've seen in adopting git is training the users.
I myself took to it like a duck to water but I've found that even some
of my brightest colleages have trouble wrapping their heads around it.
Currently, I'm trying to look at what parts they are having the most
trouble with. In general, I think it is grasping the reason for the
index file and how git commands like git-commit and git-diff interact
with it.
Even so, I've always appreciated those tools that may have a steeper
learning curve but that pay dividends over time. Also, I should mention
that this learning curve has been flattening over time as git has
developed and obtained more porcelainish commands.
Carl
On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:
Keith Packard [off-list ref] writes:
Wow....... You are switching Cairo and X.org from CVS to git?
It could be that anything is better than CVS these days, but I
have to admit that my jaw dropped after reading this, primarily
because I've have never touched anything as big as X.
Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have
more faith in git. Earlier I heard Wine folks are running git
in parallel with CVS as their dual primary SCM now, and of
course git is the primary SCM for the Linux kernel project.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:17
Hi,
On Mon, 30 Jan 2006, Carl Baldwin wrote:
In general, I think it is grasping the reason for the index file and how
git commands like git-commit and git-diff interact with it.
IMHO this is the one big showstopper. I had problems explaining the
concept myself.
For example, I had a hard time explaining to a friend why a git-add'ed
file is committed when saying "git commit some_other_file", but not
another (modified) file. Very unintuitive.
Ciao,
Dscho
From: Carl Baldwin <hidden> Date: 2016-06-15 22:42:17
Its difficult to explain because it breaks away from the precedent set
by other SCMs. I wouldn't call it a show-stopper for this reason. In
fact, some who have wrapped their heads around the concept might call it
a valuable feature. I, myself, have found it a handy thing in certain
circumstances. In other circumstances I simply bypass it by adding -a
to the command-line.
This doesn't fit my definition of a show-stopper.
Carl
On Tue, Jan 31, 2006 at 11:27:34AM +0100, Johannes Schindelin wrote:
Hi,
On Mon, 30 Jan 2006, Carl Baldwin wrote:
quoted
In general, I think it is grasping the reason for the index file and how
git commands like git-commit and git-diff interact with it.
IMHO this is the one big showstopper. I had problems explaining the
concept myself.
For example, I had a hard time explaining to a friend why a git-add'ed
file is committed when saying "git commit some_other_file", but not
another (modified) file. Very unintuitive.
Ciao,
Dscho
In general, I think it is grasping the reason for the index file and how
git commands like git-commit and git-diff interact with it.
IMHO this is the one big showstopper. I had problems explaining the
concept myself.
For example, I had a hard time explaining to a friend why a git-add'ed
file is committed when saying "git commit some_other_file", but not
another (modified) file. Very unintuitive.
I really think you should explain it one of two ways:
- ignore it. Never _ever_ use git-update-index directly, and don't tell
people about use individual filenames to git-commit. Maybe even add
"-a" by default to the git-commit flags as a special installation
addition.
- talk about the index, and revel in it as a way to explain the staging
area. This is what the old tutorial.txt did before it got simplified.
The "ignore the index" approach is the simple one to explain. It's
strictly less powerful, but hey, what else is new?
Linus
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:42:17
On Tue, Jan 31, 2006 at 09:30:48AM -0800, Linus Torvalds wrote:
I really think you should explain it one of two ways:
- ignore it. Never _ever_ use git-update-index directly, and don't tell
people about use individual filenames to git-commit. Maybe even add
"-a" by default to the git-commit flags as a special installation
addition.
- talk about the index, and revel in it as a way to explain the staging
area. This is what the old tutorial.txt did before it got simplified.
The "ignore the index" approach is the simple one to explain. It's
strictly less powerful, but hey, what else is new?
Yeah, I do wonder what's likely to be the best approach for most users.
My goal with the new tutorial was to get a reader doing something fun
and useful as quickly as possible. So it just refers elsewhere for any
discussion of the index file or SHA1 names. But probably everyone needs
to pick up that stuff eventually anyway, and maybe it's better to get to
it a little sooner, I dunno.
Besides the git-add/git-commit thing, the other thing that caught me by
suprise was the behaviour of git reset. I expected there to be an
"inverse" to git commit -a, meaning that
1) the sequence
git reset HEAD^
git commit -a
would be a no-op, in the sense that the new commit would
get the same changes as the old one, and
2) the sequence
git commit -a
git reset HEAD^
would be a no-op, in the sense that "git diff" would report
the same diff before and after.
But there isn't, and explaining how --soft and --mixed actually work
requires referring to the index file.
Is that something that can be fixed in the tools or does the user
fundamentally need to know about the index file to do this kind of
stuff?
--b.
On Sun, Jan 29, 2006 at 12:18:45PM +0100, Radoslaw Szkodzinski wrote:
quoted
The only drawback is local cloning. This operation is like 4x slower
than plain copying of the repository. Probably because it works like an
ssh clone - creates a pack, copies it, then unpacks. This is just
inefficient on a local machine.
Have you tried the "-l" option for cloneing locally? It's _very_ fast,
even for my tiny little old laptop.
Because it's cp -rl <one-tree> <second-tree> and some file modifications, right?
It's what I've been using already.
This -l option should be more prominent in the documentation.
Maybe it even already is. I've taught myself using git before 0.9.
Thank you. This helps a lot.
If you add a "-n" that will not checkout the source tree, so you can
compare the time of cloning with the checkout portion.
Cloning without -l option is much slower - some minutes vs below a minute.
I could have time(8)d it, but it's no use.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
From: Keith Packard <keithp@keithp.com> Date: 2016-06-15 22:42:17
On Tue, 2006-01-31 at 09:30 -0800, Linus Torvalds wrote:
- ignore it. Never _ever_ use git-update-index directly, and don't tell
people about use individual filenames to git-commit. Maybe even add
"-a" by default to the git-commit flags as a special installation
addition.
As a newly initiated user, this would have been a more gentle
introduction to the system. But, it would be hard to make it entirely
invisible given the current interfaces. I'm not sure if obscuring the
presense of the index is a great plan; it's already hard enough to
figure out how it works.
--
keith.packard@intel.com
On Tue, 2006-01-31 at 09:30 -0800, Linus Torvalds wrote:
quoted
- ignore it. Never _ever_ use git-update-index directly, and don't tell
people about use individual filenames to git-commit. Maybe even add
"-a" by default to the git-commit flags as a special installation
addition.
As a newly initiated user, this would have been a more gentle
introduction to the system. But, it would be hard to make it entirely
invisible given the current interfaces. I'm not sure if obscuring the
presense of the index is a great plan; it's already hard enough to
figure out how it works.
Now, I do agree. I don't actually like hiding the index too much.
Understanding the index is _invaluable_ whenever you're doing a merge with
conflicts, and understanding what tools are available to you to resolve
those conflicts.
The index is also obviously very important when you do a partial commit,
and it's something I do end up doing quite often. Again, maybe that's not
something that a new git user should be encouraged to ever do, but it's a
huge convenience feature for power-users.
Understanding the index also allows people to understand certain
performance-characteristics of git, and explains how "git add" (and
remove, if we had one) actually works independently of the commit.
So I'm actually of the "revel in the index" camp (as could probably be
guessed by the original tutorial).
My personal suggestion would be to introduce git "gently" by ignoring it,
but by the time a person actually _works_ on a project (as opposed to just
going through a tutorial or following another persons project), he/she
should probably have been introduced to the index in order to understand
what happens and to use its power.
(In particular, the difference between "git diff" and "git diff HEAD" is
an important one to understand eventually).
Linus
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
"J. Bruce Fields" [off-list ref] writes:
On Tue, Jan 31, 2006 at 09:30:48AM -0800, Linus Torvalds wrote:
quoted
The "ignore the index" approach is the simple one to explain. It's
strictly less powerful, but hey, what else is new?
Yeah, I do wonder what's likely to be the best approach for most users.
My goal with the new tutorial was to get a reader doing something fun
and useful as quickly as possible. So it just refers elsewhere for any
discussion of the index file or SHA1 names. But probably everyone needs
to pick up that stuff eventually anyway, and maybe it's better to get to
it a little sooner, I dunno.
I think many good stuff git offers would not be helpful to the
users until index is understood as the third entity, in addition
to the usual "committed state" and "working tree state". It
might be better to talk about it sooner rather than later. And
the tool is geared towards taking advantage of it, so until the
user understands that, behaviour of some tools would feel
unintuitive.
You can have local throw-away modifications while applying
patches and merging (I once broke merges by ignoring that it is
perfectly valid to have index and working tree files be
different and keep working that way. That was a hard lesson).
The index file knows what working tree changes are meant to be
committed. Another thing I find useful, which cannot be done
without index, is to sanity check while developing. When "git
diff" gives too many diffs, running update-index on paths that I
think are more-or-less OK helps to reduce clutter, and I can
view only further changes to those paths.
In a sense, update-index can be thought of to check in the
changes without committing. You can check in number of times,
and the cumulative effect is committed later. "reset --mixed"
is undoing these uncommitted check-ins. "reset --hard" undoes
the last commit.
From: Jon Loeliger <hidden> Date: 2016-06-15 22:42:17
On Tue, 2006-01-31 at 13:33, Junio C Hamano wrote:
"J. Bruce Fields" [off-list ref] writes:
I think many good stuff git offers would not be helpful to the
users until index is understood as the third entity, in addition
to the usual "committed state" and "working tree state". It
might be better to talk about it sooner rather than later. And
the tool is geared towards taking advantage of it, so until the
user understands that, behaviour of some tools would feel
unintuitive.
Agreed.
You can have local throw-away modifications while applying
patches and merging (I once broke merges by ignoring that it is
perfectly valid to have index and working tree files be
different and keep working that way. That was a hard lesson).
The index file knows what working tree changes are meant to be
committed. Another thing I find useful, which cannot be done
without index, is to sanity check while developing. When "git
diff" gives too many diffs, running update-index on paths that I
think are more-or-less OK helps to reduce clutter, and I can
view only further changes to those paths.
And right there is where people get caught by surprise.
What "they" then want to do is actually pick certain
files to commit. And when they do, they get caught off
guard by the _additional_ files.
I have done this style of "update-index on more-or-less OK
files in order to clear up the diff. And it is also in that
time frame that I start feeling that certain changes belong
to "one commit" or another. The result is, I want to then
pick the parts that get committed together. But _really_
being certain exactly which files, and _only_ those files,
will really be committed is tough.
jdl
Cloning without -l option is much slower - some minutes vs below a minute.
I could have time(8)d it, but it's no use.
Make that time(1)d.
Results for the kernel follow. Disc cache has been preheated with find.
git version: 5b2bcc7b2d546c636f79490655b3347acc91d17f
Filesystem: ext3 data=writeback
Kernel: 2.6.16-rc1-astorm2 (mostly -ck patchset with "hotfix")
Elevator: CFQ
time git clone linux-2.6.git linux-2.6.git.new
Packing 180025 objects
real 8m31.637s
user 3m19.571s
sys 0m42.211s
Extremely bad. The task is mostly cpu-bound.
Made some background applications swap out late in the process.
(that's the cause of the sys time)
time git clone -l linux-2.6.git linux-2.6.git.local
0 blocks
real 0m42.339s
user 0m2.818s
sys 0m4.040s
Good enough for me. Possibly cp -rl of objects and then a checkout.
time cp -rl linux-2.6.git linux-2.6.git.rl
real 0m18.333s
user 0m0.103s
sys 0m1.732s
Really fast, but requires additional file modification.
(namely .git/remotes/origin, removal of gitrc)
Also incompatible with apps having problems with hardlinks.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:42:17
On Tue, Jan 31, 2006 at 11:33:21AM -0800, Junio C Hamano wrote:
I think many good stuff git offers would not be helpful to the
users until index is understood as the third entity, in addition
to the usual "committed state" and "working tree state". It
might be better to talk about it sooner rather than later. And
the tool is geared towards taking advantage of it, so until the
user understands that, behaviour of some tools would feel
unintuitive.
Yeah, makes sense. But I'd like to introduce that while still
introducing the higher-level tools earlier on than core-tutorial.txt
does. I'll give some thought to how to move things in that direction,
maybe this weekend....
--b.
From: Sam Ravnborg <hidden> Date: 2016-06-15 22:42:17
As a newly initiated user, this would have been a more gentle
introduction to the system. But, it would be hard to make it entirely
invisible given the current interfaces. I'm not sure if obscuring the
presense of the index is a great plan; it's already hard enough to
figure out how it works.
I have found myself using a mixture of cogito and git commands lately.
Part of it being that my finger type something like:
rm `git ls-files -m`
cg-restore
and I have not convinced them about git reset --hard
But the primary thing is cg-commit
I give you a list of files modified which can be edited and
it have saved me a couple of times commiting to much.
And I get vi fired up so no need to fiddle with command line argumetns.
Sam
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:17
Radoslaw Szkodzinski, Sun, Jan 29, 2006 12:18:45 +0100:
quoted
Fortunately, there are very few people involved with any specific piece
of the X.org distribution; there's really only one or two people
actively developing the X.org core server, so that part of the migration
will be easy. Our users will be stuck, but there aren't many of them
either, and git makes just sucking the current bits pretty easy.
Not under Windows (bleh), but it's support for Cygwin is getting better
and better.
I use git in cygwin for a project with more then 17k files (almost 6M lines).
It's real slow on ntfs (on 3.2Mhz PIV!), PITA on fat, and has some hiccups now
and then (of the kind: "windows unexpectedly does not have feature X, which
everything else has" or "windows broke a 20-year-old feature Y").
But its more intuitive and more powerful than any alternatives here (Perforce,
SVN and CVS come to mind).
I use git in cygwin for a project with more then 17k files (almost 6M lines).
It's real slow on ntfs (on 3.2Mhz PIV!)
One thing that git does rely on is a fast "lstat()" system call. The index
file means that we almost never need to read the contents of a file to
compare, but git _does_ check that files haven't been modified, and doing
an "lstat()" on every single file it knows about is the way to do that.
Now, I suspect that you simply can't do basic filename lookups much faster
than Linux does them. The Linux VFS layer name caching reigns supreme: the
dentries are just incredibly powerful, and the reason Linux kicks ass on
many benchmarks.
And yes, git was designed for it. git is _really_ fast on Linux, but any
operating system that is so stupid that it has to call down to the
low-level filesystem for filename lookup (which is most of them, and from
what I have heard, the NT VFS layer is worse than most) will take a lot
longer.
This is sadly not something I think you can possibly avoid. Git is
literally being as fast as is humanly possible without doing explicit
locking. You _can_ avoid the "lstat()" calls if you are willing to always
explicitly mark files that you have changed (so that the SCM can stat just
_those_ files and ignore all the others), but I personally much prefer
being able to use any random tools on the files without having to prepare
them some way.
So we could speed it up on cygwin (and yes, it would speed git up a lot
even on Linux, but since the cached lstat() case is so fast anyway, I
doubt a lot of Linux users care - the biggest win would be on a cold-cache
tree). But it would require that you explicitly _mark_ the files you edit
some way.
Btw, BK wanted that, and it wasn't _too_ painful. You had to do
bk edit
to mark a file as being ready to be dirtied, and as a helper command you
would use
bk editor
which would first do the "bk edit" thing and then start up your favourite
editor (the usual ${EDITOR:${VISUAL:vi}} rules applied) on it, and it
worked fine. We _could_ do the same in git.
I'd just prefer not to.
For small projects (or big projects with fairly few files), it really
shouldn't matter. Your 17k files example is hopefully fairly rare..
But its more intuitive and more powerful than any alternatives here (Perforce,
SVN and CVS come to mind).
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:42:17
On Tue, Jan 31, 2006 at 01:25:08PM -0800, Linus Torvalds wrote:
So we could speed it up on cygwin (and yes, it would speed git up a lot
even on Linux, but since the cached lstat() case is so fast anyway, I
doubt a lot of Linux users care - the biggest win would be on a cold-cache
tree). But it would require that you explicitly _mark_ the files you edit
some way.
You couldn't depend on a combination of lstat's and some kind of
filesystem change notifications?
--b.
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:17
Linus Torvalds, Tue, Jan 31, 2006 22:25:08 +0100:
quoted
I use git in cygwin for a project with more then 17k files (almost
6M lines). It's real slow on ntfs (on 3.2Mhz PIV!)
...
So we could speed it up on cygwin (and yes, it would speed git up a lot
even on Linux, but since the cached lstat() case is so fast anyway, I
doubt a lot of Linux users care - the biggest win would be on a cold-cache
tree). But it would require that you explicitly _mark_ the files you edit
some way.
I'd hate to have to do that. The project in question is just stuffed
up beyond all reason, windows' VFS is a sorry piece of junk, and I
care much more about how comfortable the tool is.
...
For small projects (or big projects with fairly few files), it really
shouldn't matter. Your 17k files example is hopefully fairly rare..
I'd say it is fairly common. It's what driven by paranoia and
suffering from chronic undereducation projects in big companies
usually end up with. Frequently right from the start...
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
"Sam Ravnborg" [off-list ref] writes:
But the primary thing is cg-commit
I give you a list of files modified which can be edited and
it have saved me a couple of times commiting to much.
And I get vi fired up so no need to fiddle with command line argumetns.
[this is what I sent in a separate message but I goofed up the
destination headers and the message did not appear on the list,
so I am reprinting.]
I have always felt "git commit paths..." was a mistake; it
encourages partial commits by individual developers.
By "partial commit", I mean a commit that does not exactly match
the state of the working tree when the commit is made. There
are two kinds of "partial commits". Good ones and bad ones.
Being able to make partial commits is handy for people whose
primary role is to integrate many changes from trusted
developers rather than testing each and every commit as a whole
(read: Linus and subsystem maintainers). Integrators' job may
include testing what have been merged as a whole by a compile
and reboot cycle as the final "wrap-up" step, but the most
important role they play is to sanity check the changes from
architectural perspective.
For that workflow to work effectively, however, the changes fed
by individual developers to the integrators have to be clean and
well tested. A partial commit records something that never
existed in any working tree as a whole, so by definition it is
an untested change. You would risk "sorry I forgot to commit
the changes to these paths but without them it does not even
compile", and end up wasting integrators' time.
The integrators make commits out of their working trees using
git-merge and git-apply to record changes made by others after
reviewing them. These commands ignore unconflicting local
changes (but notices conflicting ones to operate correctly), and
allow them to make partial commits. This is a good thing;
otherwise they would have to reset their own changes in their
working tree, only to do merges and to accept patches. However,
people playing the integrator role rarely have reason to use
"git commit paths..." while merging from others to make such a
partial commit. Only after they resolve conflicts by hand,
perhaps. But that happens far less often than careless
individual developers making partial commits of bad kind using
the same "git commit paths..." command.
This is the reason why I feel "git commit paths..." is a bad
feature. It helps to make bad partial commits, without having
to do much with making good partial commits.
Many SCMs may have the ability to do "commit paths...", but that
does not change the fact that it encourages carelessness for
individual developers, which is especially bad in a distributed
development workflow like the Linux kernel style [*1*].
But that was not my change ;-).
[Foornote]
*1* It could be argued that being able to do partial commit is a
good thing in other SCM systems where there is no equivalent to
our "index" file. It is one way for the developer to snapshot
their work-in-progress state where they might later come back to
if the approach they are currently pursuing does not pan out.
But for that, we have index file we can "check into" without
committing.
From: Joel Becker <hidden> Date: 2016-06-15 22:42:17
On Tue, Jan 31, 2006 at 11:21:52AM -0800, Linus Torvalds wrote:
Now, I do agree. I don't actually like hiding the index too much.
Understanding the index is _invaluable_ whenever you're doing a merge with
conflicts, and understanding what tools are available to you to resolve
those conflicts.
This is precisely the experience I've had explaining GIT to
folks moving to it. The simplest workflow (clone; hack one file, commit
one file) is so similar to CVS/Subversion/Anything that it's immediately
understood. But when pull, push, merge, and any non-linear history are
discussed, I have to describe the index and the commit/tree layout.
Once I do, they get it.
So I'm actually of the "revel in the index" camp (as could probably be
guessed by the original tutorial).
I'm going to second this, from a real-world "explain it to
others" standpoint.
Joel
--
"Every day I get up and look through the Forbes list of the richest
people in America. If I'm not there, I go to work."
- Robert Orben
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:17
On Tue, 31 Jan 2006, Johannes Schindelin wrote:
Hi,
On Mon, 30 Jan 2006, Carl Baldwin wrote:
quoted
In general, I think it is grasping the reason for the index file and how
git commands like git-commit and git-diff interact with it.
IMHO this is the one big showstopper. I had problems explaining the
concept myself.
For example, I had a hard time explaining to a friend why a git-add'ed
file is committed when saying "git commit some_other_file", but not
another (modified) file. Very unintuitive.
I sort of suspect that "git commit some_other_file" should really read
HEAD into a temporary index, update "some_other_file" in that (and the
main index), and commit it. The concept of the index isn't hard (it's the
preparation you've made so far towards a commit), and plain "git commit"
makes sense with it; "git commit -a" also makes sense, since committing
all changes is pretty clear. The surprising thing is that "git commit path
..." means "everything I've already mentioned, plus path..." not just
"path ...", and it's particularly surprising because people only tend to
specify paths when they've done something they don't want to commit.
-Daniel
*This .sig left intentionally blank*
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:17
Dear diary, on Wed, Feb 01, 2006 at 12:16:26AM CET, I got a letter
where Daniel Barkalow [off-list ref] said that...
On Tue, 31 Jan 2006, Johannes Schindelin wrote:
quoted
Hi,
On Mon, 30 Jan 2006, Carl Baldwin wrote:
quoted
In general, I think it is grasping the reason for the index file and how
git commands like git-commit and git-diff interact with it.
IMHO this is the one big showstopper. I had problems explaining the
concept myself.
For example, I had a hard time explaining to a friend why a git-add'ed
file is committed when saying "git commit some_other_file", but not
another (modified) file. Very unintuitive.
I sort of suspect that "git commit some_other_file" should really read
HEAD into a temporary index, update "some_other_file" in that (and the
main index), and commit it.
FWIW, this is also what cg-commit does.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:18
Hi,
On Tue, 31 Jan 2006, Joel Becker wrote:
On Tue, Jan 31, 2006 at 11:21:52AM -0800, Linus Torvalds wrote:
quoted
Now, I do agree. I don't actually like hiding the index too much.
Understanding the index is _invaluable_ whenever you're doing a merge with
conflicts, and understanding what tools are available to you to resolve
those conflicts.
This is precisely the experience I've had explaining GIT to
folks moving to it. The simplest workflow (clone; hack one file, commit
one file) is so similar to CVS/Subversion/Anything that it's immediately
understood. But when pull, push, merge, and any non-linear history are
discussed, I have to describe the index and the commit/tree layout.
Once I do, they get it.
quoted
So I'm actually of the "revel in the index" camp (as could probably be
guessed by the original tutorial).
I'm going to second this, from a real-world "explain it to
others" standpoint.
How about talking about the index a bit at the end of tutorial.txt like
this:
-- snip --
For a number of (mostly technical) reasons, "git diff" does not show the
changes of the current working directory with respect to the latest
commit, but rather to an intermediate stage: the "index".
Think of the index as a staging area just before committing: the commit
object (and the tree and blob objects referenced from it) are assembled
there.
Also, when you checkout, the index is used to disassemble the commit
object just before writing the corresponding files and directories.
-- snap --
May this be worth the work?
Ciao,
Dscho
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:18
Carl Baldwin wrote:
- Anyone can install and fire it up without license/contract hassles.
For something like an SCM this is a big deal, and not just for the Open
Source world. In a company, it means not having to worry about having
enough licenses, and getting budget approval, etc, etc, before a new
person can join a project. Perhaps more importantly, it allows someone
who normally isn't *on* the project to look at it and participate.
-hpa
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:18
Linus Torvalds wrote:
quoted
For example, I had a hard time explaining to a friend why a git-add'ed
file is committed when saying "git commit some_other_file", but not
another (modified) file. Very unintuitive.
I really think you should explain it one of two ways:
- ignore it. Never _ever_ use git-update-index directly, and don't tell
people about use individual filenames to git-commit. Maybe even add
"-a" by default to the git-commit flags as a special installation
addition.
- talk about the index, and revel in it as a way to explain the staging
area. This is what the old tutorial.txt did before it got simplified.
The "ignore the index" approach is the simple one to explain. It's
strictly less powerful, but hey, what else is new?
I think both of these are probably the wrong answer, and it's pretty
much a matter of the git model violating the principle of least
surprise. Perhaps added (or removed?) files need to be handled in a
different way than they currently are.
-hpa