[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