unseeking?

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

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,

git seek, without any arguments.

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

Actually, this _would_ work:

	git init ../mygitdir/.git

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

git fork seconddeveloper ../mygitdir

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

Try head git*.sh. ;-)

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.

	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.)

On Sun, Apr 24, 2005 at 06:05:14PM +0200, Petr Baudis wrote:

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.

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.

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$

OK

heh. This is not more clear ;-)

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.

Be well, Zack

On Sun, 24 Apr 2005, Petr Baudis wrote:

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

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.

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

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.

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*

On Sun, Apr 24, 2005 at 01:25:35PM -0400, Daniel Barkalow 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

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.

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

On Sun, 24 Apr 2005, Zack Brown wrote:

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.

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

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

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.)

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*

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?

Be well, Zack

On Sun, 24 Apr 2005, Zack Brown wrote:

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*

Hi,

Thanks for all the help!

On Sun, Apr 24, 2005 at 06:10:42PM -0400, Daniel Barkalow wrote:

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

On Mon, 25 Apr 2005, Zack Brown wrote:

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.

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.

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.

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*

On Mon, Apr 25, 2005 at 01:27:16PM -0400, Daniel Barkalow wrote:

OK, so it's actually:

git patch pasky:this

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

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...

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?

On Tue, Apr 26, 2005 at 10:28:05PM +0200, Petr Baudis wrote:

Spelling fixes.

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

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...

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

Petr Baudis wrote:

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