* [PATCH] Add Makefile check for FreeBSD 4.9-SECURITY
From: David M. Syzdek @ 2008-10-26 11:52 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek
If the system is FreeBSD 4.9, then NO_UINTMAX_T and NO_STRTOUMAX is defined.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index bf6a6dc..c568314 100644
--- a/Makefile
+++ b/Makefile
@@ -679,6 +679,10 @@ ifeq ($(uname_S),FreeBSD)
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
+ ifeq ($(uname_R),4.9-SECURITY)
+ NO_UINTMAX_T = YesPlease
+ NO_STRTOUMAX = YesPlease
+ endif
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
--
1.6.0.2.GIT
^ permalink raw reply related
* [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: David M. Syzdek @ 2008-10-26 11:52 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek
This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then
uintmax_t is defined as uint32_t. This adds a test to configure.ac for
uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
Makefile | 3 +++
config.mak.in | 1 +
configure.ac | 8 ++++++++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 0d40f0e..bf6a6dc 100644
--- a/Makefile
+++ b/Makefile
@@ -931,6 +931,9 @@ endif
ifdef NO_IPV6
BASIC_CFLAGS += -DNO_IPV6
endif
+ifdef NO_UINTMAX_T
+ BASIC_CFLAGS += -Duintmax_t=uint32_t
+endif
ifdef NO_SOCKADDR_STORAGE
ifdef NO_IPV6
BASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in
diff --git a/config.mak.in b/config.mak.in
index b776149..c6558eb 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -39,6 +39,7 @@ NO_C99_FORMAT=@NO_C99_FORMAT@
NO_STRCASESTR=@NO_STRCASESTR@
NO_MEMMEM=@NO_MEMMEM@
NO_STRLCPY=@NO_STRLCPY@
+NO_UINTMAX_T=@NO_UINTMAX_T@
NO_STRTOUMAX=@NO_STRTOUMAX@
NO_SETENV=@NO_SETENV@
NO_UNSETENV=@NO_UNSETENV@
diff --git a/configure.ac b/configure.ac
index d3b8bc3..d9de93f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -415,6 +415,14 @@ AC_CHECK_FUNC(strlcpy,[
[NO_STRLCPY=YesPlease])
AC_SUBST(NO_STRLCPY)
#
+# Define NO_UINTMAX_T if your platform does not have uintmax_t
+AC_CHECK_TYPE(uintmax_t,
+[NO_UINTMAX_T=],
+[NO_UINTMAX_T=YesPlease],[
+#include <inttypes.h>
+])
+AC_SUBST(NO_UINTMAX_T)
+#
# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
AC_CHECK_FUNC(strtoumax,[
AC_SEARCH_LIBS(strtoumax,,
--
1.6.0.2.GIT
^ permalink raw reply related
* Feature request: git-log should optionally include tags
From: Roger Leigh @ 2008-10-26 12:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]
A feature I would very much like to have in git is to have tag
information included in the log generated by git-log. This would
make it easy to see where the tags are in the history. The use
case for us would be to have release tags displayed so that it's
possible to identify which revisions constitute release points,
which is useful for e.g. users to identify points for bisection.
I can do it now using sed to substitute in the contents of
.git/refs/tags/*, but having the functionality in git-log directly
would be most useful.
Regards,
Roger Leigh
Example of existing log:
----------------------------------------------------------------------
commit 62dca2fc0e5e356ecb24ea0d8bd9f04980ab4cbe
Author: Roger Leigh <rleigh@debian.org>
Date: Mon Oct 13 00:31:03 2008 +0100
[Sbuild::Build] Add and use log_info, _warning and _error functions
----------------------------------------------------------------------
Example of log including tags:
----------------------------------------------------------------------
commit 62dca2fc0e5e356ecb24ea0d8bd9f04980ab4cbe
Author: Roger Leigh <rleigh@debian.org>
Date: Mon Oct 13 00:31:03 2008 +0100
Tags: sbuild-0.60.1
[Sbuild::Build] Add and use log_info, _warning and _error functions
----------------------------------------------------------------------
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Feature request: git-log should optionally include tags
From: Mikael Magnusson @ 2008-10-26 12:47 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081026121326.GA3399@codelibre.net>
2008/10/26 Roger Leigh <rleigh@whinlatter.ukfsn.org>:
> A feature I would very much like to have in git is to have tag
> information included in the log generated by git-log. This would
> make it easy to see where the tags are in the history. The use
> case for us would be to have release tags displayed so that it's
> possible to identify which revisions constitute release points,
> which is useful for e.g. users to identify points for bisection.
>
> I can do it now using sed to substitute in the contents of
> .git/refs/tags/*, but having the functionality in git-log directly
> would be most useful.
git log --decorate
--
Mikael Magnusson
^ permalink raw reply
* Re: Feature request: git-log should optionally include tags
From: Roger Leigh @ 2008-10-26 12:52 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Roger Leigh, git
In-Reply-To: <237967ef0810260547o4e2143e0jc9403da7b1f4d85a@mail.gmail.com>
On Sun, Oct 26, 2008 at 01:47:44PM +0100, Mikael Magnusson wrote:
> 2008/10/26 Roger Leigh <rleigh@whinlatter.ukfsn.org>:
> > A feature I would very much like to have in git is to have tag
> > information included in the log generated by git-log. This would
> > make it easy to see where the tags are in the history. The use
> > case for us would be to have release tags displayed so that it's
> > possible to identify which revisions constitute release points,
> > which is useful for e.g. users to identify points for bisection.
> >
> > I can do it now using sed to substitute in the contents of
> > .git/refs/tags/*, but having the functionality in git-log directly
> > would be most useful.
>
> git log --decorate
Many thanks!
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 14:15 UTC (permalink / raw)
To: git; +Cc: mercurial
In-Reply-To: <ge0rla$mce$1@ger.gmane.org>
[Cc: gmane.comp.version-control.git,
gmane.comp.version-control.mercurial.general]
walt <w41ter@gmail.com> writes:
> No, no, I'm not the one calling for a vote. You old-timers here
> will know the name Matt Dillon, who is leading the dragonflybsd
> project (www.dragonflybsd.org).
>
> Matt is the one who is calling for the vote in his thread "Vote
> for your source control system" in the dragonfly.kernel group,
> accessible via nntp://nntp.dragonflybsd.org.
>
> I've already cast my vote for git, which I confess is not very
> honest because I've never even tried mercurial. I would truly
> be grateful to anyone here who knows both git and mercurial who
> could contribute verifiable facts to that debate.
I also used only Git, but I have read a bit about Mercurial; however
the information I have on Mercurial might be out of date.
Below I have tried to compare Git with Mercurial, pointing the most
important (to me) facts:
1. Documentation and ease of use.
Mercurial is supposedly better documented and easier to use; I
think this descends from the early days of Git, where it was not
very user friendly. IMHO Git has much improved since. Mercurial
had 'hgbook' from the beginning; Git User's Manual is more recent.
I also think that ease of use is just different learning curve.
I am also biased and I think that Mercurial starts easy, but it has
more difficult things (like e.g. merging, multiple branches in
single repository etc.) harder than it Git.
I'll admit that Mercurial UI is better designed; Git UI was not as
much designed as it evolved from 'stupid content tracker' to
full-featured SCM, therefore there are a few oddities (for example
git-revert might do not what you expect, if you are accustomed to
Subversion UI).
2. Implementation, portability, bindings and extending
Mercurial is implemented in Python, with core written in C for
better performance. It has a plugin system, and additional extra
features implemented through extensions. I don't know what is the
status of bindings (or implementations) in other programming
languages; but it has some API for use in extensions at least.
Git is implemented as mixture of C, shell scripts, Perl and Tcl/Tk
(for GUI). The main way of extending it is by scripting around
powerfull set of low level tools, called 'plumbing', meant to be
used in scripts. JGit is for example _reimplementation_ of Git in
Java.
3. Repository design and performance.
Git is designed around idea of content adressed object database;
objects are adressed by their content (by SHA-1 of their type and
content). Commits for example have information about author and
comitter, pointer to zero or more parent commits, and pointer to
tree object (representing top directory in project). Branches
and tags are just pointers to DAG (Direct Acyclic Graph) of
commits; current branch is denoted by HEAD pointer to branch.
There is explicit staging area called 'index', used for conflict
resolution dureing merges, and which can be used to make commit in
stages, allow uncomitted changes in tree (in working directory).
Git design supports very well multiple branches in single
repository, and tracking changes in multiple remote repositories
each with multiple branches.
Mercurial, from what I have read of its documentation, and from the
few discussion on #revctrl IRC channel, and from what I understand
is based on changes stored per file, with information about files
and their versions stored in manifest (flat) file, and with changes
described in changelog-like file (changerev). One of limitations
of "record" database (as opposed to Git's object database) is that
commits can have zero (root commit), one or two (merge commits)
parents only. There is apparent in design that Mercurial was
developed with single branch per repository paradigm in mind.
Local branches from what I understand are marked in CVS-like
fashion using tags. Tags are implemented as either local to
repository and untransferable, or as .hgtags versioned file with
special case treatment. (But I'm obviously biased here).
Git and Mercurial have similar performance, although it is thought
that due to design Mercurla has faster patch applying and is
optimized for cold cache case, while Git has faster merging and is
optimized for warm cache case.
Mercurial may have (or had) problems with larger binary files, from
what I have heard.
3. Advanced features, interfaces and tools
I don't know much about Mercurial beside basic usage, what I
remember from 'hgbook', but I think that most if not all advanced
Git features are available either in Mercurial core, or as
Mercurial extensions (plugins).
For example both Git and Mercurial have bisect command for finding
bug by searching (possibly nonlinear) history for commit which
introduced bug, ForestExtension is rough equivalent of git
submodules (or third party git-externals), there is Transplain
extension for git-rebase, etc.
Mercurial has hgserve which can function as both web repository
browser and as anonymous server; in Git they are split between
git-daemon for anonymous repository access, and gitweb (or other
web interfaces: cgit, git-php, ViewGit, Gitorious,..) for web
interface.
NOTE: In Git repacking and garbage collecting is explicit
(although can be automated with "git gc --auto", and some of it
happens automatically); Git use _rename detection_ rather than
_rename tracking_, which has its advantages and disadvantages.
They are many articles comparing Mercurial and Git; if they are blog
posts please read the comments too. Among them are:
* "Git vs. Mercurial: Please Relax" (Git is MacGyver, Mercurial
is James Bond)
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
* "The Differences Between Mercurial and Git"
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
* "Git vs. Mercurial"
http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html
* "Git versus Mercurial..."
http://codeheadsystems.wordpress.com/2008/05/10/git-versus-mercurial/
* "Git vs Mercurial"
http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html
Note however that the comparison at "Better SCM Initiative" has some
wrong information about Git: see
* "Git at Better SCM Initiative comparison of VCS (long)"
http://thread.gmane.org/gmane.comp.version-control.git/95809/focus=97253
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Maxim Vuets @ 2008-10-26 14:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: mercurial, git
In-Reply-To: <m3r663h276.fsf@localhost.localdomain>
On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> 1. Documentation and ease of use.
>
> Mercurial is supposedly better documented and easier to use; I
> think this descends from the early days of Git, where it was not
> very user friendly. IMHO Git has much improved since. Mercurial
> had 'hgbook' from the beginning; Git User's Manual is more recent.
Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
Thanks for the comprarision!
--
. Hoc est simplicissimum!
..: maxim.vuets.name
^ permalink raw reply
* Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 14:46 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
% mkdir 1; cd 1
% echo > a; git add a; git commit -m a
% cd ..
% git clone -s 1 2
% git push . master:master
fatal: Could not switch to
'/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
fatal: The remote end hung up unexpectedly
% PATH=/bin:/usr/bin git push . master:master
Everything up-to-date
The same thing happens if i try to push from 1 to 2:
% cd ../1
% git push ../2
fatal: Could not switch to
'/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
fatal: The remote end hung up unexpectedly
% echo $#PATH
196
% echo $PATH
/home/mikaelh/bin:/opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/i686-pc-linux-gnu/gcc-bin/4.2.4:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/usr/local/ipod-chain/bin
d79796bcf05b89774671a75b3285000c43129823 is first bad commit
commit d79796bcf05b89774671a75b3285000c43129823
Author: Junio C Hamano <gitster@pobox.com>
Date: Tue Sep 9 01:27:10 2008 -0700
push: receiver end advertises refs from alternate repositories
Earlier, when pushing into a repository that borrows from alternate object
stores, we followed the longstanding design decision not to trust refs in
the alternate repository that houses the object store we are borrowing
from. If your public repository is borrowing from Linus's public
repository, you pushed into it long time ago, and now when you try to push
your updated history that is in sync with more recent history from Linus,
you will end up sending not just your own development, but also the
changes you acquired through Linus's tree, even though the objects needed
for the latter already exists at the receiving end. This is because the
receiving end does not advertise that the objects only reachable from the
borrowed repository (i.e. Linus's) are already available there.
This solves the issue by making the receiving end advertise refs from
borrowed repositories. They are not sent with their true names but with a
phoney name ".have" to make sure that the old senders will safely ignore
them (otherwise, the old senders will misbehave, trying to push matching
refs, and mirror push that deletes refs that only exist at the receiving
end).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 6d6027ead17b86519d69c3dfc9b98c01e916d277
45e3cd90fd476cdb0a32e5de27739b18e060e031 Mbuiltin-receive-pack.c
:100644 100644 98a742122dbacbb39fa104cdfe909a9a884ed7b6
99af83a0479ef472078afcd288b1f6ba6283a2f0 Mcache.h
:100644 100644 ae550e89c0942bb9e34b252b653c40e869a074a4
12be17b5dace07a2ca71613e4e9093cdb77492ac Msha1_file.c
--
Mikael Magnusson
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Leo Razoumov @ 2008-10-26 15:05 UTC (permalink / raw)
To: Maxim Vuets; +Cc: Jakub Narebski, mercurial, git
In-Reply-To: <e15351d00810260730t1552e04cqb057993581514f3b@mail.gmail.com>
On 10/26/08, Maxim Vuets <maxim.vuets@gmail.com> wrote:
> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> > 1. Documentation and ease of use.
> >
> > Mercurial is supposedly better documented and easier to use; I
> > think this descends from the early days of Git, where it was not
> > very user friendly. IMHO Git has much improved since. Mercurial
> > had 'hgbook' from the beginning; Git User's Manual is more recent.
>
>
> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
>
> Thanks for the comprarision!
I have been using Mercurial for about two years and am very
comfortable with it. Here are some cons and pros
Mercurial PROS:
* Easier and more consistent UI. Newbie friendly.
* Better documentation. IMHO, hgbook is by far better than
http://book.git-scm.com/
* Windows support (personally, I do not care)
Mercurial CONS:
* Less potential than git. Once Ted Tso even said that "git has more
legs than mercurial", see
http://thunk.org/tytso/blog/2007/03/24/git-and-hg/
* Hg is strictly an SCM system while GIT is a content addressable file
system that can be used in other ways, hence the name Global
Information Tracker (GIT)
* Recently, Hg development seems to have somewhat slowed down. To
simply put it, there is not enough room in the world for several
similar SCM systems. With git's pace and momentum the other SCMs
including Hg are fighting an uphill battle.
Just my two cents.
--Leo--
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-26 15:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810240401q57e40b9dj46c35f90681cfa3d@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>>> .file.git/ to track file's history. .file.git/info/excludes is
>>> initialized to the very strong '*' pattern to ensure that things such
>>> as git status etc only consider the actually tracked file.
>> [...]
>>
>> Could you add it to Git Wiki page:
>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>>
>> I think that the project is interesting enough to be added there
>> even if it is still in beta, or even alpha, stage.
>
> Ah, good idea. Done, in Version Control Interface layers section
Thanks.
I have added link to repositoy, as you didn't configure your gitweb to
display those URL links (see gitweb/README and gitweb/INSTALL).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Felipe Contreras @ 2008-10-26 15:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, mercurial
In-Reply-To: <m3r663h276.fsf@localhost.localdomain>
On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> [Cc: gmane.comp.version-control.git,
> gmane.comp.version-control.mercurial.general]
>
> walt <w41ter@gmail.com> writes:
>
>> No, no, I'm not the one calling for a vote. You old-timers here
>> will know the name Matt Dillon, who is leading the dragonflybsd
>> project (www.dragonflybsd.org).
>>
>> Matt is the one who is calling for the vote in his thread "Vote
>> for your source control system" in the dragonfly.kernel group,
>> accessible via nntp://nntp.dragonflybsd.org.
>>
>> I've already cast my vote for git, which I confess is not very
>> honest because I've never even tried mercurial. I would truly
>> be grateful to anyone here who knows both git and mercurial who
>> could contribute verifiable facts to that debate.
<snip/>
> 3. Repository design and performance.
>
> Git is designed around idea of content adressed object database;
> objects are adressed by their content (by SHA-1 of their type and
> content). Commits for example have information about author and
> comitter, pointer to zero or more parent commits, and pointer to
> tree object (representing top directory in project). Branches
> and tags are just pointers to DAG (Direct Acyclic Graph) of
> commits; current branch is denoted by HEAD pointer to branch.
> There is explicit staging area called 'index', used for conflict
> resolution dureing merges, and which can be used to make commit in
> stages, allow uncomitted changes in tree (in working directory).
> Git design supports very well multiple branches in single
> repository, and tracking changes in multiple remote repositories
> each with multiple branches.
>
> Mercurial, from what I have read of its documentation, and from the
> few discussion on #revctrl IRC channel, and from what I understand
> is based on changes stored per file, with information about files
> and their versions stored in manifest (flat) file, and with changes
> described in changelog-like file (changerev). One of limitations
> of "record" database (as opposed to Git's object database) is that
> commits can have zero (root commit), one or two (merge commits)
> parents only. There is apparent in design that Mercurial was
> developed with single branch per repository paradigm in mind.
> Local branches from what I understand are marked in CVS-like
> fashion using tags. Tags are implemented as either local to
> repository and untransferable, or as .hgtags versioned file with
> special case treatment. (But I'm obviously biased here).
>
> Git and Mercurial have similar performance, although it is thought
> that due to design Mercurla has faster patch applying and is
> optimized for cold cache case, while Git has faster merging and is
> optimized for warm cache case.
>
> Mercurial may have (or had) problems with larger binary files, from
> what I have heard.
The fact that hg is changeset based means that certain operations are
slower, like checkout a specific commit. In hg my bet is you would
need to gather a bunch of changesets while in git the operation is
done in a single step.
It also means that bare clones are not possible in hg, or at least
very complicated.
Note: I'm not sure if what I'm claiming is correct.
--
Felipe Contreras
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: René Scharfe @ 2008-10-26 16:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Santi Béjar, git
In-Reply-To: <20081022075639.GA1284@elte.hu>
Ingo Molnar schrieb:
> The most useful angle would be if git log --format had a way to print
> the reverse name. Then i could do a git-log-line script like:
>
> git log --pretty=format:"%h: %20N %s" $@
>
> where %N prints the reverse name.
>
> While at it: it would be nice if git log had a way to crop string
> output. For example i'd love to use:
>
> git log --pretty=format:"%h: %60s" $@
>
> which would print out at most 60 characters from the first commit line.
>
> That way i can see it properly on an 80 width terminal and can paste it
> into email without linewraps, etc. But --pretty=format does not seem to
> know width restrictions.
You don't need support for format string cropping in git for the latter
example, you can use cut instead:
git log --pretty=format:%h:\ %s $@ | cut -b-70
But I only realized that after I had written the following patch. :)
Would this feature still be useful?
Thanks,
René
---
Documentation/pretty-formats.txt | 5 +++++
pretty.c | 30 ++++++++++++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index f18d33e..cc76c45 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -128,6 +128,11 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
++
+You can also specify a maximum width for each field after the '%', e.g.
+'%60s' will show the first sixty characters of the subject (or less if
+it's shorter).
+
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
diff --git a/pretty.c b/pretty.c
index 1e79943..74e8932 100644
--- a/pretty.c
+++ b/pretty.c
@@ -498,8 +498,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
-static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
- void *context)
+static size_t do_format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
{
struct format_commit_context *c = context;
const struct commit *commit = c->commit;
@@ -621,6 +621,32 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
return 0; /* unknown placeholder */
}
+static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
+{
+ size_t digits = 0;
+ size_t maxlen = 0;
+ size_t consumed;
+
+ if (isdigit(placeholder[0])) {
+ do {
+ digits++;
+ maxlen *= 10;
+ maxlen += placeholder[0] - '0';
+ placeholder++;
+ } while (isdigit(placeholder[0]));
+ maxlen += sb->len;
+ }
+
+ consumed = do_format_commit_item(sb, placeholder, context);
+ if (!consumed)
+ return 0;
+
+ if (digits && sb->len > maxlen)
+ strbuf_setlen(sb, maxlen);
+ return digits + consumed;
+}
+
void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
enum date_mode dmode)
--
1.6.0.3.514.g2f91b
^ permalink raw reply related
* Re: From Perforce to Git
From: Brandon @ 2008-10-26 16:08 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20810251641l4892ff12n7b30667c6fcc903c@mail.gmail.com>
On Sat, Oct 25, 2008 at 6:41 PM, David Symonds <dsymonds@gmail.com> wrote:
> On Sat, Oct 25, 2008 at 2:18 PM, Brandon <siamesedream01@gmail.com> wrote:
>
>> I'm trying to make a comprehensive comparison of Perforce and Git
>> features. There are two things I currently can't find:
>>
>> 1) "Who's editing what"
>> It's been documented that git can help developers communicate who
>> is editing what at any given time like perforce. (assuming there is a
>> central repositry) Has anyone seen an example of scripts to do this?
>
> That's the primary feature of Perforce that kills its scalability once
> you get past a few hundred developers; it bloats the metadata too
> much. When you're using Git, there's really little point in using it,
> since you don't declare what files you are going to be editing, and
> you can find out other people's changes at merge time at your leisure
> (not just when *you* want to commit).
I think there is an even more fundamental problem with this
feature. Since perforce 'forces' developers the checkout files for
edit, eventually you just ignore these warnings because you don't know
if someone is really checking something out to make a change they are
going to commit, or just need to make a file writable to experiment
with some other feature they're working on etc... This feature would
work much better if it were optional. I don't really care about the
feature per se I would just like to be able to state that Git can
offer everything that perforce can.
I would imagine this would require users pushing their changes to a
branch in the central git repo. Then other users could use git log or
cherry to see what files others are interested in (aka declared they
are going to edit)? Not that this is necessarily a good way to work.
>> 2) Symlinks to checkout partial repository
>> I believe I read symlinks could be used to checkout part of a
>> repository. Is this true? any references? I imagine submodules is the
>> preferred way of doing this, and "narrow" or "partial" or "sparse"
>> checkouts are under development
>
> I don't think so. You could use symlinks to *simulate* a bigger
> repository that is actually made up of smaller repositories.
>
>
> Dave.
>
thanks, I'm pretty sure I'm just imagining reading this somewhere, I
just needed some confirmation.
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-26 16:15 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List
In-Reply-To: <237967ef0810260746w10e930c1sf36a2674f49afbe1@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> % mkdir 1; cd 1
> % echo > a; git add a; git commit -m a
> % cd ..
> % git clone -s 1 2
> % git push . master:master
> fatal: Could not switch to
> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
> fatal: The remote end hung up unexpectedly
I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
callchain, but I cannot explain why the contents of $PATH leaks to the
error message.
Can you try this patch?
sha1_file.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git i/sha1_file.c w/sha1_file.c
index ab2b520..98e7d7a 100644
--- i/sha1_file.c
+++ w/sha1_file.c
@@ -402,9 +402,11 @@ void foreach_alt_odb(alt_odb_fn fn, void *cb)
struct alternate_object_database *ent;
prepare_alt_odb();
- for (ent = alt_odb_list; ent; ent = ent->next)
+ for (ent = alt_odb_list; ent; ent = ent->next) {
+ *ent->name = '\0';
if (fn(ent, cb))
return;
+ }
}
void prepare_alt_odb(void)
^ permalink raw reply related
* Re: git export to svn
From: Warren Harris @ 2008-10-26 16:24 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: J.H., git
In-Reply-To: <20081026091554.GC3612@atjola.homenet>
On Oct 26, 2008, at 2:15 AM, Björn Steinbrink wrote:
> On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
>> I tried a fetch, but still no luck:
>>
>> $ git svn fetch
>> W: Ignoring error from SVN, path probably does not exist: (175002):
>> RA
>> layer request failed: REPORT of '/svn/!svn/bc/100': Could not read
>> chunk
>> size: Secure connection truncated (https://svn)
>> W: Do not be alarmed at the above message git-svn is just searching
>> aggressively for old history.
>> This may take a while on large repositories
>> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
>> A ...
>> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>>
>> $ git svn rebase
>> Unable to determine upstream SVN information from working tree
>> history
>
> Means that your current branch is not based on what git-svn has
> fetched,
> which is expected when you use "svn init" + "svn fetch" after you
> already started working.
>
> What's the actual relationship between your local history and the
> history you fetched from svn?
Since I'm trying to export my git repo to svn, the svn repo is
completely empty.
>
>
> If your local stuff started from revision X, which you manually
> imported
> from svn, you can just rebase it:
>
> git rebase --onto <svn-revision-X> <your-revision-X>
When I try this, I keep getting:
fatal: Needed a single revision
invalid upstream
>
>
>
> If you have a bunch of merges in your local history, you might want to
> merge your stuff into the svn-based branch instead. When you dcommit,
> the svn repo will only see one big "do it all" commit though.
>
> For that, you would create a graft, so that your first "real" local
> commit gets the svn revision X commit as its parent. That is, from:
>
> S---S---SX---S---S---S (svn)
>
> LX--------L---L---L---L (local)
>
> You want to go to:
>
> S---S---SX---S---S---S (svn)
> \
> LX L---L---L---L (local)
>
>
> Where 'S' means that the commit came from SVN, and L means that it
> is a
> "local" commit. SX and LX are the commits that have the same tree
> attached (same directories/files), but have a different hash due to
> how
> they were created. The graft overrides the parent-child relation for
> the
> first "L" commit, so that it actually appears as being branched off
> of SX.
>
> And then, you'd merge local into svn, so you get:
>
> S---S---SX---S---S---S--M (svn)
> \ /
> LX L---L---L---L (local)
>
>
>
> If possible, go with the rebase though. That at least gives a somewhat
> reasonable history in the svn repo as well. Also note that when you go
> with the merge way, make sure that the svn branch is totally uptodate
> before you merge and that the merge commit is the only one to be
> dcommitted. Otherwise, funny stuff might happen, and rebase might kick
> in anyway, I don't exactly remember what git-svn does, but it wasn't
> pleasant :-)
I may not have been clear about what I'm trying to do: I have a git
repository, and I'd like to put it (either the head of the master, or
the entire revision history if possible) into svn. From then on, I
would like to be able to use 'git svn' commands to manage the two
repos. (Initially I don't expect anyone else to be committing to svn
-- it's just an archive and something for others to pull from.)
Here's a complete transcript of how I tried to do this, which seems to
be missing some crucial step:
$ mkdir test2-git-clone
$ git clone ../test2/ # clone my working repo which is unrelated to
svn at this point
$ cd test2-git-clone/test2
$ svn mkdir https://svn/svn/SANDBOX/warren/test2 -m "test2"
$ svn mkdir https://svn/svn/SANDBOX/warren/test2/trunk -m "test2"
$ svn mkdir https://svn/svn/SANDBOX/warren/test2/branches -m "test2"
$ svn mkdir https://svn/svn/SANDBOX/warren/test2/tags -m "test2"
$ git svn init https://svn/svn/SANDBOX/warren/test2 -T trunk -t tags -
b branches
Initialized empty Git repository in /Users/warren/projects/tmp/test2-
git-clone/test2/.git/
Using higher level of URL: https://svn/svn/SANDBOX/warren/test2 => https://svn/svn
$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/
libexec/git-core/git-svn line 425.
$ git merge --no-ff master
Already up-to-date.
$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/
libexec/git-core/git-svn line 425.
$ git svn fetch
$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/
libexec/git-core/git-svn line 425.
Thanks for your help,
Warren
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vljwb5o4p.fsf@gitster.siamese.dyndns.org>
2008/10/26 Junio C Hamano <gitster@pobox.com>:
> "Mikael Magnusson" <mikachu@gmail.com> writes:
>
>> % mkdir 1; cd 1
>> % echo > a; git add a; git commit -m a
>> % cd ..
>> % git clone -s 1 2
>> % git push . master:master
>> fatal: Could not switch to
>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>> fatal: The remote end hung up unexpectedly
>
> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
> callchain, but I cannot explain why the contents of $PATH leaks to the
> error message.
>
> Can you try this patch?
Yeah this fixes the issue for me. If I add this
static int add_refs_from_alternate(struct alternate_object_database
*e, void *unused)
{
+ fprintf(stderr, "add: %s\n", e->base);
char *other = xstrdup(make_absolute_path(e->base));
size_t len = strlen(other);
and
prepare_alt_odb();
for (ent = alt_odb_list; ent; ent = ent->next) {
fprintf(stderr, "for: %s\n", ent->name);
if (fn(ent, cb))
return;
then i get
for: in//usr/qt/3/bin:/usr/games/bin:/usr/loca
add: /tmp/a/1/.git/objects/in//usr/qt/3/bin:/usr/games/bin:/usr/loca
fatal: Could not switch to
'/tmp/a/1/.git/objects/in//usr/qt/3/bin:/usr/games/bin:/usr'
fatal: The remote end hung up unexpectedly
--
Mikael Magnusson
^ permalink raw reply
* Re: git export to svn
From: Björn Steinbrink @ 2008-10-26 17:15 UTC (permalink / raw)
To: Warren Harris; +Cc: J.H., git
In-Reply-To: <8ED0030A-E55E-4082-87C9-53B11F763E1B@gmail.com>
On 2008.10.26 09:24:07 -0700, Warren Harris wrote:
>
> On Oct 26, 2008, at 2:15 AM, Björn Steinbrink wrote:
>
>> On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
>>> I tried a fetch, but still no luck:
>>>
>>> $ git svn fetch
>>> W: Ignoring error from SVN, path probably does not exist: (175002):
>>> RA
>>> layer request failed: REPORT of '/svn/!svn/bc/100': Could not read
>>> chunk
>>> size: Secure connection truncated (https://svn)
>>> W: Do not be alarmed at the above message git-svn is just searching
>>> aggressively for old history.
>>> This may take a while on large repositories
>>> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
>>> A ...
>>> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>>>
>>> $ git svn rebase
>>> Unable to determine upstream SVN information from working tree
>>> history
>>
>> Means that your current branch is not based on what git-svn has
>> fetched,
>> which is expected when you use "svn init" + "svn fetch" after you
>> already started working.
>>
>> What's the actual relationship between your local history and the
>> history you fetched from svn?
>
> Since I'm trying to export my git repo to svn, the svn repo is
> completely empty.
OK, the "r58084" made me think that your code is based on something that
is already in the SVN repo. But apperently, that's just a shared svn
repo, right?
> I may not have been clear about what I'm trying to do: I have a git
> repository, and I'd like to put it (either the head of the master, or
> the entire revision history if possible) into svn. From then on, I would
> like to be able to use 'git svn' commands to manage the two repos.
> (Initially I don't expect anyone else to be committing to svn -- it's
> just an archive and something for others to pull from.)
>
> Here's a complete transcript of how I tried to do this, which seems to
> be missing some crucial step:
>
> $ mkdir test2-git-clone
> $ git clone ../test2/ # clone my working repo which is unrelated to
> svn at this point
> $ cd test2-git-clone/test2
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2 -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/trunk -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/branches -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/tags -m "test2"
> $ git svn init https://svn/svn/SANDBOX/warren/test2 -T trunk -t tags -b
> branches
> Initialized empty Git repository in /Users/warren/projects/tmp/test2-
> git-clone/test2/.git/
> Using higher level of URL: https://svn/svn/SANDBOX/warren/test2 => https://svn/svn
> $ git svn dcommit
> Can't call method "full_url" on an undefined value at /opt/local/
> libexec/git-core/git-svn line 425.
Can't work yet, your local stuff is not yet connected to the svn commit
(which you didn't even fetch yet). Same for the other dcommit calls you
did.
> $ git merge --no-ff master
> Already up-to-date.
That tries to merge master into itself ;-) The blog entry assumed that
you have a svn-based branch checked out, and applies to quite a
different situation.
This should do and uses a graft to simplify the process a bit:
Initialize git-svn:
git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
The --prefix gives you remote tracking branches like "svn/trunk" which
is nice because you don't get ambiguous names if you call your local
branch just "trunk" then. And -s is a shortcut for the standard
trunk/tags/branches layout.
Fetch the initial stuff from svn:
git svn fetch
Now look up the hash of your root commit (should show a single commit):
git rev-list --parents master | grep '^.\{40\}$'
Then get the hash of the empty trunk commit:
git rev-parse svn/trunk
Create the graft:
echo <root-commit-hash> <svn-trunk-commit-hash> >> .git/info/grafts
Now, "gitk" should show svn/trunk as the first commit on which your
master branch is based.
Make the graft permanent:
git filter-branch -- ^svn/trunk --all
Drop the graft:
rm .git/info/grafts
gitk should still show svn/trunk in the ancestry of master
Linearize your history on top of trunk:
git svn rebase
And now "git svn dcommit -n" should tell you that it is going to commit
to trunk.
Alternatively, if rebase gives just too many conflicts, you can do:
git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
git svn fetch
git checkout -b trunk svn/trunk
git merge master
git svn dcommit
That will just create a single huge commit in svn. But the history will
be retained in git. You can then work on the new "trunk" branch or move
your master branch, so it points to the same commit as trunk and then
drop the "trunk" branch or whatever. It just matters that your new work
is based upon the dcommited merge commit, so "svn/trunk" is in your
branch's history.
HTH
Björn
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: René Scharfe @ 2008-10-26 17:53 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <7vljwb5o4p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "Mikael Magnusson" <mikachu@gmail.com> writes:
>
>> % mkdir 1; cd 1
>> % echo > a; git add a; git commit -m a
>> % cd ..
>> % git clone -s 1 2
>> % git push . master:master
>> fatal: Could not switch to
>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>> fatal: The remote end hung up unexpectedly
>
> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
> callchain, but I cannot explain why the contents of $PATH leaks to the
> error message.
With the following patch, I can no longer reproduce the problem. Does it
work fo you, too?
Thanks,
René
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..8044e9c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -269,7 +269,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
entlen += base_len;
pfxlen += base_len;
}
- ent = xmalloc(sizeof(*ent) + entlen);
+ ent = xcalloc(1, sizeof(*ent) + entlen);
if (!is_absolute_path(entry) && relative_base) {
memcpy(ent->base, relative_base, base_len - 1);
^ permalink raw reply related
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-26 18:07 UTC (permalink / raw)
To: René Scharfe; +Cc: Mikael Magnusson, Git Mailing List
In-Reply-To: <4904AE8D.9090706@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> "Mikael Magnusson" <mikachu@gmail.com> writes:
>>
>>> % mkdir 1; cd 1
>>> % echo > a; git add a; git commit -m a
>>> % cd ..
>>> % git clone -s 1 2
>>> % git push . master:master
>>> fatal: Could not switch to
>>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>>> fatal: The remote end hung up unexpectedly
>>
>> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
>> callchain, but I cannot explain why the contents of $PATH leaks to the
>> error message.
>
> With the following patch, I can no longer reproduce the problem. Does it
> work fo you, too?
>
> Thanks,
> René
>
> diff --git a/sha1_file.c b/sha1_file.c
> index ab2b520..8044e9c 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -269,7 +269,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
> entlen += base_len;
> pfxlen += base_len;
> }
> - ent = xmalloc(sizeof(*ent) + entlen);
> + ent = xcalloc(1, sizeof(*ent) + entlen);
Ah, that would explain the "filled with garbage from $PATH" issue, but I
don't think it fixes the fundamental issue.
In the alternate_object_database structure, ent->base[] is a buffer the
users can use to form pathnames to loose objects, and ent->name is a
pointer into that buffer (it points at one beyond ".git/objects/"). If
you get a call to add_refs_from_alternate() after somebody used the entry
(has_loose_object() has been called, for example), *ent->name would not be
NUL, and ent->base[] won't be the path to the object store.
This caller is expecting to read the path to the object store in ent->base[];
it needs to NUL terminate the buffer if it wants to.
I think the previous patch to sha1_file.c, while it may fix the issue, is
not quite nice. Here is a replacement that should work.
builtin-receive-pack.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git c/builtin-receive-pack.c w/builtin-receive-pack.c
index 45e3cd9..9f60f31 100644
--- c/builtin-receive-pack.c
+++ w/builtin-receive-pack.c
@@ -466,12 +466,17 @@ static int delete_only(struct command *cmd)
static int add_refs_from_alternate(struct alternate_object_database *e, void *unused)
{
- char *other = xstrdup(make_absolute_path(e->base));
- size_t len = strlen(other);
+ char *other;
+ size_t len;
struct remote *remote;
struct transport *transport;
const struct ref *extra;
+ e->name[-1] = '\0';
+ other = xstrdup(make_absolute_path(e->base));
+ e->name[-1] = '/';
+ len = strlen(other);
+
while (other[len-1] == '/')
other[--len] = '\0';
if (len < 8 || memcmp(other + len - 8, "/objects", 8))
^ permalink raw reply related
* Re: Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Git Mailing List
In-Reply-To: <7v63nf5iy1.fsf@gitster.siamese.dyndns.org>
2008/10/26 Junio C Hamano <gitster@pobox.com>:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> "Mikael Magnusson" <mikachu@gmail.com> writes:
>>>
>>>> % mkdir 1; cd 1
>>>> % echo > a; git add a; git commit -m a
>>>> % cd ..
>>>> % git clone -s 1 2
>>>> % git push . master:master
>>>> fatal: Could not switch to
>>>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>>>> fatal: The remote end hung up unexpectedly
>>>
>>> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
>>> callchain, but I cannot explain why the contents of $PATH leaks to the
>>> error message.
>
> I think the previous patch to sha1_file.c, while it may fix the issue, is
> not quite nice. Here is a replacement that should work.
It does.
--
Mikael Magnusson
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 18:55 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Maxim Vuets, mercurial, git
In-Reply-To: <ee2a733e0810260805n35c3a637v4739dda938a22518@mail.gmail.com>
I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
On Sun, 26 Oct 2008, Leo Razoumov wrote:
> On 10/26/08, Maxim Vuets <maxim.vuets@gmail.com> wrote:
>> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> 1. Documentation and ease of use.
>>>
>>> Mercurial is supposedly better documented and easier to use; I
>>> think this descends from the early days of Git, where it was not
>>> very user friendly. IMHO Git has much improved since. Mercurial
>>> had 'hgbook' from the beginning; Git User's Manual is more recent.
>>
>> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
>>
>> Thanks for the comprarision!
>
> I have been using Mercurial for about two years and am very
> comfortable with it. Here are some cons and pros
>
> Mercurial PROS:
> * Easier and more consistent UI. Newbie friendly.
I think that _might_ be example of "Worse is better" scenario, with Git
having UI which evolved rather than was designed, and therefore less
consistent.
Also if you are limiting to what is described in main chapters of
'hgbook', namely one branch (one "fork") per repository paradigm
everything is simpler.
> * Better documentation. IMHO, hgbook is by far better than
> http://book.git-scm.com/
And probably better than "Git User's Manual". There are lot of various
git-related documentation: "Git Magic", "Git for Computer Scientists",
"Git from bottoms up"...
> * Windows support (personally, I do not care)
And I think it is not important for DragonflyBSD.
Besides git _has_ MS Windows support, in the form of Cygwin and in the
form of msysGit project. It is still not as full as Linux support (for
example git-svn comes to mind), but it is not bad. Well, Mercurial
has TortiouseHg, while Git-Cheetah is in very early stages...
>
> Mercurial CONS:
> * Less potential than git. Once Ted Tso even said that "git has more
> legs than mercurial", see
> http://thunk.org/tytso/blog/2007/03/24/git-and-hg/
I agree, and I think it is at least partially because of Git having
cleaner design, even if you have to understand more terms at first.
> * Hg is strictly an SCM system while GIT is a content addressable file
> system that can be used in other ways, hence the name Global
> Information Tracker (GIT)
Errr... I think you are mislead by tongue-in-cheek backronym, which was
created in the beginning, when git had very weak porcelain (i.e. SCM UI).
> * Recently, Hg development seems to have somewhat slowed down. To
> simply put it, there is not enough room in the world for several
> similar SCM systems. With git's pace and momentum the other SCMs
> including Hg are fighting an uphill battle.
The competing _distributed_ version control systems left seems to be
Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,
Freedesktop.org, Ruby on Rails people). There are many IDEs, many
editors, many web browsers; there is Linux and there are *BSD; I hope
that Mercurial would continue to be developed, and not vanish in
obscurity like Arch and clones...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 19:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, mercurial
In-Reply-To: <94a0d4530810260857u7c0cb122g8147b9484108f539@mail.gmail.com>
I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
On Sun, 26 Sep 2008, Felipe Contreras wrote:
> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > [Cc: gmane.comp.version-control.git,
> > gmane.comp.version-control.mercurial.general]
> > 3. Repository design and performance.
> > Git and Mercurial have similar performance, although it is thought
> > that due to design Mercurial has faster patch applying and is
> > optimized for cold cache case, while Git has faster merging and is
> > optimized for warm cache case.
> >
> > Mercurial may have (or had) problems with larger binary files, from
> > what I have heard.
>
> The fact that hg is changeset based means that certain operations are
> slower, like checkout a specific commit. In hg my bet is you would
> need to gather a bunch of changesets while in git the operation is
> done in a single step.
Actually from what I have read Mercurial stores current version
(snapshot) from time to time, so time to resolve specific commit is
limited. Also if you have packed your Git repository (good idea not
only to limit size, but also for performance (I/O performance)), then
resolving specific commit also might require some delta resolution
(by default delta chain length is limited to 50, see pack.depth).
> It also means that bare clones are not possible in hg, or at least
> very complicated.
I think it is things like .hgtags which make bare clones (without
working directory) to be hard or even impossible in Mercurial.
> Note: I'm not sure if what I'm claiming is correct.
Hmmm...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] add -p: warn if only binary changes present
From: Thomas Rast @ 2008-10-26 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, szeder
In-Reply-To: <20081026104006.GA18969@neumann>
Current 'git add -p' will say "No changes." if there are no changes to
text files, which can be confusing if there _are_ changes to binary
files. Add some code to distinguish the two cases, and give a
different message in the latter one.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
SZEDER Gábor wrote:
> What about
>
> Only binary files changed.
>
> or something of the sort?
Yes, why not.
git-add--interactive.perl | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index da768ee..b0223c3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -811,11 +811,16 @@ EOF
}
sub patch_update_cmd {
- my @mods = grep { !($_->{BINARY}) } list_modified('file-only');
+ my @all_mods = list_modified('file-only');
+ my @mods = grep { !($_->{BINARY}) } @all_mods;
my @them;
if (!@mods) {
- print STDERR "No changes.\n";
+ if (@all_mods) {
+ print STDERR "Only binary files changed.\n";
+ } else {
+ print STDERR "No changes.\n";
+ }
return 0;
}
if ($patch_mode) {
--
tg: (759ad19..) t/add-p-binary-warn (depends on: origin/master)
^ permalink raw reply related
* Re: [PATCH v2] add -p: warn if only binary changes present
From: Jeff King @ 2008-10-26 19:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <1225049826-14941-1-git-send-email-trast@student.ethz.ch>
On Sun, Oct 26, 2008 at 08:37:06PM +0100, Thomas Rast wrote:
> > What about
> >
> > Only binary files changed.
> >
> > or something of the sort?
>
> Yes, why not.
That is better, IMHO.
-Peff
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Felipe Contreras @ 2008-10-26 19:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, mercurial
In-Reply-To: <200810262007.30148.jnareb@gmail.com>
On Sun, Oct 26, 2008 at 9:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
>
> On Sun, 26 Sep 2008, Felipe Contreras wrote:
>> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> > [Cc: gmane.comp.version-control.git,
>> > gmane.comp.version-control.mercurial.general]
>
>> > 3. Repository design and performance.
>
>> > Git and Mercurial have similar performance, although it is thought
>> > that due to design Mercurial has faster patch applying and is
>> > optimized for cold cache case, while Git has faster merging and is
>> > optimized for warm cache case.
>> >
>> > Mercurial may have (or had) problems with larger binary files, from
>> > what I have heard.
>>
>> The fact that hg is changeset based means that certain operations are
>> slower, like checkout a specific commit. In hg my bet is you would
>> need to gather a bunch of changesets while in git the operation is
>> done in a single step.
>
> Actually from what I have read Mercurial stores current version
> (snapshot) from time to time, so time to resolve specific commit is
> limited. Also if you have packed your Git repository (good idea not
> only to limit size, but also for performance (I/O performance)), then
> resolving specific commit also might require some delta resolution
> (by default delta chain length is limited to 50, see pack.depth).
Ah, ok, good to know.
>> It also means that bare clones are not possible in hg, or at least
>> very complicated.
>
> I think it is things like .hgtags which make bare clones (without
> working directory) to be hard or even impossible in Mercurial.
Oops, I meant shallow clones (git clone --depth=1).
--
Felipe Contreras
^ 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