* Branch metainformation
From: Jakub Narebski @ 2006-04-20 7:39 UTC (permalink / raw)
To: git
It seems that ever so often there is question posted on this list on which
the answer is to add '+' in 'pu' branch 'Pull:' line. I think that it is
not a good policy to have puller to remember which branches can be
fast-forwarded, and which needs to be merged. It should be an information
set and stored by person managing the branch (pullee), as some kind of
metainformation for the branch (like description and optional signature is
for tags).
Perhaps then there would be a place for short, one-line description of the
branch...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] git-svnimport symlink support
From: Junio C Hamano @ 2006-04-20 6:54 UTC (permalink / raw)
To: smurf; +Cc: git, Martin Langhoff, Herbert Valerio Riedel
In-Reply-To: <20060420061546.GF15270@smurf.noris.de>
Thanks all.
^ permalink raw reply
* Re: [PATCH] git-svnimport symlink support
From: smurf @ 2006-04-20 6:15 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, Karl Hasselström, Martin Langhoff,
Herbert Valerio Riedel, git
In-Reply-To: <46a038f90604181716t3d04ec95u92401858736fa6dc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
Hi,
Martin Langhoff:
> On 4/18/06, Junio C Hamano <junkio@cox.net> wrote:
> > Karl, Martin, Smurf, Comments?
>
> +1 but bear in mind that I am not learned in the ways of the SVN specials...
>
Neither am I, but if it seems to work -- *shrug*.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] diff --stat: do not drop rename information.
From: Junio C Hamano @ 2006-04-20 3:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
When a verbatim rename or copy is detected, we did not show
anything on the "diff --stat" for the filepair. This makes it
to show the rename information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* In git.git itself, with and without this patch:
$ git-diff-tree --stat -M ba580ae
ba580aeafb52921025de1efe1c50db34393f9907
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$ git-diff-tree --stat -M ba580ae
ba580aeafb52921025de1efe1c50db34393f9907
Makefile | 2 +-
diff.c => diff-lib.c | 0
2 files changed, 1 insertions(+), 1 deletions(-)
Since renames are rare, I think this is a good change. We
might want to do the same for "apply --stat" as well.
diff-lib.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 81 insertions(+), 17 deletions(-)
9ea8da8f01d7fb2159a81edba9e5e7885e6b616e
diff --git a/diff-lib.c b/diff-lib.c
index 0a832c3..86d1417 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -201,7 +201,8 @@ struct diffstat_t {
int nr;
int alloc;
struct diffstat_file {
- char *name;
+ char *name_a;
+ char *name_b;
unsigned is_unmerged:1;
unsigned is_binary:1;
unsigned int added, deleted;
@@ -209,7 +210,8 @@ struct diffstat_t {
};
static struct diffstat_file *diffstat_add(struct diffstat_t *diffstat,
- const char *name)
+ char *name_a,
+ char *name_b)
{
struct diffstat_file *x;
x = xcalloc(sizeof (*x), 1);
@@ -219,7 +221,10 @@ static struct diffstat_file *diffstat_ad
diffstat->alloc * sizeof(x));
}
diffstat->files[diffstat->nr++] = x;
- x->name = strdup(name);
+ x->name_a = strdup(name_a);
+ if (name_b)
+ name_b = strdup(name_b);
+ x->name_b = name_b;
return x;
}
@@ -234,6 +239,54 @@ static void diffstat_consume(void *priv,
x->deleted++;
}
+static char *find_common_pfx(const char *a, const char *b)
+{
+ const char *old = a;
+ const char *new = b;
+ char *name = NULL;
+ int common_length;
+ int len_a = strlen(a);
+ int len_b = strlen(b);
+
+ /* Find common prefix */
+ while (1) {
+ const char *slash_old, *slash_new;
+ slash_old = strchr(old, '/');
+ slash_new = strchr(new, '/');
+ if (!slash_old ||
+ !slash_new ||
+ slash_old - old != slash_new - new ||
+ memcmp(old, new, slash_new - new))
+ break;
+ old = slash_old + 1;
+ new = slash_new + 1;
+ }
+ /* a thru old is the common prefix, and old and new
+ * through the end of names are renames.
+ * Either give
+ * common{suffix-a => suffix-b}
+ * or
+ * name-a => name-b
+ * whichever is shorter.
+ */
+ common_length = (old - a);
+ /*
+ int squashed_len = (len_a + len_b - common_length + 6);
+ int separate_len = (len_a + len_b) + 4;
+ */
+ if (common_length < 2) {
+ /* no point squashing */
+ name = xmalloc(len_a + len_b + 5);
+ sprintf(name, "%s => %s", a, b);
+ }
+ else {
+ name = xmalloc(len_a + len_b - common_length + 7);
+ sprintf(name, "%.*s{%s => %s}",
+ common_length, a, old, new);
+ }
+ return name;
+}
+
static const char pluses[] = "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++";
static const char minuses[]= "----------------------------------------------------------------------";
@@ -249,8 +302,15 @@ static void show_stats(struct diffstat_t
for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
-
- len = strlen(file->name);
+ char *name = file->name_a;
+ if (file->name_b && strcmp(name, file->name_b)) {
+ name = find_common_pfx(name, file->name_b);
+ if (name != file->name_a) {
+ free(file->name_a);
+ file->name_a = name;
+ }
+ }
+ len = strlen(name);
if (max_len < len)
max_len = len;
@@ -261,7 +321,7 @@ static void show_stats(struct diffstat_t
}
for (i = 0; i < data->nr; i++) {
- char *name = data->files[i]->name;
+ char *name = data->files[i]->name_a;
int added = data->files[i]->added;
int deleted = data->files[i]->deleted;
@@ -269,7 +329,7 @@ static void show_stats(struct diffstat_t
char *qname = xmalloc(len + 1);
quote_c_style(name, qname, NULL, 0);
free(name);
- data->files[i]->name = name = qname;
+ data->files[i]->name_a = name = qname;
}
/*
@@ -305,6 +365,8 @@ static void show_stats(struct diffstat_t
printf(" %s%-*s | Unmerged\n", prefix, len, name);
goto free_diffstat_file;
}
+ else if (data->files[i]->name_b)
+ ;
else if (added + deleted == 0) {
total_files--;
goto free_diffstat_file;
@@ -325,7 +387,8 @@ static void show_stats(struct diffstat_t
len, name, added + deleted,
add, pluses, del, minuses);
free_diffstat_file:
- free(data->files[i]->name);
+ free(data->files[i]->name_a);
+ free(data->files[i]->name_b);
free(data->files[i]);
}
free(data->files);
@@ -424,14 +487,15 @@ static void builtin_diff(const char *nam
return;
}
-static void builtin_diffstat(const char *name_a, const char *name_b,
- struct diff_filespec *one, struct diff_filespec *two,
- struct diffstat_t *diffstat)
+static void builtin_diffstat(char *name_a, char *name_b,
+ struct diff_filespec *one,
+ struct diff_filespec *two,
+ struct diffstat_t *diffstat)
{
mmfile_t mf1, mf2;
struct diffstat_file *data;
- data = diffstat_add(diffstat, name_a ? name_a : name_b);
+ data = diffstat_add(diffstat, name_a, name_b);
if (!one || !two) {
data->is_unmerged = 1;
@@ -992,10 +1056,10 @@ static void run_diff(struct diff_filepai
}
static void run_diffstat(struct diff_filepair *p, struct diff_options *o,
- struct diffstat_t *diffstat)
+ struct diffstat_t *diffstat)
{
- const char *name;
- const char *other;
+ char *name;
+ char *other;
if (DIFF_PAIR_UNMERGED(p)) {
/* unmerged */
@@ -1374,7 +1438,7 @@ static void diff_flush_patch(struct diff
}
static void diff_flush_stat(struct diff_filepair *p, struct diff_options *o,
- struct diffstat_t *diffstat)
+ struct diffstat_t *diffstat)
{
if (diff_unmodified_pair(p))
return;
@@ -1559,7 +1623,7 @@ void diff_flush(struct diff_options *opt
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
flush_one_pair(p, DIFF_FORMAT_DIFFSTAT, options,
- diffstat);
+ diffstat);
}
show_stats(diffstat);
free(diffstat);
--
1.3.0.g6057
^ permalink raw reply related
* Re: using git on flash media
From: Josh Boyer @ 2006-04-20 0:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Tweed, git
In-Reply-To: <Pine.LNX.4.64.0604191651110.3701@g5.osdl.org>
On 4/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 20 Apr 2006, David Tweed wrote:
> >
> > What I'm basically checking is that it doesn't, I dunno, rewrite files
> > so frequently that on a modern flash drive it would wear out the entire
> > drive unreasonably quickly.
>
> The largely write-once nature of git should mean that the only files that
> get rewritten a lot are
> - the directories get rewritten to, since git creates new objects at a
> reasonable pace
> - the branch references get rewritten.
>
> In general, I'd say that git probably does less writing than most other
> SCM's are likely to do.
>
> That said, when you say "modern flash drive", I really suspect you
> shouldn't care deeply any more. Modern flash devices can be rewritten a
> lot more than old ones could (by an order of magnitude or more), and they
> almost always have wear levelling in hw, making it even less of an issue
> (but if they don't, your biggest issue will be that you should use a
> filesystem that does it for you).
Finding one that claims to have HW wear leveling is still hard, so you
can never really tell.
> That said, if you want to be safe, I think flash memory card vendors
> guarantee only up to 10,000 write cycles (and it used to be much less).
>
> That's _complete_ rewrites, though, which is more than just a single
> sector write. They tend to guarantee 100,000 single-sector re-writes (ie
> more like the "directory update" things when you create a new object).
When talking about flash, it's the erase cycles that are counted.
Most NOR chips guarantee 100,000 erase cycles per eraseblock. NAND
chips, which are what most flash drives use, can vary between 10,000 -
100,000 erases depending on the technology used.
> And assuming you'd count one commit as one "total rewrite" (which sounds
> unlikely - but it's certainly more than one sector - I don't know what
> they consider a total rewrite when they make up their numbers), that
A "total rewrite" is simply something that causes an eraseblock to be
erased. That can vary alot, but it essentially boils down to needing
to write new data to a location in an eraseblock that has already been
written to.
> implies that to be really safe, you shouldn't do more than 10,000 commits
> before you replace your flash. Quite frankly, I suspect that's _way_ more
> conservative than you should be, but hey, since you asked..
To be really conservative, just don't do it ;). Most flash drives
don't allow access to the raw flash chips, so while you can use
something like JFFS2 on them still, the benefits of that are somewhat
lost since you never really know what is going on underneath.
> One rule: NEVER mount your flash with the "sync" option, and use "noatime"
> to avoid unnecessary inode access time updates (that's especially true for
Right.
josh
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-20 0:33 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87r73t2jd3.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Thanks for the careful explanation.
You're welcome. You owe me a patch that typo-fixes and
pretty-prints my message, and drop it somewhere in
Documentation/howto hierarchy for future reference ;-).
> So there's the final piece I'd like here. I think "git status -a -v"
> should provide a multi-parent diff when merging, as should "git status
> -v" after manually doing an update-index while merging.
I'll keep that in mind, but honestly I am not very interested in
that particular use case, if only because you can already do
that by committing, and running "git show".
If you do not like how the resulting merge commit looks like, we
have "git commit --amend" and "git reset --hard HEAD^" for you
already.
I (or Linus) _may_ end up doing "git diff tree1 tree2 tree3..."
as part of the planned diff rewrite, but that would be only
if/when doing things in such a generic way is not much more
trouble than the current "we only do one of index-vs-files,
tree-vs-index, tree-vs-files-via-index or tree-vs-tree and
nothing else" model.
^ permalink raw reply
* Re: using git on flash media
From: Linus Torvalds @ 2006-04-20 0:23 UTC (permalink / raw)
To: David Tweed; +Cc: git
In-Reply-To: <20060419233125.89318.qmail@web86912.mail.ukl.yahoo.com>
On Thu, 20 Apr 2006, David Tweed wrote:
>
> What I'm basically checking is that it doesn't, I dunno, rewrite files
> so frequently that on a modern flash drive it would wear out the entire
> drive unreasonably quickly.
The largely write-once nature of git should mean that the only files that
get rewritten a lot are
- the directories get rewritten to, since git creates new objects at a
reasonable pace
- the branch references get rewritten.
In general, I'd say that git probably does less writing than most other
SCM's are likely to do.
That said, when you say "modern flash drive", I really suspect you
shouldn't care deeply any more. Modern flash devices can be rewritten a
lot more than old ones could (by an order of magnitude or more), and they
almost always have wear levelling in hw, making it even less of an issue
(but if they don't, your biggest issue will be that you should use a
filesystem that does it for you).
That said, if you want to be safe, I think flash memory card vendors
guarantee only up to 10,000 write cycles (and it used to be much less).
That's _complete_ rewrites, though, which is more than just a single
sector write. They tend to guarantee 100,000 single-sector re-writes (ie
more like the "directory update" things when you create a new object).
And assuming you'd count one commit as one "total rewrite" (which sounds
unlikely - but it's certainly more than one sector - I don't know what
they consider a total rewrite when they make up their numbers), that
implies that to be really safe, you shouldn't do more than 10,000 commits
before you replace your flash. Quite frankly, I suspect that's _way_ more
conservative than you should be, but hey, since you asked..
10,000 commits is actually a fair number. The kernel has gotten 25,000 in
a year, but the kernel is a pretty active and large project. I suspect
that 10,000 commits is quite a lot of years for most projects.
One rule: NEVER mount your flash with the "sync" option, and use "noatime"
to avoid unnecessary inode access time updates (that's especially true for
git, where archive atimes aren't interesting, but it's usually a good idea
for flash in general). Otherwise you'll get normal accesses ending up
doign "writes" too and writes will do a lot more of them, and the above
"one commit = one rewrite" rule-of-thumb is suddenly not at all
conservative.
Btw, backups are still good. Flash or no flash, and whether you're very
conservative in your flash usage or not.
Linus
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-20 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzeh3ypu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Wed, 19 Apr 2006 16:57:49 -0700, Junio C Hamano wrote:
>
> I suspect this is just a misunderstanding caused by insufficient
> explanation, so let's try this a bit differently.
Junio,
Thanks for the careful explanation.
> With the patch applied (or use "next" branch I'll be pushing out
> shortly), let's try the core-tutorial example up to the point
> where we need to make a merge commit and get conflict.
Heh. We dropped back to the identical example with our
crossed-in-flight messages.
> But later (much later) we find out that there was something
> wrong with this hand-resolve and now we would want to fix it.
> The new command, "git unresolve" is designed to help us exactly
> in this situation:
Yes. And this was in fact the question I had asked in IRC. How to get
the diff again when I realize the file I updated is wrong.
And as you point out, git-unresolve does just the trick here.
The question I asked in my latest message is basically just "Shouldn't
there be a way to get the diff from the several parents to the
index?". That's slightly different, but it is the functionality I was
looking for when I was trying to recover from my update-of-botched-merge.
And its useful separately as part of the pre-commit-review I've said I
always want to be able to do, (and as you designed "git status -v" to
provide).
So there's the final piece I'd like here. I think "git status -a -v"
should provide a multi-parent diff when merging, as should "git status
-v" after manually doing an update-index while merging.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-20 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk69l5gi1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]
On Wed, 19 Apr 2006 15:48:22 -0700, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > Meanwhile, I still think it's worth re-considering the original
> > problem.
>
> Maybe you are misunderstanding something in a major way,...
It's possible, but it's also possible I'm just failing to express
myself clearly.
> > After a failed merge, I get a multi-parent diff from "git
> > diff". However, after updating the index, I can't find any way to get
> > multi-parent diffs anymore.
>
> ... and that is exactly what this "unmerge to re-populate higher
> order stages" does. The multi-parent diff you have been looking
> at failed merge _is_ generated by comparing the higher order
> stages and your working tree file.
But unmerging puts my index back into a not-ready-to-commit state,
right? If so, then that's what I don't like from this proposal.
> > I'd still like to be able to do that, even when I know that what I
> > have in the index is good, and I don't want to undo it.
>
> You cannot it have both ways. Either you want to have the unmerged
> entries (so that you *can* view the combined diff), or you do
> not want to have them (then you obviously cannot view the
> combined diff between the working tree file and these stages).
I don't understand. Why would the entire diff operation have to happen
inside the index? As soon as I'm done with the merge commit I can do
"git show" and see a multi-parent diff. That doesn't have to muck with
my index, does it?
By, example, (using the merge from the git tutorial), just before
updating the index I get a lovely multi-parent diff:
$ git diff
diff --cc hello
index 06fa6a2,cc44c73..0000000
--- a/hello
+++ b/hello
@@@ -1,3 -1,3 +1,4 @@@
Hello World
It's a new day for git
+Play, play, play
+ Work, work, work
then I can update the index:
$ git update-index hello
and at this point I know I can see a single-parent diff before
committing:
$ git diff --cached
diff --git a/hello b/hello
index 06fa6a2..8798bdc 100644
--- a/hello
+++ b/hello
@@ -1,3 +1,4 @@
Hello World
It's a new day for git
Play, play, play
+Work, work, work
But what I want to do instead is at this point get the multi-parent
diff.
Finally, after I commit, it's easy to get multi-parent diff again:
$ git commit -m "Resolved merge conflict"
$ PAGER= git show
commit 547599946cf5dfb04af804e9d5451beb17662dca
Merge: 35e0e9b... 698ac13...
Author: Carl Worth <cworth@raht.cworth.org>
Date: Wed Apr 19 16:51:55 2006 -0700
Resolved merge conflict
diff --cc hello
index 06fa6a2,cc44c73..8798bdc
--- a/hello
+++ b/hello
@@@ -1,3 -1,3 +1,4 @@@
Hello World
It's a new day for git
+Play, play, play
+ Work, work, work
So why can't I get that same result before committing without changing
my index?
If the answer is that current implementation doesn't provide for that,
(that is, it provides either an in-index multi-diff for files in
multiple stages, OR it provides a multi-parent diff for a multi-parent
commit object), then that's fine. But that doesn't seem like any
fundamental limitation preventing what I'd like to have.
Am I making more sense now? Or am I still missing something?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-19 23:57 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87wtdl2o5o.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Meanwhile, I still think it's worth re-considering the original
> problem.
>
> After a failed merge, I get a multi-parent diff from "git
> diff". However, after updating the index, I can't find any way to get
> multi-parent diffs anymore.
>
> I'd still like to be able to do that, even when I know that what I
> have in the index is good, and I don't want to undo it. So the
> proposed unresolve (or update-index --unmerge, or whatever) is still
> not totally satisfactory.
I suspect this is just a misunderstanding caused by insufficient
explanation, so let's try this a bit differently.
With the patch applied (or use "next" branch I'll be pushing out
shortly), let's try the core-tutorial example up to the point
where we need to make a merge commit and get conflict.
The easiest way to do it is to interrupt the t/t1200-tutorial.sh
sequence, like this:
------------
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index 16b3ea9..a51bb50 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -105,6 +105,8 @@ git commit -m 'Some fun.' -i hello examp
test_expect_failure 'git resolve now fails' 'git resolve HEAD mybranch "Merge work in mybranch"'
+test_done
+
cat > hello << EOF
Hello World
It's a new day for git
------------
Now, go to t/ directory and run this:
------------
$ cd t
$ ./t1200-tutorial.sh
------------
... which will stop after saying:
------------
* ok 13: git resolve now fails
* passed all 13 test(s)
------------
Then go to t/trash directory to find the initial part of
Tutorial already run for us. We have created a repository with
two files (`example` and `hello`), with two branches (`master`
and `mybranch`), and we are on `master`. Both branches touched
`hello` in a conflicting way, and we have just pulled the other
branch into `master`, which conflicted, and hand resolved.
We can see the conflict like this:
------------
$ git diff
diff --cc hello
index ba42a2a,cc44c73..0000000
--- a/hello
+++ b/hello
@@@ -1,2 -1,3 +1,7 @@@
Hello World
++<<<<<<< .merge_file_4wwUQv
+Play, play, play
++=======
+ It's a new day for git
+ Work, work, work
++>>>>>>> .merge_file_6Ie4jx
------------
and we follow the tutorial to resolve it to see how the combined
diff looks like:
------------
$ cat >hello <<\EOF
Hello World
Play, play, play
It's a new day for git
Work, work, work
EOF
$ git diff
diff --cc hello
index ba42a2a,cc44c73..0000000
--- a/hello
+++ b/hello
@@@ -1,2 -1,3 +1,4 @@@
Hello World
+Play, play, play
+ It's a new day for git
+ Work, work, work
------------
Still with me so? Now, let's say there was something wrong with
the above merge, but at this point we did not know about it.
For now, we are satisfied with this and run update-index:
------------
$ git update-index hello
$ git diff
------------
It was conflicting before, we hand-resolved and we said we are
done. We do not see "git diff" output anymore, so we can
concentrate on other files.
But later (much later) we find out that there was something
wrong with this hand-resolve and now we would want to fix it.
The new command, "git unresolve" is designed to help us exactly
in this situation:
------------
$ git unresolve hello
$ git diff
diff --cc hello
index ba42a2a,cc44c73..0000000
--- a/hello
+++ b/hello
@@@ -1,2 -1,3 +1,4 @@@
Hello World
+Play, play, play
+ It's a new day for git
+ Work, work, work
------------
Then we realize that the "Play" line is not something we would
want in the merge result, because we are in serious business.
So let's drop it from the result and view the diff again:
------------
$ mv hello hellooo
$ sed -e '2d' <hellooo >hello
$ rm hellooo
$ git diff
diff --cc hello
index ba42a2a,cc44c73..0000000
--- a/hello
+++ b/hello
------------
Oops, what happened? There is no diff?
The default option "dense combined" (--cc) is stronger than
"combined" in that it omits hunks that have differences from
only one parent, and in this case we took "their" version, so
there is no interesting combined merge remaining to be seen.
If you want to view such not-so-interesting hunks, you could
give different option to "git diff", like so:
------------
$ git diff -c -p
diff --combined hello
index ba42a2a,cc44c73..0000000
--- a/hello
+++ b/hello
@@@ -1,2 -1,3 +1,3 @@@
Hello World
- Play, play, play
+ It's a new day for git
+ Work, work, work
------------
Also we can use different options like '--ours' (view diff from
our branch) and '--theirs' (diff from their branch):
------------
$ git diff --ours hello
* Unmerged path hello
diff --git a/hello b/hello
index ba42a2a..cc44c73 100644
--- a/hello
+++ b/hello
@@ -1,2 +1,3 @@
Hello World
-Play, play, play
+It's a new day for git
+Work, work, work
$ git diff --theirs hello
* Unmerged path hello
diff --git a/hello b/hello
------------
^ permalink raw reply related
* using git on flash media
From: David Tweed @ 2006-04-19 23:31 UTC (permalink / raw)
To: git; +Cc: tweed314
I was wondering if anyone here could answer two silly
questions arising from a lack of knowledge about the
precise architecture of git (unfortunately
websearching "using git flash" turns up pages about
miserable people and Macromedia):
Is it reasonable to use git reasonably intensively
keeping it's database on a flash media drive? (Ie, the
flash drive is plugged into a standard desktop machine
and the "actual versions" of the file that're being
managed are on the machine's hard disc, but all of the
git repository data are on a flash media drive. What
I'm basically checking is that it doesn't, I dunno,
rewrite files so frequently that on a modern flash
drive it would wear out the entire drive unreasonably
quickly.
Likewise, supposing that there are several machines
with the same filesystem tree devoted to the
git-chronicled project. Supposing you've got a careful
user who checks out the latest tree from the flash
drive into the machine's hard disk upon sitting down
at one of these machines, and commits to the flash
drive & properly umounts the flash before pulling it
out. The user does this switching between several
machines randomly. (So the git repository on flash
acts to ensure that whenever I sit down at a machine
I'm presented with my latest versions of everything.)
Is there any obvious problem that could come up which
could lead to git getting confused and somehow
corrupting the archive contents on the flash drive?
(Not the kind of catastrophic loss thing that'd be
caught by taking regular backups but some corruption
that'd silently make parts of the repository
un-checkoutable in the main flash repository.) I'm
trying to imagine some program somehow getting
confused and somehow writing some vital piece of
repository data to the "current" hard disc without
realising that means it's not "always readable all the
time", unlike the flash drive proper.
(I know the answer probably ought to be "just make all
the machines networked and communicate via the network
rather than a flash drive", but assume I'm not
amenable to changing.)
Many thanks for any insight,
cheers, david tweed
Send instant messages to your online friends http://uk.messenger.yahoo.com
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-19 22:48 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87wtdl2o5o.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Meanwhile, I still think it's worth re-considering the original
> problem.
Maybe you are misunderstanding something in a major way,...
> After a failed merge, I get a multi-parent diff from "git
> diff". However, after updating the index, I can't find any way to get
> multi-parent diffs anymore.
... and that is exactly what this "unmerge to re-populate higher
order stages" does. The multi-parent diff you have been looking
at failed merge _is_ generated by comparing the higher order
stages and your working tree file.
> I'd still like to be able to do that, even when I know that what I
> have in the index is good, and I don't want to undo it.
You cannot it have both ways. Either you want to have the unmerged
entries (so that you *can* view the combined diff), or you do
not want to have them (then you obviously cannot view the
combined diff between the working tree file and these stages).
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-19 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xq16y31.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]
On Wed, 19 Apr 2006 14:43:14 -0700, Junio C Hamano wrote:
>
> > It would be nice if the complementary operations of manually
> > resolving and unresolving a merge conflict had complementary command
> > names.
>
> True. I considered two other possibilities.
>
> * "git unmerge", because it creates unmerged index entries, and
This has the same problem as git-unresolve as compared to the old
git-resolve. Namely, it would provide an "unmerge" command that
syntactically looks like a complement to "merge" but in fact is an
entirely separate, (operating on different object types, etc.)
> * "git update-index --unmerge", because this is just a special
> kind of updates to the index file.
That seems like a very reasonable place to have this functionality (if
needed). Compared to things like "update-index --add" and
"update-index --remove" the desire for this operation is likely much
more rare, so perhaps doesn't merit its own command.
Meanwhile, I still think it's worth re-considering the original
problem.
After a failed merge, I get a multi-parent diff from "git
diff". However, after updating the index, I can't find any way to get
multi-parent diffs anymore.
I'd still like to be able to do that, even when I know that what I
have in the index is good, and I don't want to undo it. So the
proposed unresolve (or update-index --unmerge, or whatever) is still
not totally satisfactory.
In this state, "git commit" is still multi-parent aware and will be
making a merged commit, (by examining .git/MERGE_HEAD). Wouldn't it be
reasonable to make "git diff --cached" also be aware of this mid-merge
state and display a multi-parent diff? at least as an option?
-Carl
PS. As a more bizarre suggestion, I've been idly wondering for some
time if it would make sense to provide names to allow the working tree
and the index to be treated as pseudo, in-progress objects. For
example, much of my initial (and occasionally residual) confusion
regarding "git diff" would be alleviated if I could run commands
something like:
git diff HEAD TREE
git diff HEAD INDEX
git diff INDEX TREE
For this usage, perhaps INDEX and TREE are not the actual names that
git supports, but just some convenient refs that a user has set
up. And I don't have any proposal for what would be appropriate
low-level names for git to use for these pseudo-objects.
But I would sure be happy if I could just use refs like the above.
Then, if a concept like that existed, it should be rather
straightforward to achieve the multi-parent HEAD,MERGE_HEAD -> INDEX
diff that I'm after. It could probably come in handy in quite a few
other situations as well.
But I can imagine the idea might also break down quite badly. So just
let me know where it is totally stupid/infeasible.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] pre-commit hook: complain about conflict markers.
From: Junio C Hamano @ 2006-04-19 21:59 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xq16y31.fsf@assigned-by-dhcp.cox.net>
Several <<< or === or >>> characters at the beginning of a line
is very likely to be leftover conflict markers from a failed
automerge the user resolved incorrectly, so detect them.
As usual, this can be defeated with "git commit --no-verify" if
you really do want to have those files, just like changes that
introduce trailing whitespaces.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
templates/hooks--pre-commit | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
6be63d37efc766756922a9b96ed8fe7a332f133a
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 43d3b6e..723a9ef 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -61,6 +61,9 @@ perl -e '
if (/^\s* /) {
bad_line("indent SP followed by a TAB", $_);
}
+ if (/^(?:[<>=]){7}/) {
+ bad_line("unresolved merge conflict", $_);
+ }
}
}
exit($found_bad);
--
1.3.0.g2c4a
^ permalink raw reply related
* [PATCH] git-merge: a bit more readable user guidance.
From: Junio C Hamano @ 2006-04-19 21:59 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xq16y31.fsf@assigned-by-dhcp.cox.net>
We said "fix up by hand" after failed automerge, which was a big
"Huh? Now what?". Be a bit more explicit without being too
verbose. Suggested by Carl Worth.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-merge.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
aec8e89ca3d38f9d0d4d287d874e8b3859d68787
diff --git a/git-merge.sh b/git-merge.sh
index 78ab422..b834e79 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -335,5 +335,5 @@ Conflicts:
then
git-rerere
fi
- die "Automatic merge failed; fix up by hand"
+ die "Automatic merge failed; fix conflicts and then commit the result."
fi
--
1.3.0.g2c4a
^ permalink raw reply related
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bg96xsv.fsf@assigned-by-dhcp.cox.net>
On Wed, 19 Apr 2006, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Tue, 18 Apr 2006, Junio C Hamano wrote:
> >>
> >> A small fry in the ointment. What should the parts that are
> >> output with --name-only say for such a diff?
> >
> > I have no idea, I have to say ;)
>
> Another small one ;-). Bare blobs do not have modes, so diffcore
> needs to be told "do not bother comparing mode for this pair".
True, but sad.
We clearly _do_ have the mode when we look it up using the tree:name
shorthand, so it's a bit sad that we drop it on the floor like that.
We could do something like with the "name" part - squirrel the mode away
for users that could use it, and use the special mode of 0 as "unknown"
for when somebody really does give a pure SHA1 number (short or full).
But I suspect most people simply don't care, so dropping the mode might
just be the right thing to do. Especially if we do know that we _could_
get the mode if people really really care and complain some day in the
future..
(The logic being: 640kB really _is_ enough for everybody, if you just know
that you can extend on it in the future without undue pain when people
complain)
Linus
^ permalink raw reply
* Re: GIT Error issue
From: Martin Langhoff @ 2006-04-19 21:53 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
If you are using Debian or a derivative, just do
apt-get install git-core
which will remove the 'git' package (GNU Interactive Tools) and
install the git SCM. On RPM systems, probably
yum install git-core
will do the trick.
cheers,
martin
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 21:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604182108070.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 18 Apr 2006, Junio C Hamano wrote:
>>
>> A small fry in the ointment. What should the parts that are
>> output with --name-only say for such a diff?
>
> I have no idea, I have to say ;)
Another small one ;-). Bare blobs do not have modes, so diffcore
needs to be told "do not bother comparing mode for this pair".
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-19 21:43 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87acah6zk6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> But this does introduce an unfortunate semantic clash with the
> existing git-resolve, (which is an automated merge tool of some sort).
> I don't know much about the existing git-resolve, but a recent thread
> suggests it is a non-useful relic and people shouldn't be using it.
It is useful in a quick-and-dirty way, but does the same thing
as 'git merge -s resolve' and that is why people discussed
about removing it. It has semantics quite different from
update-index, so I'd ignore the synonym part of your
discussion.
Time for a quick raise-hand. Does anybody still use 'git
resolve'? Maybe we could remove it by 1.4?
> It would be nice if the complementary operations of manually
> resolving and unresolving a merge conflict had complementary command
> names.
True. I considered two other possibilities.
* "git unmerge", because it creates unmerged index entries, and
* "git update-index --unmerge", because this is just a special
kind of updates to the index file.
> ... For example, it might also complain if it notices
> conflict markers in the file. That seems like it would be a useful
> convenience.
Since you should compile test the merge result before going
anywhere, and the primary target of git is to manage sources, it
might not matter in most of the case, but for non-sources and non
compiled languages, that certainly is an issue.
When it _does_ matter, you can have a customized pre-commit hook
to look for the conflict markers, like this:
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 43d3b6e..723a9ef 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -61,6 +61,9 @@ perl -e '
if (/^\s* /) {
bad_line("indent SP followed by a TAB", $_);
}
+ if (/^(?:[<>=]){7}/) {
+ bad_line("unresolved merge conflict", $_);
+ }
}
}
exit($found_bad);
As usual, you can defeat the check with "git commit --no-verify"
for unlikely false matches.
> That's not much guidance for a new user that perhaps is only used to
> "git commit -a" and "git pull" that usually works. Without getting too
> verbose, this might be improved with something like:
>
> Automatic merge failed; fix conflicts by hand, then commit the result
That should be an easy patch ;-).
diff --git a/git-merge.sh b/git-merge.sh
index 78ab422..b834e79 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -335,5 +335,5 @@ Conflicts:
then
git-rerere
fi
- die "Automatic merge failed; fix up by hand"
+ die "Automatic merge failed; fix conflicts and then commit the result."
fi
^ permalink raw reply related
* Re: Support "git cmd --help" syntax
From: Jakub Narebski @ 2006-04-19 21:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604151402470.3701@g5.osdl.org>
Linus Torvalds wrote:
> [...] You can always get the usage
> message with "git commit --huh?", so it's not like you've lost anything.
Or "git commit --usage".
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-19 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu08p72sn.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
On Wed, 19 Apr 2006 13:01:28 -0700, Junio C Hamano wrote:
>
> This is an attempt to address the issue raised on #git channel
> recently by Carl Worth.
...
> With git-unresolve <paths>..., the versions from our branch and
> their branch for specified blobs are placed in stage #2 and
> stage #3, without touching the working tree files. This gives
> you the combined diff back for easier review, along with
> "diff --ours" and "diff --theirs".
Thanks. This looks quite interesting.
The name of git-unresolve seems reasonable on its own. In fact,
git-merge already uses "resolve" to describe manual conflict
resolution. For example:
echo "Using the $best_strategy to prepare resolving by hand."
But this does introduce an unfortunate semantic clash with the
existing git-resolve, (which is an automated merge tool of some sort).
I don't know much about the existing git-resolve, but a recent thread
suggests it is a non-useful relic and people shouldn't be using it.
It would be nice if the complementary operations of manually
resolving and unresolving a merge conflict had complementary command
names. Would it be feasible to cop-opt the git-resolve name as a
synonym for update-index? (I certainly wouldn't mind a shorter name
for that operation.)
In fact, git-resolve could even go beyond being a synonym for
update-index. For example, it might also complain if it notices
conflict markers in the file. That seems like it would be a useful
convenience, (and no functionality would be robbed, since update-index
would still be available for anyone who needs to commit content that
looks like conflict markers).
Another thing I've been meaning to suggest soon is better output for
when an automatic merge fails. Currently, the final message is:
Automatic merge failed; fix up by hand
That's not much guidance for a new user that perhaps is only used to
"git commit -a" and "git pull" that usually works. Without getting too
verbose, this might be improved with something like:
Automatic merge failed; fix conflicts by hand, then commit the result
In addition, if git-commit is run with unmerged files, it could also
provide some extra guidance. Perhaps something like this, (just after
the list of "needs merge" files mentioned by git-update-index):
Fix any conflicts in these files, then git-resolve each and commit again
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] sha1_name.c: no need to include diff.h; tree-walk.h will do.
From: Linus Torvalds @ 2006-04-19 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvt8hdb.fsf@assigned-by-dhcp.cox.net>
On Wed, 19 Apr 2006, Junio C Hamano wrote:
>
> * Just a clean-up, comes on top of the one that returns mode
> from get_tree_entry().
Ack (along with the mode addition).
However, since the function is now no longer private to the SHA1 name
lookup, I wonder if it might not be more logically put into "tree-walk.c"
instead of "sha1_name.c".
Just a thought.
Linus
^ permalink raw reply
* [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-19 20:01 UTC (permalink / raw)
To: git; +Cc: Carl Worth
This is an attempt to address the issue raised on #git channel
recently by Carl Worth.
After a conflicted automerge, "git diff" shows a combined diff
to give you how the tentative automerge result differs from
what came from each branch. During a complex merge, it is
tempting to be able to resolve a few paths at a time, mark
them "I've dealt with them" with git-update-index to unclutter
the next "git diff" output, and keep going. However, when the
final result does not compile or otherwise found to be a
mismerge, the workflow to fix the mismerged paths suddenly
changes to "git diff HEAD -- path" (to get a diff from our
HEAD before merging) and "git diff MERGE_HEAD -- path" (to get
a diff from theirs), and it cannot show the combined anymore.
With git-unresolve <paths>..., the versions from our branch and
their branch for specified blobs are placed in stage #2 and
stage #3, without touching the working tree files. This gives
you the combined diff back for easier review, along with
"diff --ours" and "diff --theirs".
One thing it does not do is to place the base in stage #1; this
means "diff --base" would behave differently between the run
immediately after a conflicted three-way merge, and the run
after an update-index by mistake followed by a git-unresolve.
We could theoretically run merge-base between HEAD and
MERGE_HEAD to find which tree to place in stage #1, but
reviewing "diff --base" is not that useful so....
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* comes on top of the previous two "extended sha1" cleanups.
.gitignore | 1
Makefile | 3 +
cache.h | 1
sha1_name.c | 6 +-
unresolve.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 151 insertions(+), 5 deletions(-)
diff --git a/.gitignore b/.gitignore
index b5959d6..1e4ba7b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -111,6 +111,7 @@ git-tag
git-tar-tree
git-unpack-file
git-unpack-objects
+git-unresolve
git-update-index
git-update-ref
git-update-server-info
diff --git a/Makefile b/Makefile
index 8aed3af..85938c0 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,8 @@ PROGRAMS = \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
- git-describe$X git-merge-tree$X git-blame$X git-imap-send$X
+ git-describe$X git-merge-tree$X git-blame$X git-imap-send$X \
+ git-unresolve$X
BUILT_INS = git-log$X
diff --git a/cache.h b/cache.h
index 69801b0..a5f1eb3 100644
--- a/cache.h
+++ b/cache.h
@@ -235,6 +235,7 @@ #define DEFAULT_ABBREV 7
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
+extern int get_tree_entry(const unsigned char *, const char *, unsigned char *, unsigned *);
extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int);
extern int create_symref(const char *git_HEAD, const char *refs_heads_master);
diff --git a/sha1_name.c b/sha1_name.c
index 7ad20b5..68b1275 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -450,8 +450,6 @@ static int get_sha1_1(const char *name,
return get_short_sha1(name, len, sha1, 0);
}
-static int get_tree_entry(const unsigned char *, const char *, unsigned char *, unsigned *);
-
static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result, unsigned *mode)
{
int namelen = strlen(name);
@@ -487,13 +485,13 @@ static int find_tree_entry(struct tree_d
return -1;
}
-static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1, unsigned *mode)
+int get_tree_entry(const unsigned char *ent_sha1, const char *name, unsigned char *sha1, unsigned *mode)
{
int retval;
void *tree;
struct tree_desc t;
- tree = read_object_with_reference(tree_sha1, tree_type, &t.size, NULL);
+ tree = read_object_with_reference(ent_sha1, tree_type, &t.size, NULL);
if (!tree)
return -1;
t.buf = tree;
diff --git a/unresolve.c b/unresolve.c
new file mode 100644
index 0000000..14655f7
--- /dev/null
+++ b/unresolve.c
@@ -0,0 +1,145 @@
+#include "cache.h"
+
+static const char unresolve_usage[] =
+"git-unresolve <paths>...";
+
+static struct cache_file cache_file;
+static unsigned char head_sha1[20];
+static unsigned char merge_head_sha1[20];
+
+static struct cache_entry *read_one_ent(const char *which,
+ unsigned char *ent, const char *path,
+ int namelen, int stage)
+{
+ unsigned mode;
+ unsigned char sha1[20];
+ int size;
+ struct cache_entry *ce;
+
+ if (get_tree_entry(ent, path, sha1, &mode)) {
+ error("%s: not in %s branch.", path, which);
+ return NULL;
+ }
+ if (mode == S_IFDIR) {
+ error("%s: not a blob in %s branch.", path, which);
+ return NULL;
+ }
+ size = cache_entry_size(namelen);
+ ce = xcalloc(1, size);
+
+ memcpy(ce->sha1, sha1, 20);
+ memcpy(ce->name, path, namelen);
+ ce->ce_flags = create_ce_flags(namelen, stage);
+ ce->ce_mode = create_ce_mode(mode);
+ return ce;
+}
+
+static int unresolve_one(const char *path)
+{
+ int namelen = strlen(path);
+ int pos;
+ int ret = 0;
+ struct cache_entry *ce_2 = NULL, *ce_3 = NULL;
+
+ /* See if there is such entry in the index. */
+ pos = cache_name_pos(path, namelen);
+ if (pos < 0) {
+ /* If there isn't, either it is unmerged, or
+ * resolved as "removed" by mistake. We do not
+ * want to do anything in the former case.
+ */
+ pos = -pos-1;
+ if (pos < active_nr) {
+ struct cache_entry *ce = active_cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, path, namelen)) {
+ fprintf(stderr,
+ "%s: skipping still unmerged path.\n",
+ path);
+ goto free_return;
+ }
+ }
+ }
+
+ /* Grab blobs from given path from HEAD and MERGE_HEAD,
+ * stuff HEAD version in stage #2,
+ * stuff MERGE_HEAD version in stage #3.
+ */
+ ce_2 = read_one_ent("our", head_sha1, path, namelen, 2);
+ ce_3 = read_one_ent("their", merge_head_sha1, path, namelen, 3);
+
+ if (!ce_2 || !ce_3) {
+ ret = -1;
+ goto free_return;
+ }
+ if (!memcmp(ce_2->sha1, ce_3->sha1, 20) &&
+ ce_2->ce_mode == ce_3->ce_mode) {
+ fprintf(stderr, "%s: identical in both, skipping.\n",
+ path);
+ goto free_return;
+ }
+
+ remove_file_from_cache(path);
+ if (add_cache_entry(ce_2, ADD_CACHE_OK_TO_ADD)) {
+ error("%s: cannot add our version to the index.", path);
+ ret = -1;
+ goto free_return;
+ }
+ if (!add_cache_entry(ce_3, ADD_CACHE_OK_TO_ADD))
+ return 0;
+ error("%s: cannot add their version to the index.", path);
+ ret = -1;
+ free_return:
+ free(ce_2);
+ free(ce_3);
+ return ret;
+}
+
+static void read_head_pointers(void)
+{
+ if (read_ref(git_path("HEAD"), head_sha1))
+ die("Cannot read HEAD -- no initial commit yet?");
+ if (read_ref(git_path("MERGE_HEAD"), merge_head_sha1)) {
+ fprintf(stderr, "Not in the middle of a merge.\n");
+ exit(0);
+ }
+}
+
+int main(int ac, char **av)
+{
+ int i;
+ int err = 0;
+ int newfd;
+
+ if (ac < 2)
+ usage(unresolve_usage);
+
+ git_config(git_default_config);
+
+ /* Read HEAD and MERGE_HEAD; if MERGE_HEAD does not exist, we
+ * are not doing a merge, so exit with success status.
+ */
+ read_head_pointers();
+
+ /* Otherwise we would need to update the cache. */
+ newfd= hold_index_file_for_update(&cache_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new cachefile");
+
+ if (read_cache() < 0)
+ die("cache corrupted");
+
+ for (i = 1; i < ac; i++) {
+ char *arg = av[i];
+ err |= unresolve_one(arg);
+ }
+ if (err)
+ die("Error encountered; index not updated.");
+
+ if (active_cache_changed) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file))
+ die("Unable to write new cachefile");
+ }
+ return 0;
+}
--
1.3.0.g2c4a
^ permalink raw reply related
* [PATCH] sha1_name.c: no need to include diff.h; tree-walk.h will do.
From: Junio C Hamano @ 2006-04-19 20:01 UTC (permalink / raw)
To: git
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Just a clean-up, comes on top of the one that returns mode
from get_tree_entry().
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 35e8dfb..7ad20b5 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -3,7 +3,7 @@ #include "tag.h"
#include "commit.h"
#include "tree.h"
#include "blob.h"
-#include "diff.h"
+#include "tree-walk.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
--
1.3.0.g2c4a
^ permalink raw reply related
* [PATCH] sha1_name.c: prepare to make get_tree_entry() reusable from others.
From: Junio C Hamano @ 2006-04-19 20:01 UTC (permalink / raw)
To: git
Make the mode information extracted from the tree available.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This comes on top of the extended SHA1 expression sha1:path
patch Linus did.
sha1_name.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 0cd1139..35e8dfb 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -450,18 +450,17 @@ static int get_sha1_1(const char *name,
return get_short_sha1(name, len, sha1, 0);
}
-static int get_tree_entry(const unsigned char *, const char *, unsigned char *);
+static int get_tree_entry(const unsigned char *, const char *, unsigned char *, unsigned *);
-static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result)
+static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result, unsigned *mode)
{
int namelen = strlen(name);
while (t->size) {
const char *entry;
const unsigned char *sha1;
int entrylen, cmp;
- unsigned mode;
- sha1 = tree_entry_extract(t, &entry, &mode);
+ sha1 = tree_entry_extract(t, &entry, mode);
update_tree_entry(t);
entrylen = strlen(entry);
if (entrylen > namelen)
@@ -477,18 +476,18 @@ static int find_tree_entry(struct tree_d
}
if (name[entrylen] != '/')
continue;
- if (!S_ISDIR(mode))
+ if (!S_ISDIR(*mode))
break;
if (++entrylen == namelen) {
memcpy(result, sha1, 20);
return 0;
}
- return get_tree_entry(sha1, name + entrylen, result);
+ return get_tree_entry(sha1, name + entrylen, result, mode);
}
return -1;
}
-static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1)
+static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1, unsigned *mode)
{
int retval;
void *tree;
@@ -498,7 +497,7 @@ static int get_tree_entry(const unsigned
if (!tree)
return -1;
t.buf = tree;
- retval = find_tree_entry(&t, name, sha1);
+ retval = find_tree_entry(&t, name, sha1, mode);
free(tree);
return retval;
}
@@ -510,6 +509,7 @@ static int get_tree_entry(const unsigned
int get_sha1(const char *name, unsigned char *sha1)
{
int ret;
+ unsigned unused;
prepare_alt_odb();
ret = get_sha1_1(name, strlen(name), sha1);
@@ -518,7 +518,8 @@ int get_sha1(const char *name, unsigned
if (cp) {
unsigned char tree_sha1[20];
if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1);
+ return get_tree_entry(tree_sha1, cp+1, sha1,
+ &unused);
}
}
return ret;
--
1.3.0.g2c4a
^ permalink raw reply related
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