Re: Bootstrapping into git, commit gripes at me

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Fri, Jul 08, 2005 at 05:17:08PM -0700, Junio C Hamano wrote:
> >>>>> "MS" == Marc Singer <elf@buici.com> writes:
> 
> MS> In working through a usage example on my way to producing bonafide
> MS> patches, I've found that commit is complaining.  Here's what I've done.
> 
> MS>   o Fetched and built cogito-0.12
> MS>   o Fetched (rsync) Linus' tree
> MS>   o Created a working directory, linux-2.6
> MS>   o linked .git in the working directory to the .git directory fetched
> MS>     from the net.
> 
> This is slightly different from the BCP.  A recommended way is:
> 
>  $ mkdir linux-2.6
>  $ cd linux-2.6
>  $ git-init-db
>  $ rsync linux-2.6.git/ from kernel.org into .git/

Does this preclude symlinking .git?  I'd like to keep one .git which
is mirrored from the net and allow for more than one working
directory.

> Although your commit problem does not have to do with this.
> 
> MS>   o # git checkout -f v2.6.11
> MS>   o # cat ../old-patch-file | patch -p1
> 
> GITified Linux kernel repository starts at v2.6.12-rc2, so
> from anything older you cannot create a commit off of it
> (easily).

Trouble is that 2.6.12 breaks some things and I need to continue to
build patches from 2.6.11 for the time being.  Once I get familiar,
I'll patch the tree to build properly for my targets with later
revisions.

> MS> Then, according to Jeff's instructions, I have to perform
> MS> get-update-cache with the name of each file I changed.  Is that really
> MS> the way?
> 
> MS>   o # git-update-cache LIST_OF_CHANGED_FILES
> 
> That is correct.  Also remember to say:
> 
>     git-update-cache --add LIST_OF_ADDED_FILES
>     git-update-cache --remove LIST_OF_REMOVED_FILES

His text is a little overly-brief on this, but I got the gist.

> Notice the use of git-apply --index instead of patch -p1 in the
> above example?  If you use git-apply --index, you do not have to
> do the above steps yourself.

Notice it...where?  I gather that git-apply is a better way to apply
patches?

> MS>    fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object
> 
> That is a tag to the v2.6.11 tree, which is not a valid commit,
> so you cannot make a commit off of it.

So what does this mean?  Can I only produce commits from the master?
Is this a peculiarity of the v2.6.11 tag?

> Linus, I think git-checkout-script should not store a tag to non
> commit in HEAD.  If that did not happen, and if the repo was
> created without ref/heads/master (the usual case), then he
> _could_ have done something like this:
> 
>  $ git checkout -f v2.6.11 ;# fixed one
>  warning: v2.6.11 is not a commit -- not updating your HEAD
>  $ git commit ;# to have his own baseline at v2.6.11
>  $ git-apply --index --stat --summary --apply <../old-patch-file
>  $ : do the usual tests
>  $ git commit ;# create a commit based on the baseline v2.6.11

That sounds like what I'm looking for.  Can I do this by hand somehow?

As an ARM developer, I need to be able to cleanly track kernel
development revisions and produce patches that are easy to merge.  The
cycle is something like this:

  o Update kernel tree.
  o Fix the build.
  o Produce a patch to send upstream.
  o Apply work-in-progress patches
  o Fix the build.
  o Publish new patches against updated kernel tree

The trickiest part has been bringing the works-in-progress forward
without spending lots of time babysitting the SCM tools.

Bootstrapping into git, commit gripes at me

[Marc Singer]

In working through a usage example on my way to producing bonafide
patches, I've found that commit is complaining.  Here's what I've done.

  o Fetched and built cogito-0.12
  o Fetched (rsync) Linus' tree
  o Created a working directory, linux-2.6
  o linked .git in the working directory to the .git directory fetched
    from the net.
  o # git checkout -f v2.6.11
  o # cat ../old-patch-file | patch -p1

Then, according to Jeff's instructions, I have to perform
get-update-cache with the name of each file I changed.  Is that really
the way?

  o # git-update-cache LIST_OF_CHANGED_FILES

Now I commit.

  o # git commit

I am presented with an editor session with the list of changed files
already present.  IfI add a comment and leave the editor, I'm told

   fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object

If I don't edit the comment, it doesn't give an error but I don't
think the changes are committed because I can invoke git commit again.

Am I off track?

Cheers.

P.S.  vger isn't letting me subscribe ATM.  Please copy me with
      replies.

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

>  $ git checkout -f v2.6.11 ;# fixed one
>  warning: v2.6.11 is not a commit -- not updating your HEAD
>  $ git commit ;# to have his own baseline at v2.6.11
>  $ git-apply --index --stat --summary --apply <../old-patch-file
>  $ : do the usual tests
>  $ git commit ;# create a commit based on the baseline v2.6.11

Interesting note.  I tried the git-apply command and found that it
complained and wouldn't succeed.

  elf@florence ~...embedded/linux-2.6 > git-apply --index --stat --summary --apply < ../ms16/ide.patch 
  error: patch failed: drivers/ide/ide-io.c:129
  error: drivers/ide/ide-io.c: patch does not apply

Yet, patch does apply.

  elf@florence ~...embedded/linux-2.6 > patch -p1 < ../ms16/ide.patch
  patching file drivers/ide/arm/ide_arm.c
  patching file drivers/ide/arm/ide-lpd7952x.c
  patching file drivers/ide/arm/ide-lpd7a40x.c
  patching file drivers/ide/arm/Makefile
  patching file drivers/ide/ide-disk.c
  Hunk #1 succeeded at 282 (offset 41 lines).
  Hunk #2 succeeded at 294 (offset 41 lines).
  patching file drivers/ide/ide-io.c
  Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).
  Hunk #2 succeeded at 1227 (offset 189 lines).
  Hunk #3 succeeded at 1388 (offset 189 lines).
  Hunk #4 succeeded at 1689 (offset 187 lines).
  patching file drivers/ide/ide-iops.c
  patching file drivers/ide/ide-probe.c
  Hunk #1 succeeded at 422 (offset 51 lines).
  Hunk #2 succeeded at 784 (offset 59 lines).
  Hunk #3 succeeded at 847 (offset 59 lines).
  Hunk #4 succeeded at 1112 (offset 64 lines).
  Hunk #5 succeeded at 1172 (offset 64 lines).
  patching file drivers/ide/Kconfig
  Hunk #1 succeeded at 272 (offset -1 lines).
  Hunk #2 succeeded at 781 (offset 5 lines).
  patching file drivers/ide/legacy/ht6560b.c
  patching file drivers/ide/legacy/qd65xx.c
  patching file drivers/ide/pci/ns87415.c
  patching file drivers/ide/pci/sl82c105.c
  patching file drivers/ide/pci/trm290.c
  patching file drivers/ide/ppc/pmac.c
  Hunk #1 succeeded at 572 (offset 61 lines).
  Hunk #2 succeeded at 596 (offset 61 lines).
  patching file include/linux/ide.h
  Hunk #1 succeeded at 961 (offset 1 line).
  Hunk #2 succeeded at 1497 (offset -14 lines).

It should be obvious that a patch that doesn't apply cleanly,
i.e. without rejects, is still useful to apply so that I can fix the
places where it fails.

  o Why does patch work and git-apply fail?
  o Is there a way to force git to apply and safe the rejects?

Re: Bootstrapping into git, commit gripes at me

[Matthias Urlichs]

Hi, Marc Singer wrote:

> Yet, patch does apply. [...]
>   patching file drivers/ide/ide-io.c
>   Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).

git-apply cowardly (but sensibly) refuses to apply patches with fuzz
(i.e., ignoring some supplied context lines). 

Fuzz indicates problems.

I'd suggest that you apply the patch to whatever version it is based on...

>  o Is there a way to force git to apply and safe the rejects?

Well, you can use "patch -p1 ..." directly, and manually add the files it
created to the object cache. Personally I wouldn't, if at all possible.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
I couldn't remember things until I took that Sam Carnegie course.
		-- Bill Peterson, former Houston Oiler football coach

Re: Bootstrapping into git, commit gripes at me

[Petr Baudis]

Dear diary, on Sat, Jul 09, 2005 at 11:04:37PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> >  o Is there a way to force git to apply and safe the rejects?
> 
> Well, you can use "patch -p1 ..." directly, and manually add the files it
> created to the object cache. Personally I wouldn't, if at all possible.

Or you can do cg-patch, which should handle that for you properly as
well.  I think the "no fuzz" approach is hyper-paranoid. I deal with
small or larger fuzz all the time when I'm reordering patches or
applying them to a few hours younger version than they were based on. I
think the restriction it imposes is overly draconian here and doesn't
trust the developer to know what he is doing as much as it should. (And
that's why cg-patch doesn't use git-apply. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Fri, Jul 08, 2005 at 06:08:52PM -0700, Junio C Hamano wrote:
> >>>>> "MS" == Marc Singer <elf@buici.com> writes:
> 
> MS> Does this preclude symlinking .git?  I'd like to keep one .git which
> MS> is mirrored from the net and allow for more than one working
> MS> directory.
> 
> I think people typically do this by symlinking .git/objects, not
> .git/ itself.
> 
> Presumably the reason you would want to have more than one
> working tree is so that you can keep more than one topic of
> development, one for each working tree, and make commits
> independently, right?  Which commit is the latest in each work
> tree is, unsurprisingly, stored in .git/refs/heads/master file
> in each work tree, so usually you would _not_ want to share
> things other than .git/objects/ under .git/ directory across
> work trees.
> 
> One major downside of this, which I was burned once myself
> (which is the reason for me to stop doing it), is that
> git-fsck-cache and git-prune-script would not know anything
> about the objects in the shared .git/objects reachable from
> other work trees, and can happily garbage collect objects
> necessary for other work trees.

Hmm.  Seems, then, that this precludes any sharing at all.  It isn't
so serious with git as it was wth BK.  The latter being disk hungry.

I gather that the approved solution is to have complete replicas of
the git master from Linus for each line of development.

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

>>>>> "MS" == Marc Singer <elf@buici.com> writes:

MS> I gather that the approved solution is to have complete replicas of
MS> the git master from Linus for each line of development.

Either symlink .git/objects together, or GIT_OBJECT_DIRECTORY
environment variable point at a shared repository, and just do
not run git-prune-script and you will be fine.

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Fri, 8 Jul 2005, Marc Singer wrote:
>
> In working through a usage example on my way to producing bonafide
> patches, I've found that commit is complaining.  Here's what I've done.
> 
>   o Fetched and built cogito-0.12
>   o Fetched (rsync) Linus' tree
>   o Created a working directory, linux-2.6
>   o linked .git in the working directory to the .git directory fetched
>     from the net.
>   o # git checkout -f v2.6.11

This won't work.

v2.6.11 isn't a commit, it's a tree, and things will go downhill from 
there. 

Can you base it on 2.6.12-rc2 or later? That's the earliest with some real 
git history.

		Linus

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Fri, Jul 08, 2005 at 06:43:54PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 8 Jul 2005, Marc Singer wrote:
> >
> > In working through a usage example on my way to producing bonafide
> > patches, I've found that commit is complaining.  Here's what I've done.
> > 
> >   o Fetched and built cogito-0.12
> >   o Fetched (rsync) Linus' tree
> >   o Created a working directory, linux-2.6
> >   o linked .git in the working directory to the .git directory fetched
> >     from the net.
> >   o # git checkout -f v2.6.11
> 
> This won't work.
> 
> v2.6.11 isn't a commit, it's a tree, and things will go downhill from 
> there. 
> 
> Can you base it on 2.6.12-rc2 or later? That's the earliest with some real 
> git history.

I picked 2.6.12

  # git checkout -f v2.6.12

applied the patch and was greeted with an error about being unable to
commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
Isn't 2.6.12 later than 2.6.12-rcX?

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

Marc Singer <elf@buici.com> writes:

> I picked 2.6.12
>
>   # git checkout -f v2.6.12
>
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?

Aha.  Marc is not doing anything wrong --- he is doing as he is
told.

Linus, there is a bad interaction between tag objects and
commits right now.  For example:

 - we allow git-checkout-script with a tag; I think we store the tag
   object without dereferencing in .git/HEAD;

 - git-commit-tree says check_valid("commit") and barfs.

I think other things are covered already and the above two are
the only remaining major ones.  The merge-base command dereferences tags
and produces a commit as its result.  The rev-list command also
derefs tags, so log and whatchanged would work sensibly.

My current preference is to keep .git/refs/heads tag free.  At
least, I do not think we should ever write non commits to
.git/*_HEAD.

What do you think?  An alternative would be to allow tags
(recursively) pointing at a commit as a commit parent, but I do
not think we would want to go that route.

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

>
>  - git-commit-tree says check_valid("commit") and barfs.
>
> My current preference is to keep .git/refs/heads tag free.  At
> least, I do not think we should ever write non commits to
> .git/*_HEAD.
>
> What do you think?  An alternative would be to allow tags
> (recursively) pointing at a commit as a commit parent, but I do
> not think we would want to go that route.

Or, just dereferencing tags for commit parents in commit-tree
would be fine as well.

------------
Dereference tags given as commit-tree -p parameters.

Marc Singer noticed that when he has a tag instead of a commit
in his .git/HEAD (this happens after git checkout -f <tag>), git
commit barfs.  This patch makes commit-tree dereference tags
like everybody else does.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - master: [PATCH] git-cvsimport-script: add "import only" option
# + (working tree)
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -8,6 +8,7 @@
 #include <pwd.h>
 #include <time.h>
 #include <ctype.h>
+#include "commit.h"
 
 #define BLOCKING (1ul << 14)
 
@@ -133,10 +134,14 @@ int main(int argc, char **argv)
 	check_valid(tree_sha1, "tree");
 	for (i = 2; i < argc; i += 2) {
 		char *a, *b;
+		struct commit *commit;
 		a = argv[i]; b = argv[i+1];
 		if (!b || strcmp(a, "-p") || get_sha1(b, parent_sha1[parents]))
 			usage(commit_tree_usage);
-		check_valid(parent_sha1[parents], "commit");
+		commit = lookup_commit_reference(parent_sha1[parents]);
+		if (!commit)
+			usage(commit_tree_usage);
+		memcpy(parent_sha1[parents], commit->object.sha1, 20);
 		if (new_parent(parents))
 			parents++;
 	}

Compilation finished at Mon Jul 11 16:12:36

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Junio C Hamano wrote:
> 
>  - we allow git-checkout-script with a tag; I think we store the tag
>    object without dereferencing in .git/HEAD;

No, git-checkout-script _shouldn't_ have done that. It will do the 
read-tree on the tag (which will do the right thing), but it won't change 
the HEAD itself.

But I think Marc has/had an older git-checkout-script. The original one
didn't do branches at all, and indeed just blindly wrote its result into
.git/HEAD.

> My current preference is to keep .git/refs/heads tag free.  At
> least, I do not think we should ever write non commits to
> .git/*_HEAD.

And we don't. Not any more. 

However, right now we don't update .git/HEAD at _all_ unless we checked 
out a specific branch. Part of that is that we don't really know what we 
should change. Should we reset the current branch to that tag? Should we 
switch to the "master" branch, and switch _that_ to that tag? Should we 
create a totally new branch for just this thing?

Creating a new branch ends up being the only _safe_ option, but what 
should we choose as the branch name? 

		Linus

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Linus Torvalds wrote:
>
> No, git-checkout-script _shouldn't_ have done that. It will do the 
> read-tree on the tag (which will do the right thing), but it won't change 
> the HEAD itself.

In preparation of actually updating the HEAD, I just made "git checkout" 
verify that it only checks out a commit, not a tree tag or something like 
that. Too late for Marc, but next time around a "git checkout v2.6.11" 
will result in

	[torvalds@g5 linux]$ git checkout v2.6.11
	error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
	Needed a single revision

That's not exactly _obvious_ either, but hey, it's at least a half-way
readable and understandable error, and it's obviously correct to somebody
who knows how git works.

That still leaves the question about what to do when you do

	git checkout v2.6.12

which _is_ a valid operation. Right now it will "check out" that tag, in 
the sense that it will make the working tree correspond to v2.6.12, but it 
won't actually touch HEAD at all. The question is, what _should_ it do to 
head?

Should it just reset HEAD to point to .git/refs/master, and then write the
commit ID to it? That may actually sometimes be exactly what you want, and
at least it will result in a consistent state (ie the next commit will
have the right parent). On the other hand, it will blow away whatever the
old "master" branch contained, and thus likely leave an unreachable
commit.

On the other hand, creating a new branch might be a but surprising to 
people: "But I just wanted to check it out". But as far as I can see, it's 
the only safe thing to do, and it has the advantage that you can then go 
back to the old state with a simple "git checkout master".

But what about the branch name? Should we just ask the user? Together with 
a flag, like

	git checkout -b new-branch v2.6.12

for somebody who wants to specify the branch name? Or should we pick a 
random name and add a helper function to rename a branch later?

Opinions?

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Mon, Jul 11, 2005 at 06:43:23PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> >
> > No, git-checkout-script _shouldn't_ have done that. It will do the 
> > read-tree on the tag (which will do the right thing), but it won't change 
> > the HEAD itself.
> 
> In preparation of actually updating the HEAD, I just made "git checkout" 
> verify that it only checks out a commit, not a tree tag or something like 
> that. Too late for Marc, but next time around a "git checkout v2.6.11" 

:-) 

> will result in
> 
> 	[torvalds@g5 linux]$ git checkout v2.6.11
> 	error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
> 	Needed a single revision
> 
> On the other hand, creating a new branch might be a but surprising to 
> people: "But I just wanted to check it out". But as far as I can see, it's 
> the only safe thing to do, and it has the advantage that you can then go 
> back to the old state with a simple "git checkout master".
> 
> But what about the branch name? Should we just ask the user? Together with 
> a flag, like
> 
> 	git checkout -b new-branch v2.6.12
> 
> for somebody who wants to specify the branch name? Or should we pick a 
> random name and add a helper function to rename a branch later?
> 
> Opinions?

>From my POV, what I want is a branch with the tag v2.6.12 as the basis
of the branch.  I'm guessing that -b means "make me a branch and call
it this".

 # git checkout -b BRANCH_NAME [TAG]

If the TAG is omitted, the branch is made from the current HEAD or
some other reasonable point defined by the current working directory.

Are uncommitted changes present in the working directory maintained?
Discarded?  I wont't care since I'll never be doing that.  At least,
not on purpose.

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Marc Singer wrote:
> 
> From my POV, what I want is a branch with the tag v2.6.12 as the basis
> of the branch.  I'm guessing that -b means "make me a branch and call
> it this".

Yup. That would be the interface.

>  # git checkout -b BRANCH_NAME [TAG]
> 
> If the TAG is omitted, the branch is made from the current HEAD or
> some other reasonable point defined by the current working directory.

That would be the most natural thing that would fall out of this kind of 
interface.

> Are uncommitted changes present in the working directory maintained?
> Discarded?  I wont't care since I'll never be doing that.  At least,
> not on purpose.

They'd be maintained. If they clash with the target being checked out (ie
the checked-out tag would have changes to those files) it would error out
with a "I can't do that, Dave".

Unless you give the "-f" flag, in which case they're all thrown out, and
"git checkout" will force the new state and throw away any old state
entirely.

			Linus

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Linus Torvalds wrote:
> On Mon, 11 Jul 2005, Marc Singer wrote:
> > 
> > From my POV, what I want is a branch with the tag v2.6.12 as the basis
> > of the branch.  I'm guessing that -b means "make me a branch and call
> > it this".
> 
> Yup. That would be the interface.
> 
> >  # git checkout -b BRANCH_NAME [TAG]
> > 
> > If the TAG is omitted, the branch is made from the current HEAD or
> > some other reasonable point defined by the current working directory.
> 
> That would be the most natural thing that would fall out of this kind of 
> interface.

Ok, done. 

Now, if you try to do

	git checkout v2.6.12

git will complain with

	git checkout: you need to specify a new branch name

and some day (when I can get my act together and have man-pages that 
work), there would even be documentation for the "-b" flag to specify the 
branch name. And indeed, if you only specify the branch name, it will 
just create it and switch to it from the current HEAD.

So while there are no docs, the checkin comment hopefully says it all:

		Linus
---
commit 91dcdfd3b5331d955cfb60edf8930f1b5c142905
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Mon Jul 11 20:44:20 2005 -0700

    Make "git checkout" create new branches on demand

    In particular, if we check out something that isn't an old branch, it
    now requires a new branch-name to check the thing out into.

    So, for example:

        git checkout -b my-branch v2.6.12

    will create the new branch "my-branch", and start it at v2.6.12, while

        git checkout master

    will just switch back to the master branch.

    Of course, if you want to create a new branch "my-branch" and _not_
    check it out, you could have done so with just

        git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch

    which I think I will codify as "git branch".

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Linus Torvalds wrote:
> 
>     Of course, if you want to create a new branch "my-branch" and _not_
>     check it out, you could have done so with just
> 
>         git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch
> 
>     which I think I will codify as "git branch".

And now we have that "git branch". It's a trivial one-liner, except with
the setup and error checking it's actually more like six lines.

		Linus

---
commit 37f1a519f2ea0ce912ccd7c623aea992147c3900
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Mon Jul 11 21:30:23 2005 -0700

    Add "git branch" script

    You can use it as

        git branch <branchname> [start-point]

    and it creates a new branch of name <branchname>.  If a starting point
    is specified, that will be where the branch is created, otherwise it
    will be created at the current HEAD.

    The sequence

        git branch xyz abc
        git checkout xyz

    can also be written as

        git checkout -b xyz abc

    as per the previous commit.

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Mon, Jul 11, 2005 at 09:34:33PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> > 
> >     Of course, if you want to create a new branch "my-branch" and _not_
> >     check it out, you could have done so with just
> > 
> >         git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch
> > 
> >     which I think I will codify as "git branch".
> 
> And now we have that "git branch". It's a trivial one-liner, except with
> the setup and error checking it's actually more like six lines.

Does it make sense to think about this branch as an flow of commits?
Or is it just a starting point for a line of development?  If I make a
branch, check it out, commit changes to it, and then clobber the
working directory, can I later resume that branch of development
without creating a new branch?  Do I need to set a tag to mark the
last commit on that branch?

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Marc Singer wrote:
> 
> Does it make sense to think about this branch as an flow of commits?
> Or is it just a starting point for a line of development?

It's really a flow of commits. Nothing will ever really remember what the 
starting point was at some later date if you have done commits, and the 
branch will always follow the _head_ of development on that branch.

So if you need to remember the starting point as a _static_ entity, you
need to create a tag pointing to that place. You can do that at any point,
very much including after you've already done development (but before you
forget what to tag ;)

> If I make a branch, check it out, commit changes to it, and then clobber
> the working directory, can I later resume that branch of development
> without creating a new branch?

Absolutely. You can create a branch, commit to it, switch to another 
branch, commit to that one, switch back to the branch you created, and 
just go on. A branch will always follow the development.

> Do I need to set a tag to mark the last commit on that branch?

No, but as mentioned, _if_ you care about remembering where you _started_ 
the branch, you may want to tag that.

Of course, most of the time you really really don't care. It will be
largely obvious from the global commit history, which you can trivially
visualize with "gitk --all". You'll see where your branch "split off" the
main branch, and the only case where that is ambiguous is if you started
your branch at the tip of another branch, and no other development has
gone on in that other branch - then you don't see a "fork".

Of course, the other reason you usually don't care where you started is
that you simply don't care.  When you use CVS, you usually need to know
where the branch was started (and each point it was merged at) just so
that you can sanely merge it by doing diffs etc. With git, since we have
all the proper history, that's not necessary at all.

So I _suspect_ that most of the time when you create a branch, you don't 
need to tag where you started. Others will see what is your development 
simply by virtue of it being in your tree and not in other peoples tree, 
whether you created a branch for that or not ;)

		Linus

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Mon, Jul 11, 2005 at 09:59:25PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 11 Jul 2005, Marc Singer wrote:
> > 
> > Does it make sense to think about this branch as an flow of commits?
> > Or is it just a starting point for a line of development?
> 
> It's really a flow of commits. Nothing will ever really remember what the 
> starting point was at some later date if you have done commits, and the 
> branch will always follow the _head_ of development on that branch.

That's the important detail.

As an aside, we (a vary large set of developers) have been using SCM
tools for how-many-freakin-years and only now am I seeing something
sane.  Cheers.

Re: Bootstrapping into git, commit gripes at me

[Petr Baudis]

Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> > 
> >     Of course, if you want to create a new branch "my-branch" and _not_
> >     check it out, you could have done so with just
> > 
> >         git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch
> > 
> >     which I think I will codify as "git branch".
> 
> And now we have that "git branch". It's a trivial one-liner, except with
> the setup and error checking it's actually more like six lines.

Could we please have the branch name written to .git/head-name in case
we switch the branch? The reason is that .git/HEAD may not be always a
symlink. Specifically, I do this - there's a command cg-seek, which will
seek your working tree to a given commit, while staying on the branch
(committing and some other operations are blocked). In that case, I
remove .git/HEAD and replace it with ID of the commit I'm seeked at, and
when I'm "unseeking" back to the top, I replace it with the symlink
again. With some heuristics, I could create .git/head-name at the time
of seek and hope, but I think it'd be cleaner to just always set it
(except when we are on the master branch), if you agree.

Note that even though Cogito won't let you create/change a local branch
yet, it will understand .git/head-name and hopefully behave properly
(although it's totally untested, of course).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

I do want to see various Porcelains to agree on how to store
state information in $GIT_DIR for doing common operations, when
they are conceptually compatible.  The way they handle branches
may fall into that category.  With the barebone GIT Porcelain,
"seek" like operation may simply be done by creating another
branch or tag and jumping to it, so there may not be the concept
of "seek", in which case they may not be compatible after all.

Having said that, I do like the concept of keeping track of
"which development line are we on, and what's most recent in
it".  The way I read your description of cg-seek, you currently
have that information is either in .git/head-name and
.git/refs/heads/<head-name> pair (when .git/head-name exists),
or .git/HEAD.

If you block certain operations while you have seeked to non-top
anyway, wouldn't it be cleaner to have .git/seeked-to that
records the commit ID you are at, which at the same time
indicates that you are in a special situation, and not touching
HEAD at all?  Then .git/HEAD will always have that line of
development information.

Well, that was half tongue-in-cheek suggestion; I have a feeling
that you may feel it is a bit too late to change this kind of
thing easily.

But if we are going to agree on using .git/head-name, I'd rather
see it exist all times, so that cat "$GIT_DIR/head-name" would
always tell us which branch we are working in.

Re: Bootstrapping into git, commit gripes at me

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> Having said that, I do like the concept of keeping track of
> "which development line are we on, and what's most recent in
> it".  The way I read your description of cg-seek, you currently
> have that information is either in .git/head-name and
> .git/refs/heads/<head-name> pair (when .git/head-name exists),
> or .git/HEAD.

Personally, I'd rather have as few invariants as possible, so that various
Porcelains can agree on semantics.

What I would expect from a sane .git tree is that
* .git/HEAD contains the commit that is currently checked out.
* If HEAD is not a symlink, then switching to a branch HEAD is not a part
  of should emit a warning.
  ("fsck to find the dangling commits" is not an answer ;-)

Ideas like
* remember the branch to un-seek back to
or
* treat HEAD as read-only when there's a seek active

seem to be optional / Porcelain-specific.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
"We'll strategically withdraw to previously prepared position."
"Who prepared them?"
"we'll prepare them when we get there."
		-- Terry Pratchett (Reaper Man)

Re: Bootstrapping into git, commit gripes at me

[Petr Baudis]

Dear diary, on Tue, Jul 12, 2005 at 11:07:43AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> If you block certain operations while you have seeked to non-top
> anyway, wouldn't it be cleaner to have .git/seeked-to that
> records the commit ID you are at, which at the same time
> indicates that you are in a special situation, and not touching
> HEAD at all?  Then .git/HEAD will always have that line of
> development information.
> 
> Well, that was half tongue-in-cheek suggestion; I have a feeling
> that you may feel it is a bit too late to change this kind of
> thing easily.

The thing is, _everything_ assumes .git/HEAD is the current commit
checked out in the index. All the Cogito (that wouldn't be hard to
change at all), all the other Porcelains, the core GIT tools. So
changing that would be difficult and it's much easier this way.

> But if we are going to agree on using .git/head-name, I'd rather
> see it exist all times, so that cat "$GIT_DIR/head-name" would
> always tell us which branch we are working in.

After some thought, I like Linus' approach more now, having head-name
only when it's really necessary.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> After some thought, I like Linus' approach more now, having head-name
> only when it's really necessary.

I agree 100%.  That makes much more sense.

The message from Linus reminded me that the way he tackles a
problem is (as always) simpler, consistent and more elegant than
mine.  I have been practicing thinking things through more than
three times before I open my mouth, but still...

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Tue, 12 Jul 2005, Petr Baudis wrote:
> 
> Could we please have the branch name written to .git/head-name in case
> we switch the branch?

I wouldn't mind per se, but on the other hand I really _hate_ having 
"parallel" information that can get out of sync. If you have two places 
holding the same information, they had better match. And this is something 
that sounds like it could very easily start to not match, and then we're 
screwed.

So I'd _much_ rather see instead:

 - .git/head-name is a cogito-specific thing that is only active while 
   cogito is _seeking_. So then "cg-unseek" ends up being pretty much 
   equivalent to

	[ -e .git/head-name ] || die "You weren't seeking"
	git checkout $(cat .git/head-name)
	rm .git/head-name

   This way "head-name" is really never even supposed to be "in sync" with 
   .git/HEAD, and there are no synchronization issues. 

 - in order for a "git checkout" to not get confused and possibly throwing 
   a cogito temporary head away (and so that git-fsck-cache is happy 
   during a seek), would it be possible to make "seek" use a real 
   temporary branch instead? Ie, "cg-seek" would be something like

	[ -e .git/head-name ] && die "You are already seeking"
	readlink .git/HEAD > .git/head-name
	echo $seekpoint > .git/refs/heads/cg-seek-point
	git checkout -f cg-seek-point

   or similar?

Then "cg-seek" and "cg-unseek" would continue to work, but the core git 
layer would never be confused because they're really using normal 
branches?

		Linus

Re: Bootstrapping into git, commit gripes at me

[Petr Baudis]

Dear diary, on Tue, Jul 12, 2005 at 06:48:50PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Then "cg-seek" and "cg-unseek" would continue to work, but the core git 
> layer would never be confused because they're really using normal 
> branches?

That makes sense, I just did exactly that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> But what about the branch name? Should we just ask the user? Together with 
> a flag, like
>
> 	git checkout -b new-branch v2.6.12
>
> for somebody who wants to specify the branch name? Or should we pick a 
> random name and add a helper function to rename a branch later?
>
> Opinions?

How about treating "master" a temporary thing --- "whatever I
happen to be working on right now"?

 - git branch <branch-name>       ;# copies master to branch-name;
				     if branch-name exists in refs/heads,
                                     warn and refuse.  Override
				     with --force flag.

 - git checkout <branch-name>     ;# copies branch-name to master; but
                                     if master does not match any
                                     of the other refs/heads/, warn
                                     and refuse.  Override with
                                     --force flag.

Yes I realize that you have to be careful when to push to your
public repository if you take this route, but this is only
relevant to people like Jeff with multiple heads, and I think he
publicly stated that his "refs/heads/master" aka .git/HEAD does
not mean much and what matters are his branch heads.  People who
do not use multiple branches but just checks out various tags,
the above would be reasonably convenient.

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> > Opinions?
> 
> How about treating "master" a temporary thing --- "whatever I
> happen to be working on right now"?

I'd not mind with this in theory, but it has the fundamental problem that 
we can end up losing sight of commits we have, and then have no way to 
reach them.

Which is ok per se - sometimes you simply don't care about them, and I
occasionally drop some commits on purpose when I've done something I
decide to undo and then do a "git prune" to get rid of the objects.

But I don't want this to happen _easily_.

Your examples aren't actually very interesting:

>  - git branch <branch-name>       ;# copies master to branch-name;
> 				     if branch-name exists in refs/heads,
>                                      warn and refuse.  Override
> 				     with --force flag.
> 
>  - git checkout <branch-name>     ;# copies branch-name to master; but
>                                      if master does not match any
>                                      of the other refs/heads/, warn
>                                      and refuse.  Override with
>                                      --force flag.

because those two examples end up avoiding the _real_ issue, which is the

	git checkout v2.6.12

case, which is exactly the case that would need a "--force" flag, since 
master is what you're working on before. And --force would drop that 
information. 

So I want something that naturally works with this (very reasonable) way 
of working, and does _not_ force people to drop information.

In your world, you'd have to first save the old master with

	git branch work-branch

and then you could do

	git checkout v2.6.12

to start on "master" anew. That's fair, but it's conceptually very wrong: 
it rquires you to name the _old_ thing, which to me just sounds very 
confusing indeed. You don't care about the old thing, it's the _new_ thing 
you care about.

So at least to me it makes much more sense to say "ok, I'll start
something new, and call it xyzzy", than "ok, I'll start something new, and
I'll save the old under 'old'".

The "old" thing might not even be anything you worked on (it might be
something you just cloned from somebody else), so you giving it a name 
isn't very logical. In contrast, you're clearly doing something active 
with the new thing, so naming _that_ makes sense.

		Linus

Re: Bootstrapping into git, commit gripes at me

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> So at least to me it makes much more sense to say "ok, I'll start
> something new, and call it xyzzy", than "ok, I'll start something new, and
> I'll save the old under 'old'".
>
> The "old" thing might not even be anything you worked on (it might be
> something you just cloned from somebody else), so you giving it a name 
> isn't very logical. In contrast, you're clearly doing something active 
> with the new thing, so naming _that_ makes sense.

What I had mind was ``If you do not care about the current
"master", just say "checkout --force"''.

When I start working on something I often do not know what the
thing I am going to work on ends up to be.  So I would start
from v2.6.12 tag, do random hacking, and when I got into a
reasonable shape, I would say ``Ok, this is worth saving.  Let's
name it "foobar" branch and continue.''  And I would probably
switch to some other subproject when an urgent bugfix comes in,
and I would not want to lose my "master" _then_.  So (the
"branch" one has been revised):

  checkout [--force] <commit-ish>

   In addition to reading the tree and updating the work tree,
   stores "<commit-ish>^0" in .git/refs/heads/master.  However,
   if the current "master" is not something that matches a
   refs/*/*, then the user will be losing the trail between
   "master" before checkout and what is recorded in refs/, so
   the user needs to allow me explicitly to do it.

  branch <branch-name>

   Save the current "master" to branch-name.  If the user makes
   a mistake and tries to store the "master" head into a wrong
   branch, that would lose development trail of the branch being
   overwritten, so if the named branch exists and "master" is
   not a descendent of it, the user needs to explicitly tell me
   that it is OK to do so.

I do not quite follow your objections.  I do not think I am
forcing anybody to name an old thing.  Do you mean that "I've
been working on A and now I want to switch to B; so I'll save
the current state in A and switch to B" is too redundant, and I
should just let the user say "I've been working on something I
do not care to remember, now I want to switch to B, so just take
me to B and you should remember where I was and save it to A
automatically"?  That sort of makes sense to me.

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Junio C Hamano wrote:
> 
> I do not quite follow your objections.  I do not think I am
> forcing anybody to name an old thing.

Sure you are. You're forcing them to make a choice, where both choices 
are bad. Either:

 - name an old thing (that you may not even have worked on - "master" from 
   a newly cloned repo)

 - throw the old master state away ("--force")

Either choice is bad.

		Linus

Re: Bootstrapping into git, commit gripes at me

[Marc Singer]

On Mon, Jul 11, 2005 at 08:41:43PM -0700, Junio C Hamano wrote:
> When I start working on something I often do not know what the
> thing I am going to work on ends up to be.  So I would start
> from v2.6.12 tag, do random hacking, and when I got into a
> reasonable shape, I would say ``Ok, this is worth saving.  Let's
> name it "foobar" branch and continue.''  And I would probably
> switch to some other subproject when an urgent bugfix comes in,
> and I would not want to lose my "master" _then_.  So (the
> "branch" one has been revised):

Isn't that what a tag is for?

  o Make a sandbox
  o Commit cool changes
  o Tag the last commit object
  o Throw sandbox away.
  o Push changes or generate patch based on the tag

The change is that we can create a sandbox by giving it a starting
point, a tag.  If we decide we want to keep working on this branch,
all we'd have to do is go back to that tag, although I admit it may
seem sloppy to have to create a new branch from a tag'd commit that we
originally part of a branch.

Re: Bootstrapping into git, commit gripes at me

[Daniel Barkalow]

On Mon, 11 Jul 2005, Junio C Hamano wrote:

> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > But what about the branch name? Should we just ask the user? Together with 
> > a flag, like
> >
> > 	git checkout -b new-branch v2.6.12
> >
> > for somebody who wants to specify the branch name? Or should we pick a 
> > random name and add a helper function to rename a branch later?
> >
> > Opinions?
> 
> How about treating "master" a temporary thing --- "whatever I
> happen to be working on right now"?

That conflicts with my usage, where I have a single repository for all of
my working directories, with .git/refs and .git/objects being symlinks to 
it, but .git/HEAD being different for each branch. The stuff in objects/
and refs/ really shouldn't depend on what you're currently doing for this
reason.

My way of thinking of "master" is that it's a real branch, which is for
all of the situations where you aren't using a specially-designated
branch. For many people, they only do stuff that's not designated
specially; Jeff only does stuff that is designated specially. But if you
do both, you'll want master to be left alone while you work on the side
branch.

	-Daniel
*This .sig left intentionally blank*

Re: Bootstrapping into git, commit gripes at me

[Linus Torvalds]

On Mon, 11 Jul 2005, Marc Singer wrote:
> 
> I picked 2.6.12
> 
>   # git checkout -f v2.6.12
> 
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?

Yes.

However, that's not how "git checkout" ends up working, which is probably 
(almost certainly) a misfeature of git checkout. In particular, when you 
use a tag to checkout something, it will checkout the _state_ at that 
point (ie v2.6.12), but it won't have reset your HEAD to point to it.

And your earlier adventures made your HEAD be something that isn't a
commit (although I quite frankly don't know quite how you succeeded at
that: "git checkout" should refuse to write a HEAD unless you check out a
specific branch, and all branch pointers are proper commit points).

Anyway, here's how you fix it right now, and I'll have to figure out how 
to make a nice interface:

	#
	# Reset the "master" branch to v2.6.12
	#
	git-rev-list --max-count=1 v2.6.12 > .git/refs/heads/master

	#
	# Switch to the master branch
	#
	git checkout -f master

which should get you to be at a known point (which is v2.6.12).

		Linus