* Re: [PATCH] completion: add --graph to log command completion
From: Teemu Likonen @ 2008-06-20 6:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dan McGee, git, gitster
In-Reply-To: <20080619225552.GQ11793@spearce.org>
Shawn O. Pearce wrote (2008-06-19 18:55 -0400):
> Teemu Likonen <tlikonen@iki.fi> wrote:
> > I think I have already sent twice a patch with --graph completion.
>
> I didn't Ack them because at the time --graph wasn't even in next yet
> I think. Then I got busy and forgot. And --graph slipped through
> into the 1.5.6 release without your bash completion patches. Sorry.
No problems. I should have sent a ping to the list after the log --graph
settled to the master branch. But... I forgot.
^ permalink raw reply
* Re: [PATCH 2/3] rebase-i: slight internal improvements
From: Johannes Sixt @ 2008-06-20 7:16 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Johannes Schindelin, Christian Couder
In-Reply-To: <1213929935-15093-3-git-send-email-s-beyer@gmx.net>
Stephan Beyer schrieb:
> Add commit_message function to get the commit message
> from a commit and other slight internal improvements.
If by "other slight improvements" you mean ...
> mark_action_done () {
> - sed -e 1q < "$TODO" >> "$DONE"
> - sed -e 1d < "$TODO" >> "$TODO".new
> - mv -f "$TODO".new "$TODO"
> - count=$(grep -c '^[^#]' < "$DONE")
> - total=$(($count+$(grep -c '^[^#]' < "$TODO")))
> + sed -e 1q "$TODO" >>"$DONE"
> + sed -e 1d "$TODO" >>"$TODO.new"
> + mv -f "$TODO.new" "$TODO"
> + count="$(grep -c '^[^#]' "$DONE")"
> + total="$(expr "$count" + "$(grep -c '^[^#]' "$TODO")")"
... this ...
> has_action () {
> - grep '^[^#]' "$1" >/dev/null
> + grep -q '^[^#]' "$1"
... and this, etc, then they are not improvements. They make the script
less portable: There are 'grep's that don't have -q, others write the file
name in front of the count, and I _think_ I have encountered 'sed's that
don't take a file name as argument.
This patch is just code churn for which you give no convincing reason in
the commit message why it is good.
-- Hannes
^ permalink raw reply
* Re: [PATCH] graph.c: make many functions static
From: Junio C Hamano @ 2008-06-20 7:37 UTC (permalink / raw)
To: Adam Simpkins
Cc: しらいしななこ, git
In-Reply-To: <20080620060035.GA22345@adamsimpkins.net>
Adam Simpkins <adam@adamsimpkins.net> writes:
> On Thu, Jun 19, 2008 at 12:16:11PM -0700, Junio C Hamano wrote:
>> しらいしななこ <nanako3@lavabit.com> writes:
> ...
>> > +/* Internal API */
>> > + ...
>> > +static int graph_next_line(struct git_graph *graph, struct strbuf *sb);
>> > +static void graph_padding_line(struct git_graph *graph, struct strbuf *sb);
>> > +static void graph_show_strbuf(struct git_graph *graph, struct strbuf const *sb);
>>
>> I think these are probably fine, not in the sense that nobody calls these
>> functions _right now_ but in the sense that I do not foresee a calling
>> sequence outside the graph.c internal that needs to call these directly,
>> instead of calling graph_show_*() functions that use these.
>
> Documentation/technical/api-history-graph.txt should also be updated
> to remove the discussion of these functions if they are no longer
> publicly exposed.
Actually, I was expecting (not necessarily _hoping_) you to defend these
public API by providing examples that illustrates when calling these from
outside graph API implementation could be useful.
^ permalink raw reply
* [PATCH 1/2] git-merge-file --ours, --theirs
From: Junio C Hamano @ 2008-06-20 7:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: geoffrey.russell, sverre, Johannes Sixt, Miklos Vajna, git
In-Reply-To: <7viqw6zovi.fsf@gitster.siamese.dyndns.org>
Often people want their conflicting merges autoresolved by favouring
upstream changes (or their own --- it's the same thing), and hinted to run
"git diff --name-only | xargs git checkout MERGE_HEAD --". This is
essentially to accept automerge results for the paths that are fully
resolved automatically while taking their version of the file in full for
paths that have conflicts.
This is problematic on two counts.
One problem is that this is not exactly what these people want. They
usually want to salvage as much automerge result as possible. In
particular, they want to keep autoresolved parts in conflicting paths, as
well as the paths that are fully autoresolved.
This patch teaches two new modes of operation to the lowest-lever merge
machinery, xdl_merge(). Instead of leaving the conflicted lines from both
sides enclosed in <<<, ===, and >>> markers, you can tell the conflicts to
be resolved favouring your side or their side of changes.
A larger problem is that this tends to encourage a bad workflow by
allowing them to record such a mixed up half-merge result as a full commit
without auditing. This commit does not tackle this latter issue. In git,
we usually give long enough rope to users with strange wishes as long as
the risky features is not on by default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Essentially the same patch but with documentation.
Documentation/git-merge-file.txt | 12 ++++++++++--
builtin-merge-file.c | 10 ++++++++--
xdiff/xdiff.h | 8 +++++++-
xdiff/xmerge.c | 24 ++++++++++++++++--------
4 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 149f131..87e07d3 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
- [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
+ [--ours|--theirs] [-p|--stdout] [-q|--quiet]
+ <current-file> <base-file> <other-file>
DESCRIPTION
@@ -34,7 +35,9 @@ normally outputs a warning and brackets the conflict with <<<<<<< and
>>>>>>> B
If there are conflicts, the user should edit the result and delete one of
-the alternatives.
+the alternatives. When `--ours` or `--theirs` option is in effect, however,
+these conflicts are resolved favouring lines from `<current-file>` or
+lines from `<other-file>` respectively.
The exit value of this program is negative on error, and the number of
conflicts otherwise. If the merge was clean, the exit value is 0.
@@ -62,6 +65,11 @@ OPTIONS
-q::
Quiet; do not warn about conflicts.
+--ours::
+--theirs::
+ Instead of leaving conflicts in the file, resolve conflicts
+ favouring our (or their) side of the lines.
+
EXAMPLES
--------
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 3605960..7d4ca8c 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -4,7 +4,7 @@
#include "xdiff-interface.h"
static const char merge_file_usage[] =
-"git merge-file [-p | --stdout] [-q | --quiet] [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+"git merge-file [-p | --stdout] [-q | --quiet] [--ours|--theirs] [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
int cmd_merge_file(int argc, const char **argv, const char *prefix)
{
@@ -13,6 +13,7 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
mmbuffer_t result = {NULL, 0};
xpparam_t xpp = {XDF_NEED_MINIMAL};
int ret = 0, i = 0, to_stdout = 0;
+ int flags, favor = 0;
while (argc > 4) {
if (!strcmp(argv[1], "-L") && i < 3) {
@@ -25,6 +26,10 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
else if (!strcmp(argv[1], "-q") ||
!strcmp(argv[1], "--quiet"))
freopen("/dev/null", "w", stderr);
+ else if (!strcmp(argv[1], "--ours"))
+ favor = XDL_MERGE_FAVOR_OURS;
+ else if (!strcmp(argv[1], "--theirs"))
+ favor = XDL_MERGE_FAVOR_THEIRS;
else
usage(merge_file_usage);
argc--;
@@ -45,8 +50,9 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
argv[i + 1]);
}
+ flags = XDL_MERGE_FLAGS(XDL_MERGE_ZEALOUS_ALNUM, favor);
ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
- &xpp, XDL_MERGE_ZEALOUS_ALNUM, &result);
+ &xpp, flags, &result);
for (i = 0; i < 3; i++)
free(mmfs[i].ptr);
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 413082e..d40cf21 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -99,9 +99,15 @@ long xdl_mmfile_size(mmfile_t *mmf);
int xdl_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdemitconf_t const *xecfg, xdemitcb_t *ecb);
+#define XDL_MERGE_FAVOR_OURS 1
+#define XDL_MERGE_FAVOR_THEIRS 2
+#define XDL_MERGE_FAVOR(flag) (((flag)>>4) & 03)
+#define XDL_MERGE_LEVEL(flag) ((flag) & 07)
+#define XDL_MERGE_FLAGS(level,flag) ((level) | ((flag)<<4))
+
int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
mmfile_t *mf2, const char *name2,
- xpparam_t const *xpp, int level, mmbuffer_t *result);
+ xpparam_t const *xpp, int flag, mmbuffer_t *result);
#ifdef __cplusplus
}
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 82b3573..88c29ae 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -114,7 +114,9 @@ static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int add_nl, char *dest)
}
static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
- xdfenv_t *xe2, const char *name2, xdmerge_t *m, char *dest)
+ xdfenv_t *xe2, const char *name2,
+ int favor,
+ xdmerge_t *m, char *dest)
{
const int marker_size = 7;
int marker1_size = (name1 ? strlen(name1) + 1 : 0);
@@ -124,6 +126,9 @@ static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
int size, i1, j;
for (size = i1 = 0; m; m = m->next) {
+ if (favor && !m->mode)
+ m->mode = favor;
+
if (m->mode == 0) {
size += xdl_recs_copy(xe1, i1, m->i1 - i1, 0,
dest ? dest + size : NULL);
@@ -322,8 +327,9 @@ static int xdl_simplify_non_conflicts(xdfenv_t *xe1, xdmerge_t *m,
* returns < 0 on error, == 0 for no conflicts, else number of conflicts
*/
static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
- xdfenv_t *xe2, xdchange_t *xscr2, const char *name2,
- int level, xpparam_t const *xpp, mmbuffer_t *result) {
+ xdfenv_t *xe2, xdchange_t *xscr2, const char *name2,
+ int level, int favor,
+ xpparam_t const *xpp, mmbuffer_t *result) {
xdmerge_t *changes, *c;
int i1, i2, chg1, chg2;
@@ -430,25 +436,27 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
/* output */
if (result) {
int size = xdl_fill_merge_buffer(xe1, name1, xe2, name2,
- changes, NULL);
+ favor, changes, NULL);
result->ptr = xdl_malloc(size);
if (!result->ptr) {
xdl_cleanup_merge(changes);
return -1;
}
result->size = size;
- xdl_fill_merge_buffer(xe1, name1, xe2, name2, changes,
- result->ptr);
+ xdl_fill_merge_buffer(xe1, name1, xe2, name2,
+ favor, changes, result->ptr);
}
return xdl_cleanup_merge(changes);
}
int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
mmfile_t *mf2, const char *name2,
- xpparam_t const *xpp, int level, mmbuffer_t *result) {
+ xpparam_t const *xpp, int flag, mmbuffer_t *result) {
xdchange_t *xscr1, *xscr2;
xdfenv_t xe1, xe2;
int status;
+ int level = XDL_MERGE_LEVEL(flag);
+ int favor = XDL_MERGE_FAVOR(flag);
result->ptr = NULL;
result->size = 0;
@@ -482,7 +490,7 @@ int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
} else {
status = xdl_do_merge(&xe1, xscr1, name1,
&xe2, xscr2, name2,
- level, xpp, result);
+ level, favor, xpp, result);
}
xdl_free_script(xscr1);
xdl_free_script(xscr2);
--
1.5.6.6.gd3e97
^ permalink raw reply related
* [PATCH 2/2] git-merge-recursive-{ours,theirs}
From: Junio C Hamano @ 2008-06-20 7:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: geoffrey.russell, sverre, Johannes Sixt, Miklos Vajna, git
In-Reply-To: <7vfxr8o8sx.fsf_-_@gitster.siamese.dyndns.org>
This uses the low-level mechanism for "ours" and "theirs" autoresolution
introduced by the previous commit to introduce two additional merge
strategies, merge-recursive-ours and merge-recursive-theirs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 3 ++
builtin-merge-recursive.c | 37 ++++++++++++++++++++++++---
git-merge.sh | 3 +-
git.c | 2 +
ll-merge.c | 24 +++++++++++------
ll-merge.h | 4 ++-
t/t6034-merge-ours-theirs.sh | 56 ++++++++++++++++++++++++++++++++++++++++++
7 files changed, 114 insertions(+), 15 deletions(-)
create mode 100755 t/t6034-merge-ours-theirs.sh
diff --git a/Makefile b/Makefile
index b003e3e..82d2892 100644
--- a/Makefile
+++ b/Makefile
@@ -304,6 +304,8 @@ BUILT_INS += git-format-patch$X
BUILT_INS += git-fsck-objects$X
BUILT_INS += git-get-tar-commit-id$X
BUILT_INS += git-init$X
+BUILT_INS += git-merge-recursive-ours$X
+BUILT_INS += git-merge-recursive-theirs$X
BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
@@ -1381,6 +1383,7 @@ check-docs::
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
+ git-merge-recursive-ours | git-merge-recursive-theirs | \
git-merge-resolve | git-merge-stupid | git-merge-subtree | \
git-fsck-objects | git-init-db | \
git-?*--?* ) continue ;; \
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index 4aa28a1..a355e7a 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -20,7 +20,11 @@
#include "attr.h"
#include "merge-recursive.h"
-static int subtree_merge;
+static enum {
+ MERGE_RECURSIVE_SUBTREE = 1,
+ MERGE_RECURSIVE_OURS,
+ MERGE_RECURSIVE_THEIRS,
+} merge_recursive_variants;
static struct tree *shift_tree_object(struct tree *one, struct tree *two)
{
@@ -642,6 +646,7 @@ static int merge_3way(mmbuffer_t *result_buf,
mmfile_t orig, src1, src2;
char *name1, *name2;
int merge_status;
+ int flag, favor;
name1 = xstrdup(mkpath("%s:%s", branch1, a->path));
name2 = xstrdup(mkpath("%s:%s", branch2, b->path));
@@ -650,9 +655,26 @@ static int merge_3way(mmbuffer_t *result_buf,
fill_mm(a->sha1, &src1);
fill_mm(b->sha1, &src2);
+ if (index_only)
+ favor = 0;
+ else {
+ switch (merge_recursive_variants) {
+ case MERGE_RECURSIVE_OURS:
+ favor = XDL_MERGE_FAVOR_OURS;
+ break;
+ case MERGE_RECURSIVE_THEIRS:
+ favor = XDL_MERGE_FAVOR_THEIRS;
+ break;
+ default:
+ favor = 0;
+ break;
+ }
+ }
+ flag = LL_MERGE_FLAGS(index_only, favor);
+
merge_status = ll_merge(result_buf, a->path, &orig,
&src1, name1, &src2, name2,
- index_only);
+ flag);
free(name1);
free(name2);
@@ -1171,7 +1193,7 @@ int merge_trees(struct tree *head,
{
int code, clean;
- if (subtree_merge) {
+ if (merge_recursive_variants == MERGE_RECURSIVE_SUBTREE) {
merge = shift_tree_object(head, merge);
common = shift_tree_object(head, common);
}
@@ -1379,11 +1401,18 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
int index_fd;
+ merge_recursive_variants = 0;
if (argv[0]) {
int namelen = strlen(argv[0]);
if (8 < namelen &&
!strcmp(argv[0] + namelen - 8, "-subtree"))
- subtree_merge = 1;
+ merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
+ else if (5 < namelen &&
+ !strcmp(argv[0] + namelen - 5, "-ours"))
+ merge_recursive_variants = MERGE_RECURSIVE_OURS;
+ else if (7 < namelen &&
+ !strcmp(argv[0] + namelen - 7, "-theirs"))
+ merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
}
git_config(merge_config, NULL);
diff --git a/git-merge.sh b/git-merge.sh
index 8026ccf..39b5cd9 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -31,10 +31,11 @@ LF='
'
all_strategies='recur recursive octopus resolve stupid ours subtree'
+all_strategies="$all_strategies recursive-ours recursive-theirs"
default_twohead_strategies='recursive'
default_octopus_strategies='octopus'
no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours'
+no_trivial_strategies='recursive recur subtree ours recursive-ours recursive-theirs'
use_strategies=
allow_fast_forward=t
diff --git a/git.c b/git.c
index 59f0fcc..44cb8eb 100644
--- a/git.c
+++ b/git.c
@@ -328,6 +328,8 @@ static void handle_internal_command(int argc, const char **argv)
{ "merge-file", cmd_merge_file },
{ "merge-ours", cmd_merge_ours, RUN_SETUP },
{ "merge-recursive", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
+ { "merge-recursive-ours", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
+ { "merge-recursive-theirs", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
{ "merge-subtree", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
{ "mv", cmd_mv, RUN_SETUP | NEED_WORK_TREE },
{ "name-rev", cmd_name_rev, RUN_SETUP },
diff --git a/ll-merge.c b/ll-merge.c
index 9837c84..c6a05bf 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -19,7 +19,7 @@ typedef int (*ll_merge_fn)(const struct ll_merge_driver *,
mmfile_t *orig,
mmfile_t *src1, const char *name1,
mmfile_t *src2, const char *name2,
- int virtual_ancestor);
+ int flag);
struct ll_merge_driver {
const char *name;
@@ -39,13 +39,15 @@ static int ll_binary_merge(const struct ll_merge_driver *drv_unused,
mmfile_t *orig,
mmfile_t *src1, const char *name1,
mmfile_t *src2, const char *name2,
- int virtual_ancestor)
+ int flag)
{
/*
* The tentative merge result is "ours" for the final round,
* or common ancestor for an internal merge. Still return
* "conflicted merge" status.
*/
+ int virtual_ancestor = flag & 01;
+
mmfile_t *stolen = virtual_ancestor ? orig : src1;
result->ptr = stolen->ptr;
@@ -60,9 +62,10 @@ static int ll_xdl_merge(const struct ll_merge_driver *drv_unused,
mmfile_t *orig,
mmfile_t *src1, const char *name1,
mmfile_t *src2, const char *name2,
- int virtual_ancestor)
+ int flag)
{
xpparam_t xpp;
+ int favor = ((flag)>>1) & 03;
if (buffer_is_binary(orig->ptr, orig->size) ||
buffer_is_binary(src1->ptr, src1->size) ||
@@ -73,14 +76,15 @@ static int ll_xdl_merge(const struct ll_merge_driver *drv_unused,
path_unused,
orig, src1, name1,
src2, name2,
- virtual_ancestor);
+ flag);
}
memset(&xpp, 0, sizeof(xpp));
return xdl_merge(orig,
src1, name1,
src2, name2,
- &xpp, XDL_MERGE_ZEALOUS,
+ &xpp,
+ XDL_MERGE_FLAGS(XDL_MERGE_ZEALOUS, favor),
result);
}
@@ -90,11 +94,12 @@ static int ll_union_merge(const struct ll_merge_driver *drv_unused,
mmfile_t *orig,
mmfile_t *src1, const char *name1,
mmfile_t *src2, const char *name2,
- int virtual_ancestor)
+ int flag)
{
char *src, *dst;
long size;
const int marker_size = 7;
+ int virtual_ancestor = flag & 01;
int status = ll_xdl_merge(drv_unused, result, path_unused,
orig, src1, NULL, src2, NULL,
@@ -158,7 +163,7 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,
mmfile_t *orig,
mmfile_t *src1, const char *name1,
mmfile_t *src2, const char *name2,
- int virtual_ancestor)
+ int flag)
{
char temp[3][50];
char cmdbuf[2048];
@@ -362,10 +367,11 @@ int ll_merge(mmbuffer_t *result_buf,
mmfile_t *ancestor,
mmfile_t *ours, const char *our_label,
mmfile_t *theirs, const char *their_label,
- int virtual_ancestor)
+ int flag)
{
const char *ll_driver_name;
const struct ll_merge_driver *driver;
+ int virtual_ancestor = flag & 01;
ll_driver_name = git_path_check_merge(path);
driver = find_ll_merge_driver(ll_driver_name);
@@ -375,5 +381,5 @@ int ll_merge(mmbuffer_t *result_buf,
return driver->fn(driver, result_buf, path,
ancestor,
ours, our_label,
- theirs, their_label, virtual_ancestor);
+ theirs, their_label, flag);
}
diff --git a/ll-merge.h b/ll-merge.h
index 5388422..5daef58 100644
--- a/ll-merge.h
+++ b/ll-merge.h
@@ -5,11 +5,13 @@
#ifndef LL_MERGE_H
#define LL_MERGE_H
+#define LL_MERGE_FLAGS(virtual_ancestor,favor) ((!!(virtual_ancestor)) | ((favor)<<1))
+
int ll_merge(mmbuffer_t *result_buf,
const char *path,
mmfile_t *ancestor,
mmfile_t *ours, const char *our_label,
mmfile_t *theirs, const char *their_label,
- int virtual_ancestor);
+ int flag);
#endif
diff --git a/t/t6034-merge-ours-theirs.sh b/t/t6034-merge-ours-theirs.sh
new file mode 100755
index 0000000..56a9247
--- /dev/null
+++ b/t/t6034-merge-ours-theirs.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+test_description='Merge-recursive ours and theirs variants'
+. ./test-lib.sh
+
+test_expect_success setup '
+ for i in 1 2 3 4 5 6 7 8 9
+ do
+ echo "$i"
+ done >file &&
+ git add file &&
+ cp file elif &&
+ git commit -m initial &&
+
+ sed -e "s/1/one/" -e "s/9/nine/" >file <elif &&
+ git commit -a -m ours &&
+
+ git checkout -b side HEAD^ &&
+
+ sed -e "s/9/nueve/" >file <elif &&
+ git commit -a -m theirs &&
+
+ git checkout master^0
+'
+
+test_expect_success 'plain recursive - should conflict' '
+ git reset --hard master &&
+ test_must_fail git merge -s recursive side &&
+ grep nine file &&
+ grep nueve file &&
+ ! grep 9 file &&
+ grep one file &&
+ ! grep 1 file
+'
+
+test_expect_success 'recursive favouring theirs' '
+ git reset --hard master &&
+ git merge -s recursive-theirs side &&
+ ! grep nine file &&
+ grep nueve file &&
+ ! grep 9 file &&
+ grep one file &&
+ ! grep 1 file
+'
+
+test_expect_success 'recursive favouring ours' '
+ git reset --hard master &&
+ git merge -s recursive-ours side &&
+ grep nine file &&
+ ! grep nueve file &&
+ ! grep 9 file &&
+ grep one file &&
+ ! grep 1 file
+'
+
+test_done
--
1.5.6.6.gd3e97
^ permalink raw reply related
* Re: [PATCH 2/3] rebase-i: slight internal improvements
From: Stephan Beyer @ 2008-06-20 8:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin, Christian Couder
In-Reply-To: <485B595B.80608@viscovery.net>
Hi,
On Fri, Jun 20, 2008 at 09:16:43AM +0200, Johannes Sixt wrote:
> If by "other slight improvements" you mean ...
>
> > mark_action_done () {
> > - sed -e 1q < "$TODO" >> "$DONE"
> > - sed -e 1d < "$TODO" >> "$TODO".new
> > - mv -f "$TODO".new "$TODO"
> > - count=$(grep -c '^[^#]' < "$DONE")
> > - total=$(($count+$(grep -c '^[^#]' < "$TODO")))
> > + sed -e 1q "$TODO" >>"$DONE"
> > + sed -e 1d "$TODO" >>"$TODO.new"
> > + mv -f "$TODO.new" "$TODO"
> > + count="$(grep -c '^[^#]' "$DONE")"
> > + total="$(expr "$count" + "$(grep -c '^[^#]' "$TODO")")"
>
> ... this ...
>
> > has_action () {
> > - grep '^[^#]' "$1" >/dev/null
> > + grep -q '^[^#]' "$1"
>
> ... and this, etc, then they are not improvements. They make the script
> less portable:
Ok, great to know.
> There are 'grep's that don't have -q,
Well, it's always a little hard to say what is understood by most of the
implementations. POSIX says, there is grep -q and a few git test
scripts and the Makefile uses it, too.
Ok, so I've looked for a list "the least common denominator of shell
commands you can use to be portable" on the net and found the
GNU Autoconf documentation:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_123.html
Looks like *portable* shell programming is no fun :\
> others write the file name in front of the count,
I did not really change anything that's related to the count, btw.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* MinGW port pull request
From: Johannes Sixt @ 2008-06-20 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, msysGit
From: Johannes Sixt <johannes.sixt@telecom.at>
Junio,
please pull the MinGW (Windows) port patch series from
git://repo.or.cz/git/mingw/j6t.git for-junio
The interdiff since I submitted the patch series
http://thread.gmane.org/gmane.comp.version-control.git/75250/focus=76276
is below.
This code base has been used in production since months, and editorial
issues have been ironed out since I submitted the series. The interdiff is
fairly small (it's mostly some new vsnprintf() fixes and a new utime()
wrapper). The interdiff does not show that we don't need to modify
git-clone.sh anymore ;) IMHO, this is material for 'next'.
At this point I would like to thank all contributors to the porting
effort. Some of your patches have been integrated in other patches in the
series, which now carry my authorship (that is, I'm the one to blame), but
I still have credited you in the commit message.
Here's the patch summary:
* Part 1: Get it going
01/38 Add compat/regex.[ch] and compat/fnmatch.[ch].
02/38 Compile some programs only conditionally.
03/38 Add target architecture MinGW.
With these patches we have a working git.exe that can successfully run
those builtins that need only read-access of the repository, like
git log, git diff, etc.
* Part 2: Working locally is possible
04/38 Windows: Use the Windows style PATH separator ';'.
05/38 Windows: Strip ".exe" from the program name.
06/38 Windows: Implement a wrapper of the open() function.
07/38 Windows: A minimal implemention of getpwuid().
08/38 Windows: always chmod(, 0666) before unlink().
09/38 Windows: Work around misbehaved rename().
10/38 setup.c: Prepare for Windows directory separators.
11/38 Windows: Treat Windows style path names.
12/38 Windows: Handle absolute paths in safe_create_leading_directories().
13/38 Windows: Implement gettimeofday().
14/38 Windows: Fix PRIuMAX definition.
15/38 Windows: Implement setitimer() and sigaction().
Now builtins that write to the repository work as long as they don't need
to spawn secondary processes.
* Part 3: Shell scripts and start_command()
16/38 Windows: Wrap execve so that shell scripts can be invoked.
17/38 Windows: A pipe() replacement whose ends are not inherited to
children.
18/38 Windows: Implement start_command().
19/38 Windows: Change the name of hook scripts to make them not
executable.
Now scripted tools and the builtins and standalone programs work that
depend on start_command().
* Part 4: Remote connections
20/38 Windows: A rudimentary poll() emulation.
21/38 Windows: Disambiguate DOS style paths from SSH URLs.
22/38 Windows: Implement asynchronous functions as threads.
23/38 Windows: Work around incompatible sort and find.
24/38 Windows: Implement wrappers for gethostbyname(), socket(), and
connect().
Remote connections, both push and fetch, using local transport as well as
connections via ssh and native git protocol work.
* Part 5: Optimizations
25/38 Windows: Implement a custom spawnve().
26/38 Windows: Add a new lstat and fstat implementation based on Win32
API.
27/38 Windows: Add a custom implementation for utime().
28/38 Windows: Use a customized struct stat that also has the st_blocks
member.
* Part 6: Tie up loose ends
29/38 Turn builtin_exec_path into a function.
30/38 Windows: Compute the fallback for exec_path from the program
invocation.
31/38 Windows: Use a relative default template_dir and ETC_GITCONFIG
32/38 When installing, be prepared that template_dir may be relative.
33/38 Windows: Make the pager work.
34/38 Windows: Work around an oddity when a pipe with no reader is written
to.
35/38 Windows: Make 'git help -a' work.
36/38 Windows: TMP and TEMP environment variables specify a temporary
directory.
37/38 Windows: Fix ntohl() related warnings about printf formatting
38/38 compat/pread.c: Add a forward declaration to fix a warning
This fixes some final remaining oddities, minor missing features, and
works around differences between POSIX and Windows.
Documentation/git.txt | 6 +-
Makefile | 49 ++-
cache.h | 2 +-
compat/fnmatch.c | 488 +++++++++++++++++
compat/fnmatch.h | 84 +++
compat/mingw.c | 1008 +++++++++++++++++++++++++++++++++++
compat/mingw.h | 208 ++++++++
compat/regex.c | 4927 ++++++++++++++++++++(lots...)
compat/regex.h | 490 +++++++++++++++++
compat/snprintf.c | 19 +-
connect.c | 2 +-
date.c | 2 +-
exec_cmd.c | 41 ++-
git-compat-util.h | 31 +-
git-sh-setup.sh | 13 +
git.c | 14 +
help.c | 33 +-
| 40 ++-
path.c | 7 +
run-command.c | 126 ++++-
run-command.h | 5 +
setup.c | 58 ++-
sha1_file.c | 14 +-
templates/Makefile | 11 +-
transport.c | 3 +-
upload-pack.c | 2 +
write_or_die.c | 7 +-
27 files changed, 7617 insertions(+), 73 deletions(-)
Interdiff follows (it's line wrapped, just for exposition):
diff --git a/Makefile b/Makefile
index 4ff82c9..ad4b779 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,7 +1301,7 @@ remove-dashes:
ifeq ($(firstword $(subst /, ,$(template_dir))),..)
template_instdir = $(gitexecdir)/$(template_dir)
else
-template_instdir = $template_dir
+template_instdir = $(template_dir)
endif
export template_instdir
diff --git a/compat/mingw.c b/compat/mingw.c
index 7c8fd0e..ee26df9 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -175,6 +175,33 @@ int mingw_fstat(int fd, struct mingw_stat *buf)
return -1;
}
+static inline void time_t_to_filetime(time_t t, FILETIME *ft)
+{
+ long long winTime = t * 10000000LL + 116444736000000000LL;
+ ft->dwLowDateTime = winTime;
+ ft->dwHighDateTime = winTime >> 32;
+}
+
+int mingw_utime (const char *file_name, const struct utimbuf *times)
+{
+ FILETIME mft, aft;
+ int fh, rc;
+
+ /* must have write permission */
+ if ((fh = open(file_name, O_RDWR | O_BINARY)) < 0)
+ return -1;
+
+ time_t_to_filetime(times->modtime, &mft);
+ time_t_to_filetime(times->actime, &aft);
+ if (!SetFileTime((HANDLE)_get_osfhandle(fh), NULL, &aft, &mft)) {
+ errno = EINVAL;
+ rc = -1;
+ } else
+ rc = 0;
+ close(fh);
+ return rc;
+}
+
unsigned int sleep (unsigned int seconds)
{
Sleep(seconds*1000);
@@ -353,7 +380,7 @@ static const char *quote_arg(const char *arg)
const char *p = arg;
if (!*p) force_quotes = 1;
while (*p) {
- if (isspace(*p) || *p == '*' || *p == '?')
+ if (isspace(*p) || *p == '*' || *p == '?' || *p == '{')
force_quotes = 1;
else if (*p == '"')
n++;
diff --git a/compat/mingw.h b/compat/mingw.h
index c7db345..6965e3f 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -24,6 +24,8 @@ typedef int pid_t;
#define SIGKILL 0
#define SIGCHLD 0
#define SIGPIPE 0
+#define SIGHUP 0
+#define SIGQUIT 0
#define SIGALRM 100
#define F_GETFD 1
@@ -174,6 +176,9 @@ int mingw_fstat(int fd, struct mingw_stat *buf);
static inline int mingw_stat(const char *file_name, struct mingw_stat *buf)
{ return mingw_lstat(file_name, buf); }
+int mingw_utime(const char *file_name, const struct utimbuf *times);
+#define utime mingw_utime
+
pid_t mingw_spawnvpe(const char *cmd, const char **argv, char **env);
void mingw_execvp(const char *cmd, char *const *argv);
#define execvp mingw_execvp
diff --git a/compat/snprintf.c b/compat/snprintf.c
index 480b66f..580966e 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -13,9 +13,13 @@
int git_vsnprintf(char *str, size_t maxsize, const char *format, va_list ap)
{
char *s;
- int ret;
+ int ret = -1;
- ret = vsnprintf(str, maxsize-SNPRINTF_SIZE_CORR, format, ap);
+ if (maxsize > 0) {
+ ret = vsnprintf(str, maxsize-SNPRINTF_SIZE_CORR, format, ap);
+ /* Windows does not NUL-terminate if result fills buffer */
+ str[maxsize-1] = 0;
+ }
if (ret != -1)
return ret;
diff --git a/git-compat-util.h b/git-compat-util.h
index cdfd54d..46fc2d3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -66,12 +66,12 @@
#include <fnmatch.h>
#include <assert.h>
#include <regex.h>
+#include <utime.h>
#ifndef __MINGW32__
#include <sys/wait.h>
#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
-#include <utime.h>
#ifndef NO_SYS_SELECT_H
#include <sys/select.h>
#endif
@@ -185,7 +185,7 @@ extern ssize_t git_pread(int fd, void *buf, size_t
count, off_t offset);
* This function is used in compat/pread.c. But we can't include
* cache.h there.
*/
-extern int read_in_full(int fd, void *buf, size_t count);
+extern ssize_t read_in_full(int fd, void *buf, size_t count);
#ifdef NO_SETENV
#define setenv gitsetenv
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 822aa6f..9cceb21 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -153,9 +153,5 @@ case $(uname -s) in
find () {
/usr/bin/find "$@"
}
- # sync is missing
- sync () {
- : # no implementation
- }
;;
esac
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 51d90a3..c861141 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -441,16 +441,3 @@ do
test_done
esac
done
-
-# Fix some commands on Windows
-case $(uname -s) in
-*MINGW*)
- # Windows has its own (incompatible) sort and find
- sort () {
- /usr/bin/sort "$@"
- }
- find () {
- /usr/bin/find "$@"
- }
- ;;
-esac
^ permalink raw reply related
* Re: [PATCH 2/3] rebase-i: slight internal improvements
From: Johannes Sixt @ 2008-06-20 8:17 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Johannes Schindelin, Christian Couder
In-Reply-To: <20080620080153.GC7369@leksak.fem-net>
Stephan Beyer schrieb:
> Looks like *portable* shell programming is no fun :\
> On Fri, Jun 20, 2008 at 09:16:43AM +0200, Johannes Sixt wrote:
>> others write the file name in front of the count,
>
> I did not really change anything that's related to the count, btw.
You changed:
- count=$(grep -c '^[^#]' < "$DONE")
+ count="$(grep -c '^[^#]' "$DONE")"
It turns out that GNU grep and AIX 4.3's grep don't write the file name if
only one name was given. Nevertheless, by passing the data on stdin we are
on the safe side. And, btw, the outer quotes are not needed in this
assignment.
-- Hannes
^ permalink raw reply
* [q] git-diff --reverse 7def2be1..7def2be1^
From: Ingo Molnar @ 2008-06-20 8:20 UTC (permalink / raw)
To: git
A couple of stupid Git questions (using git-1.5.4.3-2.fc8).
Sometimes i want to see the reverse diff of a particular commit.
If i want to see the normal diff i do:
git-log -1 -p 7def2be1
But generating the reverse diff does not work:
git-log --reverse -1 -p 7def2be1
Because the '--reverse' here is the ordering of the revlist, not the
direction of the patch itself. And that's OK, albeit slightly
unintuitive.
So instead i do:
git-diff --reverse 7def2be1..7def2be1^
I've got two observations / potential suggestions:
1) the SHA1 is duplicated above, is there a way to avoid it? Initially i
tried the obvious extension:
git-diff --reverse 7def2be1..^
But Git didnt recognize that as a valid commit range.
2) is there a way to pass something like --reversediff to git-log?
[ time passes as i read the manpage - the final thing i do when
every other measure fails ;-) ]
Ah, there's "git-log -R" that would achieve this.
The situation still feels a tiny bit inconsistent to me, and that's
why my attempt to figure it out intuitively based on my existing
practices failed:
a) -R is not recognized by git-diff (so i cannot just standardize
myself on -R and have to waste neurons on remembering the
distinction ;-)
b) --reverse has different meaning in git-log and git-diff.
Perhaps one solution would be if -R was recognized by git-diff as the
meaning of --reverse is an ABI. The extension to the sha1 range
specifier would be nice as well, it feels intuitive to me.
Hm?
Ingo
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Junio C Hamano @ 2008-06-20 8:38 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080620082034.GA24913@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> a) -R is not recognized by git-diff (so i cannot just standardize
> myself on -R and have to waste neurons on remembering the
> distinction ;-)
Huh? Have you actually tried "git diff -R"? My copy of git 1.0.0 knows
about it. What year are you still in ;-)?
If you apply the output of
git diff -R HEAD^..HEAD
to your tree, you can revert the tip commit. It is the same as
git diff HEAD..HEAD^
If you want to write a forward diff in an obscure way, you could say
git diff -R HEAD..HEAD^
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Junio C Hamano @ 2008-06-20 8:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <7v7icko61g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ingo Molnar <mingo@elte.hu> writes:
>
>> a) -R is not recognized by git-diff (so i cannot just standardize
>> myself on -R and have to waste neurons on remembering the
>> distinction ;-)
>
> Huh? Have you actually tried "git diff -R"? My copy of git 1.0.0 knows
> about it. What year are you still in ;-)?
>
> If you apply the output of
>
> git diff -R HEAD^..HEAD
>
> to your tree, you can revert the tip commit. It is the same as
>
> git diff HEAD..HEAD^
>
> If you want to write a forward diff in an obscure way, you could say
>
> git diff -R HEAD..HEAD^
By the way, not linking --reverse (traverse the history normally and then
show the commits in the reverse order than usual) to -R (show diff in the
opposite way while showing the change each commit introduces) allows you
to even say "log --reverse -R", which did not come from a conscious
design, but being able to say this _is_ a conscious design:
$ git fetch j6t
$ git log --reverse -p ..j6t/for-junio
When I review a branch somebody else offers me, I may want to view the
commits on them in reverse order (so that they build a bit by bit on top
of my tree), but I _certainly_ do not want to view the patch in reverse!
^ permalink raw reply
* Re: [StGit PATCH 03/14] Write to a stack log when stack is modified
From: Catalin Marinas @ 2008-06-20 9:14 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080619100722.GB14415@diana.vm.bytemark.co.uk>
2008/6/19 Karl Hasselström <kha@treskal.com>:
> On 2008-06-19 10:24:28 +0100, Catalin Marinas wrote:
>
>> 2008/6/18 Karl Hasselström <kha@treskal.com>:
>>
>> > On 2008-06-18 17:16:10 +0100, Catalin Marinas wrote:
>> > > Making the first log entry special gets difficult with log
>> > > pruning (unless you prune the whole log rather than entries
>> > > older than a chosen time or number) since you might have to
>> > > re-create all the chained log entries as the first log's sha1
>> > > will probably change.
>> >
>> > You have to re-create all the commits anyway, since they all are
>> > immutable, and all have a back pointer.
>>
>> Ah, OK. So, at least initially, we should only support the full log
>> pruning.
>
> How do you imagine we'd do anything except a "full" pruning? There are
> grafts and shallow clones, I guess, but both of them have drawbacks.
Recreate the log but we I wouldn't spend time on this.
>> > > The applied patches are chained automatically via HEAD. For
>> > > unapplied patches, we could add the correponding commits as
>> > > parents of the logging commit (starting with the third parent as
>> > > the first two are used for log chaining and applied patches). Do
>> > > we hit any OS limit with the number of arguments?
>> >
>> > Not until long after we hit git limits to the number of parents of
>> > a commit. I believe the octopus merge refuses to create merges
>> > with more than about 25 parents, and we probably shouldn't do more
>> > than that either. We'll have to do a tree of octopuses.
>>
>> For the first log only, we could chain the unapplied patches using
>> commits with 2 parents. We just need to warn people not to stare at
>> the <branch>.stgit directly :-)
>
> We could make chains (or trees) of 16-parent commits -- that'd speed
> it up by a factor of 15. :-)
Yes, good idea.
>> > * Parents: the previous log entry; branch head; something that
>> > (recusively) points to all unapplied commits, if necessary.
>>
>> As you pointed below, "branch head" should probably be the "stack
>> top". We don't need to track the "branch head" if different, just
>> need to fix up the error and add the patches to the stack. And,
>> anyway, if one modifies the HEAD using git directly, the log will
>> still point to the top of the stack.
>
> If we ever want to be able to undo "stg repair", we have to be able to
> represent an inconsistent state where head != top.
I wouldn't bother with this feature. Why would one want to break the
stack again after repairing? If they merge patches and git commits,
they either repair the stack or commit all the patches and continue
with using Git only.
>> The third head would only be needed for the first log entry or when
>> we use pick --unapplied (in the latter, it only points to the
>> unapplied commit).
>
> Actually, except for the previous log entry, all the parents are just
> there for gc's benefit. So we could just put all of them in the same
> bucket -- branch head, stack top, and unapplied patches.
>
> ( By "bucket" I mean something like: if there are just a few of them,
> have them as direct parents of the log commit; otherwise, refer to
> them using a tree of octopuses. But in any case, just treat them as
> a set of sha1s that we need to have as ancestors but don't otherwise
> care about. )
Yes.
>> > * I'm pretty sure we want the kind of "simplified" log I have in
>> > my proposal. The full log in your proposal is going to look
>> > every bit as ugly as the one in mine.
>>
>> I agree it will look ugly but the simplified log adds an extra
>> overhead on any stgit action. If we don't use stg log -g, a text
>> only log command could show the diff. We can add it afterwards
>> though if it is fast enough.
>
> I'd actually say the opposite: until we have a good visualizer that
> doesn't need the simplified log, we need to have the simplified log.
> If I actually have to look at the diffs in the log, I find gitk
> indispensible.
And what would the simplified log contain if we decide to go with a
new scheme? In your proposal, it points to the tree of main log and
you get the diff of diffs (which also means that the diffs must be
generated for every modification of a patch). Would this be the same?
Again, I worry a bit about the overhead to generate the patch diff for
every push (with refresh I'm OK). It can be optimised as in the stable
branch where we try git-apply followed by a three-way merge (which,
BTW, I'd like added before 0.15). If git-apply succeeds, there is no
need to re-generate the diff.
--
Catalin
^ permalink raw reply
* Re: git svn --use-log-author misbehavior?
From: Fredrik Skolmli @ 2008-06-20 8:56 UTC (permalink / raw)
To: Mircea Bardac; +Cc: Git Mailing List
In-Reply-To: <485AF10B.7060202@mircea.bardac.net>
On Fri, Jun 20, 2008 at 12:51:39AM +0100, Mircea Bardac wrote:
> Hi,
>
> According to the documentation, this parameter (--use-log-author) should
> use the author from the From/Signed-off-by line. Unfortunately, I
> found this to be working only on the first git svn clone. Later rebasing
> made the commits use the old username@uuid format.
>
> I am assuming the option is not being preserved in the Git repository
> metadata and it is only used on cloning/init. Is this the intended
> behavior?
Doesn't look like it. When you're using --add-author-from on dcommit, git-svn
doesn't seem to know that it should look after "From:" in the commit, thus
not setting the author correctly. The following oneliner should solve the
case. Please let me know if it works as well for you as it did for me.
Signed-off-by: Fredrik Skolmli <fredrik@frsk.net>
---
git-svn.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a54979d..8f77b91 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -432,6 +432,9 @@ sub cmd_dcommit {
"without --no-rebase may be required."
}
while (1) {
+ if ($Git::SVN::_add_author_from) {
+ $Git::SVN::_use_log_author = 1;
+ }
my $d = shift @$linear_refs or last;
unless (defined $last_rev) {
(undef, $last_rev, undef) = cmt_metadata("$d~1");
--
1.5.6.6.gd3e97
--
Regards,
Fredrik Skolmli
^ permalink raw reply related
* Importing non-version controlled bits and pieces to Git
From: Peter Karlsson @ 2008-06-20 9:42 UTC (permalink / raw)
To: Git Mailing List
Hi!
I am looking at moving a project that has not been version-controlled
in the regular sense into Git. I have found it to currently consist of
40 directories with copies of the set of files in various shapes.
I have reconstructed something that looks like a probable revision tree
for these 40 directories, and I want to put this into Git so that I can
examine what changes have been made where, and merge the various
versions back together so that there can be one version with all the
various fixes.
I was looking for something that could do this for me, but found nothing
mentioned on the Wiki, and my Google karma was not good enough to find
something, either. The closest thing I know of is the import-tars.perl
script that I have used before, when importing something with a
(near-)linear history, but this is too far off from a linear history to
try to tar up the directories and import that way, I believe.
Has anyone written such an import tool, or should I start hacking?
--
\\// Peter, digital archeologist
^ permalink raw reply
* Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
From: Pierre Habouzit @ 2008-06-20 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vhcbpuvfb.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4122 bytes --]
On jeu, jun 19, 2008 at 06:33:12 +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Thu, Jun 19, 2008 at 03:11:10PM +0000, Jeff King wrote:
> >> On Thu, Jun 19, 2008 at 03:52:00PM +0200, Pierre Habouzit wrote:
> >> > > - there is a possible danger with "git push -f", in that you force
> >> > > both rejected branches as well as stale branches. Junio and I
> >> > Well afaict this is a separate issue, as we're (with such a patch)
> >> > only changing what gets printed on the console, not the internal
> >> > behavior. So solving this second issue should not really be a
> >> > precondition to the inclusion of such a patch.
> >>
> >> It is a separate issue, but it is exacerbated by hiding stale refs.
> >> Imagine:
> >>
> >> $ git push
> >> To /path/to/repo
> >> ! [rejected] master -> master (non-fast forward)
> >>
> >> $ git push -f
> >> To /path/to/repo
> >> + 0abfa88...c1ed93b master -> master (forced update)
> >> + 0329485...3498576 stale_branch -> stale_branch (forced update)
> >>
> >> I think that is a nasty surprise to spring on an unsuspecting user.
> >> Another solution might be "-f" not pushing rewound branches, but then we
> >> need a way to specify "no, really, push this rewound branch". Perhaps
> >> "-f -f"?
> >
> > Well then we could keep the [stalled] lines for now until this issue
> > is resolved then, despite what the people at the beginning of the other
> > thread complained about. My real issue is that I have my shell
> > configured so that my prompt becomes inverted if the last command
> > failed. So do many people I know, and well, git push for stalled
> > references should just not generate an error. _this_ is my sole concern
> > :)
>
> There are two cases the push does not fast forward. The case where you
> are truly behind (aka "stale") and you and the pushed-to repository have
> diverged history. Reporting success when you did not push due to the
> latter is unacceptable. I personally rely on the fast-forward safety in
> my push-out scripts, but I do not think it is just me. The exit status from
> commands are designed to be used that way.
Sure, but when you use `git push` or `git push <remote>` forms of the
commands, you usually don't mean to push "everything", but rather
"everything that has new stuff". Stalled branches that you didn't
fast-forwarded yet should not generate issues IMHO.
Of course, for git-push <remote> <branch> this could be different.
> The thing is, the user asked to push certain refs, and some did not get
> updated. The user has the right to expect a failure indication from the
> command. If you choose to _ignore_ the failure, that is _your_ choice,
> like:
>
> $ git push || :
I don't want to ignore push failures. It's just that in my
workflow[0], stalled branches are _not_ a problem, whereas non
fast-forward are. I cannot rely on the exit status, to know if all was
fine, and that's annoying, really (Not a _major_ PITA, but an annoyance
nonetheless).
[0] we have quite a few branches for our different releases and
production branches. I rarely do fixes there, but still have
tracking branches for those, and when I'm pushing my master, I get
errors each time another coworker pushed a production fix, until I
git stash, git checkout <stalled-branch>, git merge
<origin/stalled-branch>, git checkout back, git stash apply
*PHEEEW* all that for git push[1] ? No thanks.
[1] I know I can `git update-ref refs/heads/<stalled-branch> $(git
rev-parse origin/<stalled-branch>)` to fix that in one step but:
- it's plumbing ;
- if you forget the refs/heads it don't DWIM ;
- it's easy to mess things up with such use patterns
(sub-problem of `it's plumbing`).
So I don't really think this is the proper answer to my problem.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Ingo Molnar @ 2008-06-20 10:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3an8o5mm.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> By the way, not linking --reverse (traverse the history normally and
> then show the commits in the reverse order than usual) to -R (show
> diff in the opposite way while showing the change each commit
> introduces) allows you to even say "log --reverse -R", which did not
> come from a conscious design, but being able to say this _is_ a
> conscious design:
>
> $ git fetch j6t
> $ git log --reverse -p ..j6t/for-junio
>
> When I review a branch somebody else offers me, I may want to view the
> commits on them in reverse order (so that they build a bit by bit on
> top of my tree), but I _certainly_ do not want to view the patch in
> reverse!
yes, i too do that occasionally (and some of my export/import scripts
rely on it in fact), and i was not suggesting to change any existing
functionality anyway.
Ingo
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Ingo Molnar @ 2008-06-20 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7icko61g.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > a) -R is not recognized by git-diff (so i cannot just standardize
> > myself on -R and have to waste neurons on remembering the
> > distinction ;-)
>
> Huh? Have you actually tried "git diff -R"? My copy of git 1.0.0
> knows about it. What year are you still in ;-)?
yeah, i tried it and somehow messed up so this is a red herring - i'll
just use -R from now on :-)
the HEAD..^ format suggestion still stands, to express the range from
HEAD to HEAD-1.
Ingo
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Jakub Narebski @ 2008-06-20 10:05 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080620082034.GA24913@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> I've got two observations / potential suggestions:
>
> 1) the SHA1 is duplicated above, is there a way to avoid it? Initially i
> tried the obvious extension:
>
> git-diff --reverse 7def2be1..^
>
> But Git didnt recognize that as a valid commit range.
There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
documented anywhere, though), so you could have used
git diff 7def2be1^!
> [ time passes as i read the manpage - the final thing i do when
> every other measure fails ;-) ]
>
> Ah, there's "git-log -R" that would achieve this.
I think you should have done this first...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git svn --use-log-author misbehavior?
From: Mircea Bardac @ 2008-06-20 10:13 UTC (permalink / raw)
To: Git Mailing List; +Cc: Fredrik Skolmli
In-Reply-To: <20080620085618.GA27940@frsk.net>
Fredrik Skolmli wrote:
> On Fri, Jun 20, 2008 at 12:51:39AM +0100, Mircea Bardac wrote:
>> Hi,
>>
>> According to the documentation, this parameter (--use-log-author) should
>> use the author from the From/Signed-off-by line. Unfortunately, I
>> found this to be working only on the first git svn clone. Later rebasing
>> made the commits use the old username@uuid format.
>>
>> I am assuming the option is not being preserved in the Git repository
>> metadata and it is only used on cloning/init. Is this the intended
>> behavior?
>
> Doesn't look like it. When you're using --add-author-from on dcommit, git-svn
> doesn't seem to know that it should look after "From:" in the commit, thus
> not setting the author correctly. The following oneliner should solve the
> case. Please let me know if it works as well for you as it did for me.
I haven't tested this yet but I have a feeling this is not my case, or I
might not be fully understanding the implications of "--add-author-from"
on the functionality of "--use-log-author". Technically, they should be
independent and the options should not depend on each other:
* --use-log-author only applies to getting info from the commits
* --add-author-from only applies to putting info in the commits
From the documentation, these 2 options can only be used with git svn
init/clone so they should somehow be saved for future use. Maybe this
doesn't happen.
My Git commits (not dcommits) already have "Signed-off-by:" at the end,
added with "git commit -s". When I do a "git svn dcommit" they get
pushed to SVN and the entire commit is rewritten. I have
--add-author-from added on git clone, but nothing else is being added to
the commit except the git-svn-id - from my point of view, according to
the documentation, this is the correct behavior (since there already is
a Signed-off-by line)
The problem is that, after the dcommit, when *viewing* the latest
commits in the git-svn repository, even though they have
"Signed-off-by:" in them, I see them not respecting the --use-log-author
option, showing up as username@uuid. What I assume is that, after a
dcommit (and everything being done on dcommit) the --use-log-author
option is ignored.
Looking over the code, I see that make_log_entry (which is responsible
for getting the correct format for the user/e-mail out of the commit
message) is only being called in do_fetch and find_parent_branch. I am
not sure if these are somehow called by cmd_dcommit.
Many thanks.
--
Mircea
http://mircea.bardac.net
^ permalink raw reply
* Re: git svn --use-log-author misbehavior?
From: Stephen R. van den Berg @ 2008-06-20 10:48 UTC (permalink / raw)
To: Mircea Bardac; +Cc: Git Mailing List, Fredrik Skolmli
In-Reply-To: <485B82BD.2000404@mircea.bardac.net>
Mircea Bardac wrote:
>I haven't tested this yet but I have a feeling this is not my case, or I
>might not be fully understanding the implications of "--add-author-from"
>on the functionality of "--use-log-author". Technically, they should be
>independent and the options should not depend on each other:
>* --use-log-author only applies to getting info from the commits
>* --add-author-from only applies to putting info in the commits
They are independent.
>From the documentation, these 2 options can only be used with git svn
>init/clone so they should somehow be saved for future use. Maybe this
>doesn't happen.
At least --use-log-author can be used on git svn fetch (and possibly
other subcommands) as well.
And no, it currently is not being saved.
--
Sincerely,
Stephen R. van den Berg.
Confidence is that feeling you have before you understand the situation.
^ permalink raw reply
* git svn: how to recover from checksum mismatch?
From: Alexander Gladysh @ 2008-06-20 10:56 UTC (permalink / raw)
To: git
Hi, list!
Today I've upgraded to git 1.5.6 from 1.5.5.something (probably 1).
When I've run git svn rebase on my repo, it complained about "checksum
mismatch: trunk/path/myfile HASH".
BTW, Before that failing commit there were one more (successful) with
some strange complains about whitespace errors:
warning: CRLF will be replaced by LF in
/var/folders/8u/8uiW+GhrGka2OlIHiT1fsU+++TI/-Tmp-/hoizGwiM2P
I'm on OS X 10.5.3 and my repo is not in /var/folders tree (trailing
part of path is different for each file).
The same errors are on my second copy of that repo (independent git
repo made by the same git svn init as first).
When I run git svn init + git svn fetch on a fresh folder, it bails
out with checksum error after a few first commits (on 20th commit
actually) while giving the same odd CRLF warnings.
When I run git svn rebase on another machine (Ubuntu Hardy, git
1.5.5.1), it run smoothly without errors, so this, probably, is not an
SVN repo corruption.
I have reverted back to git 1.5.5.1, but I still get that checksum
error. I'm fetching a fresh git svn init+fetch from svn, but it takes
a few hours, and I have to do it twice (for each of my two repos). Any
advice on how can I recover less painlessly?
Thank you in advance,
Alexander.
^ permalink raw reply
* Re: git svn --use-log-author misbehavior?
From: Fredrik Skolmli @ 2008-06-20 10:57 UTC (permalink / raw)
To: Mircea Bardac; +Cc: Git Mailing List
In-Reply-To: <485B82BD.2000404@mircea.bardac.net>
On Fri, Jun 20, 2008 at 11:13:17AM +0100, Mircea Bardac wrote:
> I haven't tested this yet but I have a feeling this is not my case, or I
> might not be fully understanding the implications of "--add-author-from"
> on the functionality of "--use-log-author". Technically, they should be
> independent and the options should not depend on each other:
> * --use-log-author only applies to getting info from the commits
> * --add-author-from only applies to putting info in the commits
>
> From the documentation, these 2 options can only be used with git svn
> init/clone so they should somehow be saved for future use. Maybe this
> doesn't happen.
>
> My Git commits (not dcommits) already have "Signed-off-by:" at the end,
> added with "git commit -s". When I do a "git svn dcommit" they get
> pushed to SVN and the entire commit is rewritten. I have
> --add-author-from added on git clone, but nothing else is being added to
> the commit except the git-svn-id - from my point of view, according to
> the documentation, this is the correct behavior (since there already is
> a Signed-off-by line)
Did you mean "git svn clone" here, not "git clone"? And if --use-log-author
is to be used to get retrieve info from the commits, it should be used
instead of --add-author-from when doing a clone. (Which as far as I can see
behaves correctly.)
However, looks like I might have misunderstood your problem, and possibly
found a bug in the process. I'll look closer into it. :-)
--
Regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Matthieu Moy @ 2008-06-20 11:30 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080620082034.GA24913@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> 1) the SHA1 is duplicated above, is there a way to avoid it? Initially i
> tried the obvious extension:
>
> git-diff --reverse 7def2be1..^
>
> But Git didnt recognize that as a valid commit range.
Git may not know how to do it, but since you can omit the .. here,
your shell knows:
git diff whatever{,^}
(BTW, git-foo is being obsoleted in favor of "git foo")
--
Matthieu
^ permalink raw reply
* git svn --add-author-from implies --use-log-author
From: Fredrik Skolmli @ 2008-06-20 11:31 UTC (permalink / raw)
To: git
Hi,
when running git svn dcommit --add-author-from on a git-svn repository,
--use-log-author is not implied by itself. This causes the rewritten history
to not show the author in the way most users would expect it to be, "Name
<email@domain.tld>", but instead "<user@uuid>".
Instead of forcing people to write "svn dcommit --add-author-from
--use-log-author", is it a bad move to imply the last argument, making the
history look more user-friendly to start with?
Any thoughts?
--
Regards,
Fredrik Skolmli
^ permalink raw reply
* Re: git svn: how to recover from checksum mismatch?
From: Alexander Gladysh @ 2008-06-20 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <c6c947f60806200356s285ac4s7a4affc108c7f311@mail.gmail.com>
> I have reverted back to git 1.5.5.1, but I still get that checksum
> error. I'm fetching a fresh git svn init+fetch from svn, but it takes
> a few hours, and I have to do it twice (for each of my two repos). Any
> advice on how can I recover less painlessly?
That is more painlessly of course, not less, sorry :)
^ 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