* [PATCH 1/4] git.el: Run git-rerere on commits if the rr-cache directory exists.
From: Alexandre Julliard @ 2006-07-22 13:39 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 34c9950..7371d4b 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -584,6 +584,8 @@ (defun git-do-commit ()
(condition-case nil (delete-file ".git/MERGE_HEAD") (error nil))
(with-current-buffer buffer (erase-buffer))
(git-set-files-state files 'uptodate)
+ (when (file-directory-p ".git/rr-cache")
+ (git-run-command nil nil "rerere"))
(git-refresh-files)
(git-refresh-ewoc-hf git-status)
(message "Committed %s." commit))
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/4] git.el: Prepend a slash to the file name when adding to .gitignore.
From: Alexandre Julliard @ 2006-07-22 13:39 UTC (permalink / raw)
To: git
This way the ignore command will really only ignore the marked files
and not files with the same name in subdirectories.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 7371d4b..5837471 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -258,7 +258,7 @@ (defun git-append-to-ignore (file)
(set-buffer (find-file-noselect ignore-name))
(goto-char (point-max))
(unless (zerop (current-column)) (insert "\n"))
- (insert name "\n")
+ (insert "/" name "\n")
(sort-lines nil (point-min) (point-max))
(save-buffer))
(when created
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 3/4] git.el: Try to reuse an existing buffer when running git-status.
From: Alexandre Julliard @ 2006-07-22 13:39 UTC (permalink / raw)
To: git
By default, running git-status again will now reuse an existing buffer
that displays the same directory. The old behavior of always creating
a new buffer can be obtained by customizing the git-reuse-status-buffer
option.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5837471..92cb2b9 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -83,6 +83,12 @@ (defcustom git-append-signed-off-by nil
:group 'git
:type 'boolean)
+(defcustom git-reuse-status-buffer t
+ "Whether `git-status' should try to reuse an existing buffer
+if there is already one that displays the same directory."
+ :group 'git
+ :type 'boolean)
+
(defcustom git-per-dir-ignore-file ".gitignore"
"Name of the per-directory ignore file."
:group 'git
@@ -1003,12 +1009,28 @@ Commands:
(set (make-local-variable 'list-buffers-directory) default-directory)
(run-hooks 'git-status-mode-hook)))
+(defun git-find-status-buffer (dir)
+ "Find the git status buffer handling a specified directory."
+ (let ((list (buffer-list))
+ (fulldir (expand-file-name dir))
+ found)
+ (while (and list (not found))
+ (let ((buffer (car list)))
+ (with-current-buffer buffer
+ (when (and list-buffers-directory
+ (string-equal fulldir (expand-file-name list-buffers-directory))
+ (string-match "\\*git-status\\*$" (buffer-name buffer)))
+ (setq found buffer))))
+ (setq list (cdr list)))
+ found))
+
(defun git-status (dir)
"Entry point into git-status mode."
(interactive "DSelect directory: ")
(setq dir (git-get-top-dir dir))
(if (file-directory-p (concat (file-name-as-directory dir) ".git"))
- (let ((buffer (create-file-buffer (expand-file-name "*git-status*" dir))))
+ (let ((buffer (or (and git-reuse-status-buffer (git-find-status-buffer dir))
+ (create-file-buffer (expand-file-name "*git-status*" dir)))))
(switch-to-buffer buffer)
(cd dir)
(git-status-mode)
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 4/4] git.el: Put the git customize group in the 'tools' parent group.
From: Alexandre Julliard @ 2006-07-22 13:40 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 92cb2b9..68de9be 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -55,7 +55,8 @@ (require 'ewoc)
;;;; ------------------------------------------------------------
(defgroup git nil
- "Git user interface")
+ "A user interface for the git versioning system."
+ :group 'tools)
(defcustom git-committer-name nil
"User name to use for commits.
--
1.4.2.rc1.ge7a0
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: Makefile checks for DarwinPorts / Fink
From: Junio C Hamano @ 2006-07-22 14:43 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: git, merlyn
In-Reply-To: <f3d7535d0607210758m4410cddfw16329ce473404fd8@mail.gmail.com>
"Stefan Pfetzing" <stefan.pfetzing@gmail.com> writes:
> while I was updating the DarwinPorts Portfile for git, I saw some
> really suspicious lines in the Makefile of Git for DarwinPorts/Fink.
>
> --- snip ---
> ## fink
> ifeq ($(shell test -d /sw/lib && echo y),y)
> ALL_CFLAGS += -I/sw/include
> ALL_LDFLAGS += -L/sw/lib
> endif
> ## darwinports
> ifeq ($(shell test -d /opt/local/lib && echo y),y)
> ALL_CFLAGS += -I/opt/local/include
> ALL_LDFLAGS += -L/opt/local/lib
> endif
> --- snap ---
>
> IMHO, Git should definetely not include /sw/include and /sw/lib, just
> if it *exists*.
Could you make a concrete suggestion (I am not on Darwin)?
If I am reading you correctly, your suggestion is that
DarwinPorts and/or Fink build procedure, which drive our
Makefile from outside, should set up CFLAGS and LDFLAGS to have
the correct paths for local libraries and headers. It is not
clear to me if having these defaults there makes it hard (or
cumbersome) to override them in such a setup and you are
proposing to remove them (or commenting them out), or if you can
live with them being there.
These were made as "quick relatively sane defaults for help
people with simple configuration when people build git
themselves" initially and it may be the case that they now could
use improvements. I dunno (I am not on Darwin).
But I suspect that the "official" portfile (or whatever it is
called in the Darwin world) should be able to override whatever
is done in there --- otherwise we would need to remove them or
comment them out, but I am hoping it does not have to come to
that; I think they serve as good hint to help people who are
building from the source.
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Shawn Pearce @ 2006-07-22 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Pfetzing, git, merlyn
In-Reply-To: <7vhd19itu2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Stefan Pfetzing" <stefan.pfetzing@gmail.com> writes:
>
> > while I was updating the DarwinPorts Portfile for git, I saw some
> > really suspicious lines in the Makefile of Git for DarwinPorts/Fink.
> >
> > --- snip ---
> > ## fink
> > ifeq ($(shell test -d /sw/lib && echo y),y)
> > ALL_CFLAGS += -I/sw/include
> > ALL_LDFLAGS += -L/sw/lib
> > endif
> > ## darwinports
> > ifeq ($(shell test -d /opt/local/lib && echo y),y)
> > ALL_CFLAGS += -I/opt/local/include
> > ALL_LDFLAGS += -L/opt/local/lib
> > endif
> > --- snap ---
> >
> > IMHO, Git should definetely not include /sw/include and /sw/lib, just
> > if it *exists*.
[snip]
> But I suspect that the "official" portfile (or whatever it is
> called in the Darwin world) should be able to override whatever
> is done in there --- otherwise we would need to remove them or
> comment them out, but I am hoping it does not have to come to
> that; I think they serve as good hint to help people who are
> building from the source.
The quoted section of the Makefile was mostly my fault. GIT used
to build only against Fink but when I switched to DarwinPorts it
was first not even looking for them and second when I removed Fink
the Mac OS X linker was warning about /sw/lib not existing.
I completely agree that its incorrect to be doing this all of the
time as a higher-level build driver (e.g. Portfile) should be able
to have more direct control CFLAGS and LDFLAGS. Perhaps something
like this?
diff --git a/Makefile b/Makefile
index a1666e2..0a48c32 100644
--- a/Makefile
+++ b/Makefile
@@ -268,14 +268,18 @@ ifeq ($(uname_S),Darwin)
NEEDS_LIBICONV = YesPlease
NO_STRLCPY = YesPlease
## fink
- ifeq ($(shell test -d /sw/lib && echo y),y)
- BASIC_CFLAGS += -I/sw/include
- BASIC_LDFLAGS += -L/sw/lib
+ ifndef NO_FINK
+ ifeq ($(shell test -d /sw/lib && echo y),y)
+ BASIC_CFLAGS += -I/sw/include
+ BASIC_LDFLAGS += -L/sw/lib
+ endif
endif
+ ifndef NO_DARWIN_PORTS
## darwinports
- ifeq ($(shell test -d /opt/local/lib && echo y),y)
- BASIC_CFLAGS += -I/opt/local/include
- BASIC_LDFLAGS += -L/opt/local/lib
+ ifeq ($(shell test -d /opt/local/lib && echo y),y)
+ BASIC_CFLAGS += -I/opt/local/include
+ BASIC_LDFLAGS += -L/opt/local/lib
+ endif
endif
endif
ifeq ($(uname_S),SunOS)
--
Shawn.
^ permalink raw reply related
* Re: [OT] OLS slides
From: Petr Baudis @ 2006-07-22 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvepqi6x6.fsf@assigned-by-dhcp.cox.net>
Hi,
Dear diary, on Sat, Jul 22, 2006 at 06:45:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> My slides (with full transcripts) are available at
>
> http://members.cox.net/junkio/200607-ols.pdf
and my slides are at http://pasky.or.cz/ols-cogito/ (I've added
another two or three slides to cover some stuff I've only spoken about
at the tutorial).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-22 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607220547570.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sat, 22 Jul 2006, Petr Baudis wrote:
> > Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > > Think "changed templates".
> >
> > it may be that I'm just tired, but I don't see what you mean, sorry.
>
> If you change a template (like add a hook or something), you can call
> git-init-db in an existing repository to update that hook.
ah well, I guess that's obscure enough to tell the user to directly
run git-init-db. ;-)
> > > And also think "setup a remote repository", especially "setup a remote
> > > HTTP repository".
> >
> > Of course. Currently you need to tinker with environment variables,
> > then with hooks, possibly with permissions and stuff to make the
> > repository shared... Think cg-admin-setuprepo. ;-)
>
> git-init-db --shared
And the environment variable and the chgrp and g+s. That's my point.
> > > And also think "start a new repository with only a _part_ of the current
> > > files". There are plenty reasons -- in addition to separation of concepts
> > > -- not to commit straight after initializing a repository.
> >
> > So what _do_ you do if you don't commit straight?
>
> Sometimes, I do "git-push just@initted.repository.com master". From
> somewhere else, of course.
I guess that's more common for the bare repositories.
> And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".
git-cvsimport will create the repository for you, won't it?
> > Of course sometimes you don't want to add everything, and that should
> > still be possible to do (cg-init has a switch for that).
>
> Usually I start small projects as a single .c or .java file. Only after a
> while, I think it is worth it to init a git database. So, I _always_ have
> generated files lying around. And I would hate it if they were checked in
> automatically. (Yeah, I could remove them, _then_ remove them from the
> index, and then git-commit --amend. Ugly.)
Can't you just do make clean before git init? Or you can prepare
.gitignore before you check stuff in, so that the autogenerated files
don't pollute your git status output. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Random Git Issues/Wishlist
From: Petr Baudis @ 2006-07-22 19:55 UTC (permalink / raw)
To: git
Hi,
this is a random list of issues that come up in my mind when I was
thinking about things we could discuss at the Git BOF at OLS in case
enought Git developers gathered - which of course didn't happen but
perhaps it might be useful to mention them as well. Feel free to follow
up with *your* stuff (and comments or patches, of course).
(i) libgit - right now it has just evolved from bundling random Git
internal calls and has no defined API whatsoever; luckily, nothing
external hopefully uses it yet. If we wait much longer, people will
probably start to and we might start getting into a trouble there.
Another thing is what to do with the builtins, shall we bundle most of
the code in libgit? If not, many libgit users will probably end up just
reimplementing large chunks of their functionality. I've actually
thought about also interfacing libbuiltin.so when doing Git.pm but I
didn't yet for the sake of simplicity.
(ii) Documentation - it's currently very bad. Incomplete, out of sync,
missing tons of parameters and other things, and so on. We should be
more responsible when adding features to always document them right
away.
(iii) Lazy clone, shallow clone, whatever you call it. This has
several possible degrees of implementation:
(a) Just being able to get the latest revision (this really
shouldn't be that hard to do)
(b) Arbitrarily cut off the revisions at some point; this means
that you will get _some_ repository but with incomplete
history and we should handle that sensibly, like...
(c) ...having kind of "remote alternates", which means that if
we hit an object we don't have we will look it remotely as
well; this means moving the remote access functions much
more inside the really core Git; we want to be smart and
e.g. bundle tree requests with all the msisingblob requests
and so on; we don't want to fetch *everything* when the
user just does git log, though
(d) As an extension of (a), having some side of server-client
stuff which would also know how to do rev-lists and such
remotely; I'm not sure if the demand here is big enough
to justify that
(iv) Packing - I really feel bad about requiring users to manually
repack periodically, and also that's hurting the dumb server users
unless you take special provisions and so on
(v) Subprojects support; in a sort of long-term limbo because I guess
everyone is too lazy to finally implement something and the users aren't
loud enough ;-) (or they just moved on to another VCS)
(vi) Renames - should we follow them in logs? Will we? When? How
exactly in the interesting cases?
(vii) Private tags. refs/private or refs/tags/.hidden? Will we even?
When?
(viii) Patches versioning in StGit - many people I've told about StGit
complained that it doesn't version patches (and possibly moved to mq?).
We should have some scheme for doing meta-history (especially
interesting when/if we aim to make altering history easy).
(ix) What about the user survey? It sorta stalled, as far as I can
see.
(x) Metainformation over the Git protocol - kernel.org wants this
badly because rsyncing the repositories leads to *endless* problems;
there are some more complicated rsync schemes possible but hpa would be
happiest with making it possible to just use git to sync the
repositories out; this might be in part dependent on (iv) since the
repository maintainers basically lose control over the packing
(xi) Annotate or blame? Most people seem to be in favour of blome,
but having both is confusing; by now one of them should've already won.
(xii) Special merging - I now maintian the SuSE glibc package in git
and I'd like to use something more sensible than diff3 merger for
merging the changelogs from various branches; it's trivially solvable
conflicts all the time
(xiii) General user interface issues, like confusing error messages,
incomplete usage help, needlessly complicated (see our git init
discussion in the other thread) or inconsistent usage (git rebase,
anyone?) in general and other stuff aside of (ii).
That's probably all you'll hear from me for now, I guess. It's your
turn now.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git BOF notes
From: Timo Hirvonen @ 2006-07-22 20:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes.Schindelin, git
In-Reply-To: <20060722191652.GR13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> > Usually I start small projects as a single .c or .java file. Only after a
> > while, I think it is worth it to init a git database. So, I _always_ have
> > generated files lying around. And I would hate it if they were checked in
> > automatically. (Yeah, I could remove them, _then_ remove them from the
> > index, and then git-commit --amend. Ugly.)
>
> Can't you just do make clean before git init? Or you can prepare
> .gitignore before you check stuff in, so that the autogenerated files
> don't pollute your git status output. ;-)
I like git init-db as it is now. I don't want it to automatically add
files. GIT does what you ask it to do, not what it _thinks_ you want to
do.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Git BOF notes
From: Nguyễn Thái Ngọc Duy @ 2006-07-22 20:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: Petr Baudis, J. Bruce Fields, git
In-Reply-To: <81b0412b0607210802q4d48b277yc4c45d4acbd890a6@mail.gmail.com>
On 7/21/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/21/06, Petr Baudis <pasky@suse.cz> wrote:
> > I don't know if there's a point in being so paranoid - it already makes
> > things more painful than necessary. In the tracking branch, you just
> > want to have what the other side has anyway, and if the other side
> > decided to jump around, why would you care otherwise?
>
> But for the ones who do care, it is much harder to notice. Even if it is
> a warning (it gets lost in crontab logs).
Then create some lost+found branches for them?
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Paolo Ciarrocchi @ 2006-07-22 21:00 UTC (permalink / raw)
To: Petr Baudis, Martin Langhoff; +Cc: git
In-Reply-To: <20060722195502.GS13776@pasky.or.cz>
On 7/22/06, Petr Baudis <pasky@suse.cz> wrote:
[...]
> (ix) What about the user survey? It sorta stalled, as far as I can
> see.
Here it is the latest version:
About you
1. What country are you in?
2. What is your preferred language?
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
3. What helped you most in learning to use it?
4. When did you start using git?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
3. What hardware platforms do you use GIT on?
4. What OS (please include the version) do you use GIT on?
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the history)
7. How many different projects do you manage using GIT?
8. Which porcelains do you use?
9. Is the git.git repository including codes produced by you?
What you think of GIT
1. Overall, how happy are you with GIT?
2. How does GIT compare to other SCM tools you have used?
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plugins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Documentation
1. Do you use the GIT wiki? If yes, do you find it useful?
2. Do you find GIT's online help useful?
3. What is your favourite user documentation for any software
projects or products you have used?
4. What could be improved on the GIT homepage?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
* If yes, did you get these problems resolved quickly and to
your liking?
2. Do you subscribe to the mailing list?
* If yes, do you find it useful, and traffic levels OK?
3. Do you use the IRC channel (#git on irc.freenode.net)?
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
Sorry for not following closely this topic but unfortunately I had
personal problems.
Martin, can you upload the survey to survey.net.nz as we privately discussed?
If not, I'll sending out it in the next following days.
Thanks.
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Defaulting fetch to origin when set in the repo-config
From: Santi Béjar @ 2006-07-22 22:54 UTC (permalink / raw)
To: git
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
diff --git a/git-fetch.sh b/git-fetch.sh
index a393a50..c2eebee 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -70,7 +70,8 @@ case "$#" in
0)
test -f "$GIT_DIR/branches/origin" ||
test -f "$GIT_DIR/remotes/origin" ||
- die "Where do you want to fetch from today?"
+ git-repo-config --get remote.origin.url >/dev/null ||
+ die "Where do you want to fetch from today?"
set origin ;;
esac
^ permalink raw reply related
* Re: Random Git Issues/Wishlist
From: Martin Langhoff @ 2006-07-23 0:12 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Petr Baudis, git
In-Reply-To: <4d8e3fd30607221400j1839883es6c948464cdf22439@mail.gmail.com>
> Martin, can you upload the survey to survey.net.nz as we privately discussed?
Done. this is what it looks like:
http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50
I'll send you the login details to modify it. I've changed a few
things ever so slightly so it made sense when boiled down to an array
of radio buttons and text boxes. Survey.net doesn't quite support
"section titles" so I added the section title to the first question of
the set, hoping for a "conversational" approach to introducing the
section to the user.
The best way to edit it is by downloading the text file, editing in
$EDITOR and posting it back. the format is trivial, and explained here
http://survey.net.nz/index.php?page=faq under "Upload Survey".
cheers,
martin
^ permalink raw reply
* :), mother-in-law
From: Rafael Mead @ 2006-07-23 4:00 UTC (permalink / raw)
To: git-commits-head-owner
Genuine Swiss made Role3x repilcas are as close to the real thing
as a repilca watch can be. Sometimes even the professional jewelers
are unable to tell the difference from the real RoleJx watch.
Why spend thousands of dollars on the real deal when
a repilca watch looks so much alike that only an expert could tell the difference...
And you only pay a fractoin of the price.
VISIT US, AND GET OUR SPECIL 370% DIS1COUNT OFER!
http://4PAQO3Rn3sgaotdbtbgo553a5nlsnn5.madwortmj.com/
=====
in his eye. "Me leading? What do you mean, me leading? You're the
one with acid, squash it under a press, or melt it in an oven. And then he
"No, Jonathan, there is no such place. Heaven is not a place, and it
hundred feet of clear space either on your left or your right. So, we can go
and it was time to go home.
and ordered a flying boot. I looked over his map to see what was on it. It
extended into the wind, and fell into a vertical dive.
was sick and he had gone for the doctor. Apologized for being late. Well, we
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Shawn Pearce @ 2006-07-23 4:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060722195502.GS13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> (iii) Lazy clone, shallow clone, whatever you call it. This has
> several possible degrees of implementation:
I'd love to work on this, but I just don't have time. :-(
> (vi) Renames - should we follow them in logs? Will we? When? How
> exactly in the interesting cases?
I thought this has been settled as ``we will not record renames
directly, but instead rely on after-the-fact comparsions to identify
renames and copies based on content similarity''.
The rename identification code in diffcore isn't the fastest, but
I think someone suggested caching the results of rename comparsions
under .git as a way of speeding that up. Unfortunately nobody has
stepped forward with a reasonable caching implementation, and I
think it was also debated that caching is probably not worthwhile
due to the high number of permutations people would typically be
asking for from diffcore.
> (viii) Patches versioning in StGit - many people I've told about StGit
> complained that it doesn't version patches (and possibly moved to mq?).
> We should have some scheme for doing meta-history (especially
> interesting when/if we aim to make altering history easy).
Doesn't StGit now have a single ref for every patch commit?
What about turning on reflog support on those refs and reading the
reflog for the ``history'' of that patch? Granted the reflog isn't
prune proof but it is a history of that ref's values over time.
You can already go back in that history with the @{yesterday}
syntax (e.g. "HEAD@{yesterday}") anywhere a sha1 expression is
valid (e.g. git-log) but StGit doesn't take advantage of it.
> (xii) Special merging - I now maintian the SuSE glibc package in git
> and I'd like to use something more sensible than diff3 merger for
> merging the changelogs from various branches; it's trivially solvable
> conflicts all the time
I've been waiting for the C based recursive merger to get stable
before I take a crack at parameterizing the `merge` invocation.
I much prefer using patch reject files for conflict resolution,
but that's just me. (Besides opening a single patch process and
shoving a stream of all diffs at it is faster on Cygwin than forking
30+ merge processes for 30 files with conflicts.)
I take it you are really asking for a way to parameterize the 3 way
merge tool on a file-by-file basis, e.g. adding to the config file:
[mergetool "default"]
program = merge %real %stage1 %stage3
real = stage2
[mergetool "ChangeLog"]
program = change-log-merger %stage1 %stage2 %stage3 %real
[mergetool "some/bad/binary-file"]
program = cp %stage2 %real
An issue with storing this data in the config file is what happens
if the stuff stored at the path "some/bad/binary-file" changes such
that simply using `cp` (as above) is horribly wrong. Another is how
do you pass these "reasonable defaults" off to other team members
on a repository-by-repository basis, assuming you all have access
to the same tools (e.g. the change-log-merger mentioned above).
--
Shawn.
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Shawn Pearce @ 2006-07-23 5:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Pfetzing, git
In-Reply-To: <20060722161914.GA10754@spearce.org>
This is a slightly cleaner version of my prior patch. :-)
-->8--
Disable linking with Fink or DarwinPorts.
It may be desirable for the compiler to disable linking against Fink
or DarwinPorts, especially if both are installed on the system and
the user wants GIT to be linked specifically to only one of them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index a1666e2..99a84cc 100644
--- a/Makefile
+++ b/Makefile
@@ -267,15 +267,17 @@ ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
NO_STRLCPY = YesPlease
- ## fink
- ifeq ($(shell test -d /sw/lib && echo y),y)
- BASIC_CFLAGS += -I/sw/include
- BASIC_LDFLAGS += -L/sw/lib
+ ifndef NO_FINK
+ ifeq ($(shell test -d /sw/lib && echo y),y)
+ BASIC_CFLAGS += -I/sw/include
+ BASIC_LDFLAGS += -L/sw/lib
+ endif
endif
- ## darwinports
- ifeq ($(shell test -d /opt/local/lib && echo y),y)
- BASIC_CFLAGS += -I/opt/local/include
- BASIC_LDFLAGS += -L/opt/local/lib
+ ifndef NO_DARWIN_PORTS
+ ifeq ($(shell test -d /opt/local/lib && echo y),y)
+ BASIC_CFLAGS += -I/opt/local/include
+ BASIC_LDFLAGS += -L/opt/local/lib
+ endif
endif
endif
ifeq ($(uname_S),SunOS)
--
1.4.2.rc1.ge711
^ permalink raw reply related
* [PATCH] pack-objects: check pack.window for default window size
From: Jeff King @ 2006-07-23 5:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jeff King <peff@peff.net>
---
For some repositories, deltas simply don't make sense. One can disable
them for git-repack by adding --window, but git-push insists on making
the deltas which can be very CPU-intensive for little benefit.
Documentation/config.txt | 4 ++++
pack-objects.c | 13 ++++++++++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0b434c1..bc43da8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -193,6 +193,10 @@ merge.summary::
Whether to include summaries of merged commits in newly created
merge commit messages. False by default.
+pack.window::
+ The size of the window used by gitlink:git-pack-objects[1] when no
+ window size is given on the command line. Defaults to 10.
+
pull.octopus::
The default merge strategy to use when pulling multiple branches
at once.
diff --git a/pack-objects.c b/pack-objects.c
index 04a48b9..861c7f0 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -63,6 +63,7 @@ static const char *base_name;
static unsigned char pack_file_sha1[20];
static int progress = 1;
static volatile sig_atomic_t progress_update = 0;
+static int window = 10;
/*
* The object names in objects array are hashed with this hashtable,
@@ -1216,16 +1217,26 @@ static void setup_progress_signal(void)
setitimer(ITIMER_REAL, &v, NULL);
}
+static int git_pack_config(const char *k, const char *v)
+{
+ if(!strcmp(k, "pack.window")) {
+ window = git_config_int(k, v);
+ return 0;
+ }
+ return git_default_config(k, v);
+}
+
int main(int argc, char **argv)
{
SHA_CTX ctx;
char line[40 + 1 + PATH_MAX + 2];
- int window = 10, depth = 10, pack_to_stdout = 0;
+ int depth = 10, pack_to_stdout = 0;
struct object_entry **list;
int num_preferred_base = 0;
int i;
setup_git_directory();
+ git_config(git_pack_config);
progress = isatty(2);
for (i = 1; i < argc; i++) {
--
1.4.2.rc1.ge7a0-dirty
^ permalink raw reply related
* Re: Git BOF notes
From: Alex Riesen @ 2006-07-23 7:38 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Petr Baudis, J. Bruce Fields, git
In-Reply-To: <fcaeb9bf0607221312k2088658bqa45e622b7fe244e4@mail.gmail.com>
Nguyễn Thái Ngọc Duy, Sat, Jul 22, 2006 22:12:07 +0200:
> >> I don't know if there's a point in being so paranoid - it already makes
> >> things more painful than necessary. In the tracking branch, you just
> >> want to have what the other side has anyway, and if the other side
> >> decided to jump around, why would you care otherwise?
> >
> >But for the ones who do care, it is much harder to notice. Even if it is
> >a warning (it gets lost in crontab logs).
>
> Then create some lost+found branches for them?
if you copy files from ext3 to vfat, do you expect them to be found in
lost+found? Usually not, I believe. It should either fail or copy.
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Paolo Ciarrocchi @ 2006-07-23 8:18 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Petr Baudis, git
In-Reply-To: <46a038f90607221712gadae5b3tde2de4653fcc9e69@mail.gmail.com>
On 7/23/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > Martin, can you upload the survey to survey.net.nz as we privately discussed?
>
> Done. this is what it looks like:
>
> http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50
>
> I'll send you the login details to modify it. I've changed a few
> things ever so slightly so it made sense when boiled down to an array
> of radio buttons and text boxes. Survey.net doesn't quite support
> "section titles" so I added the section title to the first question of
> the set, hoping for a "conversational" approach to introducing the
> section to the user.
>
> The best way to edit it is by downloading the text file, editing in
> $EDITOR and posting it back. the format is trivial, and explained here
> http://survey.net.nz/index.php?page=faq under "Upload Survey".
Thanks a lot Martin! I will send out an announce in a few minutes.
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* GIT user survey
From: Paolo Ciarrocchi @ 2006-07-23 8:23 UTC (permalink / raw)
To: Git Mailing List
Hi all,
We would like to ask you a few questions about your use of the GIT
version control system. This survey is mainly to understand who is
using GIT, how and why.
The results will be published to the git wiki and discussed on the git
mailing list.
We'll close the survey in two weeks starting from today, 23rd of July.
Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of git and of course what you don't like of it.
The survey can be found here:
http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50
Kind regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: GIT user survey
From: Paolo Ciarrocchi @ 2006-07-23 8:45 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <4d8e3fd30607230123m459aa1cle2ab8c1c1dd0fcd2@mail.gmail.com>
On 7/23/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
[...]
>
> The survey can be found here:
> http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50
If you know people using GIT please forward this message to them,
currently is has been sent to the following projects:
- u-boot
- wine
- cairo
- xmms2
-xcb
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* [RFC] Colorize 'commit' lines in log ui
From: Jeff King @ 2006-07-23 9:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
When paging through the output of git-whatchanged, the color cues help to
visually navigate within a diff. However, it is difficult to notice when a
new commit starts, because the commit and log are shown in the "normal"
color. This patch colorizes the 'commit' line, customizable through
diff.colors.commit and defaulting to yellow.
As a side effect, some of the diff color engine (slot enum, get_color) has
become accessible outside of diff.c.
Signed-off-by: Jeff King <peff@peff.net>
---
I think the visual cue makes the git-whatchanged -p output much easier
to read.
I originally thought of making a "colorized commit" patch where you
could independently set commit.color and commit.color.*. However, it was
clearly much simpler to start by using the diff engine's code.
1. Do people really want to colorize the commit outside of colorizing
the diffs, anyway? It makes sense for the code to go together.
2. Should we call it something other than diff_colors (since now it's
handling the commit log, too)?
It currently just colorizes the 'commit' line. We could also do the
'Author' and 'Date' lines (either as the same color, or independently),
as well as the log text.
It colorizes all formats given to show_log() except CMIT_FMT_EMAIL (so,
e.g., the sha1's in CMIT_FMT_ONELINE will be yellow). Is that what we
want?
diff.c | 28 +++++++++++-----------------
diff.h | 11 +++++++++++
log-tree.c | 5 ++++-
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/diff.c b/diff.c
index 8b44756..6a71376 100644
--- a/diff.c
+++ b/diff.c
@@ -17,15 +17,6 @@ static int diff_detect_rename_default =
static int diff_rename_limit_default = -1;
static int diff_use_color_default = 0;
-enum color_diff {
- DIFF_RESET = 0,
- DIFF_PLAIN = 1,
- DIFF_METAINFO = 2,
- DIFF_FRAGINFO = 3,
- DIFF_FILE_OLD = 4,
- DIFF_FILE_NEW = 5,
-};
-
/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
static char diff_colors[][24] = {
"\033[m", /* reset */
@@ -33,7 +24,8 @@ static char diff_colors[][24] = {
"\033[1m", /* bold */
"\033[36m", /* cyan */
"\033[31m", /* red */
- "\033[32m" /* green */
+ "\033[32m", /* green */
+ "\033[33m" /* yellow */
};
static int parse_diff_color_slot(const char *var, int ofs)
@@ -48,6 +40,8 @@ static int parse_diff_color_slot(const c
return DIFF_FILE_OLD;
if (!strcasecmp(var+ofs, "new"))
return DIFF_FILE_NEW;
+ if (!strcasecmp(var+ofs, "commit"))
+ return DIFF_COMMIT;
die("bad config variable '%s'", var);
}
@@ -370,7 +364,7 @@ struct emit_callback {
const char **label_path;
};
-static inline const char *get_color(int diff_use_color, enum color_diff ix)
+const char *diff_get_color(int diff_use_color, enum color_diff ix)
{
if (diff_use_color)
return diff_colors[ix];
@@ -381,8 +375,8 @@ static void fn_out_consume(void *priv, c
{
int i;
struct emit_callback *ecbdata = priv;
- const char *set = get_color(ecbdata->color_diff, DIFF_METAINFO);
- const char *reset = get_color(ecbdata->color_diff, DIFF_RESET);
+ const char *set = diff_get_color(ecbdata->color_diff, DIFF_METAINFO);
+ const char *reset = diff_get_color(ecbdata->color_diff, DIFF_RESET);
if (ecbdata->label_path[0]) {
printf("%s--- %s%s\n", set, ecbdata->label_path[0], reset);
@@ -397,7 +391,7 @@ static void fn_out_consume(void *priv, c
;
if (2 <= i && i < len && line[i] == ' ') {
ecbdata->nparents = i - 1;
- set = get_color(ecbdata->color_diff, DIFF_FRAGINFO);
+ set = diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO);
}
else if (len < ecbdata->nparents)
set = reset;
@@ -410,7 +404,7 @@ static void fn_out_consume(void *priv, c
else if (line[i] == '+')
color = DIFF_FILE_NEW;
}
- set = get_color(ecbdata->color_diff, color);
+ set = diff_get_color(ecbdata->color_diff, color);
}
if (len > 0 && line[len-1] == '\n')
len--;
@@ -767,8 +761,8 @@ static void builtin_diff(const char *nam
mmfile_t mf1, mf2;
const char *lbl[2];
char *a_one, *b_two;
- const char *set = get_color(o->color_diff, DIFF_METAINFO);
- const char *reset = get_color(o->color_diff, DIFF_RESET);
+ const char *set = diff_get_color(o->color_diff, DIFF_METAINFO);
+ const char *reset = diff_get_color(o->color_diff, DIFF_RESET);
a_one = quote_two("a/", name_a);
b_two = quote_two("b/", name_b);
diff --git a/diff.h b/diff.h
index a06f959..2cced53 100644
--- a/diff.h
+++ b/diff.h
@@ -69,6 +69,17 @@ struct diff_options {
add_remove_fn_t add_remove;
};
+enum color_diff {
+ DIFF_RESET = 0,
+ DIFF_PLAIN = 1,
+ DIFF_METAINFO = 2,
+ DIFF_FRAGINFO = 3,
+ DIFF_FILE_OLD = 4,
+ DIFF_FILE_NEW = 5,
+ DIFF_COMMIT = 6,
+};
+const char *diff_get_color(int diff_use_color, enum color_diff ix);
+
extern const char mime_boundary_leader[];
extern void diff_tree_setup_paths(const char **paths, struct diff_options *);
diff --git a/log-tree.c b/log-tree.c
index 9d8d46f..b71cf9b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -129,7 +129,8 @@ void show_log(struct rev_info *opt, cons
opt->diffopt.stat_sep = buffer;
}
} else {
- printf("%s%s",
+ printf("%s%s%s",
+ diff_get_color(opt->diffopt.color_diff, DIFF_COMMIT),
opt->commit_format == CMIT_FMT_ONELINE ? "" : "commit ",
diff_unique_abbrev(commit->object.sha1, abbrev_commit));
if (opt->parents)
@@ -139,6 +140,8 @@ void show_log(struct rev_info *opt, cons
diff_unique_abbrev(parent->object.sha1,
abbrev_commit));
putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
+ printf("%s",
+ diff_get_color(opt->diffopt.color_diff, DIFF_RESET));
}
/*
--
1.4.2.rc1.gc470-dirty
^ permalink raw reply related
* Re: [RFC] Colorize 'commit' lines in log ui
From: Jan-Benedict Glaw @ 2006-07-23 11:24 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20060723092417.GA7547@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Sun, 2006-07-23 05:24:18 -0400, Jeff King <peff@peff.net> wrote:
> @@ -33,7 +24,8 @@ static char diff_colors[][24] = {
> "\033[1m", /* bold */
> "\033[36m", /* cyan */
> "\033[31m", /* red */
> - "\033[32m" /* green */
> + "\033[32m", /* green */
> + "\033[33m" /* yellow */
> };
>
> static int parse_diff_color_slot(const char *var, int ofs)
If people only were used to *always* place a comma behind the last
array element, the diff would be shorter by one line each time...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: ...und wenn Du denkst, es geht nicht mehr,
the second : kommt irgendwo ein Lichtlein her.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Jakub Narebski @ 2006-07-23 13:00 UTC (permalink / raw)
To: git
In-Reply-To: <20060723054531.GA12559@spearce.org>
Shawn Pearce wrote:
> This is a slightly cleaner version of my prior patch. :-)
>
> -->8--
> Disable linking with Fink or DarwinPorts.
>
> It may be desirable for the compiler to disable linking against Fink
> or DarwinPorts, especially if both are installed on the system and
> the user wants GIT to be linked specifically to only one of them.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Could you _please_ document this option in commentary part in main Makefile?
TIA.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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