Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] git feedback

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git feedback
  • Date: Fri, 28 Jul 2006 12:08:53 -0500

On Jul 28, Ladislav Hagara [ladislav.hagara AT unob.cz] wrote:
> > P4 does use a smarter merge strategy when dealing with changelog-type
>
> Yea, P4 is smarter and more suitable for us.
> We are "free" now but with lots of problems.

"More suitable for us" in general based on one thing that has a known
resolution path is a bit of a reach. p4 had more problems for us than
"just" the license.

> Or only I have problems because it seems you all are happy with git.

So far just you and Seth (and sometimes Andrew) have had some problems
getting acclimated. These issues have mostly seemed to be around
integrations and merges, but it seems to me to be familiarity problems more
than lacking functionality. Others have done some pretty heavy
integrations and liked how it worked. Yes, p4 supported our workflow
model, but at least part of that was tautological in nature, since that
workflow also in part came from p4. Give git some time and patience to
learn how it wants to work. It's different, but several people who really
liked p4 also really like git.

> Were you trying to integrate something bigger?

I have done some pretty large integrations (hundreds of commits at a time).
Arwed's done some hairy ones as well. Both of us had to do these as part
of keeping the multi-scm trial going, which is outside of our day-to-day
use cases but still requires the same commands.

> > Is this the main thing you're talking about when you say "git's
> > integration
> > is really horrible", or is there more to it? I have a hard time seeing how
> > 'git cherry-pick <commit-id>' is difficult or worse than
> > 'p4 integ {test,stable/0.5}/some/path/...'
>
> For example I want to copy/integrate new spell from test to stable-rc.
> In perforce it is only "p4 integrate test/abc/... stable-rc/abc/...".
> In git I have to find out several hashes (no normal catchy numbers), for
> example it was not only one commit to test grimoire, what about hundreds
> commits?, and step by step cherry/pick them.

As people get familiar with git the number of commit ids you need to find
for a given integration should get smaller. New spell integrations should
only be 1 cherry-pick, though they'll probably often be 2 because people
forget the ChangeLog entry until reminded (maybe this gets automated at
some point though).

I've *done* cherry picking of hundreds of commits at once and it can be
done nearly with a one-liner. For example, to automatically cherry pick
all the changes in the "http" section from test to devel, something like
this works:

git checkout devel; git log --no-merges devel..master http | sed -n -e
's/^commit //p' | while read; do git cherry-pick $REPLY; done

This will list all the http changes in test that aren't in devel, grab out
the commmit ids, and feed them one at a time to cherry-pick. I'm doing
even more comprehensive ones that basically involve taking every change
made in our git repository since it was created and merging them one commit
at a time back into the new git repository that contains all the p4
history. In my case I'm having to do a fair amount of manual resolving but
that's due to the way these trees diverge more than anything. In our
normal case (not that doing hundreds of commits at once is ever a "normal"
case for us) we'd currently need to do some manual resolving because of the
simple merge problem but once we resolve that globally hundreds of cherry
picks at once would be seamless as long as the two repositories didn't have
real conflicting changes.

> > as modular as any other unix tool
>
> In p4 I like I have two/three separate directories (devel,test, stable)
> and I can use normal unix tools to compare them or to work with them
> (diff, mc, tar, ...).
> In git there is only one directory and I have to use "git diff" and get
> its a/... b/....
> Why a/... and b/... and not test/... and stable-rc/...?

There's nothing stopping you from keeping a directory on disk for each
branch you want to work with. Just clone the repository multiple times and
keep each clone on a different branch. You have to do cherry-picks between
local branches of the same clone, but that shouldn't even be a noticeable
distinction at the local clone level.

Note that if you do this, you will want to use a more specific pull syntax
to keep those other clones updated. git-pull origin devel:devel, etc.

> It is confusing. Mainly in sm-commits, what is a/ what is b/ ?
> Stable-rc? Which one?

In the commmits they're diffs between the previous version and the new
version. They're all relative to the branch that was modified, they aren't
cross-branch diffs.

> > It's been suggested before, and it's certainly doable, but the typical
> > response is that our HISTORY
>
> It is not problem only of our HISTORY files.
> What about example with DETAILS file
> https://lists.ibiblio.org/sympa/arc/sm-commit/2006-July/004801.html ?

It shows up more often on the history files because of the specific way in
which RCS' /usr/bin/merge makes bad assumptions, but yes, it shows up
elsewhere as well. The fix for this would be general in nature.

> What about my last commit
> https://lists.ibiblio.org/sympa/arc/sm-commit/2006-July/005030.html ?
> Is it normal? It is really confusing.

I'm going to look at that one in a minute.

> And if you want to know what I am missing in our Git Guide:
> "$ git clone http://scm.sourcemage.org/smgl/grimoire.git grimoire"
> create only "devel, master, origin, stable-0.3, stable-rc-0.4" branches.
> How to get stable-0.4?

This is mentioned in the guide but in a different context. Anyway you
want:

git fetch origin stable-0.4:stable-0.4

This will get the stable-0.4 branch from the URL defined in the
.git/remotes/origin file and tie it to a local branch called stable-0.4.
It will also add a Pull line for it to the .git/remotes/origin file so it
will be included in future fetches you do.

You can also just add a Pull line for it to .git/remotes/origin and then do
a fetch and it will be brought down. You want to get familiar with
.git/remotes/origin, it's the config file that says which remote branches
you want to track and where to put them.

> By "git pull -s ours http://scm.sourcemage.org/smgl/grimoire.git
> stable-0.4:stable-0.4"?

Use the above instead. You don't want any merging against the current
branch when you fetch a new branch, so you don't want pull.

> Why "git pull" updates only old branches but not new stable-0.4?

Because typical git use cases haven't wanted this before. This is another
one Arwed's done some work on, to make git-fetch have an option to sync the
list of branches against upstream automatically. According to him it's not
hard; again, he probably just needs time to get it in a distributable state
and hand it out.

> How to remove "stable-0.3" branch? I do not like it I want only new
> stable-0.4.
> I removed it by "git branch -D stable-0.3" and after "git pull" it is back.

Upstream branches are defined in .git/remotes/ and tell git what local
branches to fetch from upstream and create locally if necessary.

Local branches are defined by pointers under .git/refs/heads/

git branch -D <branch> removes the local branch pointer under
.git/refs/heads, but it doesn't do anything to the remotes/ file, so the
next time you pull or fetch it's going to recreate it locally. To get rid
of it entirely locally, remove it from the remotes/ file as well.

> It is something like "p4 edit" in git to inform or to be informed
> someone is working on this spell?

git doesn't have advisory locks, no. They make very little sense given all
the branching options available, but if people really think we need it we
could look into it.

> And so on ...
> Of course I am only novice in git.

Attachment: pgp5I4K3lkJ2Z.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page