[Ecls-list] Fixes for the current git master, MSVC and not.

Samium Gromoff _deepfire at feelingofgreen.ru
Fri Oct 31 17:39:14 UTC 2008


From: "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll at googlemail.com>
> What I did several days ago was a git clone of your source tree
> followed by a git branch, to find that you only had one branch. Of
> course then I had to go through the log looking for the point where
> our source trees diverged. That is definitely not optimal :-)

What I would have done, instead, is as David has already suggested,
add my repository as a "remote".

Remotes are, in effect, mappings of remote repository branches into
local branches. For example, the default remote, called "origin",
is set up automatically upon clone, and maps remote branches
heads/* into local remotes/origin/*.

`git fetch <remote-name>', then, merely updates local
remotes/<remote-name>/* branches.

A separate thing to note, is that when doing merging, you should have
a clean state, with no uncommitted changes in the working tree.

At this point you could cherry-pick individual changes into your master,
or completely merge chosen branches.

I find cherrypicking most conveniently done via gitk --all, whereas
merging is done by `git merge'.

> Now, as for the fetch command, can I use it repeatedly?

Yes.

> Will it fetch your newest changes

Yes.

> and will they rebased to the new tip of my master branch?

No, fetch just retrieves remote history, it doesn't do merging,
which is done by `git merge' (or by `git pull', which is
`git fetch' and `git merge $DEFAULT-BRANCH-TO-MERGE' combined).

> If this is so then I can just use git diff to get the patches,
> am I wrong?

git-diff can be used to show deltas between more-or-less arbitrary points
of history in diff format, yes.

But for serialising individual commits, git-show is more convenient.

For example, `git show 7565210' in my ECL repository shows the diff for
commit with message `USE-DFFI is not exportd by SI', as it must in yours.

7565210 is an abbreviated form of the full commit id
756521026d6ff957741528ca55088ec02cbbe9ff


regards, Samium Gromoff




More information about the ecl-devel mailing list