* Git Vs. Svn for a project which *must* distribute binaries too.
From: Bryan Childs @ 2007-06-04 11:48 UTC (permalink / raw)
To: git
Hello git users / maintainers / fans,
My fellow projecteers and I watched a presentation given by Linus
Torvalds on the advantages of git given at a google questions session
sometime recently.
Our project, www.rockbox.org, an open source firmware replacement
project for digital audio players currently makes use of subversion
for it's source code management system, but Linus's eloquent (though
sometimes rather blunt) speech has made us question whether git is
perhaps a better solution for us.
On the whole, we like a lot of the features it offers but, we have a
couple of issues which we've discussed, and so far have failed to come
up with a decent resolution for them.
1) Due to the nature of our project, with multiple architectures
supported, we strive to provide a binary build of our software with
every commit to the subversion repository. This is so that we can
provide a working firmware for the majority of our users that don't
have the necessary know-how for cross-compiling and so forth.
2) Unlike the Linux Kernel, which Linus uses as a prime example of
something git is very useful for, the Rockbox project has no central
figurehead for anyone to consider as owning the "master" repository
from which to build the "current" version of the Rockbox firmware for
any given target.
3) With a central repository, for which we have a limited number of
individuals having commit access, it's easy for us to automate a build
based on each commit the repository receives.
Given these three points, we wonder how we'd best achieve the same
using git. As far as we can make out we'd need to appoint someone as a
maintainer for a master repository whose job it is to co-ordinate
pulls from people based on when they've made changes we wish to
include in the latest version of our software. This sounds like a time
consuming role for a project which is only staffed by volunteers.
Can anyone offer any insights for us here?
Bryan
^ permalink raw reply
* [PATCH] Makefile: Remove git-merge-base from PROGRAMS.
From: Johannes Sixt @ 2007-06-04 11:53 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
git-merge-base is a builtin.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 78cd36a..b8ffc82 100644
--- a/Makefile
+++ b/Makefile
@@ -238,7 +238,6 @@ PROGRAMS = \
git-convert-objects$X git-fetch-pack$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-fast-import$X \
- git-merge-base$X \
git-daemon$X \
git-merge-index$X git-mktag$X git-mktree$X git-patch-id$X \
git-peek-remote$X git-receive-pack$X \
--
1.5.2.1.114.gc6c36
^ permalink raw reply related
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Julian Phillips @ 2007-06-04 11:56 UTC (permalink / raw)
To: Bryan Childs; +Cc: git
In-Reply-To: <5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
> 2) Unlike the Linux Kernel, which Linus uses as a prime example of
> something git is very useful for, the Rockbox project has no central
> figurehead for anyone to consider as owning the "master" repository
> from which to build the "current" version of the Rockbox firmware for
> any given target.
>
> 3) With a central repository, for which we have a limited number of
> individuals having commit access, it's easy for us to automate a build
> based on each commit the repository receives.
>
> Given these three points, we wonder how we'd best achieve the same
> using git. As far as we can make out we'd need to appoint someone as a
> maintainer for a master repository whose job it is to co-ordinate
> pulls from people based on when they've made changes we wish to
> include in the latest version of our software. This sounds like a time
> consuming role for a project which is only staffed by volunteers.
You can setup git to work in a centralised style if you wish.
See http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
--
Julian
---
If reporters don't know that truth is plural, they ought to be lawyers.
-- Tom Wicker
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Andy Parkins @ 2007-06-04 12:09 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <e5bfff550706040420j22852e4btc41a88c79bffc49f@mail.gmail.com>
On Monday 2007 June 04, Marco Costalba wrote:
> The tabbed widget is here to stay. I do not plan to remove it. But the
> tabbed widget is also slower then a well behaved scroll swicth or link
> clicking.
Ah - I've not explained myself clearly. What I mean is _another_ tab widget,
instead of the scroll-to-switch. It can't possibly be slower, as it's the
same amount of work for Qt... So it would look like this (excuse rubbish
ASCII art):
+-----------------------------+
| |
| <rev list here> |
| |
| |
+-----------------------------+
| Log | Patch | |
+-----| |---------------+
| <diff goes here> |
| |
+-----------------------------|
At the moment, you have a label in the top left of the text window that is
mouse-clicked to change mode; I'm suggesting replacing that with a tab widget
as above where you mouse click to change mode. It's no more operations,
doesn't include a strange floating label and is a more standard and
recognisable user interface.
If you still wanted up and down buttons, they could very easily go to the far
right of the log|patch tabs, similar to the "close" button on the top tabs.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* 1.5.3 release notes nit
From: Johannes Sixt @ 2007-06-04 12:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Says Documentation/RelNotes-1.5.3.txt:
> - core.legacyheaders is no more, although we still can read
> objects created in a new loose object format.
Someone who doesn't know the background might mistake the 'new' as a
typo, reading it as 'old' - since usually legacy stuff is removed, not
reinstantiated.
Better perhaps:
- core.legacyheaders is no more, the legacy format of loose objects
is again "the" format; the previously "new" format is not used
anymore, although we still can read objects created in that format.
-- Hannes
^ permalink raw reply
* Git pull/merge question
From: Pelle Svensson @ 2007-06-04 12:51 UTC (permalink / raw)
To: git
Hi,
I used to pull using version 1.4.x from Linus tree but with version
1.5.x I can't get
it upp and running in the same way.
git-pull complains about:
'No merge candidate founde because value of config option" branch.my.merge
I tried git-config --add ... with orgin and master but no luck.
I also seems to be stuck on version 2.6.21 on my branch. First pull
picked up a lot of changes but did no merge it into my tree.
What should I do to get git-pull working and at the same time merge
the stuff and roll my branch forward to the latest version?
git-pull -> Warns about merge candidate
git-pull . master -> Says up to date
git-status -> Only list 3 files not commited due to changes I did.
/Pelle
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Theodore Tso @ 2007-06-04 13:18 UTC (permalink / raw)
To: Bryan Childs; +Cc: git
In-Reply-To: <5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com>
On Mon, Jun 04, 2007 at 12:48:17PM +0100, Bryan Childs wrote:
> 2) Unlike the Linux Kernel, which Linus uses as a prime example of
> something git is very useful for, the Rockbox project has no central
> figurehead for anyone to consider as owning the "master" repository
> from which to build the "current" version of the Rockbox firmware for
> any given target.
> 3) With a central repository, for which we have a limited number of
> individuals having commit access, it's easy for us to automate a build
> based on each commit the repository receives.
You might want to take a look at http://repo.or.cz for an example of
how you can have a limited number of trusted inidividuals with commit
access. As has been said before, <SCM> is not a substitute for
communication, and if you have multiple people who can commit into a
repository, you had better make sure those trusted individuals with
commit access are talking to each other.
There are some folks who have created hooks to do more fine-grained
access control systems, if you want to replicate SVN's ability to
control who can commit to which branch.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH] Show html help with git-help --html
From: Nguyen Thai Ngoc Duy @ 2007-06-04 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps4cjg1w.fsf@assigned-by-dhcp.cox.net>
On 6/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 3d8f03d..2ec8545 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -261,6 +261,18 @@ core.excludeFile::
> > ...
> > +core.htmlprogram::
> > + Specify the program used to open html help files when 'git-help'
> > + is called with option --html or core.help is other than 'man'.
> > + By default, xdg-open will be used.
>
> Is the program's calling convention something that needs to be
> customizable for this to be useful?
At first I thought xdg-open would be flexible enough for most Linux
systems because it will choose the best browser you have. But I now
recall that Git does not only run on Linux. Will make it a parameter
in config.mak.in
>
> > diff --git a/Makefile b/Makefile
> > index cac0a4a..43e0d15 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -145,6 +145,7 @@ prefix = $(HOME)
> > bindir = $(prefix)/bin
> > gitexecdir = $(bindir)
> > sharedir = $(prefix)/share/
> > +htmldir = $(sharedir)/html/
> > template_dir = $(sharedir)/git-core/templates/
> > ifeq ($(prefix),/usr)
> > sysconfdir = /etc
>
> Is it customary to have HTMLized documentation material for
> different packages all together in a single .../share/html/
> directory, like manpages are placed in share/man/man1/
> directory? I somehow had an impression that a layout to have
> html directory per package (i.e. share/doc/$pkg/html/) was more
> common. I dunno.
The default value is not really useful. I would leave that for
distribution package mantainers to decide proper location because they
have to install html files separately anyway (at least in Gentoo).
However it's not convenient for compiling-from-source users. Will redo
the patch and add rules to install html files also.
>
> > diff --git a/help.c b/help.c
> > index 6a9af4d..e3e705b 100644
> > --- a/help.c
> > +++ b/help.c
> > @@ -183,6 +187,36 @@ static void show_man_page(const char *git_cmd)
> > execlp("man", "man", page, NULL);
> > }
> >
> > +static void show_html_page(const char *git_cmd)
> > +{
> > + const char *html_dir;
> > + int i,len,ret;
> > + char *p;
> > +
> > + html_dir = HTML_DIR;
> > + if (!html_help_program)
> > + html_help_program = "xdg-open";
> > +
> > + /* html_help_program space html_dir git- git_cmd .html */
> > + len = strlen(html_help_program) + 1 + strlen(html_dir) + 4 + strlen(git_cmd) + 5;
> > + p = xmalloc(len + 1);
> > +
> > + strcpy(p, html_help_program);
> > + strcat(p," ");
> > + strcat(p,html_dir);
> > + if (prefixcmp(git_cmd, "git"))
> > + strcat(p,"git-");
> > + strcat(p,git_cmd);
> > + strcat(p,".html");
> > +
> > + ret = system(p);
>
> This is sloppy in the presense of potentially unsafe characters...
I personally think users will not shoot themselves with "git help
--html ';rm -rf'" but again scripts can. Thank you for pointing out.
Will add check for file existence before calling system().
--
Duy
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Rogan Dawes @ 2007-06-04 13:29 UTC (permalink / raw)
To: Rogan Dawes, Martin Waitz, Linus Torvalds, git
In-Reply-To: <20070604102037.GB7758@.intersec.eu>
Pierre Habouzit wrote:
> For that part, as the "right" way to deal with bugs is IMHO through
> mail, my heart balance between a ${bug_sha1}.mbox or a ${bug_sha1}/
> maildir. The former avoids to bloat the files, the latter avoids
> painless merges (chance to have a conflict in the comments is near zero
> through maildirs) but would see 3 directories (cur new tmp) be spoiled.
One downside of using maildir (which I agree has several desirable
properties), is that the filenames include characters that are illegal
on various platforms (specifically ":" in Windows). This is quite
unfortunate.
> In addition to that a ${bug_sha1}.status (or alike) flat file would be
> needed to store metadata about the bug (who it is assigned to, which
> module/category it's in, ...).
>
> Note that mails are mostly textual, flat, and allow attachments,
> signature, whatever... and are IMHO very well suited for a bugtracking
> use.
I think it would be very neat to be able to use the built-in mechanisms
in mail clients for threading, etc, and handling attachments, sorting
and filtering. Tracking things like who a bug is assigned to wouldn't
work too well, but I imagine that many kernel developers have fine tuned
their email clients to such a degree that it wouldn't be impossible :-)
I'm not familiar with how messages move around in {cur,new,tmp}, but I
suspect that if we simply make a convention that all mails are created
as "read", then we won't have clashes between developers holding some
bugs as unread, etc while others have already read them.
>> Closed bugs would be deleted from the filesystem, but would obviously be
>> available via the history.
>
> IMHO we should keep the .status file for closed bugs, and use the
> history to lookup for the content of the mail{box,dir} if needed.
Maybe.
> Merging is also easy, it's just a matter of merging the "mails".
Yes.
> Cloning bugs is just a matter of copying a report.
>
> etc… every usual BTS operation is mapped trivially on FS/git
> operations. And that's not really surprising, as bugs are contents, and
> git actually tracks contents right :)
>
>> Indexes or categories could be implemented by means of symlinks/symrefs
>> in a different set of "index directories". e.g.
>>
>> /categories/drivers/deadbeef -> ../../bugs/de/adbeef
>> /assignedto/joe@example.org/deadbeef -> ../../bugs/de/adbeef
>>
>> or similar. These might not be strictly necessary, since all that
>> information will be in the report anyway. Perhaps the indexes would be
>> stored simply as cached data, and rebuilt if out of date.
>
> IMHO that should be in a cache, all valuable information would be in
> the *.status files anyway, it's just a way to index them. FWIW I think
> this should be dealt with in a higher level tool. What is needed first
> for the developer is a way to deal with a bug he knows is here. Dealing
> with large collection of bugs must be built on top of that, and is easy
> to keep up to date through proper hooks.
Yes, hooks might be the right approach for this.
> IMHO the sole features it should provide and design specifically are:
> * the efficient linking with the rest of the repository (through
> annotations, decorations, or whichever implementation) ;
> * the storage backend, in a supple enough way to allow usual
> operations (threading, answers, attachments, use through mail or
> {web,G}ui, ...)
> * versioning of the BTS datas.
> The rest can just be built on top of that.
Agreed.
Rogan
^ permalink raw reply
* Re: [PATCH 1/2] Changed rebasing safety check to look for reachability of stack base (gna bug #9181).
From: David Kågedal @ 2007-06-04 13:42 UTC (permalink / raw)
To: git
In-Reply-To: <20070603134152.1681.82748.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> --- a/stgit/commands/pull.py
> +++ b/stgit/commands/pull.py
> @@ -77,16 +77,12 @@ def func(parser, options, args):
> check_conflicts()
> check_head_top_equal()
>
> - if policy == 'pull':
> - must_rebase = 0
> - elif policy == 'fetch-rebase':
> - must_rebase = 1
> - elif policy == 'rebase':
> - must_rebase = 1
> - else:
> + if (policy != 'pull') \
> + and (policy != 'fetch-rebase') \
> + and (policy != 'rebase'):
> raise GitConfigException, 'Unsupported pull-policy "%s"' % policy
Minor nit: I think this is much more clearly written as
if policy not in ('pull', 'fetch-rebase', 'rebase'):
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Alex Riesen @ 2007-06-04 14:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <7vvee4jh24.fsf@assigned-by-dhcp.cox.net>
On 6/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Updated. BTW, where does "no $(call) in Makefile" came from?
> > It could simplify the thing a lot
>
> Probably, but first let's make it "work right" while not
> introducing new stuff.
>
Just looked for the reasons, which appear to be there:
commit 39c015c556f285106931e0500f301de462b0e46e
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Sat Feb 18 12:40:22 2006 +0100
Fixes for ancient versions of GNU make
Some versions of GNU make do not understand $(call), and have problems to
interpret rules like this:
some_target: CFLAGS += -Dsome=defs
[jc: simplified substitution a bit. ]
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I trust Johannes to have such a make, never seen it myself, though.
> > install: all
> > $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'
> > $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
>
> I found Shawn's "DEST = $this_directory" quite decent. Forgot
> to port it?
>
Race condition. Hit the send button before reading his patch and
the related discussion. Besides, now I find it is already too much
cruft just to print a directory. Didn't want to make it pretty, just
needed some readability on screen. Still think the errors of
(eventually) failing install would be enough.
Using $(call) would allow to generalize that, BTW.
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Johannes Schindelin @ 2007-06-04 14:58 UTC (permalink / raw)
To: Bryan Childs; +Cc: git
In-Reply-To: <5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com>
Hi,
On Mon, 4 Jun 2007, Bryan Childs wrote:
> 1) Due to the nature of our project, with multiple architectures
> supported, we strive to provide a binary build of our software with
> every commit to the subversion repository.
Git has no problems with binaries. Actually, one could argue that it has
less problems with binary files than with text files, since it only
recently acquired the capability (disabled by default) to transcribe
certain files into the CR/LF line ending some Windows programs still
insist on.
As for checking in binaries, you even could set up a post-commit hook,
which builds the binary, and checks it into a separate branch...
Ciao,
Dscho
^ permalink raw reply
* Re: How to use git-svn to clone from a mirror?
From: Raja R Harinath @ 2007-06-04 15:11 UTC (permalink / raw)
To: git
In-Reply-To: <86hcpq8qjz.fsf@lola.quinscape.zz>
Hi,
David Kastrup <dak@gnu.org> writes:
> Hi, I seem to be too stupid to get this right.
>
> I have used something like
>
> git-svn clone -T trunk -b branches -t tags file:///tmp/rsync-mirror
>
> to clone an rsync mirror of an SVN repository. Now I want to have
> fetch revert to pulling from the upstream repository in future.
> However, if I change the respective line in .git/config to
> svn://the.svn.link/whatever, git-rebase will fetch the right updates,
> but then says that it can't work with the objects in the git
> repository.
>
> Changing the config back will make git-rebase -l work.
>
> So what would be the right procedure to shift the SVN source from an
> rsync mirror to the original, without git-svn breaking?
I think you'll have to
-------------8<------------
# remove stored revision db, since we're going to change all the commit ids
rm .git/svn/git-svn/.rev_db.*
# rewrite git-svn-id: lines
cg-admin-rewritehist \
--msg-filter \
'sed "s,file:///tmp/rsync-mirror,svn://the.svn.link/whatever,"'
# recreate new revision db, and fetch updates, if any
git-svn rebase
-------------8<------------
- Hari
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds @ 2007-06-04 15:20 UTC (permalink / raw)
To: Bryan Childs; +Cc: git
In-Reply-To: <5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
>
> 1) Due to the nature of our project, with multiple architectures
> supported, we strive to provide a binary build of our software with
> every commit to the subversion repository. This is so that we can
> provide a working firmware for the majority of our users that don't
> have the necessary know-how for cross-compiling and so forth.
Git has no problems with binaries, but I _really_ I hope that you don't
actually want to check these binaries into the repository? You could do
that, and the git delta algorithm might even be able to compress the
binaries against each other, but it could still be pretty nasty.
And by "pretty nasty" I don't mean that git won't be able to handle it: I
suspect it's no worse from a disk size perspective than SVN. But since
git is distributed, it means that everybody who fetches it will get the
whole archive with whole history - it means that cloning the result is
going to be really painful with tons of old binaries that nobody really
cares about beign pushed around.
So I *hope* that you want to just have automated build machinery that
builds the binaries to a *separate* location? You could use git to archive
them, and you can obviously (and easily) name the resulting binary blobs
by the versions in the source tree, but I'm just saying that trying to
track the binaries from within the same git repository as the source code
is less than optimal.
> 2) Unlike the Linux Kernel, which Linus uses as a prime example of
> something git is very useful for, the Rockbox project has no central
> figurehead for anyone to consider as owning the "master" repository
> from which to build the "current" version of the Rockbox firmware for
> any given target.
The kernel is really kind of odd in that it has just a single maintainer.
That's usually the case only for much smaller projects.
And no, git is not at all exclusively *designed* for that situation,
although it is arguably one situation that git works really well for.
There is nothing to say that you cannot have shared repositories that are
writably by multiple users. Anything that works for a single person works
equally well for a "group of people" that all write to the same central
git repo. It ends up not being how the kernel does things (not because of
git, but because it's not how I've ever worked), but the kernel situation
really _is_ pretty unusual.
So git makes everybody have their own repository in order to commit, but
you can (and some people do) just view that as your "CVS working tree",
and every time you commit, you end up pushing to some central repository
that is writable by the "core group" that has commit access.
In *practice*, I suspect that once you get used to the git model, you'd
actually end up with a hybrid scheme, where you might have a *smaller*
core group with commit access to the central repository (in git, it
wouldn't be "commit access", it would really be "ability to push", but
that's a technical difference ratehr than anything conceptually huge), and
members in that core group end up pulling from others.
But that would literally be once you have gotten used to the git model,
and you can start out just totally emulating the old CVS/SVN model with a
single central repository.
> 3) With a central repository, for which we have a limited number of
> individuals having commit access, it's easy for us to automate a build
> based on each commit the repository receives.
.. and that's exactly how you'd do it with git too. You wouldn't have a
"commit trigger", but you'd have a "receive trigger", which triggers
whenever somebody pushes to the central repository.
And that does mean that a developer might do a series of _five_ commits
locally on his own machine, and they are totally invisible to everybody
until he pushes to the central repository: and then the build will build
just the top-most end result commit. So you'd not necessarily have a
binary for _each_ commit, but:
- you could (if you really wanted to) actually force people to always
send just one commit at a time. You could even enforce that in the
pre-receive triggers, so that people *cannot* push multiple commits at
a time.
Quite frankly, I really don't think you want to go this way. I think
you want to perhaps _encourage_ people to send just one commit at a
time, but the much better model is the other choice:
- realize that the git model tends to encourage many small commits
(because you *can* make commits without impacting others), so when you
fix something, or add a new feature, with git, you can do it as many
small steps, and then only "push" when it's ready.
IOW, if you encourage people to do small step-wise changes, you
probably don't even *want* a build for each commit, you really want a
build for the case where "my feature is now ready, I'll push". So you'd
effectively get one build not per commit, but per "publication point".
But anyway, it really boils down to: you *can* use a distributed
development model to emulate a totally centralized situation (put another
way: "centralized" is just one very trivial special case of
"distributed"), but I suspect that while you might want to start out
trying to change as little as possible in your development model, I
equally strongly suspect that you'll find out that the distributed nature
makes _some_ changes to the model very natural, and you'll end up with
more of a hybrid setup: aspects of a centralized model, but with
distributed elements.
Linus
^ permalink raw reply
* Re: StGIT munged path on refresh
From: Catalin Marinas @ 2007-06-04 15:35 UTC (permalink / raw)
To: Andy Green; +Cc: git
In-Reply-To: <4663EB48.3020302@warmcat.com>
On 04/06/07, Andy Green <andy@warmcat.com> wrote:
> Andy Green wrote:
>
> > I have been using quilt with some success and now I am trying to migrate
> > to stgit. I can get started okay with stg init and stg new "mypatch",
>
> Sorry for the noise -- I found this is a FAQ, you currently have to do
> the refresh at the top of the tree, unlike in quilt.
Fixing StGIT to run correctly in subdirectories is on my to-do list,
only that I haven't had time to look at it yet.
--
Catalin
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Bryan Childs @ 2007-06-04 15:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706040755560.23741@woody.linux-foundation.org>
On 6/4/07, Linus Torvalds < [send email to
torvalds@linux-foundation.org via gmail]
torvalds@linux-foundation.org> wrote:
> So I *hope* that you want to just have automated build machinery that
> builds the binaries to a *separate* location? You could use git to archive
> them, and you can obviously (and easily) name the resulting binary blobs
> by the versions in the source tree, but I'm just saying that trying to
> track the binaries from within the same git repository as the source code
> is less than optimal.
Oh lord no - I never meant to imply that we'd be checking those
binaries in, I just meant to hi-light that we need a central
repository to build those binaries from - otherwise we'd end up with a
selection of binaries for our users to download which contain a bunch
of different features if they were built from a combination of
repositories. I know you think everyone else is a moron, but we're not
quite dumb enough to think maintaining binaries in a repository is a
good idea :)
> In *practice*, I suspect that once you get used to the git model, you'd
> actually end up with a hybrid scheme, where you might have a *smaller*
> core group with commit access to the central repository (in git, it
> wouldn't be "commit access", it would really be "ability to push", but
> that's a technical difference rather than anything conceptually huge), and
> members in that core group end up pulling from others.
This sounds like what we eventually came up with. I'm not sure how
soon we'll make a switch to a git repository, but when we do, this
seems to be the best model for the conversion in the short term, and
perhaps in the long term too.
> .. and that's exactly how you'd do it with git too. You wouldn't have a
> "commit trigger", but you'd have a "receive trigger", which triggers
> whenever somebody pushes to the central repository.
Yes, after I'd sent my email this morning I found you could do pushes
as well as pulls. That'll teach me to RTFM properly next time.
> - realize that the git model tends to encourage many small commits
> (because you *can* make commits without impacting others), so when you
> fix something, or add a new feature, with git, you can do it as many
> small steps, and then only "push" when it's ready.
This is what I personally was trying to advocate in our discussion -
but I'm not sure everyone quite understood it. Hopefully your
explanation will do a better job :)
> IOW, if you encourage people to do small step-wise changes, you
> probably don't even *want* a build for each commit, you really want a
> build for the case where "my feature is now ready, I'll push". So you'd
> effectively get one build not per commit, but per "publication point".
Absolutely.
> Linus
Thanks for your time (and everyone else who replied) - it's very much
appreciated!
Bryan
^ permalink raw reply
* Re: [RFH] QGit: how to cram a patch in a crowded screen
From: Jan Hudec @ 2007-06-04 15:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: Andy Parkins, git, Pavel Roskin
In-Reply-To: <e5bfff550706020437i3f54d459rdbe9070fe03a28c9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
On Sat, Jun 02, 2007 at 13:37:03 +0200, Marco Costalba wrote:
> On 5/31/07, Jan Hudec <bulb@ucw.cz> wrote:
> >
> >I have to say that I like the gitk way better. There is the issue of
> >over-scrolling. I often want to quickly scan through the diff, so I scroll
> >pretty quickly and it switches over when I reach the end.
> >
>
> Ok. "Smart Browsing" ;-) patch series pushed to qgit4.
>
> Refer to patches logs for a little documentation.
>
> Please give feedback if this patch series it's not smart enough for you.
I think it feels quite good. And leaves room for additional pages. Ie. merge
could have the "interesting" (--cc) diff and diff against each parent in
turn.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Support environment variables in config file
From: Johannes Schindelin @ 2007-06-04 15:57 UTC (permalink / raw)
To: Martin Waitz; +Cc: Matthias Lederhofer, git
In-Reply-To: <20070604072707.GE16637@admingilde.org>
Hi,
On Mon, 4 Jun 2007, Martin Waitz wrote:
> Do you think the approach is ok?
I actually would like it more if the calling program did the interpolation
itself.
So, for example if you want a script to access whatever.my.url, and want
to allow to interpolate any environment variable, why not
url=$(eval $(git config whatever.my.url))
I am just hesitant to change the existing behaviour, and possibly
introduce weird breakages. (There could even be some unwanted env leakages
in programs like gitweb...)
Ciao,
Dscho
^ permalink raw reply
* Re: Improved git-gui blame viewer
From: Alex Riesen @ 2007-06-04 16:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Linus Torvalds
In-Reply-To: <20070602041723.GD7044@spearce.org>
On 6/2/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> I finally got the git-gui code to the point where cleaning up the
> user interface was possible without sending myself to the nut house.
>
Very-very nice :) Does not seem to save sizes and positions of
blame and file browser windows, though. It did before, I believe
in .git/config.
BTW, saving windows positions in .git/config was scary: I
considered it user domain (yes, I _am_ afraid of using
git-config too).
Maybe it could be something like either ~/.git-gui or .git/guiconfig?
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Johannes Schindelin @ 2007-06-04 16:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4663BCDA.F1BADDD8@eudaptics.com>
Hi,
On Mon, 4 Jun 2007, Johannes Sixt wrote:
> [...] any simple command like
>
> git filter-branch -k orgin/master origin/next new-next
>
> of your git.git clone will fail with the "assertion failed". (I haven't
> tried your script, yet, but cg-admin-rewritehist fails.)
As you mentioned yourself, you should say "-s origin/next".
cg-admin-rewritehist will only rewrite the current branch (since cogito
started out as one-branch-per-repo).
> I propose that you just get rid of the "seed" stance and don't fail if a
> commit cannot be mapped - just use it unchanged (don't forget to adjust
> the map() function, too).
It is as much for debug reasons as for consistency, so I'd rather keep it.
One more safety valve for catching bugs.
> Then you can get rid of -r and use -k to specify everything you want
> under "--not" in the rev-list.
Actually, -r is quite useful. It means "start rewriting with this commit",
and saying "--not <commit>^" is _not_ the same when <commit> is a merge.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Marco Costalba @ 2007-06-04 16:15 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Pavel Roskin, Jan Hudec
In-Reply-To: <200706041309.54279.andyparkins@gmail.com>
On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Monday 2007 June 04, Marco Costalba wrote:
>
> > The tabbed widget is here to stay. I do not plan to remove it. But the
> > tabbed widget is also slower then a well behaved scroll swicth or link
> > clicking.
>
> Ah - I've not explained myself clearly. What I mean is _another_ tab widget,
> instead of the scroll-to-switch. It can't possibly be slower, as it's the
> same amount of work for Qt... So it would look like this (excuse rubbish
> ASCII art):
>
> +-----------------------------+
> | |
> | <rev list here> |
> | |
> | |
> +-----------------------------+
> | Log | Patch | |
> +-----| |---------------+
> | <diff goes here> |
> | |
> +-----------------------------|
>
> At the moment, you have a label in the top left of the text window that is
> mouse-clicked to change mode; I'm suggesting replacing that with a tab widget
> as above where you mouse click to change mode. It's no more operations,
> doesn't include a strange floating label and is a more standard and
> recognisable user interface.
>
> If you still wanted up and down buttons, they could very easily go to the far
> right of the log|patch tabs, similar to the "close" button on the top tabs.
>
>
Andy,
I have to say that I really like your idea!
Now I really don't know what to do! :-)
Probably I will create a new branch called andy_gui where I'll
implement your idea, while continue to refine the current approach. As
example one enanchment I would like to implement is to keep the labels
normally hidden and show the top (bottom) one only when user scrolls
to the top (bottom) boundary of the view so that we could resolve two
issues: knowing when a scrolling action will cause a switch (i.e. only
when the corresponding label is visible) and do not have the arrows
when not needed.
Another enanchment could be to have only one link per label instead of
two and right clicking on it to show a popup menu with available
alternatives.
Of course at the end there will remain only one! The winner will be,
of course, chosen by a democratic polling among us.
Comments?
Thanks
Marco
P.S: Your approach is simple and good, the only downside is the screen
estate taken by the tab bar. But I agree it's absolutly not a biggie.
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds @ 2007-06-04 16:23 UTC (permalink / raw)
To: Bryan Childs; +Cc: git
In-Reply-To: <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
>
> Oh lord no - I never meant to imply that we'd be checking those
> binaries in, I just meant to hi-light that we need a central
> repository to build those binaries from
Heh. I get worried (and judging from other responses, I wasn't the only
one) when people start talking about generated binaries and SCM's.
Because people _have_ traditionally done things like commit the generated
files too.
But if it's just an automated build server, everything is good. That's
trivial to do.
> > In *practice*, I suspect that once you get used to the git model, you'd
> > actually end up with a hybrid scheme, where you might have a *smaller*
> > core group with commit access to the central repository (in git, it
> > wouldn't be "commit access", it would really be "ability to push", but
> > that's a technical difference rather than anything conceptually huge), and
> > members in that core group end up pulling from others.
>
> This sounds like what we eventually came up with. I'm not sure how
> soon we'll make a switch to a git repository, but when we do, this
> seems to be the best model for the conversion in the short term, and
> perhaps in the long term too.
Yes. As mentioned, the kernel model of having just one person push is
actually fairly rare.
When you have multiple people pushing, you have issues that I never have,
but that you've already seen with CVS/SVN, for all the same reasons: you
may need to merge the changes that others have done while you were working
on yours.
However, the git "push" model is *different* from the CVS/SVN "commit"
model.
In CVS/SVN, if you want to commit, and somebody else has done updates to
the central repository, the "cvs commit" phase will obviously tell you
that you're not up-to-date, and you cannot commit at all. So you end up
doing a "cvs update -d" equivalent to first update your tree, then you
have to resolve any conflicts, and then you can try to commit again.
In git, this is technically very different, yet similar. Since you can
always commit to your *local* repository, when you do a "git commit",
you'll never have any conflicts at all, because there is no conflicting
work!
But the conflicts happen when you then do a "git push" to send out your
commit(s) to the central repository. If nobody else has done any changes,
at that point, you'll get exactly the same kind of situation as when you
do a CVS commit, and the server will tell you that you're not up-to-date,
and will refuse to take your push.
(The message is different: git will tell you that you try to push a commit
that is not a "strict superset" of what the central repository has).
So when that happens with git, you actually have two different options:
- you can do "git pull" to merge the central changes, and in that case
you get the exact same kinds of conflict markers for any conflicting
code that you would have gotten for "cvs update"
This is how most people would probably use it, and it's the simplest
one, where you get very traditional commit conflict markers, fix it up,
and commit the merge.
However, it does end up making the history explicitly showing the
parallelism that happened, and while that is *correct* and can be very
useful, sometimes it means that especially if you've done just trivial
changes, you might want to take an alternate approach that "linearizes"
the history and makes it appear linear instead of parallel:
- instead of doing a "git pull" that merges the two branches (your work,
and the work that happened by somebody else in the central repo while
you did it), you *may* also just want to do a "git fetch" to fetch the
changes from the central repo, and then do "git rebase origin" to
linearize the work you did on _top_ of those central repo one (so that
it no longer looks like a branch, and looks linear)
In the "git rebase" case, you'll effectively merge your commits one at
a time, and you may thus have to fix up *multiple* conflicts. So it's
potentially more work, but it results in a simpler history if you want
it.
Regardless of how you ended up sorting out the fact that you had parallel
development, once you've resolved it, you do a "git push" again, and now
the stuff you're pushing is a proper superset of what the central
repository had, so it will happily push it out.
(Of course, the exact same thing that can happen with CVS central
repositories can happen with git ones too: by the time you've resolved all
the differences and are ready to push them to the central one, somebody
else might have pushed *more*, and you may need to do another "update" ;)
> Yes, after I'd sent my email this morning I found you could do pushes
> as well as pulls. That'll teach me to RTFM properly next time.
I think we talk a lot more about pulls, because we have had more people
ask about them, and because more people tend to pull than to push.
The pull is also somewhat easier to explain. The pushing thing always has
to talk about resolving differences when different people have pushed, so
teaching people to push by necessity involves first teaching them about
merging (ie pull or rebase).
Also, "push" is also a bit more interesting to explain, because a "push"
won't update the working tree on the other end, so when you explain
pushing, you should also explain about "bare" repositories (which I didn't
do)), ie about having git repositories without any working tree associated
with them.
So there is a bit of a learning experience involved, but espeically if
some of the developers have seen git used in other environments (perhaps
not as developers, just as users), it shouldn't be *that* hard to pick up.
But there does seem to be a pretty big mental leap from the "centralized"
thing to the "distributed" thing - I just moved over so long ago that I
even have trouble understanding why people sometimes don't seem to find
the distributed model the only natural and sane thing to do.
(It really does seem to be one of those "aha!" moments. People think
distributed just adds a lot of complexity, and it takes a "Oh, *THAT* is
how it works" kind of enlightenment to just switch your brain over, and I
guarantee that once that moment on enlightenment hits, you'll never go
back, but I cannot guarantee that that moment will happen for all
developers ;)
Linus
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Johannes Sixt @ 2007-06-04 16:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706041711500.4046@racer.site>
Johannes Schindelin wrote:
>
> Hi,
>
> On Mon, 4 Jun 2007, Johannes Sixt wrote:
> > I propose that you just get rid of the "seed" stance and don't fail if a
> > commit cannot be mapped - just use it unchanged (don't forget to adjust
> > the map() function, too).
>
> It is as much for debug reasons as for consistency, so I'd rather keep it.
> One more safety valve for catching bugs.
>
> > Then you can get rid of -r and use -k to specify everything you want
> > under "--not" in the rev-list.
>
> Actually, -r is quite useful. It means "start rewriting with this commit",
> and saying "--not <commit>^" is _not_ the same when <commit> is a merge.
But this makes only sense if you have a linear history. Consider this
history, where you want to rewrite the commits that are only on branch
'next':
--A--B--C--D--E--F--G--H <- master
\ \ \ \ \ \ \ \
X--o--o--o--o--o--o--o--o <- next
How would you go about with the current calling convention? It's
unpractical to say the least:
git filter-branch -r X -k B -k C -k D ... -k H new-next
If you don't give all the -k, then you get the "assertion failed" error
because the parents B..H are not registered in the commit id map. This
is not something I'd like to try on a history like git.git's.
OTOH, rev-list can easily restrict the commits regardless of how many
merges there are in 'next':
git rev-list next --not master
Why not use its powers?
-- Hannes
^ permalink raw reply
* Does git-svn-id need repository path? (Re: How to use git-svn to clone from a mirror?)
From: Jan Hudec @ 2007-06-04 16:55 UTC (permalink / raw)
To: Raja R Harinath; +Cc: git
In-Reply-To: <85myzfsqji.fsf@blr-RHarinath.blr.novell.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Mon, Jun 04, 2007 at 20:41:29 +0530, Raja R Harinath wrote:
> -------------8<------------
> # remove stored revision db, since we're going to change all the commit ids
> rm .git/svn/git-svn/.rev_db.*
>
> # rewrite git-svn-id: lines
> cg-admin-rewritehist \
> --msg-filter \
> 'sed "s,file:///tmp/rsync-mirror,svn://the.svn.link/whatever,"'
>
> # recreate new revision db, and fetch updates, if any
> git-svn rebase
> -------------8<------------
Which leads me to a question. Should the url really be part of the
git-svn-id? A subversion repository is uniquely identified by it's uuid, so
the uuid + revno is a good identifier. Is it possible to change that now, or
is it necessary to keep the format now for backward compatibility?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Johannes Schindelin @ 2007-06-04 17:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <81b0412b0706040700s667afe5ap14a8343a9313ef60@mail.gmail.com>
Hi,
On Mon, 4 Jun 2007, Alex Riesen wrote:
> On 6/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > Updated. BTW, where does "no $(call) in Makefile" came from?
> > > It could simplify the thing a lot
> >
> > Probably, but first let's make it "work right" while not
> > introducing new stuff.
> >
>
> Just looked for the reasons, which appear to be there:
> commit 39c015c556f285106931e0500f301de462b0e46e
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Sat Feb 18 12:40:22 2006 +0100
>
> Fixes for ancient versions of GNU make
>
> Some versions of GNU make do not understand $(call), and have problems to
> interpret rules like this:
>
> some_target: CFLAGS += -Dsome=defs
>
> [jc: simplified substitution a bit. ]
>
> Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> I trust Johannes to have such a make, never seen it myself, though.
Yes. I no longer have access to that machine, but it was an SGI machine
running IRIX, and I had no root access, and I had a quota.
That is when I worked towards getting rid of Python (making the use of it
optional at first), and working with incompatible or sufficiently non-GNU
programs like old make, different sed, etc.
At the time I was really annoyed with the situation, especially since it
was _easy_ to stay compatible with them. I have little sympathy with
making things just a little simpler for John R. Developer, and
substantially harder for a lot of users.
So, are you sure you want to force everybody who wants to compile Git to
use a recent GNU make?
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox