Re: cogito - how do I ???

On Sun, 22 May 2005, Sam Ravnborg wrote:

quoted

quoted

quoted

1) Something similar to "bk changes -R". I use this to see what has
happened upstream - to see if I really want to merge stuff.

Not sure what bk did here, but you can do something like:

cg-pull origin
cg-log -c -r origin

In the raw git interfaces, you'd basically have to do the same thing that
"git-pull-script" does, except that _instead_ of calling the
git-resolve-script thing, you'd do

	git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin

That looks ... long.

That's why people don't generally use git natively. 

I want teach people what the "raw" interfaces are not because you're 
supposed to use them, but because I expect that the raw ones are useful 
for scripting.

In bk the usage pattern was to check what was in mainline _before_
fetching and merging.

In git (and cogito, although it's less obvious), the "fetching" is totally 
separate from the "merging". In BK, the two were the same - you couldn't 
merge without fetching, and you couldn't fetch without merging.

So it seems that with git/cogoto one has to fetch the chages, inspect
them, and then decide to apply or not.

Well, that's really what you ended up largely doing in BK too, since even
if it _looks_ like you first inspect them with "bk changes -R", the fact
is, in order to do that, you do have to _fetch_ the data first. It's just
that BK (a) fetched just the changeset changes (I think) and (b) then
threw the data away.

With git, you can also do the "fetch just the changeset changes", since if 
you use "git-http-pull" you can instruct it to first _only_ fetch the 
actual commits, and forget about the actual data. But since git considers 
"fetching" and "merging" totally separate phases, it's up to your scripts 
whether they leave the objects around or not afterwards. The normal 
operaion is to leave everything around, since that means that if/when you 
do decide to merge, you already have the data, and you don't need to 
re-fetch.

If you decide to throw it away, you first remove the reference to the
stuff you pulled, and then use "git-prune-script" to get rid of the
objects you used. Right now that is admittedly quite expensive, it's
considered a "rare" thing to do (sicne even if you decide not to merge,
the extra objects never hurt - you can prune things once a week if you
care).

When the fetches changes stay in MERGE_HEAD I assume my work when
committed will be based on top of HEAD - so I do not have to know
if I have fetched some (unmerged) updates.

Yes. Note that MERGE_HEAD ends up being just a totally temporary reference
to the top (that you decided not to merge). It has no meaning for git
itself, and the naming and meaning is purely as a git-pull-script (and
git-resolve-script) internal temporary thing.

quoted

And again, without the porcelain this is:

	git-diff-tree -v -p <name>

The key here is the SHA1. I hoped to avoid specifying SHA1's with
cogito, I so often miss one character when doing copy'n'paste.

You don't have to use the raw SHA1. git understands tags and references, 
so for example, if you take the "fetch" part of git-pull-script (I really 
should split it up into "git-fetch-script"), then you can, for example, do

	git-diff-tree -v -p MERGE_HEAD

to see the top of the (unmerged) thing. Similarly, doing a

	git-rev-list MERGE_HEAD | git-diff-tree --stdin -v -s

will give you the changelog for the unmerged side. No SHA1's necessary.

Of course, if you don't have a reference to the thing you want to look at, 
you do need to figure out the SHA1 some way. But for example, gitk will 
work fine for the unmerged stuff too - ie you can do

	gitk MERGE_HEAD ^HEAD

_before_ you merge, and get all the nice graphical tools to inspect what 
the hell there is that is new there..

Notice how this "fetch is independent of merge" thing thus means that you 
can do a lot _more_ than "bk changes -R" ever did. But yes, it's a bit 
more complex too (so normally you'd probably only use the porcelain 
layer).

		Linus