"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> Or take the following paragraph from Greg Troxel's message (ID:
> rmiio6ljiaq.fsf%fnord.ir.bbn.com@localhost) earlier in this thread:
>
> Each commit on master should have as its first parent ancestor the
> previous main line of master. (This follows from not having merge
> commits, but is the normal best practice to keep straight "what is my
> direct ancestor in development along this branch" vs "what just got
> merged in".)
>
> I have almost no idea what that first sentence means. Now, I think Greg
> was talking about very specific details of the workflow on purpose for
> those who do know Git and not intending that for the step-by-step guide,
> but if I'm wrong and that were in the step-by-step guide, that wouldn't
> be easy to follow for someone who doesn't know Git.
That's correct; I was trying to express local rules for those who do
know git.
> So, I think it really comes down to whether you want a proper
> understanding of Git to be a prerequisite of contributing to pkgsrc-wip.
> If there was a step-by-step guide like you, Martin, suggested, it would
> make the barrier to entry significantly lower for someone wishing
> to contribute who doesn't know Git. If it doesn't exist, then I'd
> have to take the time to learn Git properly in order to contribute to
> pkgsrc-wip. That wouldn't be the end of the world, but it would be a
> barrier.
It is, but it's traded for the barrier of CVS :-)
I suggest reading this:
https://progit.org/
and I think you'll find it helpful. If not, and you find something
better, let me know, because I now know git too well to evaluate
material for usefulness for new people.
What I meant about first-parent ancestor is:
merges have multiple parents. In the normal/sane case, they have two.
The first parent (git show will list them both) is the one that's
considered the logical ancestor along the branch, and the 2nd parent is
what is considered to be merged in. Except "git pull" when getting new
commits from the upstream repository does it wrong, and the 1st parent
is your commits and 2nd is the ones from upstream. This is because
"git pull" was intended to get another branch and merge it in to the
current branch, but that's not how it gets used.
I fix this by using an alias:
git config --global alias.up "!git remote update -p && git merge --ff-only @{u}"
which makes "git up" act like cvs up, sort of:
- fetch new commits from the upstream repo
- advance the local branch pointer to the new commits, if it can be
done without merges
if that fails, I do
git rebase @{u}
or
git rebase origin/master
The token @{u} is just a shorthand for the matching usptream branch.
Alternatively one can "git pull --rebase". I like git up because I get
to see what's up before I rebase. But I ~always just do it.
Note that git rebase in this situation is no more likely to create merge
conflicts than cvs up; it's only if the same/nearby lines in the same
files were touched, more or less.
Hope this helps...
Attachment:
signature.asc
Description: PGP signature