Git BOF notes

  Hi,

  a short summary of the Git BOF on OLS which finished just a short
while ago. We got to hear how Len Brown is doing things and where Git
gets in the way for him as well as interesting questions and comments
from several other people. The main highlights as I feel them (mixed
randomly with my personal blabbering) are that:

  (i) We should somehow separate the lowlevel Git commands from the
highlevel ones meant for user consumption. There's too many of them
and it is confusing for the users. Similarity with BitKeeper was pointed
out (and I refrained from mentioning GNU Arch).

  (ii) We should document the workflows better. Currently there is a
huge variety of workflows spread accross the Git user community,
probably stemming from the fact that the UI evolved so fast while
already "on the fly". Of course it shows that the Git tools are
really flxible and versatile, but it might also mean that we are not
abstracting some operations enough, or not selling the easier user
interface better. Anyway, new users might find the current mix of
workflows used across the community somewhat intimidating. This also
means that....

  (iii) ...we should spread the word about StGIT more (because StGIT
is cool and often does just what people want to do with Git and it's
clumsy), more so because...

  (iv) ...we should support mutating history better (I think this is the
most important point). There is a kind of conflict here:

	* Fundamentally, Git considers history to be immutable,
	  especially if you publish it.
	* The kernel workflow encourages the opposite - the subsystem
	  maintainers are rebasing all the time as well as just
	  generally retouching their history (typos, fixing bugs in
	  the patches etc).

  This problem can be separated to two areas:

	* Support for the history mutation. We have some nice tools
	  in Git for rebasing, but it would be nice to support the
	  other modifications easier as well. I suggested having
	  a tool you just tell a commit id and it will let you modify
	  the author info, the associated patch or fold another patch
	  in... Also, using StGIT obviously hlps a lot here.

	* Support for distributing and following the mutated history.
	  I'm actually not sure about the level of Git support for
	  this, Cogito supports cg-updating to a mutated history
	  if you have no local changes.

  Please feel free to add things if I have missed anything.

  Happy hacking,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:

  (i) We should somehow separate the lowlevel Git commands from the
highlevel ones meant for user consumption. There's too many of them
and it is confusing for the users. Similarity with BitKeeper was pointed
out (and I refrained from mentioning GNU Arch).

The man page already attempts to make this distinction in its command
list, though arguably the order is wrong (it lists the low-level
commands first) and you could argue about some of the choices (git
init-db may be "low level", but it's something everyone probably wants
to see).

"git help" already has an abbreviated list.  What else could we do?

--b.

On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:

	* Support for distributing and following the mutated history.
	  I'm actually not sure about the level of Git support for
	  this, Cogito supports cg-updating to a mutated history
	  if you have no local changes.

A fetch that doesn't fast-forward fails with a warning unless you
explicitly ask it (--force) to blow away your old history.

I don't see what more you could do.

--b.

Dear diary, on Fri, Jul 21, 2006 at 03:21:11PM CEST, I got a letter
where "J. Bruce Fields" [off-list ref] said that...

On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:

quoted

	* Support for distributing and following the mutated history.
	  I'm actually not sure about the level of Git support for
	  this, Cogito supports cg-updating to a mutated history
	  if you have no local changes.

A fetch that doesn't fast-forward fails with a warning unless you
explicitly ask it (--force) to blow away your old history.

I don't know if there's a point in being so paranoid - it already makes
things more painful than necessary. In the tracking branch, you just
want to have what the other side has anyway, and if the other side
decided to jump around, why would you care otherwise?

Just make sure you print the original commit ID and perhaps a warning.

I don't see what more you could do.

I guess a huge majority of Git users is an - almost inherently - silent
mass of those who just use Git for tracking the development of others,
and we gotta make it easy for them - and it's not easy if when the
remote side rebases it doesn't just move them to the new commit but
helpfully offers a nonsensical three-way merge.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Dear diary, on Fri, Jul 21, 2006 at 03:18:24PM CEST, I got a letter
where "J. Bruce Fields" [off-list ref] said that...

On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:

quoted

  (i) We should somehow separate the lowlevel Git commands from the
highlevel ones meant for user consumption. There's too many of them
and it is confusing for the users. Similarity with BitKeeper was pointed
out (and I refrained from mentioning GNU Arch).

The man page already attempts to make this distinction in its command
list, though arguably the order is wrong (it lists the low-level
commands first) and you could argue about some of the choices (git
init-db may be "low level", but it's something everyone probably wants
to see).

"git help" already has an abbreviated list.  What else could we do?

Perhaps (while coordinating with the porcelains, of course) we should
start moving the lowlevel tools to the libexec directory and keep only
the end-user tools around.

Yes, there is some blury stuff, but I think it's rather a sign that
something is missing in the core Git porcelain. git-init-db is lowlevel
and I think in 99% of the cases you are going to do an initial commit
right after anyway, so you might as well just get git-init which does it
for you (something akin cg-init ;). I think we still tell users to use
git-update-index to mark resolved conflicts, but all the Git people at
OLS were too afraid to even _mention_ the index to the users at all;
shouldn't we have git-resolved instead?

Oh well, except that people are gonna run git-resolve instead all the
time. Why do we still _have_ that one?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

On 7/21/06, Petr Baudis [off-list ref] wrote:

I don't know if there's a point in being so paranoid - it already makes
things more painful than necessary. In the tracking branch, you just
want to have what the other side has anyway, and if the other side
decided to jump around, why would you care otherwise?

But for the ones who do care, it is much harder to notice. Even if it is
a warning (it gets lost in crontab logs).

Hi,

On Fri, 21 Jul 2006, Petr Baudis wrote:

Yes, there is some blury stuff, but I think it's rather a sign that
something is missing in the core Git porcelain. git-init-db is lowlevel
and I think in 99% of the cases you are going to do an initial commit
right after anyway, so you might as well just get git-init which does it
for you (something akin cg-init ;).

Think "changed templates". And also think "setup a remote repository", 
especially "setup a remote HTTP repository". No, clone will not work if 
you are sitting behind a firewall and/or DSL router (and who does not?).

And also think "start a new repository with only a _part_ of the current 
files". There are plenty reasons -- in addition to separation of concepts 
-- not to commit straight after initializing a repository.

I think we still tell users to use git-update-index to mark resolved 
conflicts, [...]

I don't know, but I had the impression we'd tell them "resolve your 
conflicts, and then do git-commit -a". Which is good enough.

Ciao,
Dscho

  Hi,

Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
where Johannes Schindelin [off-list ref] said that...

On Fri, 21 Jul 2006, Petr Baudis wrote:

quoted

Yes, there is some blury stuff, but I think it's rather a sign that
something is missing in the core Git porcelain. git-init-db is lowlevel
and I think in 99% of the cases you are going to do an initial commit
right after anyway, so you might as well just get git-init which does it
for you (something akin cg-init ;).

Think "changed templates".

  it may be that I'm just tired, but I don't see what you mean, sorry.

And also think "setup a remote repository", especially "setup a remote
HTTP repository".

  Of course. Currently you need to tinker with environment variables,
then with hooks, possibly with permissions and stuff to make the
repository shared... Think cg-admin-setuprepo. ;-)

And also think "start a new repository with only a _part_ of the current 
files". There are plenty reasons -- in addition to separation of concepts 
-- not to commit straight after initializing a repository.

  So what _do_ you do if you don't commit straight?

  Of course sometimes you don't want to add everything, and that should
still be possible to do (cg-init has a switch for that).

quoted

I think we still tell users to use git-update-index to mark resolved 
conflicts, [...]

I don't know, but I had the impression we'd tell them "resolve your 
conflicts, and then do git-commit -a". Which is good enough.

  My comment there was based on the jdl's presentation at OLS. Sorry if
in docs we are saying other things, I don't tend to lookat Git porcelain
documentation. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Hi,

On Sat, 22 Jul 2006, Petr Baudis wrote:

  Hi,

Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

On Fri, 21 Jul 2006, Petr Baudis wrote:

quoted

Yes, there is some blury stuff, but I think it's rather a sign that
something is missing in the core Git porcelain. git-init-db is lowlevel
and I think in 99% of the cases you are going to do an initial commit
right after anyway, so you might as well just get git-init which does it
for you (something akin cg-init ;).

Think "changed templates".

  it may be that I'm just tired, but I don't see what you mean, sorry.

If you change a template (like add a hook or something), you can call 
git-init-db in an existing repository to update that hook.

quoted

And also think "setup a remote repository", especially "setup a remote
HTTP repository".

  Of course. Currently you need to tinker with environment variables,
then with hooks, possibly with permissions and stuff to make the
repository shared... Think cg-admin-setuprepo. ;-)

git-init-db --shared

quoted

And also think "start a new repository with only a _part_ of the current 
files". There are plenty reasons -- in addition to separation of concepts 
-- not to commit straight after initializing a repository.

  So what _do_ you do if you don't commit straight?

Sometimes, I do "git-push just@initted.repository.com master". From 
somewhere else, of course.

At other times, I do "git-add the-paper.tex && git commit initial".

And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".

  Of course sometimes you don't want to add everything, and that should
still be possible to do (cg-init has a switch for that).

Usually I start small projects as a single .c or .java file. Only after a 
while, I think it is worth it to init a git database. So, I _always_ have 
generated files lying around. And I would hate it if they were checked in 
automatically. (Yeah, I could remove them, _then_ remove them from the 
index, and then git-commit --amend. Ugly.)

quoted

quoted

I think we still tell users to use git-update-index to mark resolved 
conflicts, [...]

I don't know, but I had the impression we'd tell them "resolve your 
conflicts, and then do git-commit -a". Which is good enough.

  My comment there was based on the jdl's presentation at OLS. Sorry if
in docs we are saying other things, I don't tend to lookat Git porcelain
documentation. ;-)

That makes two of us.

Ciao,
Dscho

  Hi,

Dear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter
where Johannes Schindelin [off-list ref] said that...

On Sat, 22 Jul 2006, Petr Baudis wrote:

quoted

Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

Think "changed templates".

  it may be that I'm just tired, but I don't see what you mean, sorry.

If you change a template (like add a hook or something), you can call 
git-init-db in an existing repository to update that hook.

  ah well, I guess that's obscure enough to tell the user to directly
run git-init-db. ;-)

quoted

quoted

And also think "setup a remote repository", especially "setup a remote
HTTP repository".

  Of course. Currently you need to tinker with environment variables,
then with hooks, possibly with permissions and stuff to make the
repository shared... Think cg-admin-setuprepo. ;-)

git-init-db --shared

And the environment variable and the chgrp and g+s. That's my point.

quoted

quoted

And also think "start a new repository with only a _part_ of the current 
files". There are plenty reasons -- in addition to separation of concepts 
-- not to commit straight after initializing a repository.

  So what _do_ you do if you don't commit straight?

Sometimes, I do "git-push just@initted.repository.com master". From 
somewhere else, of course.

I guess that's more common for the bare repositories.

And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".

git-cvsimport will create the repository for you, won't it?

quoted

  Of course sometimes you don't want to add everything, and that should
still be possible to do (cg-init has a switch for that).

Usually I start small projects as a single .c or .java file. Only after a 
while, I think it is worth it to init a git database. So, I _always_ have 
generated files lying around. And I would hate it if they were checked in 
automatically. (Yeah, I could remove them, _then_ remove them from the 
index, and then git-commit --amend. Ugly.)

Can't you just do make clean before git init? Or you can prepare
.gitignore before you check stuff in, so that the autogenerated files
don't pollute your git status output. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Petr Baudis [off-list ref] wrote:

quoted

Usually I start small projects as a single .c or .java file. Only after a 
while, I think it is worth it to init a git database. So, I _always_ have 
generated files lying around. And I would hate it if they were checked in 
automatically. (Yeah, I could remove them, _then_ remove them from the 
index, and then git-commit --amend. Ugly.)

Can't you just do make clean before git init? Or you can prepare
.gitignore before you check stuff in, so that the autogenerated files
don't pollute your git status output. ;-)

I like git init-db as it is now.  I don't want it to automatically add
files.  GIT does what you ask it to do, not what it _thinks_ you want to
do.

-- 
http://onion.dynserv.net/~timo/

On 7/21/06, Alex Riesen [off-list ref] wrote:

On 7/21/06, Petr Baudis [off-list ref] wrote:

quoted

I don't know if there's a point in being so paranoid - it already makes
things more painful than necessary. In the tracking branch, you just
want to have what the other side has anyway, and if the other side
decided to jump around, why would you care otherwise?

But for the ones who do care, it is much harder to notice. Even if it is
a warning (it gets lost in crontab logs).

Then create some lost+found branches for them?

Nguyễn Thái Ngọc Duy, Sat, Jul 22, 2006 22:12:07 +0200:

quoted

quoted

I don't know if there's a point in being so paranoid - it already makes
things more painful than necessary. In the tracking branch, you just
want to have what the other side has anyway, and if the other side
decided to jump around, why would you care otherwise?

But for the ones who do care, it is much harder to notice. Even if it is
a warning (it gets lost in crontab logs).

Then create some lost+found branches for them?

if you copy files from ext3 to vfat, do you expect them to be found in
lost+found? Usually not, I believe. It should either fail or copy.

Hi,

On Sat, 22 Jul 2006, Petr Baudis wrote:

Dear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

On Sat, 22 Jul 2006, Petr Baudis wrote:

quoted

Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

And also think "setup a remote repository", especially "setup a remote
HTTP repository".

  Of course. Currently you need to tinker with environment variables,
then with hooks, possibly with permissions and stuff to make the
repository shared... Think cg-admin-setuprepo. ;-)

git-init-db --shared

And the environment variable and the chgrp and g+s. That's my point.

I do not have the itch. But of course, it would be trivial to do that as 
command line options.

quoted

And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".

git-cvsimport will create the repository for you, won't it?

It could, if I'd let it ;-)

quoted

quoted

  Of course sometimes you don't want to add everything, and that should
still be possible to do (cg-init has a switch for that).

Usually I start small projects as a single .c or .java file. Only after a 
while, I think it is worth it to init a git database. So, I _always_ have 
generated files lying around. And I would hate it if they were checked in 
automatically. (Yeah, I could remove them, _then_ remove them from the 
index, and then git-commit --amend. Ugly.)

Can't you just do make clean before git init? Or you can prepare 
.gitignore before you check stuff in, so that the autogenerated files 
don't pollute your git status output. ;-)

Yes, I can. I also can type in several sheets of hex data. But I don't 
want to. Like Timo, I am very happy to tell the computer what to do, not 
to let it take guesses.

Ciao,
Dscho