unseeking?

unseeking?

[Zack Brown]

Hi,

I've been pulling cogito and the kernel, and just fumbling around trying to
learn the tool. My latest cogito is version 0.7, tracking

pasky   rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
linus   rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git

I have many questions.

1) I saw some discussion of 'seek' as a way to get to an earlier version of a
tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
it worked - but now all I have is that very early version of my test directory.
All subsequent changes are apparently gone. How can I seek back to the most
recent state of the dir?

2) How can I 'check out' my local repository? i.e. I want to pretend to be
two developers, one of whom wants to grab a copy of the project leader's work. I
tried things like:

mkdir mygitdir2
git init ../mygitdir

where mydir is my test git repository. This didn't work. I tried rephrasing the
command with an rsync url:

git init rsync://home/zbrown/site/gitstuff/mygitdir

but that didn't work either. It just said:

defaulting to local storage area
rsync: getaddrinfo: home 873: Name or service not known
rsync error: error in socket IO (code 10) at clientserver.c(94)
gitpull.sh: unable to get the head pointer of branch master
gitinit.sh: pull failed

3) How can I do a rename with cogito? There doesn't seem to be a rename command,
and if I manually do a mv and 'git add', I can commit the result, but what
actually happened? Did I really do a rename? Is the file's history preserved?
How can I verify these things?

4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
these things do in general, but the specifics are confusing, and the README is a
little vague.

5) I'm a little confused about how to use a git repository to follow along with
a project. I have no problem pulling the latest version, but I'm interested in
generating changelogs for specific releases like 2.6.12-rc3. How can I

   a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
   represents the release I'm interested in

   b) generate the changelog between that version and the previous one,
   once I've solved (a)

Many thanks,
Zack





-- 
Zack Brown

Re: unseeking?

[Petr Baudis]

Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Hi,

Hi,

> I've been pulling cogito and the kernel, and just fumbling around trying to
> learn the tool. My latest cogito is version 0.7, tracking
> 
> pasky   rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> linus   rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git
> 
> I have many questions.
> 
> 1) I saw some discussion of 'seek' as a way to get to an earlier version of a
> tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
> it worked - but now all I have is that very early version of my test directory.
> All subsequent changes are apparently gone. How can I seek back to the most
> recent state of the dir?

git seek, without any arguments.

Perhaps we should prohibit absence of arguments and add 'unseek'?

> 2) How can I 'check out' my local repository? i.e. I want to pretend to be
> two developers, one of whom wants to grab a copy of the project leader's work. I
> tried things like:
> 
> mkdir mygitdir2
> git init ../mygitdir
> 
> where mydir is my test git repository. This didn't work. I tried rephrasing the

Actually, this _would_ work:

	git init ../mygitdir/.git

Then, you would need to git pull to get the latest changes.

> command with an rsync url:
> 
> git init rsync://home/zbrown/site/gitstuff/mygitdir
> 
> but that didn't work either. It just said:
> 
> defaulting to local storage area
> rsync: getaddrinfo: home 873: Name or service not known
> rsync error: error in socket IO (code 10) at clientserver.c(94)
> gitpull.sh: unable to get the head pointer of branch master
> gitinit.sh: pull failed

git fork seconddeveloper ../mygitdir

> 3) How can I do a rename with cogito? There doesn't seem to be a rename command,
> and if I manually do a mv and 'git add', I can commit the result, but what
> actually happened? Did I really do a rename? Is the file's history preserved?
> How can I verify these things?

Git does not record renames, and neither does Cogito (for now).

> 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> these things do in general, but the specifics are confusing, and the README is a
> little vague.

Try head git*.sh. ;-)

> 5) I'm a little confused about how to use a git repository to follow along with
> a project. I have no problem pulling the latest version, but I'm interested in
> generating changelogs for specific releases like 2.6.12-rc3. How can I
> 
>    a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
>    represents the release I'm interested in

Assuming that it is tagged, just do

	commit-id linux-2.6.12-rc3

or whatever the tag name is. From Cogito perspective, you can use the
symbolic name anywhere you would use the proper string.

There is also tree-id and parent-id, with same usage.

>    b) generate the changelog between that version and the previous one,
>    once I've solved (a)

	git log previous that

Any ideas how to improve the user interface further are deeply
appreciated. (However please note that it is going to undergo a big
change in an hour or two, so you might want to postpone them until
that.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: unseeking?

[Zack Brown]

On Sun, Apr 24, 2005 at 06:05:14PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > Hi,
> 
> Hi,
> 
> > I've been pulling cogito and the kernel, and just fumbling around trying to
> > learn the tool. My latest cogito is version 0.7, tracking
> > 
> > pasky   rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> > linus   rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git
> > 
> > I have many questions.
> > 
> > 1) I saw some discussion of 'seek' as a way to get to an earlier version of a
> > tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
> > it worked - but now all I have is that very early version of my test directory.
> > All subsequent changes are apparently gone. How can I seek back to the most
> > recent state of the dir?
> 
> git seek, without any arguments.

This didn't work. I did a 'git seek' and I still see only the early version of
my directory. However, see the next point for more on this.

> 
> Perhaps we should prohibit absence of arguments and add 'unseek'?
> 
> > 2) How can I 'check out' my local repository? i.e. I want to pretend to be
> > two developers, one of whom wants to grab a copy of the project leader's work. I
> > tried things like:
> > 
> > mkdir mygitdir2
> > git init ../mygitdir
> > 
> > where mydir is my test git repository. This didn't work. I tried rephrasing the
> 
> Actually, this _would_ work:
> 
> 	git init ../mygitdir/.git
> 
> Then, you would need to git pull to get the latest changes.

OK, I did 'git init ../mygitdir/.git', and it worked, I didn't even need to do a
pull. It's a little unintuitive that I would have to specifically identify the
.git subdirectory in that command. But it worked.

So, regarding my first point. When I did the init from the original repo, the
new repo got the latest snapshot of the tree. So I did a 'git log' in the new
directory to obtain the latest d394a1e71504c6f032a484bbd5e8ecbe4c3de05e thingy.

Then I went back to my main directory (the one I'd seeked back to the
beginning), and did

git seek d394a1e71504c6f032a484bbd5e8ecbe4c3de05e

but it didn't work. The directory is still stuck at the beginning of its history.

> 
> > command with an rsync url:
> > 
> > git init rsync://home/zbrown/site/gitstuff/mygitdir
> > 
> > but that didn't work either. It just said:
> > 
> > defaulting to local storage area
> > rsync: getaddrinfo: home 873: Name or service not known
> > rsync error: error in socket IO (code 10) at clientserver.c(94)
> > gitpull.sh: unable to get the head pointer of branch master
> > gitinit.sh: pull failed
> 
> git fork seconddeveloper ../mygitdir

Can you say what this does? Is it the same as the init+pull you described above?

Hmm... I tried it, and got:

09:24:06 [zbrown] ~/site/gitstuff/mygit3$ git fork seconddeveloper ../mygitdir
cat: .git/HEAD: No such file or directory
Invalid id: 
grep: .git/remotes: No such file or directory
gitfork.sh: ../mygitdir already exists
09:24:07 [zbrown] ~/site/gitstuff/mygit3$ 

> 
> > 3) How can I do a rename with cogito? There doesn't seem to be a rename command,
> > and if I manually do a mv and 'git add', I can commit the result, but what
> > actually happened? Did I really do a rename? Is the file's history preserved?
> > How can I verify these things?
> 
> Git does not record renames, and neither does Cogito (for now).

OK

> 
> > 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> > these things do in general, but the specifics are confusing, and the README is a
> > little vague.
> 
> Try head git*.sh. ;-)

heh. This is not more clear ;-)

> 
> > 5) I'm a little confused about how to use a git repository to follow along with
> > a project. I have no problem pulling the latest version, but I'm interested in
> > generating changelogs for specific releases like 2.6.12-rc3. How can I
> > 
> >    a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
> >    represents the release I'm interested in
> 
> Assuming that it is tagged, just do
> 
> 	commit-id linux-2.6.12-rc3
> 
> or whatever the tag name is. From Cogito perspective, you can use the
> symbolic name anywhere you would use the proper string.
> 
> There is also tree-id and parent-id, with same usage.

OK, I still have questions on this, but I see tagging is getting some heavy
work today.  I think I'll wait till that shakes out.

> 
> >    b) generate the changelog between that version and the previous one,
> >    once I've solved (a)
> 
> 	git log previous that
> 
> Any ideas how to improve the user interface further are deeply
> appreciated. (However please note that it is going to undergo a big
> change in an hour or two, so you might want to postpone them until
> that.)

Be well,
Zack

> 
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Zack Brown

Re: unseeking?

[Daniel Barkalow]

On Sun, 24 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > Hi,
> 
> Hi,
> > How can I seek back to the most recent state of the dir?
> 
> git seek, without any arguments.
> 
> Perhaps we should prohibit absence of arguments and add 'unseek'?

Have both; I think that it ought to accept anything where it's obvious
what the user means.

> Actually, this _would_ work:
> 
> 	git init ../mygitdir/.git
> 
> Then, you would need to git pull to get the latest changes.

It's worth pointing out that the reason for this (and why the rsync
version below didn't work) is that the conventional URLs are for .git
directories, not the directories that contain them: .../cogito/cogito.git
mirrors a cogito/.git directory. Or, phrasing it the other way, when it's
public, it's cogito.git; if it's in a working directory, it gets hidden by
making it just .git.

> git fork seconddeveloper ../mygitdir

Doesn't that have to be from the first one to the second one (rather than
the other way)?

> Git does not record renames, and neither does Cogito (for now).

And, in general, future history-browsing tools will work based on clever
analysis of the files, not explicit information in the database. They
ought to recognize when some content disappears from one place and
something very similar appears elsewhere, regardless of whether it is a
complete file or not.

I'm fairly certain that the most common rename-type events are moving code
within a file, not renaming files, and these would be a major pain to get
people to explicitly mark.

> > 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> > these things do in general, but the specifics are confusing, and the README is a
> > little vague.
> 
> Try head git*.sh. ;-)

Which is to say, there are useful comments at the beginnings of the
scripts. I.e., you really want "head `which gitfork.sh`"

	-Daniel
*This .sig left intentionally blank*

Rename tracking, revisited (was: unseeking?)

[Kevin Smith]

Petr Baudis wrote:
> Git does not record renames, and neither does Cogito (for now).

Here's one message in the git list archives where Linus proposes a way
to track renames without tracking renames:

  http://permalink.gmane.org/gmane.comp.version-control.git/217

I figure this will be an FAQ as more folks join the git community.

Kevin

Re: unseeking?

[Zack Brown]

On Sun, Apr 24, 2005 at 01:25:35PM -0400, Daniel Barkalow wrote:
> On Sun, 24 Apr 2005, Petr Baudis wrote:
> 
> > Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> told me that...
> 
> > git fork seconddeveloper ../mygitdir
> 
> Doesn't that have to be from the first one to the second one (rather than
> the other way)?

That works a little better for me, but neither really works. If I do

git fork currdir newdir

I get

cat: .git/HEAD: No such file or directory
Invalid id: 
grep: .git/remotes: No such file or directory
/home/zbrown/git/git-pasky-0.6.2/gitfork.sh: line 41: .git/heads/mygitdir: No
such file or directory
cat: .git/HEAD: No such file or directory
Invalid id: 
error: no access to SHA1 file directory
fatal: invalid cache
error: no access to SHA1 file directory
fatal: cache corrupted
Branch mygitdir ready in mygitdir3 with head 

If I cd into mygitdir3, I see a .git directory, but no files. If I do a 'git
pull', it asks me where to pull from, and I don't know what to tell it.

> > > 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> > > these things do in general, but the specifics are confusing, and the README is a
> > > little vague.
> > 
> > Try head git*.sh. ;-)
> 
> Which is to say, there are useful comments at the beginnings of the
> scripts. I.e., you really want "head `which gitfork.sh`"

I've looked at the scripts, but I don't find the comments specific enough. For
instance, for gitfork.sh:

# Create a branch sharing the objects database.
# Copyright (c) Petr Baudis, 2005
#
# This script creates a new branch (or revives an unused old branch)
# in a given directory, sharing the same objects database with the
# branch in the current directory, and forking from it at the latest
# commit (in the case of a new branch). You can use the name
# of the branch as an ID in all the other branches sharing the
# objects database.
#
# The new directory has a fresh checkout of the branch.
#
# Takes the desired branch name, its directory name, and potentially
# the head commit ID (for new branch).

I'm sure this is all accurate information, but I'm still unclear about several
points:

1) when I fork directory A into directory B, is A at all different from B
when the fork completes, and if so, how?

2) Are A and B altered by the forking process? i.e., is this an event that is
recorded in the repo, or is it just the equivalent of 'checking out' the repo?

3) What is the significance of a branch 'name'? Is this like a tag?

4) In normal work-flow, when would forks be created, as opposed to other ways
of getting a tree?

Thanks,
Zack

> 
> 	-Daniel
> *This .sig left intentionally blank*
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Zack Brown

Re: unseeking?

[Daniel Barkalow]

On Sun, 24 Apr 2005, Zack Brown wrote:

> That works a little better for me, but neither really works. If I do
> 
> git fork currdir newdir
> 
> I get
> 
> cat: .git/HEAD: No such file or directory
> Invalid id: 
> grep: .git/remotes: No such file or directory
> /home/zbrown/git/git-pasky-0.6.2/gitfork.sh: line 41: .git/heads/mygitdir: No
> such file or directory
> cat: .git/HEAD: No such file or directory
> Invalid id: 
> error: no access to SHA1 file directory
> fatal: invalid cache
> error: no access to SHA1 file directory
> fatal: cache corrupted
> Branch mygitdir ready in mygitdir3 with head 

I think your "mygitdir" directory has lost its idea of what's in it, so
the fork doesn't know what should be there, either. If it's tracking a
remote repository, you should be able to do a "git pull" there to both
bring it up to date and fix this. Then things should work better.

> I'm sure this is all accurate information, but I'm still unclear about several
> points:
> 
> 1) when I fork directory A into directory B, is A at all different from B
> when the fork completes, and if so, how?

They should be the same, but now independant as far as commits into them.

> 2) Are A and B altered by the forking process? i.e., is this an event that is
> recorded in the repo, or is it just the equivalent of 'checking out' the repo?

The repo contains the latest commit on each side in .git/heads/<name>

> 3) What is the significance of a branch 'name'? Is this like a tag?

It's orthogonal to a tag; it's what stays the same when you do more
commits on something. E.g., linux-scsi or linux-stable would be branch
names. (Tags, on the other hand, stick where you put them.)

> 4) In normal work-flow, when would forks be created, as opposed to other ways
> of getting a tree?

I have a tree that I want to modify, but I want to keep the original, and
I may want to update the original from an upstream source (and then sync
my work with it). I start with the original:

  cd original
  git init URL
  git addremote remote-source URL
  git track remote-source

I make my own working directory:

  git fork my-changes ../my-changes
  cd ../my-changes

Then I do my changes, and commit whenever I feel like I've gotten
somewhere (or when I think I'm about to mess something up and might want
to undo changes). Periodically, I check on the mainline:

  cd ../original
  git pull

I also merge changes from the mainline:

  cd ../my-changes
  git merge remote-source

When I'm done, I make a patch for my work:

  cd ../my-changes
  git patch remote-source

I generally then fork the original again, split the patch, apply each
section in the new fork, committing after each one, generate patches for
each of these commits, and send those out. Then I discard my old branch
and continue from the new one. If, at some point, all of the changes I
want to keep have been put into the mainline, I discard all my branches
and fork again from the mainline.

(My personal style is to discard the history of how the changes got made
in favor of the history of how the changes got into the mainline, since I
don't really need to keep all of my debugged mistakes that nobody else
saw.)

	-Daniel
*This .sig left intentionally blank*

Re: unseeking?

[Zack Brown]

On Sun, Apr 24, 2005 at 02:47:30PM -0400, Daniel Barkalow wrote:
> On Sun, 24 Apr 2005, Zack Brown wrote:
> > 4) In normal work-flow, when would forks be created, as opposed to other ways
> > of getting a tree?
> 
> I have a tree that I want to modify, but I want to keep the original, and
> I may want to update the original from an upstream source (and then sync
> my work with it).

So why not just do 'git init URL' to get the upstream sources, make your edits,
do 'git pull' to track the upstream sources every once in awhile, and do 'git
diff' when you're ready to send your changes to the upstream maintainer.

I think I've understood your explanation of what's actually happening, but I
still don't see its significance. What do you get from a fork that you don't get
from a regular old init and pull?

Be well,
Zack

> I start with the original:
> 
>   cd original
>   git init URL
>   git addremote remote-source URL
>   git track remote-source
> 
> I make my own working directory:
> 
>   git fork my-changes ../my-changes
>   cd ../my-changes
> 
> Then I do my changes, and commit whenever I feel like I've gotten
> somewhere (or when I think I'm about to mess something up and might want
> to undo changes). Periodically, I check on the mainline:
> 
>   cd ../original
>   git pull
> 
> I also merge changes from the mainline:
> 
>   cd ../my-changes
>   git merge remote-source
> 
> When I'm done, I make a patch for my work:
> 
>   cd ../my-changes
>   git patch remote-source
> 
> I generally then fork the original again, split the patch, apply each
> section in the new fork, committing after each one, generate patches for
> each of these commits, and send those out. Then I discard my old branch
> and continue from the new one. If, at some point, all of the changes I
> want to keep have been put into the mainline, I discard all my branches
> and fork again from the mainline.
> 
> (My personal style is to discard the history of how the changes got made
> in favor of the history of how the changes got into the mainline, since I
> don't really need to keep all of my debugged mistakes that nobody else
> saw.)
> 
> 	-Daniel
> *This .sig left intentionally blank*
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Zack Brown

Re: unseeking?

[Daniel Barkalow]

On Sun, 24 Apr 2005, Zack Brown wrote:

> On Sun, Apr 24, 2005 at 02:47:30PM -0400, Daniel Barkalow wrote:
> 
> So why not just do 'git init URL' to get the upstream sources, make your
> edits, do 'git pull' to track the upstream sources every once in
> awhile, and do 'git diff' when you're ready to send your changes to the
> upstream maintainer.
> 
> I think I've understood your explanation of what's actually happening,
> but I still don't see its significance. What do you get from a fork that
> you don't get from a regular old init and pull?

Primarily, the ability to inspect and build the mainline tree. If you want
to take a look at what's going on in the mainline without getting it again
or messing with your working directory or local commits, you can do that. 

Also, if you're doing two independant sets of edits, you can share the
downloads for updates between them. Say I'm working on an ambitious
project to do block-move cross-file merges in git. I've got a fork that
I'm working on that in. After I've done a bunch of work there, I notice a
bug report about some of my other code in the project. I fork off another
branch from the mainline to fix it in, so that I can ignore the fact that
I'm a dozen commits into this other thing, fix the bug, and ship off the
changes.

With fork, I save having to download the contents of the remote repository
again, because the object storage is shared. Also, I can merge my bug 
fixes into my long-term work without waiting for them to show up in the
mainline (although that makes the later merge potentially trickier) or, in
general, needing to transfer them between repositories.

The other main thing is the way that I actually split up patches. I have a
fork of the mainline. I make a second fork of the mainline. I diff
"second:first" to get the changes I need to split up, apply some of them,
commit, and then repeat. In order to diff "second:first", both have to be
stored in the same repository (because, otherwise, git won't be able to
find one or the other commit to look at). In the first iteration, when
second is mainline, it doesn't matter, but in later iterations I want to
get fewer and fewer changes to include or postpone, which requires using
commits from the splitting process.

	-Daniel
*This .sig left intentionally blank*

Re: unseeking?

[Zack Brown]

Hi,

Thanks for all the help!

On Sun, Apr 24, 2005 at 06:10:42PM -0400, Daniel Barkalow wrote:
> > but I still don't see its significance. What do you get from a fork that
> > you don't get from a regular old init and pull?
> 
> Primarily, the ability to inspect and build the mainline tree. If you want
> to take a look at what's going on in the mainline without getting it again
> or messing with your working directory or local commits, you can do that. 

OK, I think I understand this so far. So, suppose I want to contribute to
cogito. I would first do a git init on Pasky's cogito tree, to get it on my home
system. This would be my home base, and whenever I wanted to do some work on the
current state of his tree, I would fork off another branch.

So, I want to do this. From inside cogito's root directory, I give the command

git fork mycogito ../mycogito

and ../mycogito is created. In this new directory, the .git directory
contains only symlinks to ../cogito/HEAD, ../cogito/heads, ../cogito/objects,
../cogito/remotes, and ../cogito/tags, and an index file.

Question: when I make changes to mycogito and commit them, is only the index
file in .git/ altered, or are my changes reflected in the cogito/ directory as
well? If I do another fork of cogito, will I see mycogito's changes in the new
fork?

So moving on, I now have this mycogito tree. But I don't do any edits yet. I
just poke around for awhile, reading files. Finally I realize that there have
probably been updates to the upstream sources, and I want to pull those in
before I start my work. So, as I would do in the cogito directory, I give the
command

git pull pasky; git pull linus

this works fine. There are no new updates to be had, and git tells me my tree is
uptodate.

so now I start work. I run aspell on the README file, and it catches some
typos.  I fix them and save the file but don't yet commit it. Now mycogito
has some changes that I would ultimately like to push up to Pasky.

Now I'm unclear what comes next. Do I just do a 'git diff' from the mycogito
directory and post the results to the git list?

Suppose I want to keep working, changing more stuff in mycogito, but I also want
to make sure that mycogito tracks the upstream sources.

Would I just do

git pull pasky; git pull linus

and give that command whenever I wanted to grab the latest changes? What would
happen if there were upstream conflicts with my work on mycogito?

Or do I have that wrong. Instead of a pull, would I now only do

git merge pasky; git merge linus

and give that command to bring the upstream changes into mycogito?

Basically, once I'm editing files in mycogito, what commands to I give to bring
mycogito uptodate WRT the upstream sources? When I'm finally ready, and all my
changes have been committed into mycogito, what command do I give to produce a
patch to send to the git list?

Be well,
Zack

> 
> Also, if you're doing two independant sets of edits, you can share the
> downloads for updates between them. Say I'm working on an ambitious
> project to do block-move cross-file merges in git. I've got a fork that
> I'm working on that in. After I've done a bunch of work there, I notice a
> bug report about some of my other code in the project. I fork off another
> branch from the mainline to fix it in, so that I can ignore the fact that
> I'm a dozen commits into this other thing, fix the bug, and ship off the
> changes.
> 
> With fork, I save having to download the contents of the remote repository
> again, because the object storage is shared. Also, I can merge my bug 
> fixes into my long-term work without waiting for them to show up in the
> mainline (although that makes the later merge potentially trickier) or, in
> general, needing to transfer them between repositories.
> 
> The other main thing is the way that I actually split up patches. I have a
> fork of the mainline. I make a second fork of the mainline. I diff
> "second:first" to get the changes I need to split up, apply some of them,
> commit, and then repeat. In order to diff "second:first", both have to be
> stored in the same repository (because, otherwise, git won't be able to
> find one or the other commit to look at). In the first iteration, when
> second is mainline, it doesn't matter, but in later iterations I want to
> get fewer and fewer changes to include or postpone, which requires using
> commits from the splitting process.
> 
> 	-Daniel
> *This .sig left intentionally blank*
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Zack Brown

Re: unseeking?

[Daniel Barkalow]

On Mon, 25 Apr 2005, Zack Brown wrote:

> Hi,
> 
> Thanks for all the help!
> 
> On Sun, Apr 24, 2005 at 06:10:42PM -0400, Daniel Barkalow wrote:
> > > but I still don't see its significance. What do you get from a fork that
> > > you don't get from a regular old init and pull?
> > 
> > Primarily, the ability to inspect and build the mainline tree. If you want
> > to take a look at what's going on in the mainline without getting it again
> > or messing with your working directory or local commits, you can do that. 
> 
> OK, I think I understand this so far. So, suppose I want to contribute to
> cogito. I would first do a git init on Pasky's cogito tree, to get it on my home
> system. This would be my home base, and whenever I wanted to do some work on the
> current state of his tree, I would fork off another branch.
> 
> So, I want to do this. From inside cogito's root directory, I give the command
> 
> git fork mycogito ../mycogito
> 
> and ../mycogito is created. In this new directory, the .git directory
> contains only symlinks to ../cogito/HEAD, ../cogito/heads, ../cogito/objects,
> ../cogito/remotes, and ../cogito/tags, and an index file.

If you look carefully, ../cogito/.git/heads contains several files, one of
which is "mycogito", and the symlink in mycogito/.git/HEAD is to that one,
while the one in cogito/.git/HEAD is to a different one. So, while HEAD
points to a file in a shared directory, each fork points to a different
file.

> Question: when I make changes to mycogito and commit them, is only the index
> file in .git/ altered, or are my changes reflected in the cogito/ directory as
> well? If I do another fork of cogito, will I see mycogito's changes in the new
> fork?

The changes affect only the "mycogito" head, not the original head. On the
other hand, the files generated by the commit are accessible from the
original directory, so you can diff between your new head and the original
or mainline successors of it.

> So moving on, I now have this mycogito tree. But I don't do any edits yet. I
> just poke around for awhile, reading files. Finally I realize that there have
> probably been updates to the upstream sources, and I want to pull those in
> before I start my work. So, as I would do in the cogito directory, I give the
> command
> 
> git pull pasky; git pull linus
> 
> this works fine. There are no new updates to be had, and git tells me my tree is
> uptodate.
> 
> so now I start work. I run aspell on the README file, and it catches some
> typos.  I fix them and save the file but don't yet commit it. Now mycogito
> has some changes that I would ultimately like to push up to Pasky.
> 
> Now I'm unclear what comes next. Do I just do a 'git diff' from the mycogito
> directory and post the results to the git list?

Now you commit in your directory. This gives you a new head for
mycogito. You can then do "git patch pasky" (or something of the sort,
check the help for the details) to get a patch for the your changes. You
can also do multiple commits and generate either a single patch or patches
corresponding to each commit.

> Suppose I want to keep working, changing more stuff in mycogito, but I
> also want to make sure that mycogito tracks the upstream sources.
> 
> git merge pasky; git merge linus
> 
> and give that command to bring the upstream changes into mycogito?

In general, you want to use "merge" when you've got local commits. You
also want to commit before doing this, so that you have a known state
for your version to revert to if you mess up merging.

	-Daniel
*This .sig left intentionally blank*

Re: unseeking?

[Zack Brown]

On Mon, Apr 25, 2005 at 01:27:16PM -0400, Daniel Barkalow wrote:
> On Mon, 25 Apr 2005, Zack Brown wrote:
> > So moving on, I now have this mycogito tree. But I don't do any edits yet. I
> > just poke around for awhile, reading files. Finally I realize that there have
> > probably been updates to the upstream sources, and I want to pull those in
> > before I start my work. So, as I would do in the cogito directory, I give the
> > command
> > 
> > git pull pasky; git pull linus
> > 
> > this works fine. There are no new updates to be had, and git tells me my tree is
> > uptodate.
> > 
> > so now I start work. I run aspell on the README file, and it catches some
> > typos.  I fix them and save the file but don't yet commit it. Now mycogito
> > has some changes that I would ultimately like to push up to Pasky.
> > 
> > Now I'm unclear what comes next. Do I just do a 'git diff' from the mycogito
> > directory and post the results to the git list?
> 
> Now you commit in your directory. This gives you a new head for
> mycogito. You can then do "git patch pasky" (or something of the sort,
> check the help for the details)

OK, so it's actually:

git patch pasky:this

> to get a patch for the your changes. You
> can also do multiple commits and generate either a single patch or patches
> corresponding to each commit.

By replacing 'this' or 'pasky' in the above command with the appropriate
7de71a831508e51e0985cea173f3f7a7012c82b7 thingy, right?

So, I did 'git patch pasky:this', and got the following. Is this an appropriate
way to submit a patch? BTW, the 'truckload' fix I tried to change back by
editing the README again, and committing the change; but the git patch command
still shows the change.


spelling fixes

---
commit 8626d99da60a0cbb8e901df2da0f503959517bb8
tree a1c075cf00f03843de7200c2c341f1aeeb260a7f
parent 0d38182b234f5bb89e53ec31951e8d5d0ebdf69a
author <zbrown@tumblerings.org> 1114466199 -0700
committer <zbrown@tumblerings.org> 1114466199 -0700

Index: README
===================================================================
--- 7de71a831508e51e0985cea173f3f7a7012c82b7/README  (mode:100644 sha1:bc52eb0f2e4fe17157635dca34a5073944153c15)
+++ a1c075cf00f03843de7200c2c341f1aeeb260a7f/README  (mode:100644 sha1:140eefe0b740b2e7f4ee1644ec18f23855dc1af4)
@@ -9,7 +9,7 @@
    dictionary of slang.
  - "global information tracker": you're in a good mood, and it actually
    works for you. Angels sing, and a light suddenly fills the room. 
- - "goddamn idiotic truckload of sh*t": when it breaks
+ - "goddamn idiotic truck-load of sh*t": when it breaks
 
 GIT comes in two layers. The bottom layer is merely an extremely fast and
 flexible filesystem-based database designed to store directory trees with
@@ -245,7 +245,7 @@
 	In particular, since the blob is entirely defined by its data,
 	if two files in a directory tree (or in multiple different
 	versions of the repository) have the same contents, they will
-	share the same blob object. The object is toally independent
+	share the same blob object. The object is totally independent
 	of it's location in the directory tree, and renaming a file does
 	not change the object that file is associated with in any way.
 
@@ -300,7 +300,7 @@
 	actually have any relationship with the result, for example. 
 
 	Note on changesets: unlike real SCM's, changesets do not contain
-	rename information or file mode chane information.  All of that
+	rename information or file mode change information.  All of that
 	is implicit in the trees involved (the result tree, and the
 	result trees of the parents), and describing that makes no sense
 	in this idiotic file manager. 
@@ -468,7 +468,7 @@
 	changes in your working directory (ie "update-cache").
 
 	However, if you decide to jump to a new version, or check out
-	somebody elses version, or just restore a previous tree, you'd
+	somebody else's version, or just restore a previous tree, you'd
 	populate your index file with read-tree, and then you need to
 	check out the result with
 


\f
!-------------------------------------------------------------flip-


undid a bogus fix

---
commit a2e1bea63e3ed44321f560b892660ea4613f74f6
tree c28936b6a10b436f7b6027e396bf340e54ecb48c
parent 8626d99da60a0cbb8e901df2da0f503959517bb8
author <zbrown@tumblerings.org> 1114467935 -0700
committer <zbrown@tumblerings.org> 1114467935 -0700

Index: README
===================================================================
--- a1c075cf00f03843de7200c2c341f1aeeb260a7f/README  (mode:100644 sha1:140eefe0b740b2e7f4ee1644ec18f23855dc1af4)
+++ c28936b6a10b436f7b6027e396bf340e54ecb48c/README  (mode:100644 sha1:0c1630a83614acb3a2e577da64797c1512bf0cf3)
@@ -9,7 +9,7 @@
    dictionary of slang.
  - "global information tracker": you're in a good mood, and it actually
    works for you. Angels sing, and a light suddenly fills the room. 
- - "goddamn idiotic truck-load of sh*t": when it breaks
+ - "goddamn idiotic truckload of sh*t": when it breaks
 
 GIT comes in two layers. The bottom layer is merely an extremely fast and
 flexible filesystem-based database designed to store directory trees with


\f
!-------------------------------------------------------------flip-




> 
> > Suppose I want to keep working, changing more stuff in mycogito, but I
> > also want to make sure that mycogito tracks the upstream sources.
> > 
> > git merge pasky; git merge linus
> > 
> > and give that command to bring the upstream changes into mycogito?
> 
> In general, you want to use "merge" when you've got local commits. You
> also want to commit before doing this, so that you have a known state
> for your version to revert to if you mess up merging.
> 
> 	-Daniel
> *This .sig left intentionally blank*
> 

-- 
Zack Brown

Re: unseeking?

[Petr Baudis]

Dear diary, on Tue, Apr 26, 2005 at 12:28:33AM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> So, I did 'git patch pasky:this', and got the following. Is this an appropriate
> way to submit a patch? BTW, the 'truckload' fix I tried to change back by
> editing the README again, and committing the change; but the git patch command
> still shows the change.

Because it just exports individual patches. Use git diff (cg-diff) if
you want to get the cummulative diff.

Could you please sign off your patch?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: unseeking?

[Zack Brown]

On Tue, Apr 26, 2005 at 10:28:05PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 26, 2005 at 12:28:33AM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > So, I did 'git patch pasky:this', and got the following. Is this an appropriate
> > way to submit a patch? BTW, the 'truckload' fix I tried to change back by
> > editing the README again, and committing the change; but the git patch command
> > still shows the change.
> 
> Because it just exports individual patches. Use git diff (cg-diff) if
> you want to get the cummulative diff.
> 
> Could you please sign off your patch?

Spelling fixes.

Signed-off-by: Zack Brown <zbrown@tumblerings.org>

Index: README
===================================================================
--- 6159f313b10f0cfcdfedd63d6fb044029fe46aaa/README  (mode:100644
sha1:ae3c78a0f1927b9d92d788a0cd0b75d5fc3fc338)
+++ dbfe56b949992411184480136defe850a9f135cd/README  (mode:100644
sha1:bbf1920e29cc74dccec1271d57628244c87c6fb8)
@@ -233,7 +233,7 @@
        In particular, since the blob is entirely defined by its data,
        if two files in a directory tree (or in multiple different
        versions of the repository) have the same contents, they will
-       share the same blob object. The object is toally independent
+       share the same blob object. The object is totally independent
        of it's location in the directory tree, and renaming a file does
        not change the object that file is associated with in any way.
 
@@ -288,7 +288,7 @@
        actually have any relationship with the result, for example. 
 
        Note on changesets: unlike real SCM's, changesets do not contain
-       rename information or file mode chane information.  All of that
+       rename information or file mode change information.  All of that
        is implicit in the trees involved (the result tree, and the
        result trees of the parents), and describing that makes no sense
        in this idiotic file manager. 
@@ -456,7 +456,7 @@
        changes in your working directory (ie "update-cache").
 
        However, if you decide to jump to a new version, or check out
-       somebody elses version, or just restore a previous tree, you'd
+       somebody else's version, or just restore a previous tree, you'd
        populate your index file with read-tree, and then you need to
        check out the result with

-- 
Zack Brown

Re: unseeking?

[Petr Baudis]

Dear diary, on Tue, Apr 26, 2005 at 11:48:19PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Tue, Apr 26, 2005 at 10:28:05PM +0200, Petr Baudis wrote:
> > Dear diary, on Tue, Apr 26, 2005 at 12:28:33AM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> told me that...
> > > So, I did 'git patch pasky:this', and got the following. Is this an appropriate
> > > way to submit a patch? BTW, the 'truckload' fix I tried to change back by
> > > editing the README again, and committing the change; but the git patch command
> > > still shows the change.
> > 
> > Because it just exports individual patches. Use git diff (cg-diff) if
> > you want to get the cummulative diff.
> > 
> > Could you please sign off your patch?
> 
> Spelling fixes.
> 
> Signed-off-by: Zack Brown <zbrown@tumblerings.org>

Thanks, applied. (master.kernel.org is now down, so it'll take a while
before I will be able to push it out.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor