* Re: [RFC] git integrated bugtracking
From: Johan Herland @ 2007-06-03 13:48 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Michael Poole
In-Reply-To: <20070603133109.GD14336@artemis>
On Sunday 03 June 2007, Pierre Habouzit wrote:
> On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:
> > Pierre Habouzit writes:
> >
> > > The other problem I see is that at the time a bug gets reported, the
> > > user knows it's found at a commit say 'X'. But it could in fact have
> > > been generated at a commit Y, with this pattern:
> > >
> > > --o---o---Y---o---o---o---o---X---o---o--> master
> > > \
> > > o---o---o---o---o---o--> branch B
> >
> > Mainly for that reason, I would suggest having it outside the code
> > base's namespace: probably a different root in the same $GIT_DIR, but
> > I can see people wanting to have a separate $GIT_DIR. If the database
> > tracks bugs by what commit(s) introduce or expose the bug -- at least
> > once that is known -- then you get nearly free tracking of which
> > branches have the bug without having to check out largely redundant
> > trees.
>
> Sure, but if it's completely out-of-tree, then cloning a repository
> don't allow you to get the bug databases with it for free. I mean it'd
> be great to have it somehow linked to the repository, but also I agree
> that not everybody wants to clone the whole bugs databases. So maybe it
> should just be in another shadow branch that annotates the devel ones.
> Hmmm I definitely need to read the git-note thread...
I guess I'm the one responsible for starting that git-note thread...
For the moment, I'm busy implementing some concepts that came out of that
discussion (refactoring tag objects and building some infrastructure needed
to support notes without the drawbacks present in my first version).
Hopefully I'll have a proof-of-concept ready before too long. In the
meantime I'll be happy to answer questions you might have.
Regarding the notes themselves, I thought about possibly using them as a
link between the repo and the bug tracker, with some glue code in between
for making the connections. I haven't thought about integrating them more
deeply into a bug tracker, but it might be worth thinking along those
lines, especially for the kind of system you're proposing.
Now, back to hacking...
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH 2/2] Test "stg rebase" after "stg commit"
From: Yann Dirson @ 2007-06-03 13:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070603133006.1681.1742.stgit@gandelf.nowhere.earth>
Two new tests for "stg rebase":
1. Try to rebase to a commit that is ahead of HEAD. This should
work, and does.
2. Try to commit a patch, and then rebase. This doesn't work,
because "stg rebase" aborts if orig-base != base, and "stg
commit" doesn't update orig-base. (It does work if "stg rebase"
is given the --force flag.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t2200-rebase.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t2200-rebase.sh b/t/t2200-rebase.sh
index 52462dd..b48e513 100755
--- a/t/t2200-rebase.sh
+++ b/t/t2200-rebase.sh
@@ -30,4 +30,20 @@ test_expect_success \
test `stg id base@stack` = `git rev-parse master~1`
'
+test_expect_success \
+ 'Rebase to next commit' \
+ '
+ stg rebase master &&
+ test $(stg id base@stack) = $(git rev-parse master)
+ '
+
+test_expect_success \
+ 'Commit the patch and rebase again' \
+ '
+ stg commit &&
+ git tag committed-here &&
+ stg rebase master &&
+ test $(stg id base@stack) = $(git rev-parse master)
+ '
+
test_done
^ permalink raw reply related
* [PATCH 1/2] Changed rebasing safety check to look for reachability of stack base (gna bug #9181).
From: Yann Dirson @ 2007-06-03 13:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070603133006.1681.1742.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/common.py | 23 +++++++++++++++--------
stgit/commands/pull.py | 12 ++++--------
stgit/commands/rebase.py | 2 +-
stgit/git.py | 6 ++++++
stgit/stack.py | 1 -
5 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 22c78ae..a3df2a2 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -318,13 +318,22 @@ def address_or_alias(addr_str):
for addr in addr_str.split(',')]
return ', '.join([addr for addr in addr_list if addr])
-def prepare_rebase(real_rebase, force=None):
+def prepare_rebase(force=None):
if not force:
- # Be sure we won't loose results of stg-(un)commit by error.
- # Do not require an existing orig-base for compatibility with 0.12 and earlier.
- origbase = crt_series._get_field('orig-base')
- if origbase and crt_series.get_base() != origbase:
- raise CmdException, 'Rebasing would possibly lose data'
+ # Be sure we won't loose results of stg-commit by error.
+ # Note: checking for refs/bases should not be necessary with
+ # repo format version 2, but better safe than sorry.
+ branchname = crt_series.get_branch()
+ # references for anything but the current stack
+ refs = [ref for ref in git.all_refs()
+ if ref != 'refs/heads/'+branchname
+ and ref != 'refs/bases/'+branchname
+ and not re.match('^refs/patches/%s/'%branchname, ref)]
+ stray_commits = git._output_lines(['git-rev-list',
+ crt_series.get_base(),
+ '--not'] + refs)
+ if len(stray_commits) != 0:
+ raise CmdException, 'Rebasing would make the following commits below the stack base unreachable: %s' % stray_commits
# pop all patches
applied = crt_series.get_applied()
@@ -343,8 +352,6 @@ def rebase(target):
out.done()
def post_rebase(applied, nopush, merged):
- # memorize that we rebased to here
- crt_series._set_field('orig-base', git.get_head())
# push the patches back
if not nopush:
push_patches(applied, merged)
diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index beaa7b5..bacd5fc 100644
--- 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
- applied = prepare_rebase(real_rebase=must_rebase, force=options.force)
+ applied = prepare_rebase(force=options.force)
# pull the remote changes
if policy == 'pull':
diff --git a/stgit/commands/rebase.py b/stgit/commands/rebase.py
index d132b60..13933d6 100644
--- a/stgit/commands/rebase.py
+++ b/stgit/commands/rebase.py
@@ -52,7 +52,7 @@ def func(parser, options, args):
check_conflicts()
check_head_top_equal()
- applied = prepare_rebase(real_rebase=True, force=options.force)
+ applied = prepare_rebase(force=options.force)
rebase(args[0])
post_rebase(applied, options.nopush, options.merged)
diff --git a/stgit/git.py b/stgit/git.py
index 4bc41aa..bec691b 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -1070,3 +1070,9 @@ def fetch_head():
# here we are sure to have a single fetch_head
return fetch_head
+
+def all_refs():
+ """Return a list of all refs in the current repository.
+ """
+
+ return [line.split()[1] for line in _output_lines(['git-show-ref'])]
diff --git a/stgit/stack.py b/stgit/stack.py
index 7a06458..45fd98a 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -588,7 +588,6 @@ class Series(StgitObject):
self.create_empty_field('applied')
self.create_empty_field('unapplied')
os.makedirs(self.__refs_dir)
- self._set_field('orig-base', git.get_head())
config.set(format_version_key(self.get_branch()), str(FORMAT_VERSION))
^ permalink raw reply related
* [StGIT RFC PATCH 0/2] Fixing the rebase safeguard
From: Yann Dirson @ 2007-06-03 13:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This is an attempt at using a reachability test to replace the use of
orig-base, to decide when it is safe to accept a rebase.
This implementation passes the testcase posted earlier by Karl (resent
here as 2nd patch in this series), BUT fails the 4th test of t2100.
That is, it fails to deal with the case of a rewinding commit occuring
in the upstream branch, and being first git-fetch'd before being
stg-pull'd in fetch-rebase mode. In this case, the former upstream
commit will really be lost.
In this case, however, it is exactly what we want, but I'm still
undecided about how to deal with this best. Possibly insane ideas for
now include:
- parsing the remote.*.fetch lines to detect the leading + (just
kidding ;)
- using ORIG_HEAD, but then, how do we decide when it is valid to do
so ?
I'll now switch to some real-life activity to see if that helps to
find a better solution.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 13:31 UTC (permalink / raw)
To: Michael Poole; +Cc: git
In-Reply-To: <878xb19ot5.fsf@graviton.dyn.troilus.org>
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:
> Pierre Habouzit writes:
>
> > The other problem I see is that at the time a bug gets reported, the
> > user knows it's found at a commit say 'X'. But it could in fact have
> > been generated at a commit Y, with this pattern:
> >
> > --o---o---Y---o---o---o---o---X---o---o--> master
> > \
> > o---o---o---o---o---o--> branch B
>
> Mainly for that reason, I would suggest having it outside the code
> base's namespace: probably a different root in the same $GIT_DIR, but
> I can see people wanting to have a separate $GIT_DIR. If the database
> tracks bugs by what commit(s) introduce or expose the bug -- at least
> once that is known -- then you get nearly free tracking of which
> branches have the bug without having to check out largely redundant
> trees.
Sure, but if it's completely out-of-tree, then cloning a repository
don't allow you to get the bug databases with it for free. I mean it'd
be great to have it somehow linked to the repository, but also I agree
that not everybody wants to clone the whole bugs databases. So maybe it
should just be in another shadow branch that annotates the devel ones.
Hmmm I definitely need to read the git-note thread...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 13:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070603123510.GC6992@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]
On Sun, Jun 03, 2007 at 02:35:10PM +0200, Yann Dirson wrote:
> On Sun, Jun 03, 2007 at 01:48:44PM +0200, Pierre Habouzit wrote:
> > Hi, I'm currently trying to think about a bug tracking system that
> > would be tightly integrated with git, meaning that it would have to be
> > somehow decentralized.
>
> You may want to look at existing solutions, such as Bugs
> Everywhere[1], which has is modular wrt the backend SCM (supports Arch
> and Bazaar for now).
>
> I'm not sure its storage format is extensible enough, but it at least
> shows some interesting ideas.
I looked at it, the idea is good, implementation quite wrong (too many
files, with too much crancky formats). But it's quite small, so if it's
the good way, it should be easy to adapt.
> > I mean, the immediate idea is to have some .bugs/ directories (or
> > alike). This has many good properties, e.g. for projects like the linux
> > kernel with its many subsystems or driver, it would make sense to have
> > per driver/subsystems/... bug packs, and move bugs from one pack to
> > another would be the way of assigning bugs to different modules.
>
> What about a requirement that .bugs/ is at the project toplevel ?
I don't see why it's necessary, it's just random thoughts and quite
outside the scope of my concerns right now.
> > The other problem I see is that at the time a bug gets reported, the
> > user knows it's found at a commit say 'X'. But it could in fact have
> > been generated at a commit Y, with this pattern:
> >
> > --o---o---Y---o---o---o---o---X---o---o--> master
> > \
> > o---o---o---o---o---o--> branch B
> >
> >
> > Sadly, the bug report has been commited at 'X', hence it does taints
> > branch B. As "inserting" or "moving" 'X' commit before the branch is not
> > an option as it would rewrite history, that becomes also a major no-go
> > for in-tree collecting of bugs.
>
> Maybe "commit annotations" would help here ? I have noticed a thread
> about a git-note tool, though did not open it yet - so I may be
> off-track here.
Hmm, I'll try to search for it then.
> > PS: What I left over, is why I wanted such a tool. Programmers tends (or
> > say I tend to, maybe I'm over-generalizing, but I seem to remember a
> > thread on the lkml where Linus was basically saying the same) to
> > hate bugzillas and such out-of-tree tool because they suck, and do
> > not really fit in the programming cycle. I'd rather see a
> > bugtracking system where the backend is in-tree, basically mboxes so
> > that you can read them easily with your favourite MUA, as well as
> > adding new comments in it the same way. It also accommodates with
> > linux-like workflows where bugs usually are sent on the lkml, a bit
> > like patches and pull requests are handled. That's the reasons why I
> > came with this idea.
>
> I still have mixed feelings towards the idea of implementing a brand
> new defect-tracking system, when there are already so many of them,
> with many features already. Eg., my initial opinion about Bugs
> Everywhere was that it was not complete enough to be used in many
> projects.
>
> I tend to think it would be more productive to do any necessary
> changes in widely-used bug trackers (bugzilla, mantis, rt...), and
> work on glue tools, like scmbug[2].
Well, why writing yet-another-scm like err git ? Because other were
doing things wrong. Bugzilla, or especially rt are not distributed,
hence completely inadequate for use with git, whatever clumsy plumbing
you do to make them work. And I know what I'm talking about, I wrote the
plumbing for the debian bug tracking system, I've looked at a lot of
them. And only bugs everywhere was near what looks the good way, because
when you're able to deal with your code like git allows you to, it makes
absolutely no sense not being able to deal with your bug database the
same way.
And FWIW I'm just asking questions, nothing more, just because I don't
want to rush in yet-another-tool if it appears it will be broken.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Michael Poole @ 2007-06-03 12:59 UTC (permalink / raw)
To: git
In-Reply-To: <20070603114843.GA14336@artemis>
Pierre Habouzit writes:
> Hi, I'm currently trying to think about a bug tracking system that
> would be tightly integrated with git, meaning that it would have to be
> somehow decentralized.
>
> Though there is a few design issues I have, that block me from doing
> first decisions about how to implement some kind of Proof of Concept. My
> main problem is: should I put this bug tracking system in the repository
> it tracks bugs for, or not.
>
> I mean, the immediate idea is to have some .bugs/ directories (or
> alike). This has many good properties, e.g. for projects like the linux
> kernel with its many subsystems or driver, it would make sense to have
> per driver/subsystems/... bug packs, and move bugs from one pack to
> another would be the way of assigning bugs to different modules.
>
> Also, a good thing is that when you "report" a bug, it gets commited
> in the repository, and taints all the commit chilren, until you commit
> the closing patch. This allow a release manager to rapidly _see_ if his
> stable branch has this or this bug.
>
> OTOH it comes with many problems. First, and most obvious IMHO, it's
> that it'll mean bugs will have to be pulled into the mainlines. Let's
> take example with the linux repository, I'm not sure Linus would be
> really keen on doing rounds of bugs pulls, not to mention it'll bloat
> the repository somehow.
>
> The other problem I see is that at the time a bug gets reported, the
> user knows it's found at a commit say 'X'. But it could in fact have
> been generated at a commit Y, with this pattern:
>
> --o---o---Y---o---o---o---o---X---o---o--> master
> \
> o---o---o---o---o---o--> branch B
Mainly for that reason, I would suggest having it outside the code
base's namespace: probably a different root in the same $GIT_DIR, but
I can see people wanting to have a separate $GIT_DIR. If the database
tracks bugs by what commit(s) introduce or expose the bug -- at least
once that is known -- then you get nearly free tracking of which
branches have the bug without having to check out largely redundant
trees.
Michael Poole
^ permalink raw reply
* Re: quieter installs
From: Alex Riesen @ 2007-06-03 13:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070603060058.GC4507@spearce.org>
Shawn O. Pearce, Sun, Jun 03, 2007 08:00:58 +0200:
> Junio C Hamano <junkio@cox.net> wrote:
> > make -C git-gui install
> > make[1]: Entering directory `/git/git.git/git-gui'
You want to hide these (unless -w is given). The patch I just sent
does this.
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Simon Hausmann @ 2007-06-03 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm3inisa.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
On Saturday 02 June 2007 23:33:25 Junio C Hamano wrote:
> Scott Lamb <slamb@slamb.org> writes:
> > On May 31, 2007, at 4:53 PM, Junio C Hamano wrote:
> >> Actually, my preference is to have a "patch 0" before all of the
> >> above, that demotes git-p4import to contrib/ hierarchy. Having
> >> no access to p4 managed repositories (nor much inclination to
> >> get one), I can never test nor maintain it myself, so it is just
> >> crazy for me to be the maintainer for it.
> >
> > Will do. What does that mean for Documentation/git-p4import.txt and
> > the git-p4 rpm (defined in git.spec.in)? Should I move them with it?
> > (Seems nothing else in the main tree references contrib.) If so,
> > maybe I should set up a common "Documentation/asciidoc.mak" or
> > something for building the man/html pages rather than duplicating all
> > that Makefile logic.
>
> A much more preferable alternative is for you to say "Hey, don't
> say you want to demote it. I'll keep it maintained, I regularly
> use p4 and have a strong incentive to keep it working". Then we
> do not have to do the "patch 0" ;-)
On the topic of git integration with perforce, what are the chances of getting
git-p4 ( http://repo.or.cz/w/fast-export.git ) into git's contrib/fast-export
area? :)
git-p4 can do everything git-p4import can do plus a lot more (it can track
multiple branches, it's a hell of a lot faster, it can export back to p4 and
it also works on Windows!).
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Make the installation target of git-gui a little less chatty
From: Alex Riesen @ 2007-06-03 13:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20070603010044.GA4507@spearce.org>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Almost the same as Shawn's. Sending just for completeness.
git-gui/Makefile | 34 ++++++++++++++++++++++++++++------
1 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index 3de0de1..dfed1a1 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -2,6 +2,10 @@ all::
# Define V=1 to have a more verbose compile.
#
+QUIET =
+ifndef V
+ QUIET = @
+endif
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -108,13 +112,31 @@ GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
all:: $(ALL_PROGRAMS) lib/tclIndex
+ifeq ($(QUIET),@)
+INST_0 = arg=
+INST_1 = &&echo " INSTALL $$mode $$arg"&&$(INSTALL) $$mode "$$arg" # space
+BSETUP_0 = arg=
+BSETUP_1 = &&echo " GIT-GUI BUILTIN $$arg"&& \
+ rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" && \
+ ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' \
+ '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" # space
+else
+INST_0 = $(INSTALL) $$mode # space to separate "install" and its first arg
+INST_1 =
+BSETUP_0 = arg=
+BSETUP_1 = &&rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" && \
+ ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' \
+ '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" # space
+endif
+
install: all
- $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) git-gui '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(foreach p,$(GITGUI_BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
- $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(libdir_SQ)'
- $(INSTALL) -m644 lib/tclIndex '$(DESTDIR_SQ)$(libdir_SQ)'
- $(foreach p,$(ALL_LIBFILES), $(INSTALL) -m644 $p '$(DESTDIR_SQ)$(libdir_SQ)' ;)
+ $(QUIET)$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(QUIET)mode=;$(INST_0)git-gui $(INST_1)'$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(QUIET)$(foreach p,$(GITGUI_BUILT_INS),$(BSETUP_0)$p $(BSETUP_1) &&):
+ $(QUIET)$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(libdir_SQ)'
+ $(QUIET)mode=-m644; \
+ $(foreach p,lib/tclIndex $(ALL_LIBFILES), \
+ $(INST_0)$p $(INST_1) '$(DESTDIR_SQ)$(libdir_SQ)' &&):
dist-version:
@mkdir -p $(TARDIR)
--
1.5.2.182.ged6b
^ permalink raw reply related
* [PATCH] Make the installation targets a little less chatty
From: Alex Riesen @ 2007-06-03 13:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20070603010044.GA4507@spearce.org>
by default. V=1 works as usual.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Updated. BTW, where does "no $(call) in Makefile" came from?
It could simplify the thing a lot
Makefile | 44 +++++++++++++++++++++++++++++++++-----------
templates/Makefile | 5 +++--
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index cac0a4a..6409b9c 100644
--- a/Makefile
+++ b/Makefile
@@ -660,6 +660,7 @@ ifeq ($(TCLTK_PATH),)
NO_TCLTK=NoThanks
endif
+QUIET=
QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
QUIET_SUBDIR1 =
@@ -671,6 +672,8 @@ endif
ifneq ($(findstring $(MAKEFLAGS),s),s)
ifndef V
+ QUIET = @
+
QUIET_CC = @echo ' ' CC $@;
QUIET_AR = @echo ' ' AR $@;
QUIET_LINK = @echo ' ' LINK $@;
@@ -972,34 +975,53 @@ check: common-cmds.h
### Installation rules
+ifeq ($(QUIET),@)
+INST_0 = arg=
+INST_1 = &&echo " INSTALL $$arg"&&$(INSTALL) "$$arg" # space
+BSETUP_0 = arg=
+BSETUP_1 = &&echo " SETUP BUILTIN $$arg"&& \
+ rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" && \
+ ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$(X)' \
+ '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" # space
+else
+INST_0 = $(INSTALL) # space to separate "install" and its first arg
+INST_1 =
+BSETUP_0 = arg=
+BSETUP_1 = &&rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" && \
+ ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$(X)' \
+ '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" # space
+endif
+
install: all
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
- $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(MAKE) -C perl prefix='$(prefix_SQ)' install
+ $(QUIET)$(foreach p,$(ALL_PROGRAMS),\
+ $(INST_0)'$p' $(INST_1)'$(DESTDIR_SQ)$(gitexecdir_SQ)' &&):
+ $(QUIET)$(INST_0)git$X $(INST_1)'$(DESTDIR_SQ)$(bindir_SQ)'
+ $(QUIET)$(foreach p,$(BUILT_INS),$(BSETUP_0)$p $(BSETUP_1)&&):
+ $(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1) DESTDIR='$(DESTDIR_SQ)' install
+ $(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) prefix='$(prefix_SQ)' install
ifndef NO_TCLTK
- $(INSTALL) gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
- $(MAKE) -C git-gui install
+ $(QUIET)$(INST_0)gitk-wish $(INST_1)'$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) install
endif
- if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
+ $(QUIET)if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
then \
ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ @echo cleaning '$(DESTDIR_SQ)$(gitexecdir_SQ)' of old scripts
+ $(QUIET)$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
install-doc:
- $(MAKE) -C Documentation install
+ $(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) install
quick-install-doc:
- $(MAKE) -C Documentation quick-install
+ $(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) quick-install
diff --git a/templates/Makefile b/templates/Makefile
index b8352e7..b9a39e2 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -45,6 +45,7 @@ clean:
rm -rf blt boilerplates.made
install: all
- $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(template_dir_SQ)'
- (cd blt && $(TAR) cf - .) | \
+ @echo installing templates
+ $(QUIET)$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(template_dir_SQ)'
+ $(QUIET)(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_dir_SQ)' && $(TAR) xf -)
--
1.5.2.182.ged6b
^ permalink raw reply related
* Re: quieter installs
From: Alex Riesen @ 2007-06-03 13:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070603010044.GA4507@spearce.org>
Shawn O. Pearce, Sun, Jun 03, 2007 03:00:44 +0200:
> + INSTALL_L3 = && echo ' ' 'LINK ' `basename "$$dst"` '->' `basename "$$src"` && rm -f "$$dst" && ln "$$src" "$$dst"
"LINK" is already taken. By program linking step
^ permalink raw reply
* Re: [PATCH 1/4] Add 2 new contrib scripts.
From: Yann Dirson @ 2007-06-03 12:40 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git, Catalin Marinas
In-Reply-To: <20070603123254.GB6507@diana.vm.bytemark.co.uk>
On Sun, Jun 03, 2007 at 02:32:54PM +0200, Karl Hasselström wrote:
> On 2007-06-01 11:22:12 +0200, David Kågedal wrote:
>
> > This is something I've been missing.
>
> I believe this is useful, too.
>
> > But I'd call it "stg merge" or something, since what it does is that
> > it merges the top patch into the patch below it. But since "merge"
> > means something else to git, it might not be the best choice.
>
> Maybe "coalesce"? I recall using that word when turning several
> consecutive memory blocks into a single larger block in a malloc
> implementation, and this sitiation is very similar.
Hm, maybe, but the idea is not necessarily to merge this patch into
the former one (I have written contrib/stg-swallow for this use), but
really to turn the patch into just local changes (eg. to restore local
changes after a complex operation, like in stg-k).
> It would be nice if it was possible to specify an arbitrary series of
> patches, and get them coalesced into one. (StGIT would have to push
> and pop to place them consecutively and topmost.) With a parameter to
> control the name of the new large patch, and the comment being the
> concatenation of the comments of the component patches (easily
> editable in the editor window that pops up).
stg-swallow would be quite easy to extend for this usage.
Best regards,
--
Yann.
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Yann Dirson @ 2007-06-03 12:35 UTC (permalink / raw)
To: git
In-Reply-To: <20070603114843.GA14336@artemis>
On Sun, Jun 03, 2007 at 01:48:44PM +0200, Pierre Habouzit wrote:
> Hi, I'm currently trying to think about a bug tracking system that
> would be tightly integrated with git, meaning that it would have to be
> somehow decentralized.
You may want to look at existing solutions, such as Bugs
Everywhere[1], which has is modular wrt the backend SCM (supports Arch
and Bazaar for now).
I'm not sure its storage format is extensible enough, but it at least
shows some interesting ideas.
> I mean, the immediate idea is to have some .bugs/ directories (or
> alike). This has many good properties, e.g. for projects like the linux
> kernel with its many subsystems or driver, it would make sense to have
> per driver/subsystems/... bug packs, and move bugs from one pack to
> another would be the way of assigning bugs to different modules.
What about a requirement that .bugs/ is at the project toplevel ? We
could then enforce that such an "assign to submodule" operation only
assigns a bug to a real git submodule.
> The other problem I see is that at the time a bug gets reported, the
> user knows it's found at a commit say 'X'. But it could in fact have
> been generated at a commit Y, with this pattern:
>
> --o---o---Y---o---o---o---o---X---o---o--> master
> \
> o---o---o---o---o---o--> branch B
>
>
> Sadly, the bug report has been commited at 'X', hence it does taints
> branch B. As "inserting" or "moving" 'X' commit before the branch is not
> an option as it would rewrite history, that becomes also a major no-go
> for in-tree collecting of bugs.
Maybe "commit annotations" would help here ? I have noticed a thread
about a git-note tool, though did not open it yet - so I may be
off-track here.
> PS: What I left over, is why I wanted such a tool. Programmers tends (or
> say I tend to, maybe I'm over-generalizing, but I seem to remember a
> thread on the lkml where Linus was basically saying the same) to
> hate bugzillas and such out-of-tree tool because they suck, and do
> not really fit in the programming cycle. I'd rather see a
> bugtracking system where the backend is in-tree, basically mboxes so
> that you can read them easily with your favourite MUA, as well as
> adding new comments in it the same way. It also accommodates with
> linux-like workflows where bugs usually are sent on the lkml, a bit
> like patches and pull requests are handled. That's the reasons why I
> came with this idea.
I still have mixed feelings towards the idea of implementing a brand
new defect-tracking system, when there are already so many of them,
with many features already. Eg., my initial opinion about Bugs
Everywhere was that it was not complete enough to be used in many
projects.
I tend to think it would be more productive to do any necessary
changes in widely-used bug trackers (bugzilla, mantis, rt...), and
work on glue tools, like scmbug[2].
[1] http://www.panoramicfeedback.com/opensource/
[2] http://www.mkgnu.net/?q=scmbug
(both projects listed in the wiki already -
http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist)
best regards,
--
Yann.
^ permalink raw reply
* Re: [PATCH 1/4] Add 2 new contrib scripts.
From: Karl Hasselström @ 2007-06-03 12:32 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87fy5cqbaz.fsf@morpheus.local>
On 2007-06-01 11:22:12 +0200, David Kågedal wrote:
> This is something I've been missing.
I believe this is useful, too.
> But I'd call it "stg merge" or something, since what it does is that
> it merges the top patch into the patch below it. But since "merge"
> means something else to git, it might not be the best choice.
Maybe "coalesce"? I recall using that word when turning several
consecutive memory blocks into a single larger block in a malloc
implementation, and this sitiation is very similar.
It would be nice if it was possible to specify an arbitrary series of
patches, and get them coalesced into one. (StGIT would have to push
and pop to place them consecutively and topmost.) With a parameter to
control the name of the new large patch, and the comment being the
concatenation of the comments of the component patches (easily
editable in the editor window that pops up).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: StGIT: stgitformatversion vs. stgit.formatversion
From: Karl Hasselström @ 2007-06-03 12:17 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, GIT list
In-Reply-To: <20070602191641.GB6992@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-06-02 21:16:41 +0200, Yann Dirson wrote:
> What about using branch.*.stgit.formatversion to store the version,
> to be consistent with other stgit-specific per-branch settings ?
Good idea. But we should probably fall back to stgitformatversion (or
better, upgrade from it) to be nice to those running Catalin's master.
It happens a bit too often that we find problems with patches only
after Catalin has published them on "master". (At least that seems to
be the case with patches coming from me!) Maybe a "pu" branch
(maintained either by Catalin or someone else) would be a good way to
smoke them out before they're written in stone and distributed to lots
of people.
If the stgitformatversion patch had been on such a branch, we could
just have edited it and not have to worry about upgrading old configs
(aside from posting a mail on how to upgrade manually).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 11:48 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]
Hi, I'm currently trying to think about a bug tracking system that
would be tightly integrated with git, meaning that it would have to be
somehow decentralized.
Though there is a few design issues I have, that block me from doing
first decisions about how to implement some kind of Proof of Concept. My
main problem is: should I put this bug tracking system in the repository
it tracks bugs for, or not.
I mean, the immediate idea is to have some .bugs/ directories (or
alike). This has many good properties, e.g. for projects like the linux
kernel with its many subsystems or driver, it would make sense to have
per driver/subsystems/... bug packs, and move bugs from one pack to
another would be the way of assigning bugs to different modules.
Also, a good thing is that when you "report" a bug, it gets commited
in the repository, and taints all the commit chilren, until you commit
the closing patch. This allow a release manager to rapidly _see_ if his
stable branch has this or this bug.
OTOH it comes with many problems. First, and most obvious IMHO, it's
that it'll mean bugs will have to be pulled into the mainlines. Let's
take example with the linux repository, I'm not sure Linus would be
really keen on doing rounds of bugs pulls, not to mention it'll bloat
the repository somehow.
The other problem I see is that at the time a bug gets reported, the
user knows it's found at a commit say 'X'. But it could in fact have
been generated at a commit Y, with this pattern:
--o---o---Y---o---o---o---o---X---o---o--> master
\
o---o---o---o---o---o--> branch B
Sadly, the bug report has been commited at 'X', hence it does taints
branch B. As "inserting" or "moving" 'X' commit before the branch is not
an option as it would rewrite history, that becomes also a major no-go
for in-tree collecting of bugs.
Last of all, I'd also like to have a design where bugs pulls do not
create too much painful merges and conflicts. If we e.g. say that a bug
is a status file and a mbox of comments (makes sense to me), the mbox
can be merged easily (concatenate all mboxes, and purge duplicates), but
the status file is quite problematic on its own too.
So here are the first ideas/problems/remarks I have with that. I'd
be thrilled to have your comments about those points.
PS: What I left over, is why I wanted such a tool. Programmers tends (or
say I tend to, maybe I'm over-generalizing, but I seem to remember a
thread on the lkml where Linus was basically saying the same) to
hate bugzillas and such out-of-tree tool because they suck, and do
not really fit in the programming cycle. I'd rather see a
bugtracking system where the backend is in-tree, basically mboxes so
that you can read them easily with your favourite MUA, as well as
adding new comments in it the same way. It also accommodates with
linux-like workflows where bugs usually are sent on the lkml, a bit
like patches and pull requests are handled. That's the reasons why I
came with this idea.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Alex Riesen @ 2007-06-03 11:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7j2p1r5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Jun 02, 2007 21:58:22 +0200:
> I think the way QUIET_CC and friends are done is quite sensible
I don't think it is possible to implement this way: QUIET_CC uses
target-global $@, which the "install" target does not have.
^ permalink raw reply
* Re: [RFC/PATCH 4/3] Simplify naming (versioning) of non-release tig tarball and rpm file
From: Jonas Fonseca @ 2007-06-03 9:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200706021952.28426.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote Sat, Jun 02, 2007:
> This is proposal to simplify naming of non-release tarballs and rpm file,
> both for tig and also for git itself. Instead of using whole git-describe
> output as version number in tarball/rpm name (BTW. it would be nice to
> have command line switch to git-describe which would return old output,
> without number of commits since given tag) use tag part as version number,
> and number of commits since (plus optional marking dirty) as release
> number.
>
> What do you think about this?
I like the simpler and less confusing names. How about the simpler
version below?
BTW, I also added `make dist DIST_VERSION=X.Y` to make it easy to force
a version. I used it when building the documentation in the release
branch.
> diff --git a/Makefile b/Makefile
> index b49d7f8..1e67586 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -17,7 +17,13 @@ ifdef DIST_VERSION
> VERSION = $(DIST_VERSION)
> endif
>
> -RPM_VERSION = $(subst -,.,$(VERSION))
> +# $(GITDESC) looks like either x.y, or like x.y-z-g<sha1>
> +SPLIT_VERSION := $(shell echo $(GITDESC) | \
> + sed -e 's/^\(.*\)-\([0-9]\+\)-\(g[0-9a-f]\+\)$$/\1 \2 \3/g')
> +RPM_VERSION = $(subst -,.,$(word 1,$(SPLIT_VERSION)))
> +RPM_RELEASE = $(strip \
> + $(subst -,.,$(if $(word 2,$(SPLIT_VERSION)),\
> + $(word 2,$(SPLIT_VERSION)),0)$(WTDIRTY)))
>
> LDLIBS = -lcurses
> CFLAGS = -Wall -O2 '-DVERSION="$(VERSION)"'
diff --git a/Makefile b/Makefile
index 91cb097..622a916 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,11 @@ ifdef DIST_VERSION
VERSION = $(DIST_VERSION)
endif
-RPM_VERSION = $(subst -,.,$(VERSION))
+# Split the version "TAG-OFFSET-gSHA1-DIRTY" into "TAG OFFSET"
+# and append 0 as a fallback offset for "exact" tagged versions.
+RPM_VERLIST = $(filter-out g% dirty,$(subst -, ,$(VERSION))) 0
+RPM_VERSION = $(word 1,$(RPM_VERLIST))
+RPM_RELEASE = $(word 2,$(RPM_VERLIST))$(if $(WTDIRTY),.dirty)
LDLIBS = -lcurses
CFLAGS = -Wall -O2
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Use git-tag in git-cvsimport
From: Junio C Hamano @ 2007-06-03 8:37 UTC (permalink / raw)
To: Elvis Pranskevichus; +Cc: git
In-Reply-To: <11808537962798-git-send-email-el@prans.net>
Elvis Pranskevichus <el@prans.net> writes:
> Currently git-cvsimport tries to create tag objects directly via git-mktag
> in a very broken way, e.g the stuff it writes into the tagger field of
> the tag object doesn't really resemble the GIT_COMMITTER_IDENT. This makes
> gitweb and possibly other tools that try to interpret tag objects to be
> confused about tag date and authorship.
>
> Fix this by calling git-tag instead. This also has a nice side effect of
> not creating the tag object but only the lightweight tag as that's the only
> thing CVS has anyways.
>
> Signed-off-by: Elvis Pranskevichus <el@prans.net>
This sounds very sane, although I have not thought through the
possible ramifications.
> git-cvsimport.perl | 26 ++------------------------
> 1 files changed, 2 insertions(+), 24 deletions(-)
>
> diff --git a/git-cvsimport.perl b/git-cvsimport.perl
> index f68afe7..d5ca66b 100755
> --- a/git-cvsimport.perl
> +++ b/git-cvsimport.perl
> @@ -771,31 +771,9 @@ sub commit {
> $xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
> $xtag =~ tr/_/\./ if ( $opt_u );
> $xtag =~ s/[\/]/$opt_s/g;
> - ...
> +
> + system("git-tag $xtag $cid") == 0
> or die "Cannot create tag $xtag: $!\n";
> - ...
>
> print "Created tag '$xtag' on '$branch'\n" if $opt_v;
> }
> --
> 1.5.2
Other than that I would write the "system" in a slightly newer
style, i.e.
system('git-tag', $xtag, $cid)
I do not think of any obvious downside, either in the code nor
the change to use unannotated tag.
Anybody on the list see downsides with this?
^ permalink raw reply
* [PATCH] Use git-tag in git-cvsimport
From: Elvis Pranskevichus @ 2007-06-03 6:56 UTC (permalink / raw)
To: git; +Cc: Elvis Pranskevichus
Currently git-cvsimport tries to create tag objects directly via git-mktag
in a very broken way, e.g the stuff it writes into the tagger field of
the tag object doesn't really resemble the GIT_COMMITTER_IDENT. This makes
gitweb and possibly other tools that try to interpret tag objects to be
confused about tag date and authorship.
Fix this by calling git-tag instead. This also has a nice side effect of
not creating the tag object but only the lightweight tag as that's the only
thing CVS has anyways.
Signed-off-by: Elvis Pranskevichus <el@prans.net>
---
git-cvsimport.perl | 26 ++------------------------
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index f68afe7..d5ca66b 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -771,31 +771,9 @@ sub commit {
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
$xtag =~ tr/_/\./ if ( $opt_u );
$xtag =~ s/[\/]/$opt_s/g;
-
- my $pid = open2($in, $out, 'git-mktag');
- print $out "object $cid\n".
- "type commit\n".
- "tag $xtag\n".
- "tagger $author_name <$author_email>\n"
- or die "Cannot create tag object $xtag: $!\n";
- close($out)
- or die "Cannot create tag object $xtag: $!\n";
-
- my $tagobj = <$in>;
- chomp $tagobj;
-
- if ( !close($in) or waitpid($pid, 0) != $pid or
- $? != 0 or $tagobj !~ /^[0123456789abcdef]{40}$/ ) {
- die "Cannot create tag object $xtag: $!\n";
- }
-
-
- open(C,">$git_dir/refs/tags/$xtag")
+
+ system("git-tag $xtag $cid") == 0
or die "Cannot create tag $xtag: $!\n";
- print C "$tagobj\n"
- or die "Cannot write tag $xtag: $!\n";
- close(C)
- or die "Cannot write tag $xtag: $!\n";
print "Created tag '$xtag' on '$branch'\n" if $opt_v;
}
--
1.5.2
^ permalink raw reply related
* Re: quieter installs
From: Shawn O. Pearce @ 2007-06-03 6:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vfy59oa71.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Good job. I actually almost like it.
Heh. Thanks. I almost like it to. I like what it does for the
non-V=1 formatting, as I think its easier to read the installation
process. But I really don't like that install target. The problem
of course is there's no $@ that I can depend on in the install rules,
and the rules for the builtins (rm -f && ln) is very very messy.
> Without V=1, I get this from 'pu' that merged your 'pu'.
>
> ...
> make -C git-gui install
> make[1]: Entering directory `/git/git.git/git-gui'
> DEST /home/junio/git-pu/bin
> INSTALL 755 git-gui
> LINK git-citool -> git-gui
> DEST /home/junio/git-pu/share//git-gui/lib
> INSTALL 644 tclIndex
> INSTALL 644 blame.tcl
> INSTALL 644 branch.tcl
> INSTALL 644 branch_rename.tcl
> INSTALL 644 browser.tcl
> ...
Right. I wanted to try and keep the lines very simple, like we
have with our CC/GEN/BUILTIN lines. But I also wanted to be clear
about which directories we are dropping stuff into.
> And with V=1, what I see seem very readable.
Right. My target there was that the V=1 case was *exactly*
what I had before. Because a simple installation with no pretty
formatting should be exactly that; a simple installation with no
pretty formatting.
--
Shawn.
^ permalink raw reply
* Re: quieter installs
From: Junio C Hamano @ 2007-06-03 5:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Alex Riesen, git
In-Reply-To: <20070603010044.GA4507@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> So I'm looking at adding this to git-gui, to replace Alex's patch,
> as it addresses most of the issues that Junio raised. Thoughts?
>
> I'm a little unhappy with how mess the install target is now, but
> fortunately most of it is data driven through the other variables in
> the Makefile, so hopefully I don't have to tweak it too frequently.
> ;-)
Good job. I actually almost like it.
Without V=1, I get this from 'pu' that merged your 'pu'.
...
make -C git-gui install
make[1]: Entering directory `/git/git.git/git-gui'
DEST /home/junio/git-pu/bin
INSTALL 755 git-gui
LINK git-citool -> git-gui
DEST /home/junio/git-pu/share//git-gui/lib
INSTALL 644 tclIndex
INSTALL 644 blame.tcl
INSTALL 644 branch.tcl
INSTALL 644 branch_rename.tcl
INSTALL 644 browser.tcl
...
And with V=1, what I see seem very readable.
^ permalink raw reply
* gitweb on shared hosting
From: Mircea Bardac @ 2007-06-02 16:53 UTC (permalink / raw)
To: git
Hi everybody,
I don't know if this is possible or not, but I'm trying with no results.
Is it possible to install gitweb on a shared hosting system, with no root
access. Reading the INSTALL document reveals only information for
configuration on build-time/install as root.
I expected it to be installable just as any other web application:
* get gitweb.cgi and related files + place them on the webserver
* modify a config file (gitweb.cgi) to update the paths + gitweb options
* (eventually) adjust server configuration for CGI in the wanted dir
DONE.
Also, having configuration information spread across several files
(README/INSTALL/gitweb.cgi) doesn't help much.
It is also very strange to have README/"How to configure gitweb for your local
system" saying "You can specify the following configuration variables when
buiding GIT". That means I have to rebuild GIT (actually, only
gitweb/gitweb.cgi) to configure gitweb => I need to download the sources by
hand instead of using the already installed gitweb on my system (the one
which came with the git package).
Is there any strong reason to have configuration at build-time at all? It
would be a lot easier IMO to have it *just* by config files. I'm saying this
because most of the install process is manual anyway (copying/moving files).
Many thanks,
Mircea
--
http://mircea.bardac.net
^ permalink raw reply
* [PATCH 4/4] git-p4import: partial history
From: Scott Lamb @ 2007-06-03 3:58 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Scott Lamb
In-Reply-To: <11808431364066-git-send-email-slamb@slamb.org>
Allow importing partial history, which is quicker and may be necessary with
a low Perforce MaxScanRows limit.
Signed-off-by: Scott Lamb <slamb@slamb.org>
---
Documentation/git-p4import.txt | 6 ++++++
git-p4import.py | 14 ++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-p4import.txt b/Documentation/git-p4import.txt
index 714abbe..bf40b5a 100644
--- a/Documentation/git-p4import.txt
+++ b/Documentation/git-p4import.txt
@@ -10,6 +10,7 @@ SYNOPSIS
--------
[verse]
`git-p4import` [-q|-v] [--notags] [--authors <file>] [-t <timezone>]
+ [--start-with <change>]
<//p4repo/path> <branch>
`git-p4import` --stitch <//p4repo/path>
`git-p4import`
@@ -59,6 +60,11 @@ OPTIONS
etc. You only need to specify this once, it will be saved in
the git config file for the repository.
+\--start-with::
+ Start the import with the given Perforce change. A partial history can
+ be much faster to generate and is possible even with a low MaxScanRows
+ limit.
+
<//p4repo/path>::
The Perforce path that will be imported into the specified branch.
diff --git a/git-p4import.py b/git-p4import.py
index e7a52b3..c7a2033 100644
--- a/git-p4import.py
+++ b/git-p4import.py
@@ -33,7 +33,12 @@ def die(msg, *args):
sys.exit(1)
def usage():
- print "USAGE: git-p4import [-q|-v] [--authors=<file>] [-t <timezone>] [//p4repo/path <branch>]"
+ print "usage:"
+ print " git-p4import [-q|-v] [--notags] [--authors <file>] [-t <timezone>]"
+ print " [--start-with <change>]"
+ print " <//p4repo/path> <branch>"
+ print " git-p4import --stitch <//p4repo/path>"
+ print " git-p4import"
sys.exit(1)
verbosity = 1
@@ -41,6 +46,7 @@ logfile = file("/dev/null", "a")
ignore_warnings = False
stitch = 0
tagall = True
+start_with = 0
def report(level, msg, *args):
global verbosity
@@ -299,7 +305,8 @@ class git_command:
try:
opts, args = getopt.getopt(sys.argv[1:], "qhvt:",
- ["authors=","help","stitch=","timezone=","log=","ignore","notags"])
+ ["authors=","help","stitch=","timezone=","log=","ignore","notags",
+ "start-with="])
except getopt.GetoptError:
usage()
@@ -316,6 +323,8 @@ for o, a in opts:
usage()
if o in ("--ignore"):
ignore_warnings = True
+ if o in ("--start-with"):
+ start_with = int(a)
git = git_command()
branch=git.current_branch()
@@ -361,6 +370,7 @@ if stitch == 0:
top = git.top_change(branch)
else:
top = 0
+top = max(top, start_with)
changes = p4.changes(top)
count = len(changes)
if count == 0:
--
1.5.2
^ permalink raw reply related
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