* 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
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-26 21:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3k5bvgz83.fsf@localhost.localdomain>
On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> 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).
Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
computed automatically? Judging by the docs, it seems that I have to
set it manually for each project, like the description.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* git working tree status
From: Mike Clarke @ 2008-10-26 21:54 UTC (permalink / raw)
To: git
Hi all,
I'd like a way of getting a simple summary of the status of a working
tree, for consumption by other programs rather than humans.
Specifically, I'd like to know whether the working tree is:
a) fully 'clean' -- i.e., all changes checked in, no stashes;
b) all changes checked in, but there are some stashes; or
c) 'dirty' in some way -- new files, uncommitted changes, etc.
The logical way to do this seems to be via an exit code, but the exit
code of git status is not currently rich enough. As a result, I'm
considering the addition of an option to git status -- perhaps
'--is-clean' -- that would provide the required information.
My questions are:
1) Is there already some way of doing this that I've overlooked?
2) Would the preferred approach be an option (git status --is-clean)
or a sub-command (git is-clean)? A sub-command would probably result
in cleaner internal code, but would also clutter the interface.
3) Is a patch for such a feature likely to be accepted?
Thanks,
--
Mike Clarke
^ permalink raw reply
* [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Alex Riesen @ 2008-10-26 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Both are actually just vsnprintf's but additionally call cleanup_path
on the result. To be used as alternatives to mkpath and git_path where
the buffer for the created path may not be reused by subsequent calls
of the same formatting function.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
cache.h | 4 ++++
path.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index b0edbf9..a9024db 100644
--- a/cache.h
+++ b/cache.h
@@ -495,6 +495,10 @@ extern int check_repository_format(void);
#define DATA_CHANGED 0x0020
#define TYPE_CHANGED 0x0040
+extern char *mksnpath(char *buf, size_t n, const char *fmt, ...)
+ __attribute__((format (printf, 3, 4)));
+extern char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+ __attribute__((format (printf, 3, 4)));
/* Return a statically allocated filename matching the sha1 signature */
extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern char *git_path(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
diff --git a/path.c b/path.c
index 76e8872..85ab28a 100644
--- a/path.c
+++ b/path.c
@@ -32,6 +32,44 @@ static char *cleanup_path(char *path)
return path;
}
+char *mksnpath(char *buf, size_t n, const char *fmt, ...)
+{
+ va_list args;
+ unsigned len;
+
+ va_start(args, fmt);
+ len = vsnprintf(buf, n, fmt, args);
+ va_end(args);
+ if (len >= n) {
+ snprintf(buf, n, bad_path);
+ return buf;
+ }
+ return cleanup_path(buf);
+}
+
+char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+{
+ const char *git_dir = get_git_dir();
+ va_list args;
+ size_t len;
+
+ len = strlen(git_dir);
+ if (n < len + 1)
+ goto bad;
+ memcpy(buf, git_dir, len);
+ if (len && !is_dir_sep(git_dir[len-1]))
+ buf[len++] = '/';
+ va_start(args, fmt);
+ len += vsnprintf(buf + len, n - len, fmt, args);
+ va_end(args);
+ if (len >= n)
+ goto bad;
+ return cleanup_path(buf);
+bad:
+ snprintf(buf, n, bad_path);
+ return buf;
+}
+
char *mkpath(const char *fmt, ...)
{
va_list args;
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-26 22:04 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810261418y3b114e2ag81cbb75c4a80603c@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>>
>>> 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).
>
> Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
> computed automatically? Judging by the docs, it seems that I have to
> set it manually for each project, like the description.
gitweb/README:
How to configure gitweb for your local system
---------------------------------------------
[...]
* GITWEB_BASE_URL
Git base URLs used for URL to where fetch project from, i.e. full
URL is "$git_base_url/$project". Shown on projects summary page.
Repository URL for project can be also configured per repository; this
takes precedence over URLs composed from base URL and a project name.
Note that you can setup multiple base URLs (for example one for
git:// protocol access, another for http:// access) from the gitweb
config file. [No default]
[...]
Runtime gitweb configuration
----------------------------
[...]
Gitweb config file variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
* @git_base_url_list
List of git base URLs used for URL to where fetch project from, shown
in project summary page. Full URL is "$git_base_url/$project".
You can setup multiple base URLs (for example one for git:// protocol
access, and one for http:// "dumb" protocol access). Note that per
repository configuration in 'cloneurl' file, or as values of gitweb.url
project config.
Ooops, there seems to be a type in above...
Per-repository gitweb configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
* cloneurl (or multiple-valued gitweb.url)
File with repository URL (used for clone and fetch), one per line.
Displayed in the project summary page. You can use multiple-valued
gitweb.url repository configuration variable for that, but the file
takes precedence.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
From: Alex Riesen @ 2008-10-26 22:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Otherwise the function sometimes fail to resolve obviously correct
refnames, because the string data pointed to by "str" argument were
reused.
The change in dwim_log does not fix anything, just optimizes away
strcpy code as the path can be created directly in the available
buffer.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Was noticed in cygwin port, which somehow (supposedly by excessive
calling of git_config from lstat stub setup) managed to reuse the
just returned buffer.
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 41b6809..159c2ab 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -245,11 +245,13 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
*ref = NULL;
for (p = ref_rev_parse_rules; *p; p++) {
+ char fullref[PATH_MAX];
unsigned char sha1_from_ref[20];
unsigned char *this_result;
this_result = refs_found ? sha1_from_ref : sha1;
- r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
+ mksnpath(fullref, sizeof(fullref), *p, len, str);
+ r = resolve_ref(fullref, this_result, 1, NULL);
if (r) {
if (!refs_found++)
*ref = xstrdup(r);
@@ -272,7 +274,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
char path[PATH_MAX];
const char *ref, *it;
- strcpy(path, mkpath(*p, len, str));
+ mksnpath(path, sizeof(path), *p, len, str);
ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* [PATCH] Fix potentially dangerous uses of mkpath and git_path
From: Alex Riesen @ 2008-10-26 22:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Replace them with mksnpath/git_snpath and a local buffer
for the resulting string.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-apply.c | 4 ++--
builtin-for-each-ref.c | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index cfd8fce..4c4d1e1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2841,8 +2841,8 @@ static void create_one_file(char *path, unsigned mode, const char *buf, unsigned
unsigned int nr = getpid();
for (;;) {
- const char *newpath;
- newpath = mkpath("%s~%u", path, nr);
+ char newpath[PATH_MAX];
+ mksnpath(newpath, sizeof(newpath), "%s~%u", path, nr);
if (!try_create_file(newpath, mode, buf, size)) {
if (!rename(newpath, path))
return;
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index fa6c1ed..e46b7ad 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -620,14 +620,16 @@ static char *get_short_ref(struct refinfo *ref)
for (j = 0; j < i; j++) {
const char *rule = ref_rev_parse_rules[j];
unsigned char short_objectname[20];
+ char refname[PATH_MAX];
/*
* the short name is ambiguous, if it resolves
* (with this previous rule) to a valid ref
* read_ref() returns 0 on success
*/
- if (!read_ref(mkpath(rule, short_name_len, short_name),
- short_objectname))
+ mksnpath(refname, sizeof(refname),
+ rule, short_name_len, short_name);
+ if (!read_ref(refname, short_objectname))
break;
}
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-26 22:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200810262304.13582.jnareb@gmail.com>
On Sun, Oct 26, 2008 at 11:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Gitweb config file variables
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [...]
> * @git_base_url_list
> List of git base URLs used for URL to where fetch project from, shown
> in project summary page. Full URL is "$git_base_url/$project".
> You can setup multiple base URLs (for example one for git:// protocol
> access, and one for http:// "dumb" protocol access). Note that per
> repository configuration in 'cloneurl' file, or as values of gitweb.url
> project config.
Doh, thanks, I had totally overlooked it. Done 8-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 5/5] blame: use xdi_diff_hunks(), get rid of struct patch
From: René Scharfe @ 2008-10-26 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git
In-Reply-To: <7vhc708o1v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Perhaps revision.c in our history would be more interesting than cache.h
> or Makefile, as there are more line migrations from different places to
> that file.
Indeed:
# master
$ /usr/bin/time $blame revision.c >/dev/null
2.15user 0.27system 0:02.58elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
3544inputs+0outputs (29major+13835minor)pagefaults 0swaps
# this patch series
$ /usr/bin/time $blame revision.c >/dev/null
1.88user 0.14system 0:02.03elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+14068minor)pagefaults 0swaps
René
^ permalink raw reply
* Re: git working tree status
From: Miklos Vajna @ 2008-10-26 22:23 UTC (permalink / raw)
To: Mike Clarke; +Cc: git
In-Reply-To: <73f525b90810261454wb902edfk3a696c06ef2148d1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Sun, Oct 26, 2008 at 09:54:03PM +0000, Mike Clarke <clarkema@gmail.com> wrote:
> a) fully 'clean' -- i.e., all changes checked in, no stashes;
In case you want to ignore ignores:
$ git ls-files -o
otherwise:
git ls-files -o --exclude-standard
by 'stashes', I guess you mean those extra files, but using that term is
confusing, given that stashes can be listed with git stash list and they
are actually merge commits (so something totally different).
> b) all changes checked in, but there are some stashes; or
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" && echo "everything committed"
> c) 'dirty' in some way -- new files, uncommitted changes, etc.
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
see GIT-VERSION-GEN in git.git
> 1) Is there already some way of doing this that I've overlooked?
> 2) Would the preferred approach be an option (git status --is-clean)
> or a sub-command (git is-clean)? A sub-command would probably result
> in cleaner internal code, but would also clutter the interface.
I guess you overlooked the fact that plumbing is supposed to be used
from scripts and porcelain by the users. git status is porcelain, so
in general just don't use it from scripts.
> 3) Is a patch for such a feature likely to be accepted?
I don't think so, see above.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git working tree status
From: Miklos Vajna @ 2008-10-26 22:26 UTC (permalink / raw)
To: Mike Clarke; +Cc: git
In-Reply-To: <20081026222335.GJ2273@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
On Sun, Oct 26, 2008 at 11:23:35PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > c) 'dirty' in some way -- new files, uncommitted changes, etc.
>
> git update-index -q --refresh
> test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
I wanted to write '|| echo "dirty"', sorry.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 0:20 UTC (permalink / raw)
To: mercurial; +Cc: Jakub Narebski, SLONIK.AZ, git
In-Reply-To: <200810261955.10536.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> > * 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...
Before we get tangled in this train of thought:
I created a head-to-head code_swarm of Mercurial and Git and it clearly shows
that Mercurial development didn't slow down.
The code_swarm isn't a fancy one with music and annotations, but I think
you'll directly see for yourself what I mean:
- http://www.rakjar.de/shared_codeswarm/hg-vs-git-short.avi
red is git,
blue is Mercurial.
It is a result of my shared_codeswarm project with which you can create
code_swarms from more than one repository automatically - and update them
incrementally, creating new code_swarms of only the new commits in the
repositories:
- http://www.rakjar.de/shared_codeswarm/project_activity_battle_swarm.html
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-cvsimport produces different (broken) repos when using pserver or local repo access
From: Roger Leigh @ 2008-10-27 0:25 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 3350 bytes --]
Hi,
I've noticed that git-cvsimport can under some circumstances produce broken
repositories. This appears to only occur when using pserver access to the CVS
repo; running with a local repo is apparently fine, with all tested versions
giving the same repo (master head has same hash for the last commit).
In all cases cvsps version 2.1 was used.
Repo source:
pserver :pserver:anonymous@gimp-print.cvs.sourceforge.net:/cvsroot/gimp-print
local rsync -av 'rsync://gimp-print.cvs.sourceforge.net/cvsroot/gimp-print/*' cvs-backup
I've tested with a number of git versions, including git.git as of yesterday:
git version repo last commit URI
1.5.5.GIT local a51c479826 git://git.debian.org/git/users/rleigh/gutenprint-upstream.git
1.5.5.GIT (2 failures) pserver bfa6f8248a git://git.debian.org/git/users/rleigh/gutenprint-upstream-broken.git
1.5.5.GIT (no failure) pserver bfa6f8248a git://git.debian.org/git/users/rleigh/gutenprint-upstream-pserver.git
1.5.6.5 local a51c479826 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.5.6.5-local.git
1.5.6.5 pserver 6f0950c097 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.5.6.5-pserver.git
git.git 1.6.0.3.517.g759a local a51c479826 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.6-local.git
git.git 1.6.0.3.517.g759a pserver 6f0950c097 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.6-pserver.git
With git 1.5.5 I'm tracking the CVS repo running git-cvsimport every 20 mins
from a cron job. A few months ago it managed to botch, resulting in a broken
repo (it didn't delete files deleted from CVS). I think this occurs when
git-cvsimport fails (I get a perl error, though I'm afraid I don't have the log
anymore); running again results in successful completion, but the repo is
screwed, I think due to that commit being incomplete or something. This
occured twice during the import in the second line in the above table, in this
case resulting in missing files (src/cups/i18n.*). Again, I'm afraid I don't
have the logs, but I can repeat again if this is not an already known/fixed
issue. The repo is quite big, taking several hours to import, so it might
possibly be a network connection problem and it's not handling that correctly
on failure. However, even when the import comples successfully (line 3), the
hash is still the same as line 2 where it failed twice and needed restarting.
So, it looks like depending on if I use a local repo directly or remove via
pserver, I get a different repo. 1.5.5 using pserver is different to later
versions, presumably this is a buggy version because it's broken whether or not
I get a failure. Later versions always completed without failure; while the
local and pserver using repos differ, they do both seem OK. However, I would
have expected identical results, given that they are all created from the
same data.
The script I used to do the import is attached.
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 #1.2: gutenprint-bootstrap --]
[-- Type: text/plain, Size: 577 bytes --]
#!/bin/bash
CVSROOT=:pserver:anonymous@gimp-print.cvs.sourceforge.net:/cvsroot/gimp-print
CVSMODULE=print
HOME=/home/users/rleigh
GIT_DIR=/var/lib/gforge/chroot/home/users/rleigh/public_git/gutenprint-upstream.git
LOGDIR=${HOME}/log
LOCKFILE=${HOME}/gutenprint-cvs.lock
AUTHORS=${HOME}/gutenprint-auth
#date -R
lockfile -2 -r 2 ${LOCKFILE}
# If we managed to lock the file
if [ $? -eq 0 ]; then
# echo "Running git-cvsimport"
export GIT_DIR
export CVSROOT
git-cvsimport -A $AUTHORS -i -v print
rm -f ${LOCKFILE}
else
echo "Couldn't get lock for cvssuck"
fi
#date -R
[-- Attachment #1.3: gutenprint-auth --]
[-- Type: text/plain, Size: 1881 bytes --]
andystewart=Andy Stewart <andystewart@attbi.com>
anikin=Eugene Anikin <eugene@anikin.com>
cpbs=Charles Briscoe-Smith <cpbs@debian.org>
daberti=Daniele Berti <daberti@users.sourceforge.net>
davehill=Dave Hill <dave@minnie.demon.co.uk>
degger=Daniel Egger <degger@users.sourceforge.net>
doctormo=Martin Owens <doctormo@users.sourceforge.net>
dpace=David Pace <dpace@echo-on.net>
easysw=Mike Sweet <msweet@apple.com>
faust3=Sascha Sommer <saschasommer@freenet.de>
gandy=Andy Thaller <thaller@ph.tum.de>
gtaylor=Grant Taylor <gtaylor@users.sourceforge.net>
iay=Ian Young <ian@iay.org.uk>
jmv=Jean-Marc Verbavatz <verbavatz@ifrance.fr>
julianbradfield=Julian Bradfield <julianbradfield@users.sourceforge.net>
khk=Karl Heinz Kremer <khk@khk.net>
m0m=Michael Mraka <michael.mraka@linux.cz>
mbroughtn=mbroughtn <mbroughtn@users.sourceforge.net>
menthos=Christian Rose <menthos@users.sourceforge.net>
mitsch=Michael Natterer <mitschel@cs.tu-berlin.de>
mtomlinson=Mark Tomlinson <mark.tomlinson@xtra.co.nz>
nestordi=nestor di <nestordi@users.sourceforge.net>
nicholas=nicholas <nicholas@users.sourceforge.net>
peter_missel=Peter Missel <peter_missel@users.sourceforge.net>
rblancha=Richard Blanchard <rblancha@users.sourceforge.net>
rleigh=Roger Leigh <rleigh@debian.org>
rlk=Robert Krawitz <rlk@alum.mit.edu>
rwisi=Richard Wisenoecker <Richard.Wisenoecker@gmx.at>
sharkey=Eric Sharkey <sharkey@debian.org>
smiller=Steve Miller <smiller@rni.net>
spa=Salvador Abreu <spa@users.sourceforge.net>
stevek=Steve Kann <stevek@stevek.com>
tillkamppeter=Till Kamppeter <till.kamppeter@gmail.com>
ttonino=Thomas Tonino <ttonino@bio.vu.nl>
tylerb=Tyler Blessing <tylerb@users.sourceforge.net>
uid21630=uid21630 <uid21630@users.sourceforge.net>
wiz=Joseph S. Wisniewski <wiz@users.sourceforge.net>
wollvieh=Wolfgang Bauer <wollvieh@users.sourceforge.net>
zoopa =Pete Parks <zoopa@users.sourceforge.net>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 0:47 UTC (permalink / raw)
To: mercurial; +Cc: Jakub Narebski, SLONIK.AZ, git
In-Reply-To: <200810261955.10536.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> 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.
What do you mean by "cleaner design"?
From what I see (and in my definition of "design"), Mercurial is designed as
VCS with very clear and clean design, which even keeps things like streaming
disk access in mind.
Also, looking at git, git users still have to garbage collect regularly, which
shows to me that the design wasn't really cleaner.
As an example: If I want some revision in hg, my repository just reads the
files in the store, jumps to the latest snapshots, adds the changes after
these and has the data.
In git is has to check all changesets which affect the file.
If you read the hgbook, you'll find one especially nice comment:
"Unlike many revision control systems, the concepts upon which Mercurial is
built are simple enough that it’s easy to understand how the software really
works. Knowing this certainly isn’t necessary, but I find it useful to have a
“mental model” of what’s going on."
- http://hgbook.red-bean.com/hgbookch4.html
I really like that, and in my opinion it is a great compliment to hg, for two
reasons:
1) Hg is easy to understand
2) You don't have to understand it to use it
And both are indications of a good design, the first of the core, the second
of the UI.
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 1:52 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: mercurial, SLONIK.AZ, git
In-Reply-To: <200810270147.52490.arne_bab@web.de>
On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> >
> > 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.
>
> What do you mean by "cleaner design"?
Clean _underlying_ design. Git has very nice underlying model of graph
(DAG) of commits (revisions), and branches and tags as pointers to this
graph.
> From what I see (and in my definition of "design"), Mercurial is designed as
> VCS with very clear and clean design, which even keeps things like streaming
> disk access in mind.
I have read description of Mercurial's repository format, and it is not
very clear in my opinion. File changesets, bound using manifest, bound
using changerev / changelog.
Mercurial relies on transactions and O_TRUNC support, while Git relies
on atomic write and on updating data then updating reference to data.
I don't quite understand comment about streaming disk access...
> Also, looking at git, git users still have to garbage collect regularly, which
> shows to me that the design wasn't really cleaner.
Well, they have to a lot less than they used to, and there is
"git gc --auto" that can be put in crontab safely.
Explicit garbage collection was a design _decision_, not a sign of not
clear design. We can argue if it was good or bad decision, but one
should consider the following issues:
* Rolling back last commit to correct it, or equivalently amending
last commit (for example because we forgot some last minute change,
or forgot to signoff a commit), or backing out of changes to the
last commit in Mercurial relies on transactions (and locking) and
correct O_TRUNC, while in Git it leaves dangling objects to be
garbage collected later.
* Mercurial relies on transaction support. Git relies on atomic write
support and on the fact that objects are immutable; those that are
not needed are garbage collected later. Beside IIRC some of ways of
implementing transaction in databases leads to garbage collecting.
* Explicit packing and having two repository "formats": loose and
packed is a bit of historical reason: at the beginning there was
only loose format. Pack format was IIRC invented for network
transport, and was used for on disk storage (the same format!) for
better I/O patterns[1]. Having packs as 'rewrite to pack' instead
of 'append to pack' allows to prefer recency order, which result in
faster access as objects from newer commits are earlier in delta
chain and reduction in size in usual case of size growing with time
as recency order allows to use delete deltas. Also _choosing_ base
object allows further reduce size, especially in presence of
nonlinear history.
* From what I understand Mercurial by default uses packed format for
branches and tags; Git uses "loose" format for recent branches
(meaning one file per branch), while packing older references.
Using loose affects performance (and size) only for insane number of
references, and only for some operations like listing all references,
while using packed format is IMHO a bit error prone when updating.
* Git has reflogs which are pruned (expired) during garbage collecting
to not grow them without bounds; AFAIK Mercurial doesn't have
equivalent of this feature.
(Reflogs store _local_ history of branch tip, noting commits,
fetches, merges, rewinding branch, switching branches, etc._
[1] You wrote about "streaming disk access". Git relies (for reading)
on good mmap implementation.
> As an example: If I want some revision in hg, my repository just reads the
> files in the store, jumps to the latest snapshots, adds the changes after
> these and has the data.
If you want to show some revision in Git, meaning commit message and
diff in patch format (result of "git show"), Git just reads the commit,
outputs commit message, reads parent, reads trees and performs diff.
If you want to checkout to specific revision, Git just reads commit,
reads tree, and writes this tree (via index) to working area.
> In git is has to check all changesets which affect the file.
I don't understand you here... if I understand correctly above,
then you are wrong about Git.
> If you read the hgbook, you'll find one especially nice comment:
>
> "Unlike many revision control systems, the concepts upon which Mercurial is
> built are simple enough that it’s easy to understand how the software really
> works. Knowing this certainly isn’t necessary, but I find it useful to have a
> “mental model” of what’s going on."
> - http://hgbook.red-bean.com/hgbookch4.html
>
> I really like that, and in my opinion it is a great compliment to hg, for two
> reasons:
>
> 1) Hg is easy to understand
Because it is simple... and less feature rich, c.f. multiple local
branches in single repository.
> 2) You don't have to understand it to use it
You don't have to understand details of Git design (pack format, index,
stages, refs,...) to use it either.
>
> And both are indications of a good design, the first of the core, the second
> of the UI.
Well, Git is built around concept of DAG of commits and branches as
references to it. Without it you can use Git, but it is hard. But
if you understand it, you can understand easily most advanced Git
features.
I agree that Mercurial UI is better; as usually in "Worse is Better"
case... :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [ANNOUNCE] intergit repository-linking tool (early release)
From: Christian Jaeger @ 2008-10-27 2:22 UTC (permalink / raw)
To: Git Mailing List; +Cc: gambit-list
Hello
Ten days ago I started a thread about "Separating generated files?" [1],
and suggested in the end that instead of using git submodule
functionality, one might be better off using a tool which can, upon
committing files in the repository containing generated files, add a
link ("reference") pointing to the commit in the source repository which
represents the source files they have been generated from, and then when
someone is checking out some revision of the source files later, use
this information to find the (best-)matching commit in the repository
with the generated files. This may also be useful in other situations
where one likes to keep repositories separate but they have a version
dependency on each other.
I've now written a first version of a pair of these two programs, which
accomplishes this. You can get them from:
http://www.christianjaeger.ch/dyn/pubgit/gitweb?p=intergit.git;a=summary
git clone http://christianjaeger.ch/pubgit/intergit.git
This will need some finish before really being production ready; it will
mainly need some experimentation on how it is to be used exactly, so
that possibly missing features in the search and indexing algorithms can
be added (like whether it should understand merges between two commits
containing references as a commit having both references even if the
merge commit doesn't specify a reference), and I'm also keen on some
feedback implementation-wise (building the index is currently slow, and
some of the problems that I'm listing in the docs (Implementation.txt
and TODO.txt) may have solutions I've not been aware of). I've tried to
add some useful documentation (see *.txt files), so I'm hoping this
helps anyone interested to understand how it works, or just give me some
feedback on how it may or may not be useful.
I've developed and tested it on Linux. Hints on whether it works under
other systems and how to make it work with msysgit would be very
appreciated.
Christian
[1] http://marc.info/?l=git&m=122415845625044&w=2
PS. I've just noticed the thread about "repo - The Multiple Git
Repository Tool". I'll have to take a look first to see how it is
related to my program--it may take me a few days as I'll be busy.
--
My OpenPGP fingerprint: F033 D030 F75D E445 05A1 1865 4ECB DF80 1FE6 92DA
^ permalink raw reply
* Problems during upgrade git from 1.5.3.2 to latest
From: horry @ 2008-10-27 2:29 UTC (permalink / raw)
To: git
Hello ,
My previous git version is 1.5.3.2 and i perform the suggested commands :
git clone http://www.kernel.org/pub/scm/git/git.git and it goes well , end
up with :
....................................................................
got d00da833cbeec16da9415e0ac11269594279545a
Checking 1480 files out...
100% (1480/1480) done
Then i checked git version , it still shows previous version without any
change .
XXXXXXX:/apps/mds_lrt/git/git> git version
git version 1.5.3.2
Is there additional command which i should perform after clone ?
thanks,
Horry
--
View this message in context: http://www.nabble.com/Problems-during-upgrade-git-from-1.5.3.2-to-latest-tp20180862p20180862.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC] gitweb: add 'historyfollow' view that follows renames
From: Blucher, Guy @ 2008-10-27 3:17 UTC (permalink / raw)
To: ming.m.lin, jnareb, robert.moore; +Cc: git
Hi Folks,
>>
>> What should we add to automatically get all file history?
> While the 'commitdiff' view would, in default gitweb configuration,
> contain information about file renames, currently 'history' view does
> not support '--follow' option to git-log. It wouldn't be too hard to
> add it, but it just wasn't done (well, add to this the fact that
> --follow works only for simple cases).
We also ran up against this issue because renaming of files in our
project is a useful bit of information while browsing file history.
I hacked gitweb to add a 'historyfollow' viewing option in addition to
the 'history' option. Yes, '--follow' is expensive so I didn't just
make it the default 'history' behaviour.
The only problem with doing it was that parse_commits in gitweb.perl
uses git rev-list which doesn't support the '--follow' option like
git-log does. A bit of hacking to use 'git log --pretty=raw -z' to make
the output look close to that from rev-list means only minor
shoe-horning is required (perhaps it would be better to make rev-list
understand --follow though?).
I wasn't originally prepared to publish the work here because I don't
really think it's the best solution. But considering it's come up... I
include a patch inline against gitweb.perl from v1.6.0.3 that implements
a 'historyfollow' view.
Feel free to do with it what you will. It would need some substantial
tidying up by someone who knows much more about perl than me :)
We use it such that anywhere a 'history' link is provided a
'historyfollow' link is also provided next to it - This patch doesn't
implement that bit though.
Hope it helps.
Cheers,
Guy.
---
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -478,6 +478,7 @@ my %actions = (
"forks" => \&git_forks,
"heads" => \&git_heads,
"history" => \&git_history,
+ "historyfollow" => \&git_history_follow,
"log" => \&git_log,
"rss" => \&git_rss,
"atom" => \&git_atom,
@@ -2311,25 +2312,39 @@ sub parse_commit {
}
sub parse_commits {
- my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
+ my ($commit_id, $maxcount, $skip, $mode, $filename, @args) = @_;
my @cos;
$maxcount ||= 1;
$skip ||= 0;
local $/ = "\0";
+ # The '--max-count' argument is not available when doing a
+ # '--follow' to 'git log'
+ my $count_arg = ("--max-count=" . $maxcount) ;
+ if (defined $mode && $mode eq "--follow") {
+ $count_arg = "--follow" ;
+ }
- open my $fd, "-|", git_cmd(), "rev-list",
- "--header",
+
+ open my $fd, "-|", git_cmd(), "log",
+ "-z",
+ "--pretty=raw",
@args,
- ("--max-count=" . $maxcount),
+ ($count_arg ? ($count_arg ) : ()),
("--skip=" . $skip),
@extra_options,
$commit_id,
"--",
($filename ? ($filename) : ())
- or die_error(500, "Open git-rev-list failed");
+ or die_error(500, "Open git-log failed");
while (my $line = <$fd>) {
+ # Need to put a delimiter on the end of output
+ # 'git-log -z' doesn't put one before EOF like rev-list
does
+ $line = ($line . '\0');
+ # Need to strip the word commit from the start so it
+ # looks like rev-list output
+ $line =~ s/^commit // ;
my %co = parse_commit_text($line);
push @cos, \%co;
}
@@ -5363,6 +5378,13 @@ sub git_commitdiff_plain {
}
sub git_history {
+ my $mode = shift || '';
+ my $history_call = "history";
+
+ if ($mode eq "--follow") {
+ $history_call .= "historyfollow" ;
+ }
+
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
}
@@ -5377,7 +5399,7 @@ sub git_history {
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
my @commitlist = parse_commits($hash_base, 101, (100 * $page),
- $file_name, "--full-history")
+ $mode, $file_name,
"--full-history")
or die_error(404, "No such file or directory on given
branch");
if (!defined $hash && defined $file_name) {
@@ -5398,7 +5420,7 @@ sub git_history {
my $paging_nav = '';
if ($page > 0) {
$paging_nav .=
- $cgi->a({-href => href(action=>"history",
hash=>$hash, hash_base=>$hash_base,
+ $cgi->a({-href => href(action=>"$history_call",
hash=>$hash, hash_base=>$hash_base,
file_name=>$file_name)},
"first");
$paging_nav .= " ⋅ " .
@@ -5429,6 +5451,11 @@ sub git_history {
git_footer_html();
}
+sub git_history_follow {
+ git_history('--follow');
+}
+
+
sub git_search {
gitweb_check_feature('search') or die_error(403, "Search is
disabled");
if (!defined $searchtext) {
@@ -5469,7 +5496,7 @@ sub git_search {
$greptype = "--committer=";
}
$greptype .= $searchtext;
- my @commitlist = parse_commits($hash, 101, (100 *
$page), undef,
+ my @commitlist = parse_commits($hash, 101, (100 *
$page), undef, undef,
$greptype,
'--regexp-ignore-case',
$search_use_regexp ?
'--extended-regexp' : '--fixed-strings');
@@ -5737,7 +5764,7 @@ sub git_feed {
# log/feed of current (HEAD) branch, log of given branch,
history of file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150, 0, $file_name);
+ my @commitlist = parse_commits($head, 150, 0, undef,
$file_name);
my %latest_commit;
my %latest_date;
---
Guy.
____________________________________________________
Guy Blucher
Defence Science and Technology Organisation
AUSTRALIA
IMPORTANT : This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this email in error, you are
requested to contact the sender and delete the email.
^ permalink raw reply
* Re: Problems during upgrade git from 1.5.3.2 to latest
From: Pete Harlan @ 2008-10-27 3:58 UTC (permalink / raw)
To: horry; +Cc: git
In-Reply-To: <20180862.post@talk.nabble.com>
horry wrote:
> Hello ,
> My previous git version is 1.5.3.2 and i perform the suggested commands :
> git clone http://www.kernel.org/pub/scm/git/git.git and it goes well , end
> up with :
>
> ....................................................................
> got d00da833cbeec16da9415e0ac11269594279545a
> Checking 1480 files out...
> 100% (1480/1480) done
>
> Then i perform make in the same directory i performed clone and it shows
> errors .
>
> bfnt47-gx1:/apps/mds_lrt/git/git> make
> GIT_VERSION = 1.6.0.3.517.g759a
> * new build flags or prefix
> CC fast-import.o
> In file included from /usr/include/openssl/ssl.h:179,
> from git-compat-util.h:104,
> from builtin.h:4,
> from fast-import.c:142:
> /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
This is saying that you are missing this header file. On my machine
(Debian Linux "testing") the package that provides that file is libkrb5-dev.
Even if you're not using Debian, or Linux, this page may help you locate
which packages on your system may contain a given missing file:
http://www.debian.org/distrib/packages#search_contents
Entering krb5.h in the "Search the contents of packages" box brings up a
list of packages containing files ending in "krb5.h", one (likely
example of which) is libkrb5-dev.
--Pete
> XXXXXXX:/apps/mds_lrt/git/git> git version
> git version 1.5.3.2
>
> Can someone tell me how to resolve it ?
>
> thanks,
> Horry
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Leo Razoumov @ 2008-10-27 4:15 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: mercurial, Jakub Narebski, git
In-Reply-To: <200810270120.55276.arne_bab@web.de>
On 10/26/08, Arne Babenhauserheide <arne_bab@web.de> wrote:
> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
>
> > > * 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...
>
>
> Before we get tangled in this train of thought:
>
> I created a head-to-head code_swarm of Mercurial and Git and it clearly shows
> that Mercurial development didn't slow down.
>
I am not familiar with code swarms, sorry. My impressions are
subjective are thoroughly un-scientific:-)
(1) Judging by the activity of mailing lists git community is several
times larger and more active in terms of actual submitted patches.
(2) Hg forest extension is still not in the tree with outdated and
incorrect documentation in the wiki. For me it was biggest reason to
migrate from Hg to git.
--Leo--
^ permalink raw reply
* Re: [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Junio C Hamano @ 2008-10-27 5:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Where is git_snpath() used?
^ permalink raw reply
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw)
To: David M. Syzdek; +Cc: git
In-Reply-To: <1225021957-11880-1-git-send-email-david.syzdek@acsalaska.net>
"David M. Syzdek" <david.syzdek@acsalaska.net> writes:
> 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.
> ...
> 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
I have a stupid question.
Would it be a more appropriate improvement to do it like this:
ifdef USE_THIS_AS_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t="$(USE_THIS_AS_UINTMAX_T)"
endif
and then add a section for FreeBSD 4.9-SECURITY like this:
ifeq ($(uname_R),4.9-SECURITY)
USE_THIS_AS_UINTMAX_T = uint32_t
endif
That way, an oddball 64-bit machine can use uint64_t here if it wants to,
possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Junio C Hamano, René Scharfe, Git Mailing List
In-Reply-To: <237967ef0810261129y58898019m503a1f1593a95591@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> 2008/10/26 Junio C Hamano <gitster@pobox.com>:
> ...
>> 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.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 7/8] wt-status: load diff ui config
From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081026044935.GG21047@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But it makes me a little nervous. On one hand, I think it is definitely
> the right thing for "status -v" to respect user options. But we do
> several _other_ diffs in addition, and those are more "plumbing" diffs.
> I think they should probably at least have diff_basic_config (e.g., for
> rename limits). But we are applying the diff_ui_config options to all
> diffs. Looking over the available options, I _think_ there are no nasty
> surprises. But you never know.
Up to 6/8 are indisputably good changes. The next one means well, and
this one is a requisite step for it, but I agree that this feels somewhat
risky.
^ permalink raw reply
* Re: [PATCH 0/3] symref rename/delete fixes
From: Junio C Hamano @ 2008-10-27 5:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1224987944.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> A symref-aware rename_ref() is needed by git remove rename, since it
> typically does origin/HEAD -> upstream/HEAD symref renames there.
>
> Of course you can say that this should be handled by git-remote itself,
> without using rename_ref() but that not seem to be a good solution to
> me. (Workaround in the wrong layer, instead of a solution in a good
> one.)
I do not think it is a workaround at all.
I would even say that the renaming of symref that "git remote rename"
needs to do is fundamentally different from what rename_ref() is about,
and trying to cram it into rename_ref() is a grave mistake.
If you "git remote rename origin upstream" when origin/HEAD points at
refs/remotes/origin/master, you need to make the renamed one point at
refs/remotes/upstream/master, as you will be renaming origin/master to
upstream/master.
Normal "rename_ref()" would just rename the ref without touching its
contents, and if you used it to implement "git remote rename", your
upstream/HEAD would point at the old name "origin/master" that will
disappear when rename is finished, wouldn't it? I do not think it is
useful.
There may be cases where you would really want to rename the symbolic ref
without changing its value (e.g. which other ref it points at), but as you
mentioned, even "git branch -m" is not such a usecase.
I think it is better to simply forbid renaming of a symref _until_ we know
what we want it to mean. It is a lot easier to start strict and then add
features, than start loosely and implement an unclean semantics, and then
having to fix that semantics after people start to rely on the initial
(potentially crazy) semantics.
^ 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