Newbie falls at first hurdle

Newbie falls at first hurdle

[Alan Chandler]

I have been lurking on this mailing list since the beginning, but have just 
got to the point where I want to use git to manage something I am doing.

I have already got a working directory (or rather a directory hierarchy) of an 
application with files (combination of html and java), and I need to start 
applying some control to it.  The Tutorial unfortunately does not cover this 
case.  Nevertheless I have proceeded.

So at the top-level I have done 'git-init-db'

but I now assume I have to add all the files to the cache

So 'git-update-cache --add *' would seem to be the next step.

However this fails with a message 

error: JavaSource: is a directory
fatal: Unable to add JavaSource to database; maybe you want to use --add 
option?

Since I am already using the --add option, I really don't understand what I am 
doing wrong.

Help please.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Newbie falls at first hurdle

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> So 'git-update-cache --add *' would seem to be the next step.
>
> However this fails with a message 
>
> error: JavaSource: is a directory
> fatal: Unable to add JavaSource to database; maybe you want to use --add 
> option?

Sorry, that is not a very helpful error message.

We do not track 'directories'.  Only files and symlinks, which
could live within subdirectories, and that's why you got that
error message -- you told it to add a directory.  You'd need
something like this:

    $ find * ! -type d -print0 | xargs -0 git add

Re: Newbie falls at first hurdle

[Alan Chandler]

On Saturday 17 Sep 2005 17:13, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:

> We do not track 'directories'.  ...

>
>     $ find * ! -type d -print0 | xargs -0 git add

I did actually manage to create content with

find . -wholename './.git' -prune -o -wholename './.deployables' -prune -o 
\( -type f -print \) | xargs git-update-cache --add 

and then commited it (with git commit)

The editor file that came up with this listed all the files it was going to 
commit INCLUDING some .files from the root directory (I am using eclipse, so 
I had files like .project and .classpath there).  It says in the 
Documentation that git ignores those - has it done?


I then blew away (ie deleted) a couple of directories in my working tree and 
loaded them from an earlier backup and git diff HEAD showed the differences 
of the content of these new directories against the committed ones just fine.  
I then deleted these directories again and then attempted to check them out 
from the repository with

git checkout master

None of these directories has been created in my working directory.

Does this mean that I have to manually create the directory structure for the 
files to be checked into?


-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Newbie falls at first hurdle

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> The editor file that came up with this listed all the files it was going to 
> commit INCLUDING some .files from the root directory (I am using eclipse, so 
> I had files like .project and .classpath there).  It says in the 
> Documentation that git ignores those - has it done?

We ignore '.git' but we let you have paths starting with dots
these days -- the change happened quite a while ago and if some
documentation still says we do not, then you spotted a
documentation bug.

> I then deleted these directories again and then attempted to check them out 
> from the repository with
>
> git checkout master
>
> None of these directories has been created in my working directory.

After you told git about those files, you removed them from your
working tree.  "git checkout" tries not to lose your local
changes -- which means that what you removed will be left
removed (so are what you locally edited).

    $ git checkout -f

would give them back, but you would also lose other local
changes if you have some.

Re: Newbie falls at first hurdle

[Alan Chandler]

On Saturday 17 Sep 2005 17:50, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> > The editor file that came up with this listed all the files it was going
> > to commit INCLUDING some .files from the root directory (I am using
> > eclipse, so I had files like .project and .classpath there).  It says in
> > the Documentation that git ignores those - has it done?
>
> We ignore '.git' but we let you have paths starting with dots
> these days -- the change happened quite a while ago and if some
> documentation still says we do not, then you spotted a
> documentation bug.

I think that is probably my problem.  I deleted all of /usr/local/bin (which 
had an earlier version of git in it) and then tried to re-install git 99.6.  
When I got a permissions error I gave up and installed into ~/bin.


But of course - that probably means that the man pages are old ones from when 
I last installed git (very early in the development cycle).

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Newbie falls at first hurdle

[Horst von Brand]

Alan Chandler <alan@chandlerfamily.org.uk> wrote:

[...]

> I have already got a working directory (or rather a directory hierarchy)
> of an application with files (combination of html and java), and I need
> to start applying some control to it.  The Tutorial unfortunately does
> not cover this case.  Nevertheless I have proceeded.

The easiest way of doing this is using cogito (near where you found
git). It automates some tasks using git as backendq, in this case it would
only need:

   cg-init
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Newbie falls at first hurdle

[Martin Langhoff]

On 9/18/05, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> The easiest way of doing this is using cogito (near where you found
> git). It automates some tasks using git as backendq, in this case it would
> only need:
> 
>    cg-init

+1 -- I work with a small team and we are migrating to cogito/git.
There's still a few things we have to call git utilities for (change
branch, for instance) but for "intuitive" usage, cogito is the cat's
whiskers.

cheers,


martin

Re: Newbie falls at first hurdle

[Alan Chandler]

On Sunday 18 Sep 2005 11:54, Martin Langhoff wrote:
> On 9/18/05, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> > The easiest way of doing this is using cogito (near where you found
> > git). It automates some tasks using git as backendq, in this case it
> > would only need:
> >
> >    cg-init
>
> +1 -- I work with a small team and we are migrating to cogito/git.
> There's still a few things we have to call git utilities for (change
> branch, for instance) but for "intuitive" usage, cogito is the cat's
> whiskers.

Yes - I had increasingly believed that with all the scripts being generated 
with git that cogito was becoming irrelevant.  However experience of the last 
day has shown me that is far from the case.

I really like cg-commit where it lists the files its going to commit for you, 
and where if you delete the line it doesn't.  If I've been doing a bit too 
many things at once it helps commit in small chunks

Seems cogito branch handling only really deals with linking to others. I have 
ended up also using git branch and git checkout -f to keep lots of little 
local branches in my repository.

Still struggling with how to cherry pick parts a previous update (between 
possibly two other branches) and apply them to a current branch - all the 
tutorials assume you want it all, and I can't really understand what the 
cherry pick commands do from their manuals.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Newbie falls at first hurdle

[Petr Baudis]

Dear diary, on Sat, Sep 17, 2005 at 02:09:46PM CEST, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> told me that...
> I have been lurking on this mailing list since the beginning, but have just 
> got to the point where I want to use git to manage something I am doing.
> 
> I have already got a working directory (or rather a directory hierarchy) of an 
> application with files (combination of html and java), and I need to start 
> applying some control to it.  The Tutorial unfortunately does not cover this 
> case.  Nevertheless I have proceeded.
> 
> So at the top-level I have done 'git-init-db'
> 
> but I now assume I have to add all the files to the cache
> 
> So 'git-update-cache --add *' would seem to be the next step.
> 
> However this fails with a message 
> 
> error: JavaSource: is a directory
> fatal: Unable to add JavaSource to database; maybe you want to use --add 
> option?
> 
> Since I am already using the --add option, I really don't understand what I am 
> doing wrong.

Two reports about this error message in one day, and I've seen more in
the past. Heh. ;-) I'd submit a patch, but I'm still staying at the last
git release because of the command renames.

BTW, cg-add should be now (not in the last release yet, though) totally
directory-friendly.

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

Re: Newbie falls at first hurdle

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> Yes - I had increasingly believed that with all the scripts being generated 
> with git that cogito was becoming irrelevant.

That is not going to happen.

The point of git barebone Porcelain (or Porcelainish commands)
is to give minimally usable UI on top of Plumbing tools for
people who like to get their hands dirty, and sometimes to
demonstrate how to take advantage of new core features before
Porcelains start using them.  It is not about competing with
real Porcelains.

> Still struggling with how to cherry pick parts a previous
> update (between possibly two other branches) and apply them to
> a current branch - all the tutorials assume you want it all,
> and I can't really understand what the cherry pick commands do
> from their manuals.

An example to pick a couple of commits from one branch to another.

    $ git show-branch master pu
    * [mister] Improve the safety check used in fetch.c
     ! [pu] Merge branch 'nuker' of .; branch 'merge' of .
    --
     + [pu] Merge branch 'nuker' of .; branch 'merge' of .
     + [pu^3] Use git-merge instead of git-resolve in git-pull.
     + [pu^2] Add two options to diffcore.
     + [pu^2~1] Diff cleanup.
     + [pu^2~2] Retire rev-tree.
     + [pu^2~3] Retire git-export.
    ++ [mister] Improve the safety check used in fetch.c

Let's cherry-pick two commits from pu branch:

    $ git cherry-pick pu^3 ; git cherry-pick pu^2~2

Then the result looks like this:

    $ git show-branch mister pu
    * [mister] Retire rev-tree.
     ! [pu] Merge branch 'nuker' of .; branch 'merge' of .
    --
     + [pu] Merge branch 'nuker' of .; branch 'merge' of .
     + [pu^3] Use git-merge instead of git-resolve in git-pull.
     + [pu^2] Add two options to diffcore.
     + [pu^2~1] Diff cleanup.
     + [pu^2~2] Retire rev-tree.
     + [pu^2~3] Retire git-export.
    +  [mister] Retire rev-tree.
    +  [mister~1] Use git-merge instead of git-resolve in git-pull.
    ++ [pu~1] Improve the safety check used in fetch.c

Note that new two commits are _not_ the same commit objects you
cherry picked from the pu branch.  They are new commits that
introduce changes equivalent to them.

Re: Newbie falls at first hurdle

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Two reports about this error message in one day, and I've seen more in
> the past. Heh. ;-) I'd submit a patch, but I'm still staying at the last
> git release because of the command renames.

That should not be a reason to stay at the last release; the old
command names should be supported as well in the current
"master" branch -- unless something is broken (missing backward
compatible old-name symlinks, for example), which I hope is not
the case.

Re: Newbie falls at first hurdle

[Linus Torvalds]

On Sun, 18 Sep 2005, Junio C Hamano wrote:
> 
> An example to pick a couple of commits from one branch to another.

Your examples scare even me.

How about you add this to the tutorial as an "advanced usage" example, and 
explain everything that was done in terms of what the "stupid usage" 
examples earlier in the tutorial did.

In other words, you'd have to explain what "pu^2~3" means.

And octopus merges, for that matter. I don't think the tutorial ever 
explains those.

		Linus

Re: Newbie falls at first hurdle

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> In other words, you'd have to explain what "pu^2~3" means.
>
> And octopus merges, for that matter. I don't think the tutorial ever 
> explains those.

Sorry, my excuses are (1) I just did a quick example from a tree
I had handy -- my live tree; (2) as long as the user knows the
commit show-branch labeled with the cryptic "pu^2~3" is the one
s/he wants, it does not matter much what that label exactly
means.

But of course you are right.

Re: Newbie falls at first hurdle

[Martin Langhoff]

On 9/19/05, Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> Still struggling with how to cherry pick parts a previous update (between
> possibly two other branches) and apply them to a current branch - all the
> tutorials assume you want it all, and I can't really understand what the
> cherry pick commands do from their manuals.

Forget the cherry pick commands -- here's a usable, easy strategy.

git-checkout the "source" branch, create a temporary directory to hold
the patches, and call

    git-format-patch --mbox -o patchdir destbranch

This will create one file per patch in the destination directory. Feel
free to delete patches you don't want, and edit the patches you've got
there. Then switch to the destination branch, and use git-applymbox to
merge them in.

If you do this repeatedly, git-format-patch will not reexport patches
you've merged to the destination branch already (if they merged
cleanly unchanged)... or at least that's the theory ;)

The only limitation I've found in this strategy is that it doesn't
deal with binary objects. I'm lost as to what to do in those cases.

cheers,


martin

[PATCH] Improve git-update-index error reporting

[Petr Baudis]

Dear diary, on Sun, Sep 18, 2005 at 07:35:00PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > Two reports about this error message in one day, and I've seen more in
> > the past. Heh. ;-) I'd submit a patch, but I'm still staying at the last
> > git release because of the command renames.
> 
> That should not be a reason to stay at the last release; the old
> command names should be supported as well in the current
> "master" branch -- unless something is broken (missing backward
> compatible old-name symlinks, for example), which I hope is not
> the case.

You are obviously right. I don't make install, but running
./cmd-rename.sh manually seemed to work fine.

--

This makes git-update-index error reporting much less confusing. The
user will know what went wrong with better precision, and will be given
a hopefully less confusing advice.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
commit c758513532d4077630977fd0ee86ad1ba37c250a
tree db9476c44cb74ea98ebec31cf7431cd012d5db94
parent 7f4b3d9fef3f1855005e243de43776d8015ca737
author Petr Baudis <pasky@suse.cz> Sun, 18 Sep 2005 21:08:35 +0200
committer Petr Baudis <xpasky@machine.(none)> Sun, 18 Sep 2005 21:08:35 +0200

 update-index.c |   36 +++++++++++++++++++++++++-----------
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/update-index.c b/update-index.c
--- a/update-index.c
+++ b/update-index.c
@@ -50,11 +50,20 @@ static int add_file_to_cache(char *path)
 		 * case just fine without --force-remove.
 		 */
 		if (status == 0 || (errno == ENOENT || errno == ENOTDIR)) {
-			if (allow_remove)
-				return remove_file_from_cache(path);
+			if (allow_remove) {
+				if (remove_file_from_cache(path))
+					return error("%s: cannot remove from the index",
+					             path);
+				else
+					return 0;
+			} else if (status < 0) {
+				return error("%s: does not exist and --remove not passed",
+				             path);
+			}
 		}
 		if (0 == status)
-			return error("%s: is a directory", path);
+			return error("%s: is a directory - add files inside instead",
+			             path);
 		else
 			return error("lstat(\"%s\"): %s", path,
 				     strerror(errno));
@@ -71,15 +80,17 @@ static int add_file_to_cache(char *path)
 	case S_IFREG:
 		fd = open(path, O_RDONLY);
 		if (fd < 0)
-			return -1;
+			return error("open(\"%s\"): %s", path, strerror(errno));
 		if (index_fd(ce->sha1, fd, &st, !info_only, NULL) < 0)
-			return -1;
+			return error("%s: failed to insert into database", path);
 		break;
 	case S_IFLNK:
 		target = xmalloc(st.st_size+1);
 		if (readlink(path, target, st.st_size+1) != st.st_size) {
+			char *errstr = strerror(errno);
 			free(target);
-			return -1;
+			return error("readlink(\"%s\"): %s", path,
+			             errstr);
 		}
 		if (info_only) {
 			unsigned char hdr[50];
@@ -87,15 +98,18 @@ static int add_file_to_cache(char *path)
 			write_sha1_file_prepare(target, st.st_size, "blob",
 						ce->sha1, hdr, &hdrlen);
 		} else if (write_sha1_file(target, st.st_size, "blob", ce->sha1))
-			return -1;
+			return error("%s: failed to insert into database", path);
 		free(target);
 		break;
 	default:
-		return -1;
+		return error("%s: unsupported file type", path);
 	}
 	option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
 	option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
-	return add_cache_entry(ce, option);
+	if (add_cache_entry(ce, option))
+		return error("%s: cannot add to the index - missing --add option?",
+			     path);
+	return 0;
 }
 
 static int compare_data(struct cache_entry *ce, struct stat *st)
@@ -393,11 +407,11 @@ int main(int argc, char **argv)
 		}
 		if (force_remove) {
 			if (remove_file_from_cache(path))
-				die("git-update-index: --force-remove cannot remove %s", path);
+				die("git-update-index: unable to remove %s", path);
 			continue;
 		}
 		if (add_file_to_cache(path))
-			die("Unable to add %s to database; maybe you want to use --add option?", path);
+			die("Unable to process file %s", path);
 	}
 	if (write_cache(newfd, active_cache, active_nr) ||
 	    commit_index_file(&cache_file))

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

Re: Newbie falls at first hurdle

[Alan Chandler]

On Sunday 18 Sep 2005 18:22, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:

> > Still struggling with how to cherry pick parts a previous
> > update (between possibly two other branches) and apply them to
> > a current branch - all the tutorials assume you want it all,
> > and I can't really understand what the cherry pick commands do
> > from their manuals.
>
> An example to pick a couple of commits from one branch to another.

I understood your example (on the assumption I don't really care what pu^2~2 
actually means as its copied from a list) and that is a new piece of useful 
information that I didn't have before, (and which I would have used several 
times this afternoon had I known) but its not exactly what I meant.

Before using git I had made a lot of unrelated changes to my working 
directory, some of which were bad.  The only way to get a snapshot before I 
made it bad (trying to hack a combination CSS and dynamically created html to 
get it to do what I want - mind breaking:-( ) was to go back to the previous 
days backup of the whole working directory. 

It was this mess I had got myself into that kicked me into getting into git, 
rather than waiting for the 1.0 release, which had been my previous plan.

I effectively loaded both my current code and the day before's backup into git 
as two separate branches.

What I was then trying to do, via various attempts with git diff -p was to 
extract small chunks of updates (ie limit scope over a few files).  Edit the 
result to limit the diff to cover a small update and then apply it to a my 
current stuff to slowly undo some of the mess that I had made. 

Being new to git, meant reading man pages all the time - which was making it 
slow progress (and which wasn't helped by realising I had an old version of 
the man pages installed part way through :-( ).  In the end it was easier to 
manually retrace my steps by typing in the changes I needed.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Newbie falls at first hurdle

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> I effectively loaded both my current code and the day before's
> backup into git as two separate branches.
>
> What I was then trying to do, via various attempts with git diff -p was to 
> extract small chunks of updates (ie limit scope over a few files).  Edit the 
> result to limit the diff to cover a small update and then apply it to a my 
> current stuff to slowly undo some of the mess that I had made. 

Ah, what you have to work with are only date-based snapshots of
various states (i.e. the separation between one snapshot and
another does not necessarily have much to do with a single set
of logically isolated changes).

I end up doing that myself, although the situation I'd be in
tend to be one logical change spread over multiple commits (the
other way around from your case where one diff contains many
logically unrelated chagnes).  I run git-diff-tree -p between
states to obtain a set of N diffs, look them over and hand edit
them to collect related things together and separate independent
things separate to create a different set of M diffs. then
create a temporary branch that is reset to the state before
those N diffs and use applymbox to apply M diffs.  This is
essentially what Martin suggested.

In your case, each diff you have contains unrelated changes and
you have to move things around.  It's a pain but I am afraid
there are not any SCM can do much to help you.

Re: Newbie falls at first hurdle

[Sven Verdoolaege]

On Sun, Sep 18, 2005 at 08:11:10PM +0100, Alan Chandler wrote:
> What I was then trying to do, via various attempts with git diff -p was to 
> extract small chunks of updates (ie limit scope over a few files).  Edit the 
> result to limit the diff to cover a small update and then apply it to a my 
> current stuff to slowly undo some of the mess that I had made. 

Yoy may find my changes to dirdiff useful if you do things like that.
(http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary)
I've basically changed it to allow "merging" (i.e., commiting) to a branch.

You'd start it like this

girdiff master .

Then you loop through the files with differences, for each
file selecting the changes you want to copy and selecting
Merge/"update master".
Then you fill in a commit message and select File/Commit
from the commit message window.

Only lightly tested so far.
Rediff'ing doesn't work yet, so you'll have to restart
girdiff after each commit for now.

skimo