* [PATCH] diff: add --no-diff-deleted to make -p more pleasant
From: Eric Wong @ 2006-01-29 14:24 UTC (permalink / raw)
To: git list
This is a feature I've stol^Wborrowed from svn that I find very
useful since I usually don't care to see what I've deleted.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
diff.c | 6 ++++++
diff.h | 3 +++
2 files changed, 9 insertions(+), 0 deletions(-)
0b426af15a7da4f430d9cca8c1ad057557d93627
diff --git a/diff.c b/diff.c
index f45d18c..6db3e19 100644
--- a/diff.c
+++ b/diff.c
@@ -769,6 +769,7 @@ void diff_setup(struct diff_options *opt
{
memset(options, 0, sizeof(*options));
options->output_format = DIFF_FORMAT_RAW;
+ options->diff_deleted = 1;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -849,6 +850,8 @@ int diff_opt_parse(struct diff_options *
}
else if (!strcmp(arg, "--find-copies-harder"))
options->find_copies_harder = 1;
+ else if (!strcmp(arg, "--no-diff-deleted"))
+ options->diff_deleted = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (!strncmp(arg, "--abbrev=", 9)) {
@@ -1103,6 +1106,9 @@ int diff_unmodified_pair(struct diff_fil
static void diff_flush_patch(struct diff_filepair *p, struct diff_options *o)
{
+ if (!o->diff_deleted && (p->status == DIFF_STATUS_DELETED))
+ return;
+
if (diff_unmodified_pair(p))
return;
diff --git a/diff.h b/diff.h
index 9a0169c..4f320ac 100644
--- a/diff.h
+++ b/diff.h
@@ -39,6 +39,7 @@ struct diff_options {
int find_copies_harder;
int line_termination;
int output_format;
+ int diff_deleted;
int pickaxe_opts;
int rename_score;
int reverse_diff;
@@ -120,6 +121,8 @@ extern void diffcore_std_no_resolve(stru
" -C detect copies.\n" \
" --find-copies-harder\n" \
" try unchanged files as candidate for copy detection.\n" \
+" --no-diff-deleted\n" \
+" do not print patch format for deleted files\n" \
" -l<n> limit rename attempts up to <n> paths.\n" \
" -O<file> reorder diffs according to the <file>.\n" \
" -S<string> find filepair whose only one side contains the string.\n" \
--
1.1.5.gae18-dirty
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Morten Welinder @ 2006-01-29 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j8jpu48.fsf@assigned-by-dhcp.cox.net>
> I think that 40% sounds about right. My understanding of the
> underlying format CVS uses, RCS, is that it stores an full copy
> of the tip of trunk uncompressed, and other versions of the file
> are represented as incremental delta from that. The packed git
> format does not favor particular version based on the distance
> from the tip, and stores either a compressed full copy, or a
> delta from some other revision (which may not necessarily be
> represented as a full copy). When we store something as a delta
> from something else, we limit the length of the delta chain to a
> full copy to 10 (by default), so that you can get to a specific
> object with at most 10 applications of delta on top of a full
> copy.
If I understand this right, that means that for a log file (in this
case a ChangeLog file) that is appended to linearly as a
function of revision number, we have...
cvs: O(n) archive size
git: O(n*n) archive size
At least that is what we get if revision N is always deltad over
revision N-1. A good deal could be saved if instead of dumping
a full copy every 10 revisions, that revision would instead be
deltad off an earlier revision, but I think it'll still be O(n*n).
(/me prepares for Linus chiming in and telling me I should not
keep ChangeLog files, :-)
M.
^ permalink raw reply
* [PATCH] git-branch: Documentation fixes
From: Fredrik Kuivinen @ 2006-01-29 14:02 UTC (permalink / raw)
To: git; +Cc: junkio
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
Documentation/git-branch.txt | 7 +++++--
git-branch.sh | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
fb625f143454671bfa6862ee83fbe9cdbac9af0b
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index d20b475..b1bc827 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -7,7 +7,7 @@ git-branch - Create a new branch, or rem
SYNOPSIS
--------
-'git-branch' [-d | -D] [<branchname> [start-point]]
+'git-branch' [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]]
DESCRIPTION
-----------
@@ -25,10 +25,13 @@ OPTIONS
-D::
Delete a branch irrespective of its index status.
+-f::
+ Force a reset of <branchname> to <start-point> (or current head).
+
<branchname>::
The name of the branch to create or delete.
-start-point::
+<start-point>::
Where to create the branch; defaults to HEAD. This
option has no meaning with -d and -D.
diff --git a/git-branch.sh b/git-branch.sh
index b0e54ed..6ac961e 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[-d <branch>] | [[-f] <branch> [start-point]]'
+USAGE='[(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]]'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
If two arguments, create a new branch <branchname> based off of <start-point>.'
--
0.99.9k.g3480-dirty
^ permalink raw reply related
* [PATCH] rev-{list,parse}: optionally allow -<n> as shorthand for --max-count=<n>
From: Eric Wong @ 2006-01-29 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <20060129134056.GA3428@Muzzle>
I also made this for my own private use, it's on top of the previous
one I made that is POSIX-friendly. I don't if you or anyone wants
it merged mainline, but I like it :)
This will only be enabled if POSIX_SHMOSIX is defined at compile-time.
Some versions of head(1) and tail(1) allow their line limits to be
parsed this way. I find --max-count to be a commonly used option,
and also similar in spirit to head/tail, so I decided to make life
easier on my worn out (and lazy :) fingers with this patch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Makefile | 3 +++
git-compat-util.h | 3 +++
rev-list.c | 7 ++++++-
rev-parse.c | 4 ++++
4 files changed, 16 insertions(+), 1 deletions(-)
3b650b00deb7e51e5c9a8bdc4cc1eaaf4fc65029
diff --git a/Makefile b/Makefile
index 2e95353..9ef97ca 100644
--- a/Makefile
+++ b/Makefile
@@ -367,6 +367,9 @@ endif
ifdef NO_IPV6
ALL_CFLAGS += -DNO_IPV6
endif
+ifdef POSIX_SHMOSIX
+ ALL_CFLAGS += -DPOSIX_SHMOSIX=1
+endif
ifdef NO_SOCKADDR_STORAGE
ifdef NO_IPV6
ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in
diff --git a/git-compat-util.h b/git-compat-util.h
index f982b8e..46d331d 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -154,4 +154,7 @@ static inline int sane_case(int x, int h
#ifndef MAXPATHLEN
#define MAXPATHLEN 256
#endif
+#ifndef POSIX_SHMOSIX
+#define POSIX_SHMOSIX 0
+#endif
#endif
diff --git a/rev-list.c b/rev-list.c
index 33541cc..c85de51 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -731,7 +731,12 @@ int main(int argc, const char **argv)
char *dotdot;
struct commit *commit;
unsigned char sha1[20];
-
+
+ /* accept, -<digit>, like some versions of head/tail */
+ if (POSIX_SHMOSIX && (*arg == '-') && isdigit(arg[1])) {
+ max_count = atoi(arg + 1);
+ continue;
+ }
if (!strcmp(arg, "-n")) {
if (++i >= argc)
die("-n requires an argument");
diff --git a/rev-parse.c b/rev-parse.c
index 3790463..d9b3fa9 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -53,6 +53,10 @@ static int is_rev_argument(const char *a
};
const char **p = rev_args;
+ /* accept, -<digit>, like some versions of head/tail */
+ if (POSIX_SHMOSIX && (*arg == '-') && isdigit(arg[1]))
+ return 1;
+
for (;;) {
const char *str = *p++;
int len;
--
1.1.4.g3b65
^ permalink raw reply related
* [PATCH] rev-{list,parse}: allow -n<n> as shorthand for --max-count=<n>
From: Eric Wong @ 2006-01-29 13:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <20060125063325.GA7953@mail.yhbt.net>
Both -n<n> and -n <n> are supported. POSIX versions of head(1) and
tail(1) allow their line limits to be parsed this way. I find
--max-count to be a commonly used option, and also similar in spirit to
head/tail, so I decided to make life easier on my worn out (and lazy :)
fingers with this patch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
rev-list.c | 10 ++++++++++
rev-parse.c | 19 +++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
a598ce380cfcf01b27be92bca92a3c451d3b41e3
diff --git a/rev-list.c b/rev-list.c
index e00e6fc..33541cc 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -732,6 +732,16 @@ int main(int argc, const char **argv)
struct commit *commit;
unsigned char sha1[20];
+ if (!strcmp(arg, "-n")) {
+ if (++i >= argc)
+ die("-n requires an argument");
+ max_count = atoi(argv[i]);
+ continue;
+ }
+ if (!strncmp(arg,"-n",2)) {
+ max_count = atoi(arg + 2);
+ continue;
+ }
if (!strncmp(arg, "--max-count=", 12)) {
max_count = atoi(arg + 12);
continue;
diff --git a/rev-parse.c b/rev-parse.c
index 7abad35..3790463 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -21,6 +21,7 @@ static char *def = NULL;
static int show_type = NORMAL;
static int symbolic = 0;
static int output_sq = 0;
+static int next_arg_is_rev = 0;
static int revs_count = 0;
@@ -162,6 +163,24 @@ int main(int argc, char **argv)
show_file(arg);
continue;
}
+ if (next_arg_is_rev) {
+ if ((filter & DO_FLAGS) && (filter & DO_REVS))
+ show(arg);
+ next_arg_is_rev = 0;
+ continue;
+ }
+ if (!strcmp(arg,"-n")) {
+ next_arg_is_rev = 1;
+ if ((filter & DO_FLAGS) && (filter & DO_REVS))
+ show(arg);
+ continue;
+ }
+ if (!strncmp(arg,"-n",2)) {
+ if ((filter & DO_FLAGS) && (filter & DO_REVS))
+ show(arg);
+ continue;
+ }
+
if (*arg == '-') {
if (!strcmp(arg, "--")) {
as_is = 1;
--
1.1.4.g3b65
^ permalink raw reply related
* Re: No merge strategy handled the merge (git version 1.1.GIT)
From: Radoslaw Szkodzinski @ 2006-01-29 12:32 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Roberto Nibali, git
In-Reply-To: <43DCB3D8.8010902@gorzow.mm.pl>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
Radoslaw Szkodzinski wrote:
>> The problem is that merge(1), which is used for file-level merges,
>> couldn't be found. Is it installed on your system? If you use Linux,
>> it is usually found in the "rcs" package in your favorite
>> distribution.
>
> Also in diffutils (the package with diff3).
>
No, I was wrong. However, diff3 can merge files and should also be
supported. It is much lighter than full rcs.
Parameters:
diff3 -m local base new > mergedlocal
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: No merge strategy handled the merge (git version 1.1.GIT)
From: Radoslaw Szkodzinski @ 2006-01-29 12:23 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Roberto Nibali, git
In-Reply-To: <20060129120344.GB4815@c165.ib.student.liu.se>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
> The problem is that merge(1), which is used for file-level merges,
> couldn't be found. Is it installed on your system? If you use Linux,
> it is usually found in the "rcs" package in your favorite
> distribution.
Also in diffutils (the package with diff3).
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH] merge-recursive: Improve the error message printed when merge(1) isn't found.
From: Fredrik Kuivinen @ 2006-01-29 12:16 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Roberto Nibali, git, junkio
In-Reply-To: <20060129120344.GB4815@c165.ib.student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-recursive.py | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
75cd8eff434fd6e9cf7fff98f13a27bfaa1b363b
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index 56c3641..b17c8e5 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -205,11 +205,16 @@ def mergeFile(oPath, oSha, oMode, aPath,
orig = runProgram(['git-unpack-file', oSha]).rstrip()
src1 = runProgram(['git-unpack-file', aSha]).rstrip()
src2 = runProgram(['git-unpack-file', bSha]).rstrip()
- [out, code] = runProgram(['merge',
- '-L', branch1Name + '/' + aPath,
- '-L', 'orig/' + oPath,
- '-L', branch2Name + '/' + bPath,
- src1, orig, src2], returnCode=True)
+ try:
+ [out, code] = runProgram(['merge',
+ '-L', branch1Name + '/' + aPath,
+ '-L', 'orig/' + oPath,
+ '-L', branch2Name + '/' + bPath,
+ src1, orig, src2], returnCode=True)
+ except ProgramError, e:
+ print >>sys.stderr, e
+ die("Failed to execute 'merge'. merge(1) is used as the "
+ "file-level merge tool. Is 'merge' in your path?")
sha = runProgram(['git-hash-object', '-t', 'blob', '-w',
src1]).rstrip()
--
0.99.9k.g3480-dirty
^ permalink raw reply related
* Re: No merge strategy handled the merge (git version 1.1.GIT)
From: Fredrik Kuivinen @ 2006-01-29 12:03 UTC (permalink / raw)
To: Roberto Nibali; +Cc: git
In-Reply-To: <43DB4D16.6050807@drugphish.ch>
On Sat, Jan 28, 2006 at 11:53:10AM +0100, Roberto Nibali wrote:
> Hello,
>
> I've been hacking on some features for IPVS in the Linux kernel recently
> but abandoned work for 3 weeks. Today I wanted to re-sync with Linus to
> work in a more up-to-date tree and simply typed (forgot I had previously
> done work in that tree)
>
> git-pull
>
> in my local repository tree, which resulted in following:
>
...
> Auto-merging net/ipv4/ipvs/ip_vs_ctl.c
> Traceback (most recent call last):
> File "/home/ratz/bin/git-merge-recursive", line 915, in ?
> firstBranch, secondBranch, graph)
> File "/home/ratz/bin/git-merge-recursive", line 87, in merge
> branch1Name, branch2Name)
> File "/home/ratz/bin/git-merge-recursive", line 160, in mergeTrees
> if not processEntry(entry, branch1Name, branch2Name):
> File "/home/ratz/bin/git-merge-recursive", line 868, in processEntry
> branch1Name, branch2Name)
> File "/home/ratz/bin/git-merge-recursive", line 212, in mergeFile
> src1, orig, src2], returnCode=True)
> File "/home/ratz/share/git-core/python/gitMergeCommon.py", line 72,
> in runProgram
> raise ProgramError(progStr, e.strerror)
> ProgramError: merge -L HEAD/net/ipv4/ipvs/ip_vs_ctl.c -L
> orig/net/ipv4/ipvs/ip_vs_ctl.c -L
> 3ee68c4af3fd7228c1be63254b9f884614f9ebb2/net/ipv4/ipvs/ip_vs_ctl.c
> .merge_file_uofMwv .merge_file_hcesLs .merge_file_TwtEqw: No such file
> or directory
> No merge strategy handled the merge.
>
The problem is that merge(1), which is used for file-level merges,
couldn't be found. Is it installed on your system? If you use Linux,
it is usually found in the "rcs" package in your favorite
distribution.
This have came up a couple of times now, we should probably make this
error message a bit less cryptic. I will send a patch in a separate
mail.
> I'm all for verbosity when it comes to a problem with software, however
> this output does not tell me much about what I could do to achieve
> following state:
>
> 1. Sync my local tree to Linus' tree.
> 2. Merge my changes I've done locally with the resulting tree of 1.
>
If your repository is in the state that the failed git-pull left it
in, then the following actions should merge your changes with Linus'
tree.
1. Install merge(1)
2. Run 'git reset --hard' (NOTE: Be careful with this command. It will
revert any uncommitted changes you may have in your working directory!)
3. Run 'git pull'
> Oh, btw, how is git branch -D supposed to work? Isn't there some code
> missing?
Could you be a bit more specific? Do you mean that there is code
missing in git-branch.sh? What happens when you run 'git branch -D
<some branch>'? It seems to work fine here.
- Fredrik
^ permalink raw reply
* Re: [Census] So who uses git?
From: Radoslaw Szkodzinski @ 2006-01-29 11:18 UTC (permalink / raw)
To: Keith Packard
Cc: Junio C Hamano, cworth, Martin Langhoff, Linus Torvalds,
Git Mailing List
In-Reply-To: <1138529385.9919.185.camel@evo.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
Keith Packard wrote:
> Fortunately, there are very few people involved with any specific piece
> of the X.org distribution; there's really only one or two people
> actively developing the X.org core server, so that part of the migration
> will be easy. Our users will be stuck, but there aren't many of them
> either, and git makes just sucking the current bits pretty easy.
>
Not under Windows (bleh), but it's support for Cygwin is getting better
and better.
> I don't know of other huge projects moving to git; it's not all that
> interesting as we know the tool is stable and will scale to support our
> project already. Also, hg and bzr are not ready for production use in my
> opinion; hg as it appears likely a flag day will be required before 1.0,
I haven't seen any such flag day since 0.3. Repository format seems
stable, except rename and modes support (these will be added in a
compatible way I think).
0.8 release is imminent (today or tomorrow).
I personally wouldn't mind git - it's great.
The only drawback is local cloning. This operation is like 4x slower
than plain copying of the repository. Probably because it works like an
ssh clone - creates a pack, copies it, then unpacks. This is just
inefficient on a local machine.
> and bzr because they didn't focus on repository format, and have
> suggested that they will switch to a hash-addressed scheme at some point
> in the future...
>
Not only that - they don't have an efficient network transfer protocol.
(they use HTTP walkers, not even supporting persistent connections and
also do too many DNS lookups)
This is very unfortunate, especially for large projects.
(branching Linux would take 3 days I think)
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Fredrik Kuivinen @ 2006-01-29 10:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, Junio C Hamano, Git Mailing List, keithp
In-Reply-To: <Pine.LNX.4.64.0601280047240.2909@evo.osdl.org>
On Sat, Jan 28, 2006 at 12:53:31AM -0500, Linus Torvalds wrote:
>
>
> On Sat, 28 Jan 2006, Martin Langhoff wrote:
> >
> > BTW, have you still got that patch to git-merge to seed the commit msg
> > with conflicted files? ;-)
>
> Nope. But it was something like the appended (totally untested, and
> slightly improved).
>
> The point being that we'd fill in a template that the committer will
> hopefully edit to explain what he did to fix up the merge for each file
> that had conflicts.
>
Would it make sense to add an optional
mergeresult <tree>
line to merge commit objects? Here <tree> is supposed to be a SHA1 of
the tree object which corresponds to the result of the automatic part
of a merge. Hence, for a given merge commit which had conflicts
"git-diff-tree <commit SHA1> <mergeresult SHA1>" would give a diff
which shows the changes that was applied to resolve the conflict.
When the recursive merge strategy is used we actually write the
'mergeresult' tree object to the object database, so this thing should
be straight forward to implement in that case. If there is interest it
could be implemented for the resolve strategy too.
I think those mergeresult lines might be useful when implementing
git-annotate across merges too. It makes it easy to distinguish
changes which came from the merged branches and changes introduced in
the merge itself.
It would not be backwards compatible with the current git though...
- Fredrik
^ permalink raw reply
* Re: [Census] So who uses git?
From: Keith Packard @ 2006-01-29 10:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: cworth, keithp, Martin Langhoff, Linus Torvalds, Git Mailing List
In-Reply-To: <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]
On Sat, 2006-01-28 at 13:08 -0800, Junio C Hamano wrote:
> Keith Packard <keithp@keithp.com> writes:
>
> > Once we're happy with the import, I'm pretty sure we'll just switch
> > cairo over to git and dump the CVS bits. X.org is a harder case, for
> > that I suspect we'll migrate individual modules over one at a time,
> > perhaps starting with the core X server pieces so that I can get my work
> > done, have it published in the main repository and not have it also
> > break everyone else's X server.
>
> Wow....... You are switching Cairo and X.org from CVS to git?
We're not switching 'X.org', we're switching the X server core. X.org is
now broken into many separate projects, and each one will get to choose
SCM on their own. I expect to migrate the ones I maintain and use to
git, but migration of the dead code is unlikely to ever happen (and
there's lots of dead code)
> It could be that anything is better than CVS these days, but I
> have to admit that my jaw dropped after reading this, primarily
> because I've have never touched anything as big as X.
>
> Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have
> more faith in git. Earlier I heard Wine folks are running git
> in parallel with CVS as their dual primary SCM now, and of
> course git is the primary SCM for the Linux kernel project.
>
> For things like the source code management, it takes a new
> software to be at least 10 times as good as the one that has
> been used, because switching _is_ a pain no matter how well tool
> helps the transition. You have to transition not just the
> repository, but people who interact with it.
Fortunately, there are very few people involved with any specific piece
of the X.org distribution; there's really only one or two people
actively developing the X.org core server, so that part of the migration
will be easy. Our users will be stuck, but there aren't many of them
either, and git makes just sucking the current bits pretty easy.
> When the Linux kernel switched, it was not that hard to be
> infinitely better than the previous one. Because the previous
> one was no longer available to the kernel community; git did not
> have to be 10 times better on technical merits alone when the
> transition happened.
git really does look 10x better than CVS at this point; mostly social
issues are now blocking X development as weaker developers are refused
access to source code management to protect the project from damage. git
eliminates that barrier, and should let many new developers experiment
and share their results without affecting my work
> Can I hear experiences from other big projects that tried to use
> git [*1*]? I suspect there are many that have tried, and I
> would not be surprised at all if git did not work out well for
> them. For projects that already run on a (free) SCM, I would be
> very surprised if the developers find the current git 10 times
> better than the SCM they have been using (probably with an
> exception of CVS), unless they have very specific need, such as
> parallel development of distributed nature like the Linux
> kernel.
Everyone *wants* parallel distributed development, CVS prevents it.
And, remember that this is *not* a huge project, the core X server is
only 2M lines of source code. We separate out all of the drivers,
libraries and applications. Doing the migration in pieces allows us to
incrementally affect developers, and repair issues without suspending
all development.
I don't know of other huge projects moving to git; it's not all that
interesting as we know the tool is stable and will scale to support our
project already. Also, hg and bzr are not ready for production use in my
opinion; hg as it appears likely a flag day will be required before 1.0,
and bzr because they didn't focus on repository format, and have
suggested that they will switch to a hash-addressed scheme at some point
in the future...
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Possible git-rev-list bug
From: Marco Costalba @ 2006-01-29 9:41 UTC (permalink / raw)
To: junkio; +Cc: git
In today git archive:
$ git-rev-list --max-count=1 --parents addafaf92eeb86033da91323d0d3ad7a496dae83 -- rev-list.c
addafaf92eeb86033da91323d0d3ad7a496dae83 d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b 93b74bca86f59b8df410b6fd4803b88ee0f304bf d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b
d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b 3815f423ae39bf774de3c268c6d3e3b72128a4e5
We have the same parent (d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b) multiple times.
This behaviour causes a wrong graph in qgit and brakes gitk (try 'qgit rev-list.c' or
'gitk rev-list.c' and click on first merge commit).
Please confirm if it's a rev-list bug or it's a 'feature' ;-) in the latter case I will fix qgit.
Marco
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* qgit with autotools
From: Marco Costalba @ 2006-01-29 9:14 UTC (permalink / raw)
To: git; +Cc: proski
Hi all,
QGit now uses autotools instead of scons, courtesy of Pavel patch that has been pushed.
In patch description you will find the rationale for this update.
Also old git public repo has been removed after a deprecation period, so please now use:
http://digilander.libero.it/mcostalba/scm/qgit.git
After pulling new changes you should run "autoreconf -i" to create proper build environment and
then the usual ./configure + make + make install
Following, Pavel's answers regarding some notes on new build environment.
>
> 1) qgit binary is now 4,6MB on my machine, with scons it was 858KB.
I think Autoconf defaults to using "-g". You can strip the binary. I think you
can even run "make install-strip". And of course you can use "configure
CXXFLAGS=-O2" or something to disable debug information.
> 2) qgit is built in src directory instead of ./bin/ or ./ (not a biggie)
That's an Automake thing. There are ways to work it about, but they are not
nice (using libraries).
However, you can create a separate directory and run "configure && make" from it
(configure should run be with full path to the source directory). Then you get
a build outside the source tree. It may be just as good for your purposes.
Marco
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* [PATCH/RFC] git-rerere: reuse recorded resolve.
From: Junio C Hamano @ 2006-01-29 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q3ssbr6.fsf@assigned-by-dhcp.cox.net>
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).
This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* With my admittedly limited tests, this seems to work rather
well. I do a lot of "same" merges, because I rebuild "pu"
every time I have something new in the "master" branch, and
often what conflict are the things in my own topic branches,
none of which has been advanced meanwhile.
The feature is not enabled until you manually create
$GIT_DIR/rr-cache directory, at least for now.
Documentation/git-rerere.txt | 177 +++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 +
Makefile | 2
git-am.sh | 1
git-commit.sh | 1
git-merge.sh | 1
git-rerere.perl | 223 ++++++++++++++++++++++++++++++++++++++++++
git-reset.sh | 2
8 files changed, 408 insertions(+), 2 deletions(-)
create mode 100644 Documentation/git-rerere.txt
create mode 100755 git-rerere.perl
9843f047463a7b0b993c4bd80d34934618d5d622
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
new file mode 100644
index 0000000..8b6b651
--- /dev/null
+++ b/Documentation/git-rerere.txt
@@ -0,0 +1,177 @@
+git-rerere(1)
+=============
+
+NAME
+----
+git-rerere - Reuse recorded resolve
+
+SYNOPSIS
+--------
+'git-rerere'
+
+
+DESCRIPTION
+-----------
+
+In a workflow that employs relatively long lived topic branches,
+the developer sometimes needs to resolve the same conflict over
+and over again until the topic branches are done (either merged
+to the "release" branch, or sent out and accepted upstream).
+
+This command helps this process by recording conflicted
+automerge results and corresponding hand-resolve results on the
+initial manual merge, and later by noticing the same automerge
+results and applying the previously recorded hand resolution.
+
+[NOTE]
+You need to create `$GIT_DIR/rr-cache` directory to enable this
+command.
+
+DISCUSSION
+----------
+
+When your topic branch modifies overlapping area that your
+master branch (or upstream) touched since your topic branch
+forked from it, you may want to test it with the latest master,
+even before your topic branch is ready to be pushed upstream:
+
+------------
+ o---*---o topic
+ /
+ o---o---o---*---o---o master
+------------
+
+For such a test, you need to merge master and topic somehow.
+One way to do it is to pull master into the topic branch:
+
+------------
+ $ git checkout topic
+ $ git pull . master
+
+ o---*---o---+ topic
+ / /
+ o---o---o---*---o---o master
+------------
+
+The commits marked with `*` touch the same area in the same
+file; you need to resolve the conflicts when creating the commit
+marked with `+`. Then you can test the result to make sure your
+work-in-progress still works with what is in the latest master.
+
+After this test merge, there are two ways to continue your work
+on the topic. The easiest is to build on top of the test merge
+commit `+`, and when your work in the topic branch is finally
+ready, pull the topic branch into master, and/or ask the
+upstream to pull from you. By that time, however, the master or
+the upstream might have been advanced since the test merge `+`,
+in which case the final commit graph would look like this:
+
+------------
+ $ git checkout topic
+ $ git pull . master
+ $ ... work on both topic and master branches
+ $ git checkout master
+ $ git pull . topic
+
+ o---*---o---+---o---o topic
+ / / \
+ o---o---o---*---o---o---o---o---+ master
+------------
+
+When your topic branch is long-lived, however, your topic branch
+would end up having many such "Merge from master" commits on it,
+which would unnecessarily clutter the development history.
+Readers of the Linux kernel mailing list may remember that Linus
+complained about such too frequent test merges when a subsystem
+maintainer asked to pull from a branch full of "useless merges".
+
+As an alternative, to keep the topic branch clean of test
+merges, you could blow away the test merge, and keep building on
+top of the tip before the test merge:
+
+------------
+ $ git checkout topic
+ $ git pull . master
+ $ git reset --hard HEAD^ ;# rewind the test merge
+ $ ... work on both topic and master branches
+ $ git checkout master
+ $ git pull . topic
+
+ o---*---o-------o---o topic
+ / \
+ o---o---o---*---o---o---o---o---+ master
+------------
+
+This would leave only one merge commit when your topic branch is
+finally ready and merged into the master branch. This merge
+would require you to resolve the conflict, introduced by the
+commits marked with `*`. However, often this conflict is the
+same conflict you resolved when you created the test merge you
+blew away. `git-rerere` command helps you to resolve this final
+conflicted merge using the information from your earlier hand
+resolve.
+
+Running `git-rerere` command immediately after a conflicted
+automerge records the conflicted working tree files, with the
+usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
+them. Later, after you are done resolving the conflicts,
+running `git-rerere` again records the resolved state of these
+files. Suppose you did this when you created the test merge of
+master into the topic branch.
+
+Next time, running `git-rerere` after seeing a conflicted
+automerge, if the conflict is the same as the earlier one
+recorded, it is noticed and a three-way merge between the
+earlier conflicted automerge, the earlier manual resolution, and
+the current conflicted automerge is performed by the command.
+If this three-way merge resolves cleanly, the result is written
+out to your working tree file, so you would not have to manually
+resolve it. Note that `git-rerere` leaves the index file alone,
+so you still need to do the final sanity checks with `git diff`
+(or `git diff -c`) and `git update-index` when you are
+satisfied.
+
+As a convenience measure, `git-merge` automatically invokes
+`git-rerere` when it exits with a failed automerge, which
+records it if it is a new conflict, or reuses the earlier hand
+resolve when it is not. `git-commit` also invokes `git-rerere`
+when recording a merge result. What this means is that you do
+not have to do anything special yourself (Note: you still have
+to create `$GIT_DIR/rr-cache` directory to enable this command).
+
+In our example, when you did the test merge, the manual
+resolution is recorded, and it will be reused when you do the
+actual merge later with updated master and topic branch, as long
+as the earlier resolution is still applicable.
+
+The information `git-rerere` records is also used when running
+`git-rebase`. After blowing away the test merge and continuing
+development on the topic branch:
+
+------------
+ o---*---o-------o---o topic
+ /
+ o---o---o---*---o---o---o---o master
+
+ $ git rebase master topic
+
+ o---*---o-------o---o topic
+ /
+ o---o---o---*---o---o---o---o master
+------------
+
+you could run `git rebase master topic`, to keep yourself
+up-to-date even before your topic is ready to be sent upstream.
+This would result in falling back to three-way merge, and it
+would conflict the same way the test merge you resolved earlier.
+`git-rerere` is run by `git rebase` to help you resolve this
+conflict.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index e8ef3ef..2d0ca9d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -313,6 +313,9 @@ gitlink:git-rebase[1]::
gitlink:git-repack[1]::
Pack unpacked objects in a repository.
+gitlink:git-rerere[1]::
+ Reuse recorded resolution of conflicted merges.
+
gitlink:git-reset[1]::
Reset current HEAD to the specified state.
diff --git a/Makefile b/Makefile
index 2aa2385..a566951 100644
--- a/Makefile
+++ b/Makefile
@@ -116,7 +116,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-shortlog.perl git-fmt-merge-msg.perl \
+ git-shortlog.perl git-fmt-merge-msg.perl git-rerere.perl \
git-svnimport.perl git-mv.perl git-cvsexportcommit.perl
SCRIPT_PYTHON = \
diff --git a/git-am.sh b/git-am.sh
index 731ab1f..ee6886f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -88,6 +88,7 @@ fall_back_3way () {
# saying that we reverted all those changes.
git-merge-resolve $orig_tree -- HEAD $his_tree || {
+ git-rerere
echo Failed to merge in the changes.
exit 1
}
diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..bfcb0f2 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -237,6 +237,7 @@ else
fi
ret="$?"
rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG"
+git-rerere
if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
then
diff --git a/git-merge.sh b/git-merge.sh
index 92e5a65..586ac08 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -309,5 +309,6 @@ Conflicts:
sed -e 's/^[^ ]* / /' |
uniq
} >>"$GIT_DIR/MERGE_MSG"
+ git rerere
die "Automatic merge failed; fix up by hand"
fi
diff --git a/git-rerere.perl b/git-rerere.perl
new file mode 100755
index 0000000..df11951
--- /dev/null
+++ b/git-rerere.perl
@@ -0,0 +1,223 @@
+#!/usr/bin/perl
+#
+# REuse REcorded REsolve. This tool records a conflicted automerge
+# result and its hand resolution, and helps to resolve future
+# automerge that results in the same conflict.
+#
+# To enable this feature, create a directory 'rr-cache' under your
+# .git/ directory.
+
+use Digest;
+use File::Path;
+use File::Copy;
+
+my $git_dir = $::ENV{GIT_DIR} || ".git";
+my $rr_dir = "$git_dir/rr-cache";
+my $merge_rr = "$git_dir/rr-cache/MERGE_RR";
+
+my %merge_rr = ();
+
+sub read_rr {
+ if (!-f $merge_rr) {
+ %merge_rr = ();
+ return;
+ }
+ my $in;
+ local $/ = "\0";
+ open $in, "<$merge_rr" or die "$!: $merge_rr";
+ while (<$in>) {
+ chomp;
+ my ($name, $path) = /^([0-9a-f]{40})\t(.*)$/s;
+ $merge_rr{$path} = $name;
+ }
+ close $in;
+}
+
+sub write_rr {
+ my $out;
+ open $out, ">$merge_rr" or die "$!: $merge_rr";
+ for my $path (sort keys %merge_rr) {
+ my $name = $merge_rr{$path};
+ print $out "$name\t$path\0";
+ }
+ close $out;
+}
+
+sub compute_conflict_name {
+ my ($path) = @_;
+ my @side = ();
+ my $in;
+ open $in, "<$path" or die "$!: $path";
+
+ my $sha1 = Digest->new("SHA-1");
+ my $hunk = 0;
+ while (<$in>) {
+ if (/^<<<<<<< .*/) {
+ $hunk++;
+ @side = ([], undef);
+ }
+ elsif (/^=======$/) {
+ $side[1] = [];
+ }
+ elsif (/^>>>>>>> .*/) {
+ my ($one, $two);
+ $one = join('', @{$side[0]});
+ $two = join('', @{$side[1]});
+ if ($two le $one) {
+ ($one, $two) = ($two, $one);
+ }
+ $sha1->add($one);
+ $sha1->add("\0");
+ $sha1->add($two);
+ $sha1->add("\0");
+ @side = ();
+ }
+ elsif (@side == 0) {
+ next;
+ }
+ elsif (defined $side[1]) {
+ push @{$side[1]}, $_;
+ }
+ else {
+ push @{$side[0]}, $_;
+ }
+ }
+ close $in;
+ return ($sha1->hexdigest, $hunk);
+}
+
+sub record_preimage {
+ my ($path, $name) = @_;
+ my @side = ();
+ my ($in, $out);
+ open $in, "<$path" or die "$!: $path";
+ open $out, ">$name" or die "$!: $name";
+
+ while (<$in>) {
+ if (/^<<<<<<< .*/) {
+ @side = ([], undef);
+ }
+ elsif (/^=======$/) {
+ $side[1] = [];
+ }
+ elsif (/^>>>>>>> .*/) {
+ my ($one, $two);
+ $one = join('', @{$side[0]});
+ $two = join('', @{$side[1]});
+ if ($two le $one) {
+ ($one, $two) = ($two, $one);
+ }
+ print $out "<<<<<<<\n";
+ print $out $one;
+ print $out "=======\n";
+ print $out $two;
+ print $out ">>>>>>>\n";
+ @side = ();
+ }
+ elsif (@side == 0) {
+ print $out $_;
+ }
+ elsif (defined $side[1]) {
+ push @{$side[1]}, $_;
+ }
+ else {
+ push @{$side[0]}, $_;
+ }
+ }
+ close $out;
+ close $in;
+}
+
+sub find_conflict {
+ my $in;
+ local $/ = "\0";
+ open $in, '-|', qw(git ls-files -z -u) or die "$!: ls-files";
+ my %path = ();
+ my @path = ();
+ while (<$in>) {
+ chomp;
+ my ($mode, $sha1, $stage, $path) =
+ /^([0-7]+) ([0-9a-f]{40}) ([123])\t(.*)$/s;
+ $path{$path} |= (1 << $stage);
+ }
+ close $in;
+ while (my ($path, $status) = each %path) {
+ if ($status == 14) { push @path, $path; }
+ }
+ return @path;
+}
+
+sub merge {
+ my ($name, $path) = @_;
+ record_preimage($path, "$rr_dir/$name/thisimage");
+ unless (system('merge', map { "$rr_dir/$name/${_}image" }
+ qw(this pre post))) {
+ my $in;
+ open $in, "<$rr_dir/$name/thisimage" or
+ die "$!: $name/thisimage";
+ my $out;
+ open $out, ">$path" or die "$!: $path";
+ while (<$in>) { print $out $_; }
+ close $in;
+ close $out;
+ return 1;
+ }
+ return 0;
+}
+
+-d "$rr_dir" || exit(0);
+
+read_rr();
+my %conflict = map { $_ => 1 } find_conflict();
+
+# MERGE_RR records paths with conflicts immediately after merge
+# failed. Some of the conflicted paths might have been hand resolved
+# in the working tree since then, but the initial run would catch all
+# and register their preimages.
+
+for my $path (keys %conflict) {
+ # This path has conflict. If it is not recorded yet,
+ # record the pre-image.
+ if (!exists $merge_rr{$path}) {
+ my ($name, $hunk) = compute_conflict_name($path);
+ next unless ($hunk);
+ $merge_rr{$path} = $name;
+ if (! -d "$rr_dir/$name") {
+ mkpath("$rr_dir/$name", 0, 0777);
+ print STDERR "Recorded preimage for '$path'\n";
+ record_preimage($path, "$rr_dir/$name/preimage");
+ }
+ }
+}
+
+# Now some of the paths that had conflicts earlier might have been
+# hand resolved. Others may be similar to a conflict already that
+# was resolved before.
+
+for my $path (keys %merge_rr) {
+ my $name = $merge_rr{$path};
+
+ # We could resolve this automatically if we have images.
+ if (-f "$rr_dir/$name/preimage" &&
+ -f "$rr_dir/$name/postimage") {
+ if (merge($name, $path)) {
+ print STDERR "Resolved '$path' using previous resolution.\n";
+ # Then we do not have to worry about this path
+ # anymore.
+ delete $merge_rr{$path};
+ next;
+ }
+ }
+
+ # Let's see if we have resolved it.
+ (undef, my $hunk) = compute_conflict_name($path);
+ next if ($hunk);
+
+ print STDERR "Recorded resolution for '$path'.\n";
+ copy($path, "$rr_dir/$name/postimage");
+ # And we do not have to worry about this path anymore.
+ delete $merge_rr{$path};
+}
+
+# Write out the rest.
+write_rr();
diff --git a/git-reset.sh b/git-reset.sh
index 6c9e58a..fe53fc8 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -100,4 +100,4 @@ case "$reset_type" in
;;
esac
-rm -f "$GIT_DIR/MERGE_HEAD"
+rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR"
--
1.1.5.g3480-dirty
^ permalink raw reply related
* qgit with autotools
From: Marco Costalba @ 2006-01-29 8:14 UTC (permalink / raw)
To: git; +Cc: proski
Hi all,
QGit now uses autotools instead of scons, courtesy of Pavel patch that has been pushed.
In patch description you will find the rationale for this update.
Also old git public repo has been removed after a deprecation period, so please now use:
http://digilander.libero.it/mcostalba/scm/qgit.git
After pulling new changes you should run "autoreconf -i" to create proper build environment and
then the usual ./configure + make + make install
Following, Pavel's answers regarding some notes on new build environment.
>
> 1) qgit binary is now 4,6MB on my machine, with scons it was 858KB.
I think Autoconf defaults to using "-g". You can strip the binary. I think you
can even run "make install-strip". And of course you can use "configure
CXXFLAGS=-O2" or something to disable debug information.
> 2) qgit is built in src directory instead of ./bin/ or ./ (not a biggie)
That's an Automake thing. There are ways to work it about, but they are not
nice (using libraries).
However, you can create a separate directory and run "configure && make" from it
(configure should run be with full path to the source directory). Then you get
a build outside the source tree. It may be just as good for your purposes.
Marco
^ permalink raw reply
* [PATCH] cvs-migration documentation update
From: J. Bruce Fields @ 2006-01-29 4:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Here's some changes to the cvs-migration.txt. As usual, in my attempt
to make things clearer someone may have found I've made them less so, or
I may have just gotten something wrong; so any review is welcomed.
I can break up this sort of thing into smaller steps if preferred, the
monolothic patch is just a bit simpler for me for this sort of
thing.
I moved the material describing shared repository management from
core-tutorial.txt to cvs-migration.txt, where it seems more appropriate,
and combined two sections to eliminate some redundancy.
I also revised the earlier sections of cvs-migration.txt, mainly trying
to make it more concise.
I've left the last section of cvs-migration.txt (on CVS annotate
alternatives) alone for now.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/core-tutorial.txt | 118 -----------------
Documentation/cvs-migration.txt | 276 +++++++++++++++++++++++----------------
2 files changed, 167 insertions(+), 227 deletions(-)
bfa569527ebfa0388103c0619f15a2ee71ef3624
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 35579cc..4513ad6 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1623,123 +1623,7 @@ suggested in the previous section may be
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
-For this, set up a public repository on a machine that is
-reachable via SSH by people with "commit privileges". Put the
-committers in the same user group and make the repository
-writable by that group. Make sure their umasks are set up to
-allow group members to write into directories other members
-have created.
-
-You, as an individual committer, then:
-
-- First clone the shared repository to a local repository:
-------------------------------------------------
-$ git clone repo.shared.xz:/pub/scm/project.git/ my-project
-$ cd my-project
-$ hack away
-------------------------------------------------
-
-- Merge the work others might have done while you were hacking
- away:
-------------------------------------------------
-$ git pull origin
-$ test the merge result
-------------------------------------------------
-[NOTE]
-================================
-The first `git clone` would have placed the following in
-`my-project/.git/remotes/origin` file, and that's why this and
-the next step work.
-------------
-URL: repo.shared.xz:/pub/scm/project.git/ my-project
-Pull: master:origin
-------------
-================================
-
-- push your work as the new head of the shared
- repository.
-------------------------------------------------
-$ git push origin master
-------------------------------------------------
-If somebody else pushed into the same shared repository while
-you were working locally, `git push` in the last step would
-complain, telling you that the remote `master` head does not
-fast forward. You need to pull and merge those other changes
-back before you push your work when it happens.
-
-The `git push` command without any explicit refspec parameter
-pushes the refs that exist both in the local repository and the
-remote repository. So the last `push` can be done with either
-one of these:
-------------
-$ git push origin
-$ git push repo.shared.xz:/pub/scm/project.git/
-------------
-as long as the shared repository does not have any branches
-other than `master`.
-[NOTE]
-============
-If you created your shared repository by cloning from somewhere
-else, you may have the `origin` branch. Your developers
-typically do not use that branch; remove it. Otherwise, that
-would be pushed back by the `git push origin` because your
-developers' repository would surely have `origin` branch to keep
-track of the shared repository, and would be counted as "exist
-on both ends".
-============
-
-Advanced Shared Repository Management
--------------------------------------
-
-Being able to push into a shared repository means being able to
-write into it. If your developers are coming over the network,
-this means you, as the repository administrator, need to give
-each of them an SSH access to the shared repository machine.
-
-In some cases, though, you may not want to give a normal shell
-account to them, but want to restrict them to be able to only
-do `git push` into the repository and nothing else.
-
-You can achieve this by setting the login shell of your
-developers on the shared repository host to `git-shell` program.
-
-[NOTE]
-Most likely you would also need to list `git-shell` program in
-`/etc/shells` file.
-
-This restricts the set of commands that can be run from incoming
-SSH connection for these users to only `receive-pack` and
-`upload-pack`, so the only thing they can do are `git fetch` and
-`git push`.
-
-You still need to create UNIX user accounts for each developer,
-and put them in the same group. Make sure that the repository
-shared among these developers is writable by that group.
-
-. Initializing the shared repository with `git-init-db --shared`
-helps somewhat.
-
-. Run the following in the shared repository:
-+
-------------
-$ chgrp -R $group repo.git
-$ find repo.git -type d -print | xargs chmod ug+rwx,g+s
-$ GIT_DIR=repo.git git repo-config core.sharedrepository true
-------------
-
-The above measures make sure that directories lazily created in
-`$GIT_DIR` are writable by group members. You, as the
-repository administrator, are still responsible to make sure
-your developers belong to that shared repository group and set
-their umask to a value no stricter than 027 (i.e. at least allow
-reading and searching by group members).
-
-You can implement finer grained branch policies using update
-hooks. There is a document ("control access to branches") in
-Documentation/howto by Carl Baldwin and JC outlining how to (1)
-limit access to branch per user, (2) forbid overwriting existing
-tags.
-
+See link:cvs-migration.txt[git for CVS users] for the details.
Bundling your work together
---------------------------
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 8fd1a33..2bd58d3 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -1,126 +1,182 @@
git for CVS users
=================
-Ok, so you're a CVS user. That's ok, it's a treatable condition, and the
-first step to recovery is admitting you have a problem. The fact that
-you are reading this file means that you may be well on that path
-already.
-
-The thing about CVS is that it absolutely sucks as a source control
-manager, and you'll thus be happy with almost anything else. git,
-however, may be a bit 'too' different (read: "good") for your taste, and
-does a lot of things differently.
-
-One particular suckage of CVS is very hard to work around: CVS is
-basically a tool for tracking 'file' history, while git is a tool for
-tracking 'project' history. This sometimes causes problems if you are
-used to doing very strange things in CVS, in particular if you're doing
-things like making branches of just a subset of the project. git can't
-track that, since git never tracks things on the level of an individual
-file, only on the whole project level.
-
-The good news is that most people don't do that, and in fact most sane
-people think it's a bug in CVS that makes it tag (and check in changes)
-one file at a time. So most projects you'll ever see will use CVS
-'as if' it was sane. In which case you'll find it very easy indeed to
-move over to git.
-
-First off: this is not a git tutorial. See
-link:tutorial.html[Documentation/tutorial.txt] for how git
-actually works. This is more of a random collection of gotcha's
-and notes on converting from CVS to git.
-
-Second: CVS has the notion of a "repository" as opposed to the thing
-that you're actually working in (your working directory, or your
-"checked out tree"). git does not have that notion at all, and all git
-working directories 'are' the repositories. However, you can easily
-emulate the CVS model by having one special "global repository", which
-people can synchronize with. See details later, but in the meantime
-just keep in mind that with git, every checked out working tree will
-have a full revision control history of its own.
+So you're a CVS user. That's ok, it's a treatable condition. The job of
+this document is to put you on the road to recovery, by helping you
+convert an existing cvs repository to git, and by showing you how to use a
+git repository in a cvs-like fashion.
+Some basic familiarity with git is required. This
+link:tutorial.html[tutorial introduction to git] should be sufficient.
+
+First, note some ways that git differs from CVS:
+
+ * Commits are atomic and project-wide, not per-file as in CVS.
+
+ * Offline work is supported: you can make multiple commits locally,
+ then submit them when you're ready.
+
+ * Branching is fast and easy.
+
+ * Every working tree contains a repository with a full copy of the
+ project history, and no repository is inherently more important than
+ any other. However, you can emulate the CVS model by designating a
+ single shared repository which people can synchronize with; see below
+ for details.
Importing a CVS archive
-----------------------
-Ok, you have an old project, and you want to at least give git a chance
-to see how it performs. The first thing you want to do (after you've
-gone through the git tutorial, and generally familiarized yourself with
-how to commit stuff etc in git) is to create a git'ified version of your
-CVS archive.
-
-Happily, that's very easy indeed. git will do it for you, although git
-will need the help of a program called "cvsps":
-
- http://www.cobite.com/cvsps/
-
-which is not actually related to git at all, but which makes CVS usage
-look almost sane (ie you almost certainly want to have it even if you
-decide to stay with CVS). However, git will want 'at least' version 2.1
-of cvsps (available at the address above), and in fact will currently
-refuse to work with anything else.
-
-Once you've gotten (and installed) cvsps, you may or may not want to get
-any more familiar with it, but make sure it is in your path. After that,
-the magic command line is
-
- git cvsimport -v -d <cvsroot> -C <destination> <module>
-
-which will do exactly what you'd think it does: it will create a git
-archive of the named CVS module. The new archive will be created in the
-subdirectory named <destination>; it'll be created if it doesn't exist.
-Default is the local directory.
-
-It can take some time to actually do the conversion for a large archive
-since it involves checking out from CVS every revision of every file,
-and the conversion script is reasonably chatty unless you omit the '-v'
-option, but on some not very scientific tests it averaged about twenty
-revisions per second, so a medium-sized project should not take more
-than a couple of minutes. For larger projects or remote repositories,
-the process may take longer.
-
-After the (initial) import is done, the CVS archive's current head
-revision will be checked out -- thus, you can start adding your own
-changes right away.
-
-The import is incremental, i.e. if you call it again next month it'll
-fetch any CVS updates that have been happening in the meantime. The
-cut-off is date-based, so don't change the branches that were imported
-from CVS.
-
-You can merge those updates (or, in fact, a different CVS branch) into
-your main branch:
-
- git resolve HEAD origin "merge with current CVS HEAD"
-
-The HEAD revision from CVS is named "origin", not "HEAD", because git
-already uses "HEAD". (If you don't like 'origin', use cvsimport's
-'-o' option to change it.)
+First, install version 2.1 or higher of cvsps from
+link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
+sure it is in your path. The magic command line is then
+
+-------------------------------------------
+$ git cvsimport -v -d <cvsroot> -C <destination> <module>
+-------------------------------------------
+
+This puts a git archive of the named CVS module in the directory
+<destination>, which will be created if necessary. The -v option makes
+the conversion script very chatty.
+
+The import checks out from CVS every revision of every file. Reportedly
+cvsimport can average some twenty revisions per second, so for a
+medium-sized project this should not take more than a couple of minutes.
+Larger projects or remote repositories may take longer.
+
+The main trunk is stored in the git branch named `origin`, and additional
+CVS branches are stored in git branches with the same names. The most
+recent version of the main trunk is also left checked out on the `master`
+branch, so you can start adding your own changes right away.
+
+The import is incremental, so if you call it again next month it will
+fetch any CVS updates that have been made in the meantime. For this to
+work, you must not modify the imported branches; instead, create new
+branches for your own changes, and merge in the imported branches as
+necessary.
+
+Development Models
+------------------
+
+CVS users are accustomed to giving a group of developers commit access to
+a common repository. In the next section we'll explain how to do this
+with git. However, the distributed nature of git allows other development
+models, and you may want to first consider whether one of them might be a
+better fit for your project.
+
+For example, you can choose a single person to maintain the project's
+primary public repository. Other developers then clone this repository
+and each work in their own clone. When they have a series of changes that
+they're happy with, they ask the maintainer to pull from the branch
+containing the changes. The maintainer reviews their changes and pulls
+them into the primary repository, which other developers pull from as
+necessary to stay coordinated. The Linux kernel and other projects use
+variants of this model.
+
+With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.
+
+Emulating the CVS Development Model
+-----------------------------------
+
+Start with an ordinary git working directory containing the project, and
+remove the checked-out files, keeping just the bare .git directory:
+
+------------------------------------------------
+$ mv project/.git /pub/repo.git
+$ rm -r project/
+------------------------------------------------
+
+Next, give every team member read/write access to this repository. One
+easy way to do this is to give all the team members ssh access to the
+machine where the repository is hosted. If you don't want to give them a
+full shell on the machine, there is a restricted shell which only allows
+users to do git pushes and pulls; see gitlink:git-shell[1].
+
+Put all the committers should in the same group, and make the repository
+writable by that group:
+
+------------------------------------------------
+$ chgrp -R $group repo.git
+$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
+$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+------------------------------------------------
+
+Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.
+
+Suppose this repository is now set up in /pub/repo.git on the host
+foo.com. Then as an individual commiter you can clone the shared
+repository:
+
+------------------------------------------------
+$ git clone foo.com:/pub/repo.git/ my-project
+$ cd my-project
+------------------------------------------------
+
+and hack away. The equivalent of `cvs update` is
+
+------------------------------------------------
+$ git pull origin
+------------------------------------------------
+
+which merges in any work that others might have done since the clone
+operation.
+
+[NOTE]
+================================
+The first `git clone` places the following in the
+`my-project/.git/remotes/origin` file, and that's why the previous step
+and the next step both work.
+------------
+URL: foo.com:/pub/project.git/ my-project
+Pull: master:origin
+------------
+================================
+You can update the shared repository with your changes using:
-Emulating CVS behaviour
------------------------
+------------------------------------------------
+$ git push origin master
+------------------------------------------------
+
+If some else has updated the repository more recently, `git push`, like
+`cvs commit`, will complain, in which case you must pull any changes
+before attempting the push again.
+
+In the `git push` command above we specify the name of the remote branch
+to update (`master`). If we leave that out, `git push` tries to update
+any branches in the remote repository that have the same name as a branch
+in the local repository. So the last `push` can be done with either of:
+------------
+$ git push origin
+$ git push repo.shared.xz:/pub/scm/project.git/
+------------
-So, by now you are convinced you absolutely want to work with git, but
-at the same time you absolutely have to have a central repository.
-Step back and think again. Okay, you still need a single central
-repository? There are several ways to go about that:
-
-1. Designate a person responsible to pull all branches. Make the
-repository of this person public, and make every team member
-pull regularly from it.
-
-2. Set up a public repository with read/write access for every team
-member. Use "git pull/push" as you used "cvs update/commit". Be
-sure that your repository is up to date before pushing, just
-like you used to do with "cvs commit"; your push will fail if
-what you are pushing is not up to date.
-
-3. Make the repository of every team member public. It is the
-responsibility of each single member to pull from every other
-team member.
+as long as the shared repository does not have any branches
+other than `master`.
+[NOTE]
+============
+Because of this behaviour, if the shared repository and the developer's
+repository both have branches named `origin`, then a push like the above
+attempts to update the `origin` branch in the shared repository from the
+developer's `origin` branch. The results may be unexpected, so it's
+usually best to remove any branch named `origin` from the shared
+repository.
+============
+
+Advanced Shared Repository Management
+-------------------------------------
+
+Git allows you to specify scripts called "hooks" to be run at certain
+points. You can use these, for example, to send all commits to the shared
+repository to a mailing list. See link:hooks.txt[Hooks used by git].
+
+You can enforce finer grained permissions using update hooks. See
+link:howto/update-hook-example.txt[Controlling access to branches using
+update hooks].
CVS annotate
------------
--
0.99.8b.g3480-dirty
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-01-29 3:53 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0601281814i503bf934ge32b12e7b090c44@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
>> Can I hear experiences from other big projects that tried to use
>> git [*1*]? I suspect there are many that have tried, and I
>> would not be surprised at all if git did not work out well for
>> them.
>
> I've been playing with Gnumeric under git.
> ...
> We haven't switched yet, but I expect that we will...
I might have sounded as if I was looking for failure report, but
success stories are of course welcome ;-). It's always good to
hear their git experiences first-hand from people in the top
echelon of public projects.
> 270M is about 40% of the cvs repository size. Given
> compression I would have expected bigger savings.
I think that 40% sounds about right. My understanding of the
underlying format CVS uses, RCS, is that it stores an full copy
of the tip of trunk uncompressed, and other versions of the file
are represented as incremental delta from that. The packed git
format does not favor particular version based on the distance
from the tip, and stores either a compressed full copy, or a
delta from some other revision (which may not necessarily be
represented as a full copy). When we store something as a delta
from something else, we limit the length of the delta chain to a
full copy to 10 (by default), so that you can get to a specific
object with at most 10 applications of delta on top of a full
copy.
Comparing these two formats for storage efficiency is tricky:
- A full copy of the version at the tip in CVS is not
compressed but in git a full copy is compressed -- zlib gives
50% for typical text sources -- git has some advantage here.
- Because of delta-length limit, we store full copy, albeit
compressed [*1*], every ten or so versions. This trades off
storage effciency for run-time efficiency.
- CVS storage records most things as delta for a long-lived
project, and delta are less compressible (IOW, you could
think of them as already compressed somewhat), so it is not
_that_ inefficient to begin with.
- Delta representation is used only when representing something
as a delta from something else buys as enough space reduction
than compressing it as a full copy in git. This is a pure
improvement from the CVS format.
[Footnote]
*1* You could make different trade-off by using --depth flag
when running git-pack-objects.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Morten Welinder @ 2006-01-29 2:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net>
> Can I hear experiences from other big projects that tried to use
> git [*1*]? I suspect there are many that have tried, and I
> would not be surprised at all if git did not work out well for
> them.
I've been playing with Gnumeric under git.
-rw-rw-r-- 1 welinder research 270M Nov 5 09:46
gnumeric/.git/objects/pack/pack-91291de5477ddd06545b052460239b3dae89ad72.pack
270M is about 40% of the cvs repository size. Given
compression I would have expected bigger savings.
Conversion isn't perfect, probably because the cvs tree has
seen some hacking over the years. (I am not posting the URL
because I don't want to kill gnome.org.)
We haven't switched yet, but I expect that we will. We are
looking for (in no particular order):
1. Offline history.
2. Patch sets and other things that'll make it easier to maintain
more than one branch.
In other words, pretty-much anything but cvs will fit the bill, :-./
M.
^ permalink raw reply
* Re: Notes on Subproject Support
From: Junio C Hamano @ 2006-01-28 21:43 UTC (permalink / raw)
To: Horst von Brand; +Cc: git, Daniel Barkalow, Petr Baudis
In-Reply-To: <200601280455.k0S4tx6N003251@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> One thing that has bugged me from the beginning of this, and which does
> come out of your example: Why only project/subproject? In your example, you
> have the kernel (OK(ish)) and "rest of the world",...
Because I presented the example badly, perhaps?
There is nothing that prevents you from having more "bind" lines
than the example showed, to have one project that works with N
subprojects. In fact, the examples in earlier threads used a
project with the kernel and gcc subprojects -- I just felt it
was so obvious you can do N subprojects instead of just one, so
used just one subproject in the latest round of example for the
sake of brevity.
And there is nothing that prevents you from having "bind" lines
in the subproject commit objects, either.
The structure the lower level objects support with the "bound
commit" extension is not about "project vs subproject". You can
express "project that has subprojects each of which has
subsubprojects".
Now, it is totally a separate issue that anybody sane would want
to keep track of such structure, or we would be better off
leaving it to build infrastructure specific to each toplevel
project, as argued by some earlier.
^ permalink raw reply
* [Census] So who uses git?
From: Junio C Hamano @ 2006-01-28 21:08 UTC (permalink / raw)
To: Keith Packard; +Cc: Martin Langhoff, Linus Torvalds, Git Mailing List
In-Reply-To: <1138446030.9919.112.camel@evo.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> Once we're happy with the import, I'm pretty sure we'll just switch
> cairo over to git and dump the CVS bits. X.org is a harder case, for
> that I suspect we'll migrate individual modules over one at a time,
> perhaps starting with the core X server pieces so that I can get my work
> done, have it published in the main repository and not have it also
> break everyone else's X server.
Wow....... You are switching Cairo and X.org from CVS to git?
It could be that anything is better than CVS these days, but I
have to admit that my jaw dropped after reading this, primarily
because I've have never touched anything as big as X.
Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have
more faith in git. Earlier I heard Wine folks are running git
in parallel with CVS as their dual primary SCM now, and of
course git is the primary SCM for the Linux kernel project.
For things like the source code management, it takes a new
software to be at least 10 times as good as the one that has
been used, because switching _is_ a pain no matter how well tool
helps the transition. You have to transition not just the
repository, but people who interact with it.
When the Linux kernel switched, it was not that hard to be
infinitely better than the previous one. Because the previous
one was no longer available to the kernel community; git did not
have to be 10 times better on technical merits alone when the
transition happened.
Can I hear experiences from other big projects that tried to use
git [*1*]? I suspect there are many that have tried, and I
would not be surprised at all if git did not work out well for
them. For projects that already run on a (free) SCM, I would be
very surprised if the developers find the current git 10 times
better than the SCM they have been using (probably with an
exception of CVS), unless they have very specific need, such as
parallel development of distributed nature like the Linux
kernel.
I do not do mailing list search as often as I would like to be
doing, but I have seen some projects tried and went back to CVS.
We would learn much from our failures to support them -- what
those people found lacking.
[Foornote]
*1* Please limit yourselves to reasonably well-known "it is
surprising you haven't heard of this project" kind...
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-01-28 21:08 UTC (permalink / raw)
To: git
Now the Kiwi thing is over, I have merged up most of the topic
branches I've been holding back to the master branch.
Here are the highlights:
* "rev-list --remove-empty" by Linus, a step to help "annotate".
* "diff -c/--cc" combined diff format. When used with diff-tree,
they make a merge commit a bit more readable. They can also be
used with diff-files with an unmerged index to see the difference
to the working tree files from ours and theirs.
* Fix "diff-tree" to honour info/grafts file while showing parents.
When "rev-list --parents" output is piped to "diff-tree --stdin", I
think it also should show a fake header, but that is not currently
fixed.
* "rev-parse v2.6.14..v2.6.16" fix by Linus, with a follow up fix to
make "git whatchanged -- git-fetch-script" work again.
* Various 'abbreviation' fixes.
I'd like to do a 1.2 release with these sometime next week, but I
would like to encourage people to upgrade to 1.1.5 (or tonight's
"master") sooner rather than waiting for 1.2, since previous versions
have a little problem that can lead to a core dump or worse.
The "bind commit" thing is still in "pu"; since the discussion somehow
stalled, it may stay there for a while. I have not been exercising it
more than just using it in my regular workflow (meaning, I have not
seen any regression but no tests on the additional features) and have
not started playing with Porcelainish layer, primarily because I am
not in urgent need for subprojects myself.
^ permalink raw reply
* Re: Notes on Subproject Support
From: Horst von Brand @ 2006-01-28 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow, Petr Baudis
In-Reply-To: <7v3bjfafql.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This is still a draft/WIP, but "release early" is a good
> discipline, so...
One thing that has bugged me from the beginning of this, and which does
come out of your example: Why only project/subproject? In your example, you
have the kernel (OK(ish)) and "rest of the world", which could itself break
up and be tracking e.g. uClibc, and dhcp, and... And perhaps the kernel
itself breaks up into (local and vanilla) components.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Keith Packard @ 2006-01-28 11:00 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
On Sat, 2006-01-28 at 18:33 +1300, Martin Langhoff wrote:
> I've got a few small improvements to cvsimport in my laptop that I'll
> push out for Junio to merge as soon as I get back to the office. I've
> run "99% successful" imports of cairo and of x.org (modular and
> monolithic) with all their branches and tags. It isn't literally the
> 20 years of commits Jim talked initially about -- cvs holds just the
> last ~5 years.
Yeah, X CVS is a scattered mess at present. I think it would be better
to just leave that mess alone and grab a reasonably recent chunk of it
to put into a GIT repository. Save a bunch of space too. We also haven't
quite finished all of the recovery needed to span the whole twenty years
yet.
Carl and I hacked at the tool a bit to pull apart our ChangeLog-based
commit messages; extracting email addresses and separating the commit
messages from the (now useless) list of affected files.
We're getting clean cairo imports now, there are a few weirdnesses
around branches that we've seen -- one commit appears on both the branch
and trunk for some reason.
Once we're happy with the import, I'm pretty sure we'll just switch
cairo over to git and dump the CVS bits. X.org is a harder case, for
that I suspect we'll migrate individual modules over one at a time,
perhaps starting with the core X server pieces so that I can get my work
done, have it published in the main repository and not have it also
break everyone else's X server.
I'm not sure we'll need ongoing synchronization with existing X.org CVS
for long; there aren't any other developers doing any significant
changes to this part of the system, so we can abandon the losers with no
remorse.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* No merge strategy handled the merge (git version 1.1.GIT)
From: Roberto Nibali @ 2006-01-28 10:53 UTC (permalink / raw)
To: git
Hello,
I've been hacking on some features for IPVS in the Linux kernel recently
but abandoned work for 3 weeks. Today I wanted to re-sync with Linus to
work in a more up-to-date tree and simply typed (forgot I had previously
done work in that tree)
git-pull
in my local repository tree, which resulted in following:
[...]
ff/df76b725bc7c0ce7db0b123957c21989674aaf
pack/pack-0741dd55e7c560f401c7f37120f3203ad8664bb0.idx
pack/pack-0741dd55e7c560f401c7f37120f3203ad8664bb0.pack
wrote 43124 bytes read 122278591 bytes 66461.13 bytes/sec
total size is 122060858 speedup is 1.00
* refs/heads/origin: fast forward to branch 'master' of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 3ee68c4af3fd7228c1be63254b9f884614f9ebb2
Merging:
03f7e47c28dc1273395112c72ee198e86f2d576d Merge
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
3ee68c4af3fd7228c1be63254b9f884614f9ebb2 [SPARC64]: Use
compat_sys_futimesat in 32-bit syscall table.
found 1 common ancestor(s):
48ea753075aa15699bd5fac26faa08431aaa697b Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
Removing arch/sh/boards/hp6xx/hp620/mach.c
Removing arch/ia64/ia32/ia32_ioctl.c
Removing drivers/net/sk98lin/skproc.c
Removing include/asm-arm/arch-epxa10db/timer00.h
Removing arch/powerpc/xmon/start_32.c
Removing arch/arm/mach-integrator/dma.c
Removing drivers/video/aty/xlinit.c
Removing arch/arm/mach-epxa10db/Makefile.boot
Removing scripts/lxdialog/lxdialog.c
Removing include/asm-mips/.gitignore
Removing arch/ppc/platforms/pmac_smp.c
Removing drivers/scsi/sym53c8xx_defs.h
Removing arch/ppc/platforms/pmac_pci.c
Removing arch/sparc64/kernel/ioctl32.c
Removing arch/powerpc/xmon/start_8xx.c
Removing arch/um/include/time_user.h
Removing include/asm-mips/riscos-syscall.h
Removing drivers/char/rio/poll.h
Removing drivers/char/rio/brates.h
Removing scripts/lxdialog/inputbox.c
Removing drivers/char/rio/eisa.h
Removing arch/ppc/boot/openfirmware/coffmain.c
Removing drivers/char/rio/proto.h
Removing drivers/char/rio/riowinif.h
Removing drivers/char/rio/riscos.h
Removing drivers/serial/uart00.c
Removing net/ipv6/netfilter/ip6t_length.c
Removing arch/sh/kernel/cpu/irq_ipr.c
Removing arch/s390/crypto/des_z990.c
Removing scripts/lxdialog/yesno.c
Removing arch/x86_64/boot/compressed/miscsetup.h
Removing net/ipv6/netfilter/ip6t_mark.c
Removing net/ipv6/netfilter/ip6t_NFQUEUE.c
Removing include/asm-arm/arch-epxa10db/io.h
Removing drivers/char/rio/hosthw.h
Removing arch/ppc/platforms/pmac_time.c
Removing net/ipv6/netfilter/ip6t_MARK.c
Removing kernel/crash_dump.c
Removing arch/arm/mach-epxa10db/irq.c
Removing arch/ppc/platforms/pmac_low_i2c.c
Removing drivers/char/rio/cmd.h
Removing drivers/net/arm/ether00.c
Removing arch/mips/kernel/ioctl32.c
Removing arch/um/kernel/skas/mem_user.c
Removing drivers/i2c/busses/i2c-pmac-smu.c
Removing drivers/input/mouse/maplemouse.c
Removing drivers/char/rio/rtahw.h
Removing drivers/char/rio/mca.h
Removing scripts/lxdialog/textbox.c
Auto-merging net/ipv4/ipvs/ip_vs_ctl.c
Traceback (most recent call last):
File "/home/ratz/bin/git-merge-recursive", line 915, in ?
firstBranch, secondBranch, graph)
File "/home/ratz/bin/git-merge-recursive", line 87, in merge
branch1Name, branch2Name)
File "/home/ratz/bin/git-merge-recursive", line 160, in mergeTrees
if not processEntry(entry, branch1Name, branch2Name):
File "/home/ratz/bin/git-merge-recursive", line 868, in processEntry
branch1Name, branch2Name)
File "/home/ratz/bin/git-merge-recursive", line 212, in mergeFile
src1, orig, src2], returnCode=True)
File "/home/ratz/share/git-core/python/gitMergeCommon.py", line 72,
in runProgram
raise ProgramError(progStr, e.strerror)
ProgramError: merge -L HEAD/net/ipv4/ipvs/ip_vs_ctl.c -L
orig/net/ipv4/ipvs/ip_vs_ctl.c -L
3ee68c4af3fd7228c1be63254b9f884614f9ebb2/net/ipv4/ipvs/ip_vs_ctl.c
.merge_file_uofMwv .merge_file_hcesLs .merge_file_TwtEqw: No such file
or directory
No merge strategy handled the merge.
I'm all for verbosity when it comes to a problem with software, however
this output does not tell me much about what I could do to achieve
following state:
1. Sync my local tree to Linus' tree.
2. Merge my changes I've done locally with the resulting tree of 1.
git-diff shows me 222 unmerged paths, along with my changes:
~> git-diff net/ipv4/ipvs/
* Unmerged path net/ipv4/ipvs/ip_vs_ctl.c
diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c
* Unmerged path net/ipv4/ipvs/ip_vs_lblc.c
diff --git a/net/ipv4/ipvs/ip_vs_lblc.c b/net/ipv4/ipvs/ip_vs_lblc.c
* Unmerged path net/ipv4/ipvs/ip_vs_lblcr.c
diff --git a/net/ipv4/ipvs/ip_vs_lblcr.c b/net/ipv4/ipvs/ip_vs_lblcr.c
* Unmerged path net/ipv4/ipvs/ip_vs_proto_tcp.c
diff --git a/net/ipv4/ipvs/ip_vs_proto_tcp.c
b/net/ipv4/ipvs/ip_vs_proto_tcp.c
Would it be faster for me to clone the current master again and diff the
old (master, probably inconsistent) tree to master and merge the changes
by hand? Of course I can start my work again from scratch, it's only
been around 200 lines of changes so far ;).
Oh, btw, how is git branch -D supposed to work? Isn't there some code
missing?
Thanks for any insights,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ 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