* Re: FAQ Q: another version control system?
From: Martin Langhoff @ 2007-05-02 22:04 UTC (permalink / raw)
To: Peter; +Cc: git
In-Reply-To: <9e7886190705020013k5721480aj767c1c8643fc8d23@mail.gmail.com>
On 5/2/07, Peter <petervanbohning@gmail.com> wrote:
> But why isn't such a feature set added into SVN? Why do I have to
> download another version control system just so that I can "git"
> libxcb and X11 so that I can compile gtk so that I can compile xchat
If you are just a user trying to get a development version of libxcb,
I am sure that you can download a snapshot -- if the project doesn't
offer them formally, it'll probably have a "gitweb" thingy to browse
the development history online that also allows you to download a
snapshot. If it's really x.org they _definitely_ have gitweb (just
like viewsvn or viewcvs). No need to get git.
If you are a developer, git knows a lot of tricks that svn/cvs don't,
things that change how a large and broad project is developed. Lots of
people find it worthwhile, so chances are there'll be a payoff to the
pain of learning it. :-)
cheers,
martin
^ permalink raw reply
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Dana How @ 2007-05-02 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <56b7f5510705021155k40b576d6ke286e65494fc8b05@mail.gmail.com>
On 5/2/07, Dana How <danahow@gmail.com> wrote:
> On 5/2/07, Junio C Hamano <junkio@cox.net> wrote:
> > Dana How <danahow@gmail.com> writes:
> > > Consequently, for such a usage pattern it is useful
> > > to specify different compression levels for loose
> > > objects and packs. This patch implements a config
> > > variable pack.compression in addition to the existing
> > > core.compression, meant to be used for repacking.
> > > It also adds --compression=N to pack-objects,
> > > meant for push/pull/fetch, if different, or if different
> > > on a per-repository basis.
> > >
> > > ** THIS PATCH IS UNTESTED AND MEANT FOR DISCUSSION. **
> >
> > I think we tweaked this area in the past, but I do not think
> > the current setting was determined to be the best tradeoff for
> > all workloads. To be able to discuss the patch, I think it
> > needs to come with benchmark numbers using publicly available
> > repositories as guinea pigs and set of typical git operations,
> > so people can reproduce and compare notes.
>
> OK, but this patch doesn't mandate any particular setting.
>
> Its motivation in my work environment is for pack.compression
> to be what core.compression currently is, and to set
> core.compression to 0 to speed up large commits
> (the resulting space-inefficient loose objects will be scrubbed away
> by a later off-line repack).
> Thus, my config settings (almost) change the gzip's behind a git-add to cp's.
> Do you want me to submit timings for a git-add/git-commit -a
> on a typical 50-file commit I would be interested in,
> with the (new) settings that I would use?
Note the linux-2.6 git tree from a week ago has 22K checked-out files
of average size 11KB; the largest is fs/nls/nls-cp949.c at 874KB.
(The largest file in git is gitk at 176K.)
The tree I'm interested in maintaining with git is almost 70GB
checked-out in 13K files of average size >5.2MB. This is over
2 orders of magnitude larger average file size than current git users.
(Some of these numbers may decrease after a little retraining ;-).)
I would like git to perform as responsively as possible on files
up to ~500MB. Within this tree, the largest file is 1234MB
[I think checking this in was a mistake!]
and I did the following experiments on it:
$ rm -rf .git
$ git-init
Initialized empty Git repository in .git/
$ git-config core.compression -1
$ wc large.spef
12762072 37832482 1234082774 large.spef
$ /usr/bin/time git-add large.spef
41.54user 0.70system 0:49.76elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k
$ ls -lR .git/objects/??
.git/objects/d5:
total 83836
-r--r--r-- 1 how group 85670068 May 2 15:11
d6cde2af063cdfa835038385f29a897bf9533b
$ rm -rf .git
$ git-init
Initialized empty Git repository in .git/
$ git-config core.compression 1
$ wc large.spef
12762072 37832482 1234082774 large.spef
$ /usr/bin/time git-add large.spef
23.66user 0.74system 0:34.07elapsed 71%CPU (0avgtext+0avgdata 0maxresident)k
$ ls -lR .git/objects/??
.git/objects/d5:
total 105116
-r--r--r-- 1 how group 107419557 May 2 15:13
d6cde2af063cdfa835038385f29a897bf9533b
So for a 25% increase in blob size I get 33% less elapsed time
in git-add, all by changing core.compression from -1 to 1.
I'll definitely take that improvement. [For the compressible files
we typically have, using 0 is a bad idea: the CPU "advantage"
is swamped out by the time to write a much larger file.]
Since I don't care [to the same degree] about the responsiveness of
packing, I'd rather pack with -1 or better to keep packs small.
(And inflation time seems independent of compression setting.)
Since someone might be working while the packing is happening,
I'd rather not change the config setting to achieve this.
Hence the patch.
Concerning various public repositories, clearly the patch has no
impact if you don't specify different core.compression and pack.compression
values. If you do specify different values, I doubt there would be much
noticeable speed-up for e.g. the linux-2.6 repo stats I included above.
There would be some, but that wasn't the motivation for the patch.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [PATCH] git-merge.1: Mention option -s at topic MERGE STRATEGIES
From: Jari Aalto @ 2007-05-02 23:01 UTC (permalink / raw)
To: git
When the option is reminded at the same place as the explanation text,
this will help reader to associate these two. Sidenote: text may be
currently scrolled in a manual reader or HTML page to hide the
mentioned options at the beginning.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 9c08efa..fb0c9f7 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -38,7 +38,7 @@ include::merge-options.txt[]
include::merge-strategies.txt[]
-
+The strategy is defined by supplying option '-s'.
If you tried a merge which resulted in a complex conflicts and
would want to start over, you can recover with
gitlink:git-reset[1].
--
1.5.1.3
^ permalink raw reply related
* Re: Git benchmarks at OpenOffice.org wiki
From: Jakub Narebski @ 2007-05-02 23:30 UTC (permalink / raw)
To: Jan Holesovsky, git; +Cc: dev
In-Reply-To: <200705021624.25560.kendy@suse.cz>
Jan Holesovsky wrote:
> On Tuesday 01 May 2007 23:46, Jakub Narebski wrote:
>
>> What I am concerned about is some of git benchmark results at Git page
>> on OpenOffice.org wiki:
>> http://wiki.services.openoffice.org/wiki/Git#Comparison
>> The problem is with 'Size of checkout': to start working in repository
>> one needs 1.4G (sources) and 98M (third party) for CVS checkout (it is
>> 1.5G for sources for Subversion checkout). Ordinary for distributed SCM
>> you would need size of repository + size of sources (working area),
>> which is 2.8G for sources and 688M for third party stuff files you can
>> hack on + the history]. This makes some prefer to go centralized SCM
>> route, i.e. Subversion as replacement for CVS (+ CWS, ChildWorkSpace).
>
> Considering the size OOo needs for build (>8G without languages),
> the ~1.4G overhead for history is very well bearable. I am surprised about
> the 100M overhead for SVN as well - from my experience it is usually about
> the size of the project itself; but maybe they improved something in SVN
> in the meantime.
I think the supposition that SVN uses hardlinks for pristine copy
of sources (HEAD version) seems probable; then there it is 100M overhead
plus size of changed files, and of course this tricks works only on
filesystems which support hardlinks, and assumes either hardlinks being
COW-links (copy-on-write) or editor behaving.
>> What might help here is splitting repository into current (e.g. from
>> OOo 2.0) and historical part,
>
> No, I don't want this ;-)
I forgot to add there is possible to graft historical repository to the
current work repository, resulting in full history available. For example
Linux kernel repository has backported from BK historical repository, and
there is grafts file which connect those two repositories.
>> and / or using shallow clone.
git-clone(1):
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
specified number of revs. A shallow repository has
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
want to only look at near the tip of a large project
with a long history, and would want to send in a fixes
as patches.
It is possible that those limitations will be lifted in the future
(if possible), so there is alternate possibility to reduce needed
disk space for git checkout. But certainly this is not for everybody.
>> Implementing
>> partial checkouts, i.e. checking out only part of working area (...)
The problem with implementing this feature (you can do partial checkout
using low level commands, but this feature is not implemented [yet?]
per se) is with doing merge on part which is not checked out. Might
not be a problem for OOo; but this might be also not needed for OOo.
Sometimes submodules are better, sometimes partial checkout is the
only way: see below.
>> Splitting repository into submodules, and submodule
>> support -- it depends on organization of OOo sources, would certainly
>> help for third party stuff repository.
>
> We should better split the OOo sources; it's a process that already started
> [UNO runtime environment vs. OOo without URE], and I proposed some more
> changes already.
In my opinion each submodule should be able to compile and test by
itself. You can go X.Org route with splitting sources into modules...
or you can make use of the new submodules support (currently plumbing
level, i.e. low level commands), aka. gitlinks.
The submodules support makes it possible to split sources into
independent modules (parts), which can be developed independently,
and which you can download (clone, fetch) or not, while making it
possible to bind it all together into one superproject.
See (somewhat not up to date) http://git.or.cz/gitwiki/SubprojectSupport
page on git wiki.
>> What I'm really concerned about is branch switch and merging branches,
>> when one of the branches is an old one (e.g. unxsplash branch), which
>> takes 3min (!) according to the benchmark. 13-25sec for commit is also
>> bit long, but BRANCH SWITCHING which takes 3 MINUTES!? There is no
>> comparison benchmark for CVS or Subversion, though...
By the way, the time to switch branch should be proportional to number
of changed files, which you can get with "git diff --summary unxsplash
HEAD". Or to be more realistic to checkout some old version
(some old tag), as usually branches which got merged in are deleted
(or even never got published). For example when bisecting some bug:
Subversion doesn't have bisect, does it?
I wonder if running "git pack-refs" would help this benchmark...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-blame not tracking copies
From: Junio C Hamano @ 2007-05-02 23:42 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705022033.25885.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> All git-blame commands are "git-blame -C1 -C1"
I am sick and not functioning well today, so will not be able to
review what is happening with your example deeply, but here are
some comments to get you started digging.
There is a built-in sanity valve in git-blame that refuses to
pass down the blame via -M/-C for really trivial hunks. Without
such safety, all the empty lines in the latest revision would be
attributed to a random empty line in a random file in the root
commit ;-).
By default, the sanity valve is set to refuse a hunk that has 20
or 40 alnum characters. These values seem to be appropriate for
real life projects, but obviously the real-world case would be
very different from a made-up "each commit changes one-line"
test case and it would be understandable that the command would
behave differently.
Also with real-life projects, probably depending on the coding
style and merge patterns, I would not be surprised if there are
rooms to tweak the heuristics.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Jakub Narebski @ 2007-05-02 23:48 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20070502T111026-882@post.gmane.org>
Panagiotis Issaris wrote:
> Some of the people of the FFmpeg project are looking at both GIT and Mercurial
> as possible replacements for the current Subversion repository. They have some
> questions regarding the possibility of doing certain things, which I prefer not
> to answer as I am not sure my answer would be correct :) Which is why I am
> posting here...
>
> The questions are stated in this e-mail [1]. One of the things that are being
> discussed is the following action on a publicly mirrored repository:
> git branch -m master dead_end
> git branch -m last_good master
>
> I'd think this would fail as people could have pulled from the repository while
> the "dead_end" commit was already available, right?
>
> There are some other things the FFmpeg maintainer mentions, namely:
> * He wants to be able to revert a commit in some way without "wiping" history.
> That is without committing a patch which reverses the broken commit, as this
> would pollute "git blame". The maintainer sees this as critical feature for
> switching to git as it apparently can be doing using Subversion:
> "in svn we can do this with svn cp from a specific
> revission git and mercurial lack proper copy support"
About removing a commit: assume that you have the following history
A---B---C---D---E <--- branch
Now you have noticed that commit C is wrong, and it should not be there.
One solution, which is used usually if the history was published, is to
revert a commit, resulting in the following history:
A---B---C---D---E---C^-1 <--- branch
(which is what git-revert does).
Now if you didn't publish this history, or you don't care that you are
rewriting history, it is fairly easy to remove commit C (for example
using "git rebase --onto B D E" command), resulting in the following
history:
A---B---C---D---E
\
\
\----D'--E' <--- branch
(which after pruning would result in A---B---D'--E' history).
The problem exists _only_ if somebody based his/her work on commit
C or its descendant, i.e. original D, E commits. He/she would have
to rebase his/her work on top of _changed_ (moved) commits D' and E'.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Petr Baudis @ 2007-05-03 1:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f1b806$nc7$1@sea.gmane.org>
On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:
> About removing a commit: assume that you have the following history
> The problem exists _only_ if somebody based his/her work on commit
> C or its descendant, i.e. original D, E commits. He/she would have
> to rebase his/her work on top of _changed_ (moved) commits D' and E'.
"_Only_"?
I think it's just totally unsustainable to do this history rewriting in
an "upstream" git repository. You will get horridly confused, then
frustrated and then just move from software development to beekeeping.
Imagine what will happen in gitk --all - you will see many commits
several times in a row because each is part of different subhistory for
a given head. Merging between branches will become totally impossible.
People keeping their clones (or even forking history) will be confused
and horrified. Bits of patches inbetween the original commit and the
revert moment will lose their meaning, the history won't be trustworthy
anymore at all.
In the end, using these practices git will end up useful roughly as a
faster but crippled SVN. So please don't ever just suggests how random
git commands and features with special usage might work without
carefully explaining the implications and why this is _not_ the way to
use git. If ffmpeg insists on having an X feature and it's not feasible
to make it work well with principles git is built on, ffmpeg will be
better off without git and staying with SVN, if anything to not make git
bad name between frustrated ffmpeg users and developers.
PS: Beekeeping _is_ kind of cool, really.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Martin Langhoff @ 2007-05-03 1:48 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <loom.20070502T111026-882@post.gmane.org>
On 5/2/07, Panagiotis Issaris <takis.issaris@uhasselt.be> wrote:
> The questions are stated in this e-mail [1]. One of the things that are being
> discussed is the following action on a publicly mirrored repository:
> git branch -m master dead_end
> git branch -m last_good master
>
> I'd think this would fail as people could have pulled from the repository while
> the "dead_end" commit was already available, right?
Yes - that's something you shouldn't do on a normal branch... but
that's a feature ;-) -- we call it re-winding a branch.
A good workaround if you expect to go down some dead_ends is to have
an experimental branch that you pre-announce that will be rewound
regularly. On the git repo, Junio does exactly that with "pu"
("proposed updates"), and several feature-development branches have
been dropped or rewound at times.
Now, for your main dev and various maintenance branches, just do a
revert. If something made it into the main dev branch it means it's
not so experimental anymore and all the developers are building
further development on top. At that stage, the potential mistake has
made it "quite far" so you can't rewind it and pretend it didn't exist
;-)
So the good practice is to never rewind the long-term branches people
base their work on. Branches in your repo, and public branches clearly
marked as experimental, anything goes.
cheers,
martin
^ permalink raw reply
* [PATCH] Make xstrndup common
From: Daniel Barkalow @ 2007-05-03 2:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This also improves the implementation to match how strndup is
specified (by GNU): if the length given is longer than the string,
only the string's length is allocated and copied, but the string need
not be null-terminated if it is at least as long as the given length.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Haven't got the rest of my series updated for comments, but I'd like to
get this change, which is logically unrelated aside from being a
dependancy, in now.
commit.c | 8 --------
git-compat-util.h | 12 ++++++++++++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/commit.c b/commit.c
index f1ba972..aa7059c 100644
--- a/commit.c
+++ b/commit.c
@@ -718,14 +718,6 @@ static char *logmsg_reencode(const struct commit *commit,
return out;
}
-static char *xstrndup(const char *text, int len)
-{
- char *result = xmalloc(len + 1);
- memcpy(result, text, len);
- result[len] = '\0';
- return result;
-}
-
static void fill_person(struct interp *table, const char *msg, int len)
{
int start, end, tz = 0;
diff --git a/git-compat-util.h b/git-compat-util.h
index 2c84016..0dcd4e2 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -197,6 +197,18 @@ static inline void *xmalloc(size_t size)
return ret;
}
+static inline char *xstrndup(const char *str, int len)
+{
+ char *ret;
+ int i;
+ for (i = 0; i < len && str[i]; i++)
+ ;
+ ret = xmalloc(i + 1);
+ strncpy(ret, str, i);
+ ret[i] = '\0';
+ return ret;
+}
+
static inline void *xrealloc(void *ptr, size_t size)
{
void *ret = realloc(ptr, size);
--
1.5.1.2.255.g6ead4-dirty
^ permalink raw reply related
* Re: [PATCH 2/5] Add remote functions
From: Daniel Barkalow @ 2007-05-03 3:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virbfg22c.fsf@assigned-by-dhcp.cox.net>
On Sat, 28 Apr 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Make a struct and a set of functions to handle the parsing of remote
> > configurations (branches files, remotes files, and config sections),
> > and do some simple operations on lists of refspecs in the struct.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
>
> I do not have any objection to making a generally useful library
> function to deal with branches/remotes/config, and this is
> probably a good start. Eventually we would want to do a built-in
> git-remote command that supports interactive editing of remote
> information, not just fetch/push in C.
>
> But I do not think I can apply this patch as is, even for 'pu'.
> Comments below.
>
> > diff --git a/remote.c b/remote.c
> > new file mode 100644
> > index 0000000..58e6a96
> > --- /dev/null
> > +++ b/remote.c
> > @@ -0,0 +1,241 @@
> > +#include "cache.h"
> > +#include "remote.h"
> > +
> > +#define MAX_REMOTES 16
> > +
> > +static struct remote *remotes[MAX_REMOTES];
>
> I do not think the limitation of MAX_URI=16 in the original is
> unreasonable, but this MAX_REMOTES is way too low, if we want to
> eventually support somebody like Andrew, who has to deal with a
> few dozen git trees.
Sure; easy enough to fix.
> > +static void add_uri(struct remote *remote, const char *uri)
> > +{
> > + int i;
> > + for (i = 0; i < MAX_REMOTE_URI; i++) {
> > + if (!remote->uri[i]) {
> > + remote->uri[i] = uri;
> > + return;
> > + }
> > + }
> > + error("ignoring excess uri");
> > +}
>
> Why not do this just like refspecs, as an array of URIs? Doing
> so would also lift the MAX_REMOTE_URI limitation. Although more
> than one URIs per remote is not a norm but an exception (and
> makes sense only for push), it would shrink the base structure,
> and probably make the code simpler.
Again easy enough. Actually, it might be nice to have some common
functions for arrays of pointers, since I've now got 3 nearly identical
functions, but not too important.
> > +
> > +static struct remote *make_remote(const char *name, int len)
> > +{
> > + int i, empty = -1;
> > +
> > + for (i = 0; i < MAX_REMOTES; i++) {
> > + if (!remotes[i]) {
> > + if (empty < 0)
> > + empty = i;
> > + } else {
> > + if (len ? !strncmp(name, remotes[i]->name, len) :
> > + !strcmp(name, remotes[i]->name))
> > + return remotes[i];
> > + }
>
> If you have "remote.foobar.url = /git/repo.git", this is called
> with "foobar.url" in name and 6 in len. Do you want to match an
> existing remote whose name is "foobarbaz"?
Yeah, I need to test !(existing remote)[len] also.
> > +static void read_remotes_file(struct remote *remote)
> > +{
> > + FILE *f = fopen(git_path("remotes/%s", remote->name), "r");
> > +
> > + if (!f)
> > + return;
> > + while (fgets(buffer, BUF_SIZE, f)) {
> > + int is_refspec;
>
> The original dealt with URL or refspec, so "is_refspec" made
> some sense. It isn't anymore as you differentiate between push
> and fetch refspecs.
"value_list" instead.
> > +static void read_branches_file(struct remote *remote)
> > +{
> > + const char *slash = strchr(remote->name, '/');
> > + int n = slash ? slash - remote->name : 1000;
> > + FILE *f = fopen(git_path("branches/%.*s", n, remote->name), "r");
> > + char *s, *p;
> > + int len;
>
> I know you inherited this from builtin-push.c, but can't we
> clean up this magic 1000 somehow, please?
I'm a bit leary of touching this code; I don't have repositories with this
sort of config to test against. Can I just move it and have someone how
understands the code clean it up (before or after)?
> > +static const char *default_remote_name = NULL;
> > +static const char *current_branch = NULL;
> > +static int current_branch_len = 0;
> > +
> > +static int handle_config(const char *key, const char *value)
> > +{
> > + const char *name;
> > + const char *subkey;
> > + struct remote *remote;
> > + if (!prefixcmp(key, "branch.") && current_branch &&
> > + !strncmp(key + 7, current_branch, current_branch_len) &&
> > + !strcmp(key + 7 + current_branch_len, ".remote")) {
> > + default_remote_name = xstrdup(value);
> > + }
>
> Who sets current_branch to non-NULL value? It is static and I
> do not see anybody setting it in this file.
I was going to set it when I figured out how to find the right value, but
then forgot. (This would also make "git-push" use the same remote as
"git-pull" when the current branch has a "remote" setting, which is
obviously less surprising, but is a change in behavior)
> Also the original value of default_remote_name leaks here. But
> you cannot blindly free the original value, as you could end up
> storing it in ret->uri[0] when somebody calls remote_get(NULL).
Actually, read_config() can only do anything once (since it returns with
default_remote_name not null), so handle_config can't be called again
after remote_get() has potentially used it. So I can definitely free it.
> > + if (prefixcmp(key, "remote."))
> > + return 0;
> > + name = key + 7;
> > + subkey = strchr(name, '.');
> > + if (!subkey)
> > + return error("Config with no key for remote %s", name);
>
> This is not right.
>
> [section "section name"]
> variable = value
>
> allows dot in "section name" part, so you would want strrchr()
> to find out the end of it, not the first dot with strchr(). You
> found an input error (missing subkey) if strrchr() finds the dot
> at the end of "remote." (i.e. subkey == key + 6).
Just replacing strchr with strrchr does the right thing, right? (If I
start at name (== key + 7), it won't find that wrong dot.)
> > +char *remote_fetch_to(struct remote *remote, const char *ref)
> > +{
> > + int i;
> > + for (i = 0; i < remote->fetch_refspec_nr; i++) {
> > + const char *refspec = remote->fetch_refspec[i];
> > + const char *cons = strchr(refspec, ':');
> > + const char *glob = strchr(refspec, '*');
> > + if (*refspec == '+')
> > + refspec++;
>
> I cannot offhand tell what this function is about...
>
> Would there be callers who are interested in finding out if
> refspec is forcing or not?
>
> You are not protecting yourself from refspecs without tracking
> branch (i.e. sans any colon) and would segfault in the rest of
> this function.
This is to find the local tracking ref that a remote head would be fetched
to, taking into account patterns and multiple items in the list. I should
probably actually be sucking this code out of builtin-fetch--tool and
connect, which I hadn't noticed handled this in C already.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 4/5] Add --remote option to send-pack
From: Daniel Barkalow @ 2007-05-03 4:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejm3g0dg.fsf@assigned-by-dhcp.cox.net>
On Sat, 28 Apr 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > We're not pretending anything; remote has confirmed that the head that the
> > ref tracks has a particular new value (which we provided), so we should be
> > able to update the tracking ref to that value. I don't think it's
> > particularly important that we came by this information in the course of
> > an exchange that wasn't a fetch.
> >
>
> We are indeed pretending. Consider:
>
> (1) You push, and push succeeds.
>
> (2) Somebody fetches your result, works on it and pushes back;
> this might happen in post-receive hook.
>
> (3) You fetch. You should see somebody else's commit at the
> tip, not what you pushed in (1).
>
> By not fetching but instead of storing what you pushed, you are
> pretending that you re-fetched so fast that you gave no chance
> to anybody to perform (2) quickly enough.
But you did effectively re-fetch instantaneously by doing an operation
that atomicly updates the ref and reports success. If you consider the
operation that updates tracking refs not to be necessarily "git-fetch" but
rather "having a connection that discusses refs", this sequence isn't any
different from (1) being a fetch instead of a push; there's always the
chance that your interaction with the server is shortly before the ref
values you update to being replaced, whether the operation you're doing is
getting the remote's value or setting the remote's value.
Even if a post-update hook further changes the ref you push to, it had
better not change it to a non-descendant of the value you pushed, since
there would be a race with other people fetching your value with the
post-update hook is running and seeing history roll back. So, at worst,
you could have the situation where, effectively, you *always* miss out on
the latest thing, but it's already the case that you would *sometimes*
miss out on the latest thing, if the post-update hook is running more
slowly than your next fetch.
The fact that the config option is "fetch" isn't really an argument that
the way you have to get the knowledge of the value of the ref at the
instant you remember locally has to be "git-fetch"; any way of getting
knowledge of that value at some instant should suffice.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Make xstrndup common
From: Junio C Hamano @ 2007-05-03 4:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705022248040.28708@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This also improves the implementation to match how strndup is
> specified (by GNU): if the length given is longer than the string,
> only the string's length is allocated and copied, but the string need
> not be null-terminated if it is at least as long as the given length.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
> Haven't got the rest of my series updated for comments, but I'd like to
> get this change, which is logically unrelated aside from being a
> dependancy, in now.
>
> commit.c | 8 --------
> git-compat-util.h | 12 ++++++++++++
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/commit.c b/commit.c
> index f1ba972..aa7059c 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -718,14 +718,6 @@ static char *logmsg_reencode(const struct commit *commit,
> return out;
> }
>
> -static char *xstrndup(const char *text, int len)
> -{
> - char *result = xmalloc(len + 1);
> - memcpy(result, text, len);
> - result[len] = '\0';
> - return result;
> -}
> -
> static void fill_person(struct interp *table, const char *msg, int len)
> {
> int start, end, tz = 0;
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 2c84016..0dcd4e2 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -197,6 +197,18 @@ static inline void *xmalloc(size_t size)
> return ret;
> }
>
> +static inline char *xstrndup(const char *str, int len)
> +{
> + char *ret;
> + int i;
> + for (i = 0; i < len && str[i]; i++)
> + ;
> + ret = xmalloc(i + 1);
> + strncpy(ret, str, i);
Why strncpy() not memcpy()?
> + ret[i] = '\0';
> + return ret;
> +}
> +
> static inline void *xrealloc(void *ptr, size_t size)
> {
> void *ret = realloc(ptr, size);
> --
> 1.5.1.2.255.g6ead4-dirty
^ permalink raw reply
* [PATCH] Documentation: "bisect run" can be given bangs before the run script.
From: Christian Couder @ 2007-05-03 5:06 UTC (permalink / raw)
To: Uwe Kleine-König, Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Hi Uwe and Junio,
This is the documentation related to my latest patch:
[RFC/PATCH] Bisect: add special treatment for bangs passed to "bisect run".
(http://article.gmane.org/gmane.comp.version-control.git/45943)
Thanks in advance,
Christian.
Documentation/git-bisect.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 5f68ee1..a1cceb5 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -175,6 +175,12 @@ Any other exit code will abort the automatic bisect process. (A
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
the value is chopped with "& 0377".)
+You can use one or more "!" argument immediately after "git bisect
+run" if you want to revert once or more times the "run" script exit
+code, even if your current shell does not support the "!"
+keyword. Reverting the exit code means 0 gives 1 and anything other
+than 0 gives 0.
+
You may often find that during bisect you want to have near-constant
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
"revision that does not have this commit needs this patch applied to
--
1.5.2.rc0.71.g4342-dirty
^ permalink raw reply related
* Re: [PATCH] Make xstrndup common
From: Daniel Barkalow @ 2007-05-03 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm4m35xm.fsf@assigned-by-dhcp.cox.net>
On Wed, 2 May 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This also improves the implementation to match how strndup is
> > specified (by GNU): if the length given is longer than the string,
> > only the string's length is allocated and copied, but the string need
> > not be null-terminated if it is at least as long as the given length.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > ---
> > Haven't got the rest of my series updated for comments, but I'd like to
> > get this change, which is logically unrelated aside from being a
> > dependancy, in now.
> >
> > commit.c | 8 --------
> > git-compat-util.h | 12 ++++++++++++
> > 2 files changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/commit.c b/commit.c
> > index f1ba972..aa7059c 100644
> > --- a/commit.c
> > +++ b/commit.c
> > @@ -718,14 +718,6 @@ static char *logmsg_reencode(const struct commit *commit,
> > return out;
> > }
> >
> > -static char *xstrndup(const char *text, int len)
> > -{
> > - char *result = xmalloc(len + 1);
> > - memcpy(result, text, len);
> > - result[len] = '\0';
> > - return result;
> > -}
> > -
> > static void fill_person(struct interp *table, const char *msg, int len)
> > {
> > int start, end, tz = 0;
> > diff --git a/git-compat-util.h b/git-compat-util.h
> > index 2c84016..0dcd4e2 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -197,6 +197,18 @@ static inline void *xmalloc(size_t size)
> > return ret;
> > }
> >
> > +static inline char *xstrndup(const char *str, int len)
> > +{
> > + char *ret;
> > + int i;
> > + for (i = 0; i < len && str[i]; i++)
> > + ;
> > + ret = xmalloc(i + 1);
> > + strncpy(ret, str, i);
>
> Why strncpy() not memcpy()?
Left over from my previous attempt. memcpy() is better with the length
check.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Make xstrndup common
From: Junio C Hamano @ 2007-05-03 5:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705030100050.28708@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> Why strncpy() not memcpy()?
>
> Left over from my previous attempt. memcpy() is better with the length
> check.
Ok, I was just sanity checking myself. Will apply with the
change.
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: "bisect run" can be given bangs before the run script.
From: Junio C Hamano @ 2007-05-03 5:29 UTC (permalink / raw)
To: Christian Couder; +Cc: Uwe Kleine-König, git
In-Reply-To: <20070503070607.fa2ffe92.chriscool@tuxfamily.org>
I am not convinced that '!' is a good extension for two and half
reasons.
* The expected use is not quite clear. If it is not used to
run a custom test script but something stock as "make", by
the nature of UNIX exit status convention, you are looking
for the commit that _fixed_ some breakage (i.e. "which commit
fixed the compilation error?"). While sometimes that is a
useful thing to do, it feels somewhat of limited value.
On the other hand, if you are running a custom test script, I
do not think it is unreasonable to always require that a test
script to signal "bad" with small non-zero, "good" with zero,
and error with high non-zero status, as we already do.
* How should this interact with the "high non-zero status means
an error and we cannot bisect" return convention?
* I was hoping that we can officially support "don't know,
cannot test this one, please give me another" for interactive
use, and at the same time allow the run-script used by
"git bisect run" to signal such with a special exit value
(perhaps "exit 42"). Taken together with the previous point,
it is not clear how '!' should interact with such an
enhancement.
^ permalink raw reply
* Re: [PATCH 4/5] Add --remote option to send-pack
From: Junio C Hamano @ 2007-05-03 5:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705022330460.28708@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Sat, 28 Apr 2007, Junio C Hamano wrote:
>
>> We are indeed pretending. Consider:
>>
>> (1) You push, and push succeeds.
>>
>> (2) Somebody fetches your result, works on it and pushes back;
>> this might happen in post-receive hook.
>>
>> (3) You fetch. You should see somebody else's commit at the
>> tip, not what you pushed in (1).
>>
>> By not fetching but instead of storing what you pushed, you are
>> pretending that you re-fetched so fast that you gave no chance
>> to anybody to perform (2) quickly enough.
>
> But you did effectively re-fetch instantaneously by doing an operation
> that atomicly updates the ref and reports success.
I do not think there is much point arguing over this; I am not
fundamentally opposed to keeping a copy of what we just pushed
to the other side.
But I think it needs to be documented that hooks on the remote
side could do funny things, and probably we should strongly
discourage people from doing such.
You do need to take care of the case where we are _not_ tracking
the remote side, though (i.e. lack of colon in the fetch
refspecs).
^ permalink raw reply
* Re: [PATCH 4/5] Add --remote option to send-pack
From: Daniel Barkalow @ 2007-05-03 5:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virba31wd.fsf@assigned-by-dhcp.cox.net>
On Wed, 2 May 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Sat, 28 Apr 2007, Junio C Hamano wrote:
> >
> >> We are indeed pretending. Consider:
> >>
> >> (1) You push, and push succeeds.
> >>
> >> (2) Somebody fetches your result, works on it and pushes back;
> >> this might happen in post-receive hook.
> >>
> >> (3) You fetch. You should see somebody else's commit at the
> >> tip, not what you pushed in (1).
> >>
> >> By not fetching but instead of storing what you pushed, you are
> >> pretending that you re-fetched so fast that you gave no chance
> >> to anybody to perform (2) quickly enough.
> >
> > But you did effectively re-fetch instantaneously by doing an operation
> > that atomicly updates the ref and reports success.
>
> I do not think there is much point arguing over this; I am not
> fundamentally opposed to keeping a copy of what we just pushed
> to the other side.
>
> But I think it needs to be documented that hooks on the remote
> side could do funny things, and probably we should strongly
> discourage people from doing such.
I don't see what's any *more* odd about this situation with my change than
otherwise (and I'm afraid I'm missing something, which is why I'm still
discussing it).
> You do need to take care of the case where we are _not_ tracking
> the remote side, though (i.e. lack of colon in the fetch
> refspecs).
Indeed. Is there documentation on all the possibilities for refspecs
somewhere all together? I could only find it for particular programs, and
didn't see a no-colon option permitted anywhere.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [git-svn PATCH] Add --no-rebase option to git-svn dcommit
From: Karl Hasselström @ 2007-05-03 5:51 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
git-svn dcommit exports commits to Subversion, then imports them back
to git again, and last but not least rebases or resets HEAD to the
last of the new commits. I guess this rebasing is convenient when
using just git, but when the commits to be exported are managed by
StGIT, it's really annoying. So add an option to disable this
behavior. And document it, too!
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Arguably, the switch should be --rebase instead, and default to not
rebase. But that would change the existing behavior, and possibly make
dcommit less convenient to use for at least the person who implemented
the existing behavior. Opinions?
Documentation/git-svn.txt | 3 +++
git-svn.perl | 33 ++++++++++++++++++---------------
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 62d7ef8..fcdeeaa 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -125,6 +125,9 @@ and have no uncommitted changes.
alternative to HEAD.
This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
++
+--no-rebase;;
+ After committing, do not rebase or reset.
--
'log'::
diff --git a/git-svn.perl b/git-svn.perl
index 6657e10..3c4f490 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -55,7 +55,7 @@ $sha1_short = qr/[a-f\d]{4,40}/;
my ($_stdin, $_help, $_edit,
$_message, $_file,
$_template, $_shared,
- $_version, $_fetch_all,
+ $_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_verbose);
$Git::SVN::_follow_parent = 1;
@@ -114,6 +114,7 @@ my %cmd = (
'verbose|v' => \$_verbose,
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
+ 'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
@@ -413,21 +414,23 @@ sub cmd_dcommit {
return;
}
$_fetch_all ? $gs->fetch_all : $gs->fetch;
- # we always want to rebase against the current HEAD, not any
- # head that was passed to us
- my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
- my @finish;
- if (@diff) {
- @finish = rebase_cmd();
- print STDERR "W: HEAD and ", $gs->refname, " differ, ",
- "using @finish:\n", "@diff";
- } else {
- print "No changes between current HEAD and ",
- $gs->refname, "\nResetting to the latest ",
- $gs->refname, "\n";
- @finish = qw/reset --mixed/;
+ unless ($_no_rebase) {
+ # we always want to rebase against the current HEAD, not any
+ # head that was passed to us
+ my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
+ my @finish;
+ if (@diff) {
+ @finish = rebase_cmd();
+ print STDERR "W: HEAD and ", $gs->refname, " differ, ",
+ "using @finish:\n", "@diff";
+ } else {
+ print "No changes between current HEAD and ",
+ $gs->refname, "\nResetting to the latest ",
+ $gs->refname, "\n";
+ @finish = qw/reset --mixed/;
+ }
+ command_noisy(@finish, $gs->refname);
}
- command_noisy(@finish, $gs->refname);
}
sub cmd_find_rev {
^ permalink raw reply related
* Re: [PATCH 4/5] Add --remote option to send-pack
From: Junio C Hamano @ 2007-05-03 6:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705030137520.28708@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Indeed. Is there documentation on all the possibilities for refspecs
> somewhere all together? I could only find it for particular programs, and
> didn't see a no-colon option permitted anywhere.
Documentation/pull-fetch-param.txt which is included by various
manpages would be the best place to start.
<refspec>::
The canonical format of a <refspec> parameter is
`+?<src>:<dst>`; that is, an optional plus `+`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
Again, if the optional plus `+` is used, the local ref
is updated even if it does not result in a fast forward
update.
Hmph. So <dst> could be empty, and in such a case there is no
tracking. But this does not say missing colon is allowed (but
that was intentionally left out as we clarify it later). Let's
read on. After a few [Notes], we find this.
Some short-cut notations are also supported.
+
* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
it requests fetching everything up to the given tag.
* A parameter <ref> without a colon is equivalent to
<ref>: when pulling/fetching, so it merges <ref> into the current
branch without storing the remote branch anywhere locally
Ahh, so a refspec that does not have a colon, and ends with a
colon (hence an empty <dst>) are equivalent, and does not result
in remote tracking.
^ permalink raw reply
* git-send-email vs address syntax
From: Brown, Len @ 2007-05-03 6:13 UTC (permalink / raw)
To: git
I recently used git-format-patch and git-send-email
to patch bomb 105 patches to linux-acpi@vger.kernel.org
But It appears that messages 37-45 and 96-104.
got dropped by the mail server because they
had a '.' in a destination address:
To: linux-acpi@vger.kernel.org
Cc: malattia@linux.it <malattia@linux.it>, Len Brown
<len.brown@intel.com>
Illegal-Object: Syntax error in Cc: address found on vger.kernel.org:
Cc: malattia@linux.it<malattia@linux.it>
^-missing end of address
Dave Miller says that this address would have been legal
if it were enclosed in quotes.
I don't know if the fix should be in the git-am script
which set the From: field, or in the git-format-patch
script which takes that field and makes it into
an e-mail message.
-Len
^ permalink raw reply
* Re: git-send-email vs address syntax
From: Junio C Hamano @ 2007-05-03 6:25 UTC (permalink / raw)
To: Brown, Len; +Cc: git
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB6030BDEAF@hdsmsx411.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> writes:
> I don't know if the fix should be in the git-am script
> which set the From: field, or in the git-format-patch
> script which takes that field and makes it into
> an e-mail message.
The fix should be in send-email script, as COMMITTER_NAME and
AUTHOR_NAME are just simple strings without RFC2822 limitation
(such as necessity of quoting a ".").
As a matter of fact, recent enough send-email is supposed to
have a fix for this exact problem. If your copy of send-email
does not have
sub sanitize_address_rfc822 {
you might want to upgrade. Both 1.5.2-rc1 and 1.5.1.3 have
this.
^ permalink raw reply
* RE: git-send-email vs address syntax
From: Brown, Len @ 2007-05-03 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Miller
In-Reply-To: <7v8xc62zky.fsf@assigned-by-dhcp.cox.net>
>As a matter of fact, recent enough send-email is supposed to
>have a fix for this exact problem. If your copy of send-email
>does not have
>
> sub sanitize_address_rfc822 {
>
>you might want to upgrade. Both 1.5.2-rc1 and 1.5.1.3 have
>this.
>
>
Hmmm, the message has this tag at the bottom:
1.5.2.rc0.34.gda94
so I guess I didn't have the latest at the time.
thanks,
-Len
^ permalink raw reply
* Re: [PATCH] Documentation: "bisect run" can be given bangs before the run script.
From: Uwe Kleine-König @ 2007-05-03 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vmz0m3261.fsf@assigned-by-dhcp.cox.net>
Hello,
Junio C Hamano wrote:
> I am not convinced that '!' is a good extension for two and half
> reasons.
>
> * The expected use is not quite clear. If it is not used to
> run a custom test script but something stock as "make", by
> the nature of UNIX exit status convention, you are looking
> for the commit that _fixed_ some breakage (i.e. "which commit
> fixed the compilation error?"). While sometimes that is a
> useful thing to do, it feels somewhat of limited value.
>
> On the other hand, if you are running a custom test script, I
> do not think it is unreasonable to always require that a test
> script to signal "bad" with small non-zero, "good" with zero,
> and error with high non-zero status, as we already do.
>
> * How should this interact with the "high non-zero status means
> an error and we cannot bisect" return convention?
>
> * I was hoping that we can officially support "don't know,
> cannot test this one, please give me another" for interactive
> use, and at the same time allow the run-script used by
> "git bisect run" to signal such with a special exit value
> (perhaps "exit 42"). Taken together with the previous point,
> it is not clear how '!' should interact with such an
> enhancement.
Ack for all 2½ reasons.
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Florian Weimer @ 2007-05-03 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <200705012346.14997.jnareb@gmail.com>
* Jakub Narebski:
> The problem is with 'Size of checkout': to start working in repository
> one needs 1.4G (sources) and 98M (third party) for CVS checkout (it is
> 1.5G for sources for Subversion checkout).
The text bases for Subversion really should take another 1.4 GiB.
As a result, Subversion should be closer to 3 GiB.
> What might help here is splitting repository into current (e.g. from
> OOo 2.0) and historical part, and / or using shallow clone.
You could also split along project boundaries, but this is probably
too political.
> What I'm really concerned about is branch switch and merging branches,
> when one of the branches is an old one (e.g. unxsplash branch), which
> takes 3min (!) according to the benchmark. 13-25sec for commit is also
> bit long, but BRANCH SWITCHING which takes 3 MINUTES!?
IIRC, GIT accesses every file in the tree, not just the ones that need
updating. How many files were actually updated when you changed
branches in your experiment?
^ 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