* Re: bad git pull
From: Nicolas Pitre @ 2005-12-17 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4q582htm.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > That said, I think a lot of newbies might want to have a "git undo", and
> > not because of any BK history. Even if it just ends up being nothing but
> > shorthand for "git reset --hard ORIG_HEAD".
>
> I agree to this in principle, but I am afraid "git undo" is too
> generic and fuzzy a term. Things you might possibly want to
> undo depends on what you did last [*1*]. In most undoable
> cases, "reset --hard" is almost right but most likely would
> result in information loss.
One observation is that ORIG_HEAD should probably be named PREV_HEAD in
such context to make it more obvious what it is about.
Nicolas
^ permalink raw reply
* [PATCH] diff: --abbrev option
From: Junio C Hamano @ 2005-12-17 9:41 UTC (permalink / raw)
To: git
When I show transcripts to explain how something works, I often
find myself hand-editing the diff-raw output to shorten various
object names in the output.
This adds --abbrev option to the diff family, which shortens
diff-raw output and diff-tree commit id headers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Earlier I announced that I have this toy in proposed updates
without actually showing the code, so here it is. I have
added code to find unique abbreviation as well. It is
primarily useful to quote things in e-mail, like this:
$ git-rev-parse master | git-diff-tree --pretty -r --abbrev --stdin
diff-tree 01385e2... (from 6922471...)
Author: Junio C Hamano <junkio@cox.net>
Date: Fri Dec 16 23:12:33 2005 -0800
Comment fixes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100755 100755 0266f46... b0e54ed... M git-branch.sh
:100755 100755 f241d4b... 36308d2... M git-checkout.sh
Documentation/diff-options.txt | 7 +++++
diff-tree.c | 40 +++++++++++++++++-----------
diff.c | 57 ++++++++++++++++++++++++++++++++++++----
diff.h | 9 ++++++
sha1_name.c | 3 ++
5 files changed, 93 insertions(+), 23 deletions(-)
ea2d93b12d2deae007311d0898616b4bb2f299d2
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 6b496ed..3d1175e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -18,6 +18,13 @@
object name of pre- and post-image blob on the "index"
line when generating a patch format output.
+--abbrev::
+ Instead of showing the full 40-byte hexadecimal object
+ name in diff-raw format output and diff-tree header
+ lines, show only handful prefix. This is independent of
+ --full-index option above, which controls the diff-patch
+ output format.
+
-B::
Break complete rewrite changes into pairs of delete and create.
diff --git a/diff-tree.c b/diff-tree.c
index d56d921..efa2b94 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -14,11 +14,6 @@ static enum cmit_fmt commit_format = CMI
static struct diff_options diff_options;
-static void call_diff_setup_done(void)
-{
- diff_setup_done(&diff_options);
-}
-
static int call_diff_flush(void)
{
diffcore_std(&diff_options);
@@ -43,7 +38,6 @@ static int diff_tree_sha1_top(const unsi
{
int ret;
- call_diff_setup_done();
ret = diff_tree_sha1(old, new, base, &diff_options);
call_diff_flush();
return ret;
@@ -55,7 +49,6 @@ static int diff_root_tree(const unsigned
void *tree;
struct tree_desc empty, real;
- call_diff_setup_done();
tree = read_object_with_reference(new, "tree", &real.size, NULL);
if (!tree)
die("unable to read root tree (%s)", sha1_to_hex(new));
@@ -69,18 +62,29 @@ static int diff_root_tree(const unsigned
return retval;
}
-static const char *generate_header(const char *commit, const char *parent, const char *msg)
+static const char *generate_header(const unsigned char *commit_sha1,
+ const unsigned char *parent_sha1,
+ const char *msg)
{
static char this_header[16384];
int offset;
unsigned long len;
+ int abbrev = diff_options.abbrev;
if (!verbose_header)
- return commit;
+ return sha1_to_hex(commit_sha1);
len = strlen(msg);
- offset = sprintf(this_header, "%s%s (from %s)\n", header_prefix, commit, parent);
- offset += pretty_print_commit(commit_format, msg, len, this_header + offset, sizeof(this_header) - offset);
+
+ offset = sprintf(this_header, "%s%s ",
+ header_prefix,
+ diff_unique_abbrev(commit_sha1, abbrev));
+ offset += sprintf(this_header + offset, "(from %s)\n",
+ parent_sha1 ?
+ diff_unique_abbrev(parent_sha1, abbrev) : "root");
+ offset += pretty_print_commit(commit_format, msg, len,
+ this_header + offset,
+ sizeof(this_header) - offset);
return this_header;
}
@@ -99,18 +103,18 @@ static int diff_tree_commit(const unsign
/* Root commit? */
if (show_root_diff && !commit->parents) {
- header = generate_header(name, "root", commit->buffer);
+ header = generate_header(sha1, NULL, commit->buffer);
diff_root_tree(commit_sha1, "");
}
/* More than one parent? */
if (ignore_merges && commit->parents && commit->parents->next)
- return 0;
+ return 0;
for (parents = commit->parents; parents; parents = parents->next) {
struct commit *parent = parents->item;
- header = generate_header(name,
- sha1_to_hex(parent->object.sha1),
+ header = generate_header(sha1,
+ parent->object.sha1,
commit->buffer);
diff_tree_sha1_top(parent->object.sha1, commit_sha1, "");
if (!header && verbose_header) {
@@ -129,6 +133,7 @@ static int diff_tree_stdin(char *line)
int len = strlen(line);
unsigned char commit[20], parent[20];
static char this_header[1000];
+ int abbrev = diff_options.abbrev;
if (!len || line[len-1] != '\n')
return -1;
@@ -138,7 +143,9 @@ static int diff_tree_stdin(char *line)
if (isspace(line[40]) && !get_sha1_hex(line+41, parent)) {
line[40] = 0;
line[81] = 0;
- sprintf(this_header, "%s (from %s)\n", line, line+41);
+ sprintf(this_header, "%s (from %s)\n",
+ diff_unique_abbrev(commit, abbrev),
+ diff_unique_abbrev(parent, abbrev));
header = this_header;
return diff_tree_sha1_top(parent, commit, "");
}
@@ -239,6 +246,7 @@ int main(int argc, const char **argv)
diff_options.recursive = 1;
diff_tree_setup_paths(get_pathspec(prefix, argv));
+ diff_setup_done(&diff_options);
switch (nr_sha1) {
case 0:
diff --git a/diff.c b/diff.c
index 2e0797b..c815918 100644
--- a/diff.c
+++ b/diff.c
@@ -723,11 +723,13 @@ static void run_diff(struct diff_filepai
if (memcmp(one->sha1, two->sha1, 20)) {
char one_sha1[41];
- const char *index_fmt = o->full_index ? "index %s..%s" : "index %.7s..%.7s";
+ int abbrev = o->full_index ? 40 : DIFF_DEFAULT_INDEX_ABBREV;
memcpy(one_sha1, sha1_to_hex(one->sha1), 41);
len += snprintf(msg + len, sizeof(msg) - len,
- index_fmt, one_sha1, sha1_to_hex(two->sha1));
+ "index %.*s..%.*s",
+ abbrev, one_sha1, abbrev,
+ sha1_to_hex(two->sha1));
if (one->mode == two->mode)
len += snprintf(msg + len, sizeof(msg) - len,
" %06o", one->mode);
@@ -791,6 +793,8 @@ int diff_setup_done(struct diff_options
}
if (options->setup & DIFF_SETUP_USE_SIZE_CACHE)
use_size_cache = 1;
+ if (options->abbrev <= 0 || 40 < options->abbrev)
+ options->abbrev = 40; /* full */
return 0;
}
@@ -841,6 +845,10 @@ int diff_opt_parse(struct diff_options *
}
else if (!strcmp(arg, "--find-copies-harder"))
options->find_copies_harder = 1;
+ else if (!strcmp(arg, "--abbrev"))
+ options->abbrev = DIFF_DEFAULT_ABBREV;
+ else if (!strncmp(arg, "--abbrev=", 9))
+ options->abbrev = strtoul(arg + 9, NULL, 10);
else
return 0;
return 1;
@@ -947,14 +955,49 @@ void diff_free_filepair(struct diff_file
free(p);
}
+/* This is different from find_unique_abbrev() in that
+ * it needs to deal with 0{40} SHA1.
+ */
+const char *diff_unique_abbrev(const unsigned char *sha1, int len)
+{
+ int abblen;
+ const char *abbrev;
+ if (len == 40)
+ return sha1_to_hex(sha1);
+
+ abbrev = find_unique_abbrev(sha1, len);
+ if (!abbrev) {
+ if (!memcmp(sha1, null_sha1, 20)) {
+ char *buf = sha1_to_hex(null_sha1);
+ if (len < 37)
+ strcpy(buf + len, "...");
+ return buf;
+ }
+ else
+ return sha1_to_hex(sha1);
+ }
+ abblen = strlen(abbrev);
+ if (abblen < 37) {
+ static char hex[41];
+ if (len < abblen && abblen <= len + 2)
+ sprintf(hex, "%s%.*s", abbrev, len+3-abblen, "..");
+ else
+ sprintf(hex, "%s...", abbrev);
+ return hex;
+ }
+ return sha1_to_hex(sha1);
+}
+
static void diff_flush_raw(struct diff_filepair *p,
int line_termination,
int inter_name_termination,
- int output_format)
+ struct diff_options *options)
{
int two_paths;
char status[10];
+ int abbrev = options->abbrev;
const char *path_one, *path_two;
+ int output_format = options->output_format;
path_one = p->one->path;
path_two = p->two->path;
@@ -985,8 +1028,10 @@ static void diff_flush_raw(struct diff_f
}
if (output_format != DIFF_FORMAT_NAME_STATUS) {
printf(":%06o %06o %s ",
- p->one->mode, p->two->mode, sha1_to_hex(p->one->sha1));
- printf("%s ", sha1_to_hex(p->two->sha1));
+ p->one->mode, p->two->mode,
+ diff_unique_abbrev(p->one->sha1, abbrev));
+ printf("%s ",
+ diff_unique_abbrev(p->two->sha1, abbrev));
}
printf("%s%c%s", status, inter_name_termination, path_one);
if (two_paths)
@@ -1194,7 +1239,7 @@ void diff_flush(struct diff_options *opt
case DIFF_FORMAT_NAME_STATUS:
diff_flush_raw(p, line_termination,
inter_name_termination,
- diff_output_format);
+ options);
break;
case DIFF_FORMAT_NAME:
diff_flush_name(p,
diff --git a/diff.h b/diff.h
index 32b4780..c3486ff 100644
--- a/diff.h
+++ b/diff.h
@@ -44,6 +44,7 @@ struct diff_options {
int reverse_diff;
int rename_limit;
int setup;
+ int abbrev;
change_fn_t change;
add_remove_fn_t add_remove;
@@ -87,6 +88,9 @@ extern int diff_setup_done(struct diff_o
#define DIFF_PICKAXE_ALL 1
+#define DIFF_DEFAULT_INDEX_ABBREV 7 /* hex digits */
+#define DIFF_DEFAULT_ABBREV 7 /* hex digits */
+
extern void diffcore_std(struct diff_options *);
extern void diffcore_std_no_resolve(struct diff_options *);
@@ -98,7 +102,8 @@ extern void diffcore_std_no_resolve(stru
" -u synonym for -p.\n" \
" --name-only show only names of changed files.\n" \
" --name-status show names and status of changed files.\n" \
-" --full-index show full object name on index ines.\n" \
+" --full-index show full object name on index lines.\n" \
+" --abbrev abbreviate object names in diff-tree header and diff-raw.\n" \
" -R swap input file pairs.\n" \
" -B detect complete rewrites.\n" \
" -M detect renames.\n" \
@@ -137,4 +142,6 @@ extern void diff_flush(struct diff_optio
#define DIFF_STATUS_FILTER_AON '*'
#define DIFF_STATUS_FILTER_BROKEN 'B'
+extern const char *diff_unique_abbrev(const unsigned char *, int);
+
#endif /* DIFF_H */
diff --git a/sha1_name.c b/sha1_name.c
index bf8f0f0..875e2f8 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -188,7 +188,10 @@ const char *find_unique_abbrev(const uns
{
int status;
static char hex[41];
+
memcpy(hex, sha1_to_hex(sha1), 40);
+ if (len == 40)
+ return hex;
while (len < 40) {
unsigned char sha1_ret[20];
status = get_short_sha1(hex, len, sha1_ret, 1);
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Remove misguided branch disambiguation.
From: Junio C Hamano @ 2005-12-17 9:37 UTC (permalink / raw)
To: git
This removes the misguided attempt to refuse processing a branch
name xyzzy and insist it to be given as either heads/xyzzy or
tags/xyzzy when a tag xyzzy exists. There was no reason to do
so --- the search order was predictable and well defined, so if
the user says xyzzy we should have taken the tag xyzzy in such a
case without complaining.
This incidentally fixes another subtle bug related to this. If
such a duplicate branch/tag name happened to be a unique valid
prefix of an existing commit object name (say, "beef"), we did
not take the tag "beef" but after complaining used the commit
object whose name started with beef.
Another problem this fixes while introducing some confusion is
that there is no longer a reason to forbid a branch name HEAD
anymore. In other words, now "git pull . ref1:HEAD" would work
as expected, once we revert "We do not like HEAD branch" patch.
It creates "HEAD" branch under ${GIT_DIR-.git}/refs/heads (or
fast-forwards if already exists) using the tip of ref1 branch
from the current repository, and merges it into the current
branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_name.c | 33 +++------------------------------
1 files changed, 3 insertions(+), 30 deletions(-)
a012e1b2b5218729e148befd0705bd52962ac272
diff --git a/sha1_name.c b/sha1_name.c
index bf8f0f0..49e2cc3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -238,7 +238,6 @@ static int get_sha1_basic(const char *st
NULL
};
const char **p;
- int found = 0;
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
@@ -249,36 +248,10 @@ static int get_sha1_basic(const char *st
for (p = prefix; *p; p++) {
char *pathname = git_path("%s/%.*s", *p, len, str);
-
- if (!read_ref(pathname, sha1)) {
- /* Must be unique; i.e. when heads/foo and
- * tags/foo are both present, reject "foo".
- */
- if (1 < found++)
- return -1;
- }
-
- /* We want to allow .git/description file and
- * "description" branch to exist at the same time.
- * "git-rev-parse description" should silently skip
- * .git/description file as a candidate for
- * get_sha1(). However, having garbage file anywhere
- * under refs/ is not OK, and we would not have caught
- * ambiguous heads and tags with the above test.
- */
- else if (**p && !access(pathname, F_OK)) {
- /* Garbage exists under .git/refs */
- return error("garbage ref found '%s'", pathname);
- }
- }
- switch (found) {
- case 0:
- return -1;
- case 1:
- return 0;
- default:
- return error("ambiguous refname '%.*s'", len, str);
+ if (!read_ref(pathname, sha1))
+ return 0;
}
+ return -1;
}
static int get_sha1_1(const char *name, int len, unsigned char *sha1);
--
0.99.9.GIT
^ permalink raw reply related
* What's in git.git tonight
From: Junio C Hamano @ 2005-12-17 9:37 UTC (permalink / raw)
To: git
Since 0.99.9n, there have been a couple of fixes and some
documentation updates. One notable is that we do not allow '?',
'*' and '[' in ref names anymore --- this was done after the
list discussion with Pasky and friends.
Another notable is "We do not like HEAD branch" patch, but I've
been thinking seriously about reverting it and replace its
effect by also reverting the misguided attempt to disambiguate
branch names and tag names. This patch with a commit message
will follow in a separate message; it currently lives in the
proposed updates branch. One positive effect this change brings
is that it fixes a corner case bug/confusion Johannes mentioned
the other day while diagnosing the trouble Len had with his
repository (I do not think the problem has anything to do with
Len's trouble, though). If you have a branch called "dead", and
you also have a tag called "dead", and if your repository has
only one object whose name begins with "dead"
(e.g. "deadbeef1234..."), "git rev-parse --verify dead" would
pick up the "deadbeef1234..." object, not "dead" tag nor "dead"
head. When no such object exists, "git rev-parse --verify dead"
fails, saying "dead" is ambiguous between heads and tags. This
is just confused, and "reverting the misguided disambiguation"
change will make it pick up the "dead" tag in either case. Most
likely I'll have it in "master" after further testing over the
weekend.
One important patch waiting in the proposed updates is to give
an option to git-fetch-pack to keep the downloaded pack without
unpacking it; this was primarily done to help Cogito, but I
haven't heard back about it from Pasky yet. The primary
difference between this and the clone-pack change that is
already in the master branch, from the user's point of view, is
that git-fetch-pack can be efficiently used in an already
populated repository [*1*]. Imagine cloning "master" branch
from linux-2.6 repository of Linus, and then fetching ALL branch
from libata-dev repository of Jeff --- the difference is large
enough that you would want to keep the downloaded stuff packed,
while you do want to take advantage of the fact that you already
have objects from Linus. Currently it saves exploding about a
~800K pack with 1100 objects in it. Although I mentioned we are
supposed to be in deep feature freeze, I feel it is worth to
have this one in 1.0.
[Footnote]
*1* Theoretically we could deprecate git-clone-pack and use
git-fetch-pack exclusively, if we are willing to create refs
matching what the remote has in the wrapper script git-clone.
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Junio C Hamano @ 2005-12-17 9:36 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, git
In-Reply-To: <e5bfff550512170044v59f96262ica6511e981889ea9@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Using
>
> git-clone http://digilander.libero.it/mcostalba/qgit.git qgit_test
>
> does not work (never did). Peraphs it's time I dig a little bit deeper.
Do you keep qgit.git/info/refs, qgit.git/objects/info/packs, and
possibly qgit.git/objects/info/alternates up-to-date under
http://digilander.libero.it/mcostalba/? Your server seems to
give friendly "no such page" instead of usual 404 not found for
nonexisting paths, which means that you would probably need to
have an empty info/alternates file there, and if you do not have
packs then empty info/packs files as well.
Also I suspect once you start packing your repository the
downloaders would have a hard time --- instead of getting "not
found" as a cue to switch to fetching packs they would get the
"friendly page" and mistakenly think the loose object stored in
your repository is corrupt.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-17 9:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512162342010.3698@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> That said, I think a lot of newbies might want to have a "git undo", and
> not because of any BK history. Even if it just ends up being nothing but
> shorthand for "git reset --hard ORIG_HEAD".
I agree to this in principle, but I am afraid "git undo" is too
generic and fuzzy a term. Things you might possibly want to
undo depends on what you did last [*1*]. In most undoable
cases, "reset --hard" is almost right but most likely would
result in information loss.
If we want to really newbie-proof the "undo" command, I think
the hard ones are not the ones that can be approximated with
reset ORIG_HEAD, but other "No way to undo" ones and "Nothing to
undo" ones.
Earlier on the list I gave an overview on merge for an unnamed
person with only an e-mail address, and one thing struck me as
quite hard to explain was that there are two kinds of "merge
failures" --- ones that did not even start the merge and ones
that failed in the middle due to conflicts. Somebody totally
new to git, after seeing "git pull" to fail in the first kind,
would get scared and type "git undo". We could prevent doing
damage by making sure we remove ORIG_HEAD in "Nothing to undo"
situations, but if we say "Nothing to undo" when the user types
"git undo" in such a situation, we will surely hear "what do you
mean? the command said failed to pull and I wanted to recover
from that!".
It also is not clear if it is wise to clear ORIG_HEAD for "No
way to undo" ones. Doing so would rob useful undo information
from people who know git and expect "No way to undo" ones do not
muck with the existing ORIG_HEAD.
Even for the ones that we would do "reset --hard ORIG_HEAD",
many lose information, and "undo" to me implies "undo only what
the last command messed up", which is not what actually happens.
The word "reset" does not have that connotation -- it takes you
to some defined state, which may be close to what you had before
but may not be exactly the same if you had local changes in your
tree. HEAD, ORIG_HEAD, and HEAD^ are such defined states you
can go, and the user gives where he wants to go explicitly.
"undo" does not really say where to go and hides halfway what we
do, without doing exactly what the user would expect (and cannot
be implemented fully unless we are willing to take a snapshot of
working tree, I suspect).
[Appendix]
*1* List of commands that a user might want to undo.
A merge or non-merge commit, cherry-pick, and revert::
reset --hard HEAD^ ;# this can be helped by leaving ORIG_HEAD
# but "--hard" is not quite right;
# your working tree could have been
# dirty at irrelevant paths
A fetch fast-forwarding non-current branch::
No way to undo -- we do not keep the old information.
A merge, that was fast-forward::
reset ORIG_HEAD ;# never "--hard" -- your working tree could
# have been dirty and in this case
# there is no information loss.
A merge attempt, conflicted::
reset --hard ORIG_HEAD
# again, "--hard" is not quite right --
# your working tree could have been
# dirty at irrelevant paths.
A merge attempt, did not even start because index or tree was dirty::
Nothing to undo.
A successful checkout (switch branch)::
No way to undo -- we do not keep the old information.
git-update-index and git-add::
No way to really undo -- we do not keep the old
information. The closest is "git reset" but it reverts
more than the last operation.
rebase::
reset --hard ORIG_HEAD
am/applymbox::
No way to undo -- we do not keep the old information.
;# this can be helped by leaving ORIG_HEAD
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-17 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy82kbiho.fsf@assigned-by-dhcp.cox.net>
On Fri, 16 Dec 2005, Junio C Hamano wrote:
>
> You guys were on BK for how many months, and have been on git
> for how many months now? Do BK-familiarity factor matter, and
> will it continue to matter for how long?
I don't think it is a huge deal, I suspect that people who used BK have a
much easier time with git if only because they already understand the
whole distributed thing and about commits and merges.
That said, I think a lot of newbies might want to have a "git undo", and
not because of any BK history. Even if it just ends up being nothing but
shorthand for "git reset --hard ORIG_HEAD".
Linus
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Junio C Hamano @ 2005-12-17 6:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, git
In-Reply-To: <e5bfff550512161247v4c187cc0gedae8234d454c3b6@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
>> > So perpahs this assumption is broken and works only on my box.
>> >
>> > Can you please send me also the git-ls-remote ./.git output?
>>
>> Attached. Apparently my sort (coreutils 5.2.1) thinks that caret
>> follows period in C locale, so v0.99^{} goes after v0.99.9n^{}. Since
>> there should be a reason for sort in git-ls-remote.sh, I assume it's the
>> script that should be fixed.
>>
>> Not that I would object against qgit being more robust :-)
Somehow I am getting your message without the message your
message is a reply to, but anyway, guessing without having
access to qgit source [*1*], you seem to be running ls-remote
against the local repository, reading its output and deciding if
"xyzzy" is followed immediately by "xyzzy^{}" then it is a tag
otherwise it is a non tag object?
If you are always doing that against the local repository, then
peek-remote would be more efficient, does not sort, and
"xyzzy^{}" comes immediately after "xyzzy", which I do not see
an immediate need of changing.
[Footnote]
*1* Why is that http:// URL does not work is mystery to me which
I do not particularly interested in figuring out myself. Maybe
the site is trying to be too helpful and showing "Oh where do
you want to go" page with status 200 which confuses the h*ck out
of downloaders?
^ permalink raw reply
* Re: [PATCH] Fix git-am --skip
From: Junio C Hamano @ 2005-12-17 6:41 UTC (permalink / raw)
To: Jan Harkes; +Cc: git
In-Reply-To: <20051217060106.GS30531@delft.aura.cs.cmu.edu>
Thanks.
^ permalink raw reply
* [PATCH] Fix git-am --skip
From: Jan Harkes @ 2005-12-17 6:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-am --skip does not unpack the next patch and ends up reapplying the
old patch, believing that it is the new patch in the sequence.
If the old patch applied successfully it will commit it with the
supposedly skipped log message and ends up dropping the following patch.
If the patch did not apply the user is left with the conflict he tried
to skip and has to unpack the next patch in the sequence by hand to get
git-am back on track.
By clearing the resume variable whenever skips bumps the sequence
counter we correctly unpack the next patch. I also added another
resume= in the case a patch file is missing from the sequence to
avoid the same problem when a file in the sequence was removed.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
git-am.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
5cfce3a48e6a6cf08caa5fae990eeeaf08154921
diff --git a/git-am.sh b/git-am.sh
index 1a114bc..731ab1f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -211,6 +211,7 @@ this=`cat "$dotest/next"`
if test "$skip" = t
then
this=`expr "$this" + 1`
+ resume=
fi
if test "$this" -gt "$last"
@@ -225,6 +226,7 @@ do
msgnum=`printf "%0${prec}d" $this`
next=`expr "$this" + 1`
test -f "$dotest/$msgnum" || {
+ resume=
go_next
continue
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: git merge questions
From: Junio C Hamano @ 2005-12-17 3:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Don Zickus, git
In-Reply-To: <Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> just a thought: maybe in this case -- git fails to recognize a rename --
> Pasky's idea would have some merit.
It is not as simple as that. If you look at the output of the
following command, you would understand why.
$ git rev-list ^$(git merge-base test test2) test2 -- \
arch/powerpc/Kconfig arch/ppc64/Kconfig |
git diff-tree --pretty -C -r --stdin --abbrev --name-status \
arch/powerpc/Kconfig arch/ppc64/Kconfig
The transition happened over time with multiple commits.
First ppc64/Kconfig was somewhat stripped of its contents,
starting at this commit:
diff-tree bcdd1ea... (from 5bfc826...)
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon Sep 19 23:13:24 2005 +1000
[PATCH] powerpc: Move arch/ppc*/oprofile/Kconfig to arch/powerpc
These files are identical.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
M arch/ppc64/Kconfig
and after a lot of hard work, powerpc/Kconfig gets
created.
diff-tree 14cf11a... (from e5baa39...)
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Sep 26 16:04:21 2005 +1000
powerpc: Merge enough to start building in arch/powerpc.
This creates the directory structure under arch/powerpc and a bunch
of Kconfig files...
A arch/powerpc/Kconfig
After that both continues to exist for some time, and finally
ppc64/Kconfig gets deleted with this one:
diff-tree 7568cb4... (from c55377e...)
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Nov 14 17:30:17 2005 +1100
powerpc: Move most remaining ppc64 files over to arch/powerpc
Also deletes files in arch/ppc64 that are no longer used now that
we don't compile with ARCH=ppc64 any more.
Signed-off-by: Paul Mackerras <paulus@samba.org>
M arch/powerpc/Kconfig
D arch/ppc64/Kconfig
You cannot record "this is the rename" by attributing that
information to one particular commit. Even looking at the
commit history one by one you cannot really say powerpc/Kconfig
is a rename of ppc64/Kconfig. I suspect that it is not really a
rename --- from reading of the log messages, its original
contents were moved around and scattered over to other Kconfig
files in the tree, or along with other configuration pieces got
consolidated into powerpc/Kconfig, or perhaps both.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-17 2:19 UTC (permalink / raw)
To: Morten Welinder; +Cc: Linus Torvalds, Don Zickus, git
In-Reply-To: <118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
>> - undo the last commit entirely ("hard reset to previous state"):
>>
>> - undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":
>
> It would be outright peachy if Documentation/git-commit.txt and
> Documentation/git-pull.txt mentioned these. That is certainly
> where I would look first to answer the "what if I screwed up?"
> question.
Yup. Maybe one line comment at the bottom of these manual pages
pointing at git-reset manual page (which has nice examples
section) would be good enough?
-- >8 --
[PATCH] Examples of resetting.
Morten Welinder says examples of resetting is really about
recovering from botched commit/pulls. I agree that pointers
from commands that cause a reset to be needed in the first place
would be very helpful.
Also reset examples did not mention "pull/merge" cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index b92cf48..8b91f22 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -66,6 +66,10 @@ OPTIONS
Update specified paths in the index file before committing.
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 0cac563..4ce799b 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -37,6 +37,11 @@ include::merge-options.txt[]
include::merge-strategies.txt[]
+If you tried a merge which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
HOW MERGE WORKS
---------------
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c65ca9a..3a7d385 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -104,6 +104,11 @@ merge the remote `origin` head into the
local `master` branch.
+If you tried a pull which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
SEE ALSO
--------
gitlink:git-fetch[1], gitlink:git-merge[1]
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 0204891..c6a269b 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -111,6 +111,39 @@ remain there.
changes still in the working tree.
------------
+Undo a merge or pull::
++
+------------
+$ git pull <1>
+Trying really trivial in-index merge...
+fatal: Merge requires file-level merging
+Nope.
+...
+Auto-merging nitfol
+CONFLICT (content): Merge conflict in nitfol
+Automatic merge failed/prevented; fix up by hand
+$ git reset --hard <2>
+
+<1> try to update from the upstream resulted in a lot of
+conflicts; you were not ready to spend a lot of time merging
+right now, so you decide to do that later.
+<2> "pull" has not made merge commit, so "git reset --hard"
+which is a synonym for "git reset --hard HEAD" clears the mess
+from the index file and the working tree.
+
+$ git pull . topic/branch <3>
+Updating from 41223... to 13134...
+Fast forward
+$ git reset --hard ORIG_HEAD <4>
+
+<3> merge a topic branch into the current branch, which resulted
+in a fast forward.
+<4> but you decided that the topic branch is not ready for public
+consumption yet. "pull" or "merge" always leaves the original
+tip of the current branch in ORIG_HEAD, so resetting hard to it
+brings your index file and the working tree back to that state,
+and resets the tip of the branch to that commit.
+------------
Author
------
^ permalink raw reply related
* Re: bad git pull
From: Junio C Hamano @ 2005-12-17 1:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512161701400.3698@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Or maybe "git commit" should always _write_ ORIG_HEAD with the old head,
> so that we can always do an "undo" by doing "git reset --hard ORIG_HEAD"
> regardless of whether the last thing was a "git commit" or a "git pull".
>
> Hmm?
If we define "git undo" as "Revert the tree to the state one
before the last successfull commit/pull", then overwriting
ORIG_HEAD as you say at the commit time and always using "git
reset --hard ORIG_HEAD" would make sense.
I fail to see the merit of "git undo/unpull/unmerge/..."; mostly
because I have never seen BK and do not benefit from the
familiarity factor at all. To people without BK experience,
having too many synonyms (e.g. "git undo" does something magical
by feeding "git reset --hard" with ORIG_HEAD) might be just more
noise and confusion. I can see them asking "why are there two
ways to do identical things?".
However, the reason I am maintaining git is not to make it
useful for _me_, but to make it useful for the kernel people, so
if these BK-like synonyms help them, I'm all for it. If we are
going to do that, somebody needs to describe what should each
command do in each case in detail, because I do not know BK at
all.
You guys were on BK for how many months, and have been on git
for how many months now? Do BK-familiarity factor matter, and
will it continue to matter for how long?
^ permalink raw reply
* Re: git merge questions
From: Junio C Hamano @ 2005-12-17 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Don Zickus, git
In-Reply-To: <Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> just a thought: maybe in this case -- git fails to recognize a rename --
> Pasky's idea would have some merit. You could then provide git with some
> extra information a la .git/info/grafts: "Even if you, git, do not believe
> it: this file *was* renamed from blah to blop".
Yeah, except small details such as: where does it record it, and
how does the information presented to the user, and how does the
user tell git that information should be used?
What would be interesting would be to extend on this thing I
just wrote:
Something like:
$ git resolve-renamed-path arch/ppc64/ arch/powerpc/
to mean "I want the result of this merge to rename ppc64/Kconfig
to powerpc/Kconfig", perhaps?
I think this would work very nicely even without rename
detectino by the recursive strategy. What would happen with
resolve strategy is that unchanged paths are removed from
arch/ppc64 and added to arch/powerpc by the usual read-tree
merge rules, and all paths (not just unrecognizable renames --
because resolve would not even try) that have been changed on
the "test" branch would be in stage1+stage3 state in arch/ppc64,
while the corresponding ones in arch/powerpc are collapsed
("only added in test2 branch") to stage0. The fictional
resolve-renamed-path command (notice that I removed the explicit
"Kconfig" from the sample command line) could go through the
index file, looking for paths that arch/powerpc/ has stage0 and
arch/ppc64 has stage1+3, and perform the renaming merge at that
point.
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-17 1:05 UTC (permalink / raw)
To: Morten Welinder; +Cc: Junio C Hamano, Don Zickus, git
In-Reply-To: <118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com>
On Fri, 16 Dec 2005, Morten Welinder wrote:
>
> It would be outright peachy if Documentation/git-commit.txt and
> Documentation/git-pull.txt mentioned these. That is certainly
> where I would look first to answer the "what if I screwed up?"
> question.
It might be even better to have some of the "safe" versions around. Ie
something that refuses to "undo" a merge (you want to "unpull" it or
"unmerge" it), and refuses to "undo" when there's a ORIG_HEAD around that
implies that the last commit was a "pull" (in which case again "undo" may
be the wrong thing to do, since it will only undo _one_ commit, even
though the pull might have fast-forwarded a _lot_ of commits).
Of course, if we do that, we should also make sure that "git commit"
removes ORIG_HEAD.
Or maybe "git commit" should always _write_ ORIG_HEAD with the old head,
so that we can always do an "undo" by doing "git reset --hard ORIG_HEAD"
regardless of whether the last thing was a "git commit" or a "git pull".
Hmm?
Linus
^ permalink raw reply
* Re: bad git pull
From: Morten Welinder @ 2005-12-17 0:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Don Zickus, git
In-Reply-To: <Pine.LNX.4.64.0512161347490.3698@g5.osdl.org>
> - undo the last commit entirely ("hard reset to previous state"):
>
> git reset --hard HEAD^
>
> This was "bk undo"
>
> - undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":
>
> git reset --hard ORIG_HEAD
>
> This was "bk unpull".
It would be outright peachy if Documentation/git-commit.txt and
Documentation/git-pull.txt mentioned these. That is certainly
where I would look first to answer the "what if I screwed up?"
question.
Morten
^ permalink raw reply
* Re: git merge questions
From: Johannes Schindelin @ 2005-12-16 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Don Zickus, git
In-Reply-To: <7voe3gd6ul.fsf@assigned-by-dhcp.cox.net>
Hi,
just a thought: maybe in this case -- git fails to recognize a rename --
Pasky's idea would have some merit. You could then provide git with some
extra information a la .git/info/grafts: "Even if you, git, do not believe
it: this file *was* renamed from blah to blop".
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Nicolas Pitre @ 2005-12-16 22:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Johannes Schindelin, Junio C Hamano,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512161412310.3698@g5.osdl.org>
On Fri, 16 Dec 2005, Linus Torvalds wrote:
>
>
> On Fri, 16 Dec 2005, Nicolas Pitre wrote:
>
> > On Fri, 16 Dec 2005, Linus Torvalds wrote:
> >
> > > But, for example:
> > >
> > > [torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
> > > real 0m37.993s
> > > user 0m41.912s
> > > sys 0m0.400s
> >
> > Hmmm... I'd like to have a system like that too, where reality is
> > smaller than the sum of system and user time. ;-)
>
> It's called "smp".
Gah! Maybe I should have tried the same before posting, since I get
this on my P4 with HT:
real 0m36.930s
user 0m41.971s
sys 0m0.656s
/me hides shamefully
Nicolas
^ permalink raw reply
* Re: git merge questions
From: Junio C Hamano @ 2005-12-16 22:17 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512161335k50a3ec64lee6f73ea4f8ae23f@mail.gmail.com>
Don Zickus <dzickus@gmail.com> writes:
>> and then, the digging I suggested yields these:
>>
>> $ ls -l arch/{ppc64,powerpc}/Kconfig
>> -rw-rw-r-- 1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig
>> -rw-rw-r-- 1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig
>> $ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig
>> 100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0 arch/powerpc/Kconfig
>> 100644 c658650af429672267409508b02b38754c11a40f 1 arch/ppc64/Kconfig
>> 100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3 arch/ppc64/Kconfig
>> ..
>> The result you want in this case is to merge changes between
>> c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into
>> bb2efd (the latest contents of the new path) and register it as
>> the result of merge for arch/powerpc/Kconfig, and remove
>> arch/ppc64/Kconfig. So the sequence would be:
>>
>> $ orig=$(git unpack-file c65865)
>> $ from_test=$(git unpack-file 8abf11)
>> $ merge $from_test $orig arch/powerpc/Kconfig
>> merge: warning: conflicts during merge
I suspect there might be a room for improvement to make this
easier with a new command, if this becomes a common pattern.
Something like:
$ git resolve-renamed-path arch/ppc64/Kconfig arch/powerpc/Kconfig
to mean "I want the result of this merge to rename ppc64/Kconfig
to powerpc/Kconfig", perhaps? There are three cases: (1) we
renamed they didn't --- this is the case we are looking at and
there will be stage1 and stage3 but not stage2 for the old path,
and stage0 for the new path; (2) they renamed we didn't --- this
would happen if you pulled test2 into test, and there will be
stage1 and stage2 but not stage3 for the old path, and stage0
for the new path; (3) both of us renamed.
The third case is handled by the merge command automatically.
Old path will not remain to bother you even if the merge of the
new path needs hand-resolving, so you do not need
resolve-renamed-path command to deal with that case.
> Now say I didn't know the name of the rename and I had to dig
> that up. Would the following be the right way or is there
> something easier?
>
> %git log <renamed file> #grab the last commit id from here
> %git-diff-tree -p <last commit id> # search for the new file
That would work.
Or an explicit rename detection to see where many of the
neighbouring paths moved (this is very expensive):
mb=$(git merge-base test test2)
git diff-tree -r --diff-filter=R -M -l0 --name-status $mb test2
Or the diff-tree between the merge base and your current tree
and perhaps the other tree (this may give a lot of cruft):
mb=$(git merge-base test test2)
git diff-tree -r --diff-filter=A --name-status $mb test2
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Linus Torvalds @ 2005-12-16 22:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Martin Langhoff, Johannes Schindelin, Junio C Hamano,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512161636150.26663@localhost.localdomain>
On Fri, 16 Dec 2005, Nicolas Pitre wrote:
> On Fri, 16 Dec 2005, Linus Torvalds wrote:
>
> > But, for example:
> >
> > [torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
> > real 0m37.993s
> > user 0m41.912s
> > sys 0m0.400s
>
> Hmmm... I'd like to have a system like that too, where reality is
> smaller than the sum of system and user time. ;-)
It's called "smp".
You can buy then anywhere.
Linus
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-16 22:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Don Zickus, git
In-Reply-To: <7vfyoshmp6.fsf@assigned-by-dhcp.cox.net>
On Fri, 16 Dec 2005, Junio C Hamano wrote:
>
> Morten Welinder <mwelinder@gmail.com> writes:
>
> >> While I am sympathetic, this "Oops, I said pull when I meant
> >> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
> >> meant to say 'ls -r'". Is it that the tool is too fragile?
> >
> > Didn't bk come with some kind of (one-level) undo pull? It should not
> > be too hard to create something similar considering that one could
> > just leave new objects in the db orphaned.
>
> Yes, that is called "git reset".
Well, this is one area where BK and git differ a lot. BK didn't overload
many things onto the same "reset" functionality, but had specific
operations for specific cases.
Also BK would never leave a merge in the git kind of half-merged state,
because BK refuses to have two branches open. Instead, BK had a special
way of handling merges, which worked fine but quite frankly I have very
little idea of how it worked (it was some kind of "shadow BK tree", it was
called ".bk/RESOLVE/" or something like that - but because the tools
were so nice, you never really had any reason to look into it, so I
don't know what it did).
BK would never change the working tree itself until the merge was done, so
you would never need to do what a plain "git reset --hard" (without any
arguments) does.
In many ways the BK thing was very nice, although the git way is perhaps a
bit more flexible (because git makes the intermediate tree visible you can
easily edit the merge errors, and compile/test the result, before you
decide to commit any manual merge).
I really do like the way git does merges now (especially after the last
round of git-diff-tree fixes that allow comparing the different stages),
but the BK way is in some ways cleaner and leaves less potential for
confusion since it avoids ever exposing you to any half-merged state.
You may remember how I initially argued that we should always try to merge
stuff outside of the normal working directory. And I still _like_ that
approach, although I've since decided that I actually prefer the current
git way is even better in practice.
But "git reset" is a lot more than the "revert to previous state". It
_also_ does - without the error checking - what "bk fix" used to do
(which is to undo the last commit, so that you can re-commit it), and it
also does what "bk undo" used to do. It also does "bk unpull".
So "git reset" really does a whole lot of different and _mostly_ related
things:
- undo any half-way changes (very similar to just "git checkout -f"), and
just reset to the state of the last successful commit (ie "current
HEAD"):
git reset --hard
BK didn't need this, although if you just want to remove your edits
(which "git reset --hard" also does), you could - like with git - just
do a "checkout" operation, of course.
- undo the last commit, but don't undo the working tree ("soft reset to
parent of head").
git reset HEAD^
I think this was "bk fix -C".
- undo the last commit entirely ("hard reset to previous state"):
git reset --hard HEAD^
This was "bk undo"
- undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":
git reset --hard ORIG_HEAD
This was "bk unpull".
where the last two are obviously just special cases of a generic "undo to
arbitrary previous commit state".
BK in many ways had more hand-holding (which I think is good, and "git" to
some degree has an unnecessarily "hard core" approach to these things).
For example, I think "bk undo" not only asked you about it, but it also
only ever undid the last commit (and refused to undo a pull or merge). If
you wanted to undo to some arbitrary state, you had to use the "-a" flag,
iirc.
Of course, under BK the "undo" operation was final, so BK _had_ to be more
careful. With git, if you undo to some arbitrary state, you can still
"re-do" all your commits if you just find the old head (and
git-fsck-objects will help you do that), so in that sense git doesn't
_need_ to be as careful as BK was.
Linus
^ permalink raw reply
* Re: Why do we need [PATCH]?
From: Sam Ravnborg @ 2005-12-16 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsnwenqy.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 16, 2005 at 01:27:33PM -0800, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
>
> > I looked at the source and found the -k option, but adding [PATCH]
> > should not be default behaviour so this is not the correct solution.
>
> The "correct" solution depends on where you come from. That
> extra [PATCH] is a carryover from BK days, I was told by Linus,
> to make e-mailed things stand out --- I've never used BK but I
> am guessing that things were not as obvious as our commit
> messages, perhaps?
You can a typical bk commit here:
http://linus.bkbits.net:8080/linux-2.5/cset@1.2243?nav=index.html|ChangeSet@-9M
And here it made much more sense sine the author/comitter info are
less structured. Also we do nto have the Signed-off-by: stuff back then.
> We have "Author/Committer" distinction so
> the [PATCH] marker is redundant.
>
> The rewrite, "git-am" does not bother with adding [PATCH], but
> the original "git-applymbox", being everyday Linus' tool, was
> left as it was, not to disrupt the workflow of Linus.
Thanks, I had forgotten the git-am rewrite.
I will use that in the future - if I remember.
Sam
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Nicolas Pitre @ 2005-12-16 21:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Johannes Schindelin, Junio C Hamano,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512160843450.3060@g5.osdl.org>
On Fri, 16 Dec 2005, Linus Torvalds wrote:
> But, for example:
>
> [torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
> real 0m37.993s
> user 0m41.912s
> sys 0m0.400s
Hmmm... I'd like to have a system like that too, where reality is
smaller than the sum of system and user time. ;-)
Nicolas
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Junio C Hamano @ 2005-12-16 21:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, junkio, git
In-Reply-To: <e5bfff550512161247v4c187cc0gedae8234d454c3b6@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Type information is already available in git-ls-remote.sh...
???? is it ???? where and how ????
The only thing you know is where things are, and optionally if
that thing is a tag object or not (by presense or lack of
corresponding "it^{}").
^ permalink raw reply
* Re: git merge questions
From: Don Zickus @ 2005-12-16 21:35 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vy82keo8p.fsf@assigned-by-dhcp.cox.net>
> and then, the digging I suggested yields these:
>
> $ ls -l arch/{ppc64,powerpc}/Kconfig
> -rw-rw-r-- 1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig
> -rw-rw-r-- 1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig
> $ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig
> 100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0 arch/powerpc/Kconfig
> 100644 c658650af429672267409508b02b38754c11a40f 1 arch/ppc64/Kconfig
> 100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3 arch/ppc64/Kconfig
> $ ls arch/{powerpc,ppc64}/Kconfig~*
> ls: arch/powerpc/Kconfig~*: No such file or directory
> ls: arch/ppc64/Kconfig~*: No such file or directory
> $ git diff --theirs arch/ppc64/Kconfig
> * Unmerged path arch/ppc64/Kconfig
> diff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig
>
> The merge algorithm thought your branch (that is, test2 which is
> v2.6.15-rc4) removed the old ppc64/Kconfig path, but the other
> branch (test1 which has diff between v2.6.14 and v2.6.14.4) made
> updates to that file. For the other path, it simply thought
> your branch added a new file arch/powerpc/Kconfig while the
> other branch did not do anything to that path between v2.6.14
> and v2.6.14.4, so it merged it already.
>
> The result you want in this case is to merge changes between
> c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into
> bb2efd (the latest contents of the new path) and register it as
> the result of merge for arch/powerpc/Kconfig, and remove
> arch/ppc64/Kconfig. So the sequence would be:
>
> $ orig=$(git unpack-file c65865)
> $ from_test=$(git unpack-file 8abf11)
> $ merge $from_test $orig arch/powerpc/Kconfig
> merge: warning: conflicts during merge
>
> After resolving the conflict in $from_test file, and other conflicts:
>
> $ ed $from_test
> $ cat $from_tset >arch/ppc64/Kconfig
> $ rm arch/powerpc/Kconfig
> $ rm $orig $from_test
> $ git update-index --add --remove arch/ppc64/Kconfig arch/powerpc/Kconfig
> # also mark paths you hand-resolved such as Makefile, drivers/pcmcia/i82365.c
> # etc. with "git update-index" here.
> $ git commit
>
> would commit the result of the merge.
>
Wow. That makes sense then. All your digging techniques seem to be
fairly straightforward. Now say I didn't know the name of the rename
and I had to dig that up. Would the following be the right way or is
there something easier?
%git log <renamed file> #grab the last commit id from here
%git-diff-tree -p <last commit id> # search for the new file
Thanks again,
Don
^ 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