questions about cg-update, cg-pull, and cg-clone.

questions about cg-update, cg-pull, and cg-clone.

[Zack Brown]

Hi,

I'm trying to figure out the new Cogito syntax. What is the difference between
cg-update and cg-pull? Here is my take so far, please correct me:

'cg-update branch-name' grabs any new changes from the upstream repository and
merges them into my local repository. If I've been editing files in my local
repository, the update attempts to merge the changes cleanly.

Now, if the update is clean, a cg-commit is invoked automatically, and if the
update is not clean, I then have to resolve any conflicts and give the cg-commit
command by hand. But: what is the significance of either of these cg-commit
commands? Why should I have to write a changelog entry recording this merge? All
I'm doing is updating my tree to be current. Why should I have to 'commit' that
update?

Now I look at 'cg-pull'. What does this do? The readme says something about
printing two ids, and being useful for diffs. But can't I do a diff after a
cg-update and get the same result? I'm very confused about cg-pull right now.

Also, the README says that cg-clone and cg-init are identical, except that
cg-clone creates a new directory for the repository. Is that really the only
difference? Why do we have cg-clone then?

Be well,
Zack

-- 
Zack Brown

Re: questions about cg-update, cg-pull, and cg-clone.

[David A. Wheeler]

Zack Brown wrote:
> Hi,
> 
> I'm trying to figure out the new Cogito syntax. What is the difference between
> cg-update and cg-pull? Here is my take so far, please correct me:
> 
> 'cg-update branch-name' grabs any new changes from the upstream repository and
> merges them into my local repository. If I've been editing files in my local
> repository, the update attempts to merge the changes cleanly.

Yes. "cg-update branch-name" is EXACTLY the same as
  cg-pull branch-name && cg-merge branch-name
You can see this by examining the last lines of the cg-update script.
Because updating is one of the single most common operations for an SCM,
it makes sense to have a single command that does it.

Currently cg-update without a branch name does "recover deleted files"
instead, but I think that's a wart & Petr agrees (that will probably
get moved to a different command, see separate discussion).


> Now, if the update is clean, a cg-commit is invoked automatically,

Correct; cg-merge calls "cg-commit -C" (ignore cache)
if the merge is clean.

> and if the
> update is not clean, I then have to resolve any conflicts and give the cg-commit
> command by hand.

Correct.

> But: what is the significance of either of these cg-commit
> commands? Why should I have to write a changelog entry recording this merge? All
> I'm doing is updating my tree to be current. Why should I have to 'commit' that
> update?

I can't speak Petr, but I would guess that he's doing that because
he's trying to avoid data loss.

> Now I look at 'cg-pull'. What does this do? The readme says something about
> printing two ids, and being useful for diffs. But can't I do a diff after a
> cg-update and get the same result? I'm very confused about cg-pull right now.

cg-pull BRANCH copies any changes from the named branch into your
repository.  You could do a diff afterwards, yes, to get the
same results as long as the data is in your repository.  However,
after a successful merge the HEAD will be different from before
a successful merge, so the DEFAULT answers from a
diff will be different.


> Also, the README says that cg-clone and cg-init are identical, except that
> cg-clone creates a new directory for the repository. Is that really the only
> difference? Why do we have cg-clone then?

You'll have to ask Petr.  My guess is that he has bigger plans
for cg-clone, what you're seeing is just the current stub.

Anyway, hope my guessing helps.

--- David A. Wheeler

Re: questions about cg-update, cg-pull, and cg-clone.

[Zack Brown]

On Fri, Apr 29, 2005 at 10:37:29PM -0400, David A. Wheeler wrote:
> Zack Brown wrote:
> >Now, if the update is clean, a cg-commit is invoked automatically,
> 
> Correct; cg-merge calls "cg-commit -C" (ignore cache)
> if the merge is clean.
> 
> >and if the
> >update is not clean, I then have to resolve any conflicts and give the 
> >cg-commit
> >command by hand.
> 
> Correct.
> 
> >But: what is the significance of either of these cg-commit
> >commands? Why should I have to write a changelog entry recording this 
> >merge? All
> >I'm doing is updating my tree to be current. Why should I have to 'commit' 
> >that
> >update?
> 
> I can't speak Petr, but I would guess that he's doing that because
> he's trying to avoid data loss.

So, what would be an appropriate comment for that commit? I have no idea
what is changing on my tree in that case, all I know is that I'm merging from
someone else. All I really want is their changes and their commit messages,
not one of my own that is meaningless.

So far I just type ^d when this happens, and leave the commit message blank.

Be well,
Zack

> 
> 
> --- David A. Wheeler
> -
> 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: questions about cg-update, cg-pull, and cg-clone.

[Petr Baudis]

Dear diary, on Sat, Apr 30, 2005 at 02:53:22AM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> 'cg-update branch-name' grabs any new changes from the upstream repository and
> merges them into my local repository. If I've been editing files in my local
> repository, the update attempts to merge the changes cleanly.

Yes.

> Now, if the update is clean, a cg-commit is invoked automatically, and if the
> update is not clean, I then have to resolve any conflicts and give the cg-commit
> command by hand. But: what is the significance of either of these cg-commit
> commands? Why should I have to write a changelog entry recording this merge? All

You might want to write some special notes regarding the merge, e.g.
when you want to describe some non-trivial conflict resolution, or even
give a short blurb of the changes you are merging.

If you don't know what to say, just press Ctrl-D. The first line of the
commit always says "Merge with what_you_are_merging_with".

> I'm doing is updating my tree to be current. Why should I have to 'commit' that
> update?

If you are only updating your tree to be current, you don't have to
commit, and in fact you don't commit (you do so-called "fast-forward
merge", which will just update your HEAD pointer to point at the newer
commit). You commit only when you were merging stuff (so-called "tree
merge"; well, that's at least how I call it to differentiate it from the
fast-forward merge). That means you have some local commits over there -
I can't just update your tree to be current, sorry. That would lose your
commit. I have to merge the changes into your tree through a merge
commit.

> Now I look at 'cg-pull'. What does this do? The readme says something about
> printing two ids, and being useful for diffs. But can't I do a diff after a
> cg-update and get the same result? I'm very confused about cg-pull right now.

cg-pull does the first part of cg-update. It is concerned by fetching
the stuff from the remote repository to the local one. cg-merge then
does the second part, merging the stuff to your local tree (doing either
fast-forward or tree merge).

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

Re: questions about cg-update, cg-pull, and cg-clone.

[Zack Brown]

On Mon, May 02, 2005 at 09:58:46PM +0200, Petr Baudis wrote:
> Dear diary, on Sat, Apr 30, 2005 at 02:53:22AM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > 'cg-update branch-name' grabs any new changes from the upstream repository and
> > merges them into my local repository. If I've been editing files in my local
> > repository, the update attempts to merge the changes cleanly.
> 
> Yes.
> 
> > Now, if the update is clean, a cg-commit is invoked automatically, and if the
> > update is not clean, I then have to resolve any conflicts and give the cg-commit
> > command by hand. But: what is the significance of either of these cg-commit
> > commands? Why should I have to write a changelog entry recording this merge? All
> 
> You might want to write some special notes regarding the merge, e.g.
> when you want to describe some non-trivial conflict resolution, or even
> give a short blurb of the changes you are merging.
> 
> If you don't know what to say, just press Ctrl-D. The first line of the
> commit always says "Merge with what_you_are_merging_with".
> 
> > I'm doing is updating my tree to be current. Why should I have to 'commit' that
> > update?
> 
> If you are only updating your tree to be current, you don't have to
> commit, and in fact you don't commit (you do so-called "fast-forward
> merge", which will just update your HEAD pointer to point at the newer
> commit). You commit only when you were merging stuff (so-called "tree
> merge"; well, that's at least how I call it to differentiate it from the
> fast-forward merge). That means you have some local commits over there -
> I can't just update your tree to be current, sorry. That would lose your
> commit. I have to merge the changes into your tree through a merge
> commit.

Hm.

So, suppose I'm working on your Cogito HEAD. I make some changes to my local
tree and commit them to my tree, and then before I go forward, I want to grab
whatever you've done recently, to make sure we're not in conflict before I add
new changes. If I understand you right, this situation would be a 'fast forward
merge'. So what is the command I give to just 'merge' your HEAD with mine,
without requiring a changelog entry?

Alternatively, suppose I'm you, the project lead, and Zackdude has some
changes for me, based on my HEAD. I want to 'merge' his tree into mine. If
I'm still understanding you, this is a 'tree merge'. Now I give a cg-update,
and now I *want* to give a changelog entry to record the merge.  Correct?

No, I still don't see it. I don't see why I would want to add an additional
changelog entry on top of whatever changelog entries Zackdude has made himself.
It just seems to pollute the changelog with entries that are essentially
meaningless. When I read back over the logs, I'm not going to be interested in
the bookkeeping of when I merged with various developers, I'm going to be
interested in what those developers actually did to the code, and what *I*
actually did to the code.

> 
> > Now I look at 'cg-pull'. What does this do? The readme says something about
> > printing two ids, and being useful for diffs. But can't I do a diff after a
> > cg-update and get the same result? I'm very confused about cg-pull right now.
> 
> cg-pull does the first part of cg-update. It is concerned by fetching
> the stuff from the remote repository to the local one. cg-merge then
> does the second part, merging the stuff to your local tree (doing either
> fast-forward or tree merge).

OK, I don't understand this either. What is the difference between fetching the
stuff and merging the stuff? Suppose I am working on a local repo of Cogito
HEAD. I make some changes, commit them, and then I do a cg-pull. What happens?
Are my changes overwritten? Do they show up at all? Do they exist in some
nebulous ether that I will never see until I do a merge?

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: questions about cg-update, cg-pull, and cg-clone.

[Joel Becker]

On Tue, May 03, 2005 at 08:22:15AM -0700, Zack Brown wrote:
> So, suppose I'm working on your Cogito HEAD. I make some changes to my local
> tree and commit them to my tree, and then before I go forward, I want to grab
> whatever you've done recently, to make sure we're not in conflict before I add
> new changes. If I understand you right, this situation would be a 'fast forward
> merge'. So what is the command I give to just 'merge' your HEAD with mine,
> without requiring a changelog entry?

	Remember that HEAD is merely a SHA1 of the toplevel tree object.
Imagine you have the simplest tree, one directory containing one file.
The file has the has hash aaaaaa.  The tree object containing it has the
hash bbbbbb.  So, HEAD contains bbbbbb.
	Now you update from Petr, having made no changes.  You pull his
newest tree, which also has a new file.  That new file has the hash
cccccc.  The new tree object, containing both files, now has the hash
dddddd.  HEAD now contains dddddd.  As you are in a matching state to
his tree, you have not done anything interesting to your tree, and there
is no commit.  This is a "fast-forward" merge.
	Then you change the first file, adding a few functions.  You
commit it, and it now has the hash 111111.  This change means the tree
hash becomes 222222.  So, HEAD contains 222222.
	You then update from Petr again.  He's changed the second file.
It's hash is no longer cccccc, it's eeeeee.  In his tree, the hash of
the tree is 333333 (from file 1's aaaaaa and file 2's eeeeee).  But the
hash of your tree is 444444 (from your local file 1's 111111 and file 2's eeeeee).  So, the hash of the your tree becomes 444444.  Your HEAD contains 444444.
This does _not_ match his 333333 HEAD.  You are committing the
combination of his change and yours.  He is saying that this work, which
may have required hand-merging or commit resolution, is "interesting"
information.

Joel

-- 

Life's Little Instruction Book #69

	"Whistle"

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: questions about cg-update, cg-pull, and cg-clone.

[Daniel Barkalow]

On Tue, 3 May 2005, Zack Brown wrote:

> So, suppose I'm working on your Cogito HEAD. I make some changes to my local
> tree and commit them to my tree, and then before I go forward, I want to grab
> whatever you've done recently, to make sure we're not in conflict before I add
> new changes. If I understand you right, this situation would be a 'fast forward
> merge'. So what is the command I give to just 'merge' your HEAD with mine,
> without requiring a changelog entry?

In this case, you have to do a tree merge, because you have some commits
and he has some commits, and you want to be in a state where you have your
commits and his; this state is new, so you need a new commit with both
lines as parents.

> Alternatively, suppose I'm you, the project lead, and Zackdude has some
> changes for me, based on my HEAD. I want to 'merge' his tree into mine. If
> I'm still understanding you, this is a 'tree merge'. Now I give a cg-update,
> and now I *want* to give a changelog entry to record the merge.  Correct?

In this case, you don't have any commits that the other guy doesn't
have. Zackdude took your tree, made some changes, and that's his
head. Your head is still the same. He's already specified what happens
when you go from your head to his head; that's what he did, so the answer
has to be his head. That's a fast-forward.

Now, if the project lead decided to update from a second contributor who
hadn't rebased their contribution on the new head, then a merge is
required, to resolve the potential conflicts, and this merge needs a
commit.

> No, I still don't see it. I don't see why I would want to add an additional
> changelog entry on top of whatever changelog entries Zackdude has made himself.
> It just seems to pollute the changelog with entries that are essentially
> meaningless. When I read back over the logs, I'm not going to be interested in
> the bookkeeping of when I merged with various developers, I'm going to be
> interested in what those developers actually did to the code, and what *I*
> actually did to the code.

If developer A's changes work, and developer B's changes work, but they
don't work in your merge of them, you'll want to see that. Furthermore,
without a commit with both of their commits as parents, you can't reach
both of their histories from anywhere.

> OK, I don't understand this either. What is the difference between fetching the
> stuff and merging the stuff? Suppose I am working on a local repo of Cogito
> HEAD. I make some changes, commit them, and then I do a cg-pull. What happens?
> Are my changes overwritten? Do they show up at all? Do they exist in some
> nebulous ether that I will never see until I do a merge?

If you do a "cg-pull pasky", this doesn't change any of your stuff, but it
means that "cg-diff -r pasky" will now compare against his new head,
rather than the head he had when you previously did stuff. "cg-log
pasky" will include the new messages, and so forth. Also, you can then do
the merge without a network connection; you can pull overnight and merge
on the train.

You don't see anything different in your working directory, but your
repository essentially "knows more".

	-Daniel
*This .sig left intentionally blank*

Re: questions about cg-update, cg-pull, and cg-clone.

[Joel Becker]

On Tue, May 03, 2005 at 08:59:15AM -0700, Joel Becker wrote:
> 	Then you change the first file, adding a few functions.  You
> commit it, and it now has the hash 111111.  This change means the tree
> hash becomes 222222.  So, HEAD contains 222222.
> 	You then update from Petr again.  He's changed the second file.
> It's hash is no longer cccccc, it's eeeeee.  In his tree, the hash of
> the tree is 333333 (from file 1's aaaaaa and file 2's eeeeee).  But the
> hash of your tree is 444444 (from your local file 1's 111111 and file 2's eeeeee).  So, the hash of the your tree becomes 444444.  Your HEAD contains 444444.
> This does _not_ match his 333333 HEAD.  You are committing the
> combination of his change and yours.  He is saying that this work, which
> may have required hand-merging or commit resolution, is "interesting"
> information.

	Actually, it is more than interesting.  The tree has gone from a
HEAD of 222222 to a HEAD of 444444.  When HEAD changes, you need a
commit to describe the path.  Otherwise, you have a breakdown in the
history.  cg-log (or any other command) would have no way to get back
from 444444 to 222222 (or Petr's 333333) without the commit object
specifying its parent(s).
	If you have made no commits on your side, then the old HEAD is
Petr's old HEAD, the new HEAD is Petr's new 333333, and he's already
created a commit object describing this.  You're just fast-forwarding.

Joel

-- 

"The nice thing about egotists is that they don't talk about other
 people."
         - Lucille S. Harper

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127