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: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git feedback
  • Date: Fri, 28 Jul 2006 22:14:49 +0200

On Fri, Jul 28, 2006 at 12:08:53PM -0500, Jeremy Blosser wrote:
> 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.

p4 is one of the best SCMs I ever worked with and I was really happy
with it technically. The real issues I had with it was that quite some
stuff was very slow because it needs a lot of communication with the
server (e.g. big diffs).

> > 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.
>
[...]
> > 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).

There are two different kinds of integrations, one is the real git style
one, one is an adaptation of the p4 integration. You can cherry-pick all
changes that made up the version you want to integrate. With more
frequent releases of the different branches, this should get easier all
the time, as it will need less and less cherry-picks. The other way of
integrating is to essentially just get the directory you want to
integrate from the other branch and make that the new state of your
current branch. I posted the commands to do that several times already,
when I find some time I'll make a script from it.

[...]
> > 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.

Merging in perforce was far from perfect too, but it was fitting our
work model a little bit better. There definitely is the possibility to
make the merging work better for us due to git just using external
tools, but all I did in that area was a proof-of-concept so far.

[...]
> > 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.

I'm attaching my git-update-branches script. It gets all branches
existing on the remote and pulls them, setting up a Pull line for future
updates. It's a very simple quick-hack, so don't expect it to be too
smart, but it worked fine for me to update my clone after the new stable
branches were created.

[...]
> > 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.

I don't really see a need for it. There were very few cases I remember
in p4 where the notice about other people having files opened for edit
kept me from doing duplicate work. Usually it was different work on the
same files and all the notice did was make me ask on irc why the files
were opened ...

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page