* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-11 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <7vvd1v4bmt.fsf@alter.siamese.dyndns.org>
On Tue, Jan 11, 2011 at 09:02:18AM -0800, Junio C Hamano wrote:
> > Also, one other question while we are on the subject. I think we all
> > agree that "git checkout $foo" should prefer $foo as a branch. But what
> > about "git checkout -b $branch $start_point"?
>
> That has always been defined as a synonym for
>
> git branch $branch $start_point && git checkout $branch
>
> so $start_point is just a random extended SHA-1 expression.
That's what I would have expected, but I wanted to write a test to make
sure it was the case.
But it's not. Even taking away the die, my second test here fails (built
on top of the three previous commits under discussion):
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
index e2b330b..7a6b30b 100755
--- a/t/t2019-checkout-amiguous-ref.sh
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -50,4 +50,13 @@ test_expect_success VAGUENESS_SUCCESS 'checkout reports switch to detached HEAD'
! grep "^HEAD is now at" stderr
'
+test_expect_success 'new branch from ambiguous start_point works' '
+ git checkout -b newbranch ambiguity
+'
+
+test_expect_success 'checkout chooses tag over branch for start_point' '
+ echo tag >expect &&
+ test_cmp expect file
+'
+
test_done
For bonus fun, doing this:
git branch newbranch ambiguity
git checkout newbranch
_does_ prefer the branch. So it is checkout feeding create_branch() the
modified sha1. I'll see if I can dig further.
-Peff
^ permalink raw reply related
* Re: clone breaks replace
From: Jonathan Nieder @ 2011-01-11 17:56 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Phillip Susi, git, Christian Couder, Stephen Bash
In-Reply-To: <20110111175031.GA2085@sigill.intra.peff.net>
Jeff King wrote:
> I think you are stuck with something manual
> like:
>
> # grab "view" from upstream and name it; let's imagine it links 2010
> # history into 2009
> git fetch origin refs/replace/$sha1 refs/views/2009/$sha1
>
> # now we feel like using them
> git for-each-ref --shell --format='%(refname)' refs/views/2009 |
> while read ref; do
> git update-ref "refs/replace/${ref#refs/views/2009}" "$ref"
> done
>
> Which is a little overkill for the simple example you gave, but would
> also handle something as complex as a view like "pretend the foo/
> subtree never existed" or even "pretend the foo/ subtree existed all
> along".
>
> Not that I'm sure such things are actually sane to do, performance-wise.
> The replace system is fast, but it was designed for a handful of
> objects, not hundreds or thousands.
>
> Anyway. My point is that we don't have the porcelain to do something
> like managing views or enabling/disabling them in a sane manner.
Maybe something like
git fetch origin refs/views/2009/*:refs/replace/*
except that that does not provide a nice way to remove to replace
refs when done.
A potential usability enhancement might be to allow additional
replacement hierarchies to be requested on a per command basis, like
GIT_REPLACE_REFS=refs/remotes/origin/views/2009 gitk --all
along the lines of GIT_NOTES_REF.
^ permalink raw reply
* Re: [PATCH] fast-import: Don't barf if import-marks file is missing
From: Jonathan Nieder @ 2011-01-11 17:51 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List
In-Reply-To: <1294766058-29739-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> The --import-marks option used to barf when the specified marks file
> doesn't exist.
Micronit: change descriptions should contrast present behavior
The --import-marks options errors out when the marks file is
missing.
with user requirements
But if a frontend is just using a marks file to ensure its state
persists between runs, it would be simpler if missing marks
files were tolerated. In some cases the frontend cannot even
check for the existence of the marks file itself because with
--relative-marks, the location of the marks file is
backend-dependent.
and the proposed solution
Change the meaning of --import-marks to "read marks file if it
exists so such frontends don't have to use a different command
line when bootstrapping.
I.e., the preferred style is to use present tense for the description
of present behavior, so the patch can be read as a bug report.
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -72,7 +72,7 @@ OPTIONS
>
> --import-marks=<file>::
> Before processing any input, load the marks specified in
> - <file>. The input file must exist, must be readable, and
> + <file>, if it exists.
This means removing a typo detection facility.
git fast-import --import-marks=something-like-a-real-marks-file.marks
would be accepted and result in an empty marks table instead of an
error message. Is that considered worth it? (My hunch is no, but
either way, I think it ought to be mentioned in the change
description.)
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1795,7 +1795,11 @@ static void read_marks(void)
Nice implementation. Maybe something like this on top?
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-fast-import.txt | 6 +++-
fast-import.c | 12 ++++++--
t/t9300-fast-import.sh | 55 +++++++++++++++++++++++++++++++++++++
3 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 94fbe54..32a062c 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -72,12 +72,16 @@ OPTIONS
--import-marks=<file>::
Before processing any input, load the marks specified in
- <file>, if it exists. The input file must be readable, and
+ <file>. The input file must exist, must be readable, and
must use the same format as produced by \--export-marks.
Multiple options may be supplied to import more than one
set of marks. If a mark is defined to different values,
the last file wins.
+--import-marks-if-exists=<file>::
+ Like --import-marks but instead of erroring out, silently
+ skips the file if it does not exist.
+
--relative-marks::
After specifying --relative-marks= the paths specified
with --import-marks= and --export-marks= are relative
diff --git a/fast-import.c b/fast-import.c
index cbd5124..c525fda 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -329,6 +329,7 @@ static struct mark_set *marks;
static const char *export_marks_file;
static const char *import_marks_file;
static int import_marks_file_from_stream;
+static int import_marks_file_ignore_missing;
static int relative_marks_paths;
/* Our last blob */
@@ -1797,7 +1798,7 @@ static void read_marks(void)
FILE *f = fopen(import_marks_file, "r");
if (f)
;
- else if (errno == ENOENT)
+ else if (import_marks_file_ignore_missing && errno == ENOENT)
return; /* Marks file does not exist */
else
die_errno("cannot read '%s'", import_marks_file);
@@ -2865,7 +2866,8 @@ static char* make_fast_import_path(const char *path)
return strbuf_detach(&abs_path, NULL);
}
-static void option_import_marks(const char *marks, int from_stream)
+static void option_import_marks(const char *marks,
+ int from_stream, int ignore_missing)
{
if (import_marks_file) {
if (from_stream)
@@ -2879,6 +2881,7 @@ static void option_import_marks(const char *marks, int from_stream)
import_marks_file = make_fast_import_path(marks);
safe_create_leading_directories_const(import_marks_file);
import_marks_file_from_stream = from_stream;
+ import_marks_file_ignore_missing = ignore_missing;
}
static void option_date_format(const char *fmt)
@@ -2978,7 +2981,10 @@ static int parse_one_feature(const char *feature, int from_stream)
if (!prefixcmp(feature, "date-format=")) {
option_date_format(feature + 12);
} else if (!prefixcmp(feature, "import-marks=")) {
- option_import_marks(feature + 13, from_stream);
+ option_import_marks(feature + 13, from_stream, 0);
+ } else if (!prefixcmp(feature, "import-marks-if-exists=")) {
+ option_import_marks(feature + strlen("import-marks-if-exists="),
+ from_stream, 1);
} else if (!prefixcmp(feature, "export-marks=")) {
option_export_marks(feature + 13);
} else if (!strcmp(feature, "cat-blob")) {
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 222d105..870e55b 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1706,6 +1706,61 @@ test_expect_success \
'cat input | git fast-import --export-marks=other.marks &&
grep :1 other.marks'
+test_expect_success 'R: catch typo in marks file name' '
+ test_must_fail git fast-import --import-marks=nonexistent.marks </dev/null &&
+ echo "feature import-marks=nonexistent.marks" |
+ test_must_fail git fast-import
+'
+
+test_expect_success 'R: import and output marks can be the same file' '
+ rm -f io.marks &&
+ blob=$(echo hi | git hash-object --stdin) &&
+ cat >expect <<-EOF &&
+ :1 $blob
+ :2 $blob
+ EOF
+ git fast-import --export-marks=io.marks <<-\EOF &&
+ blob
+ mark :1
+ data 3
+ hi
+
+ EOF
+ git fast-import --import-marks=io.marks --export-marks=io.marks <<-\EOF &&
+ blob
+ mark :2
+ data 3
+ hi
+
+ EOF
+ test_cmp expect io.marks
+'
+
+test_expect_success 'R: --import-marks=foo --output-marks=foo to create foo fails' '
+ rm -f io.marks &&
+ test_must_fail git fast-import --import-marks=io.marks --export-marks=io.marks <<-\EOF
+ blob
+ mark :1
+ data 3
+ hi
+
+ EOF
+'
+
+test_expect_success 'R: --import-marks-if-exists' '
+ rm -f io.marks &&
+ blob=$(echo hi | git hash-object --stdin) &&
+ echo ":1 $blob" >expect &&
+ git fast-import --import-marks-if-exists=io.marks --export-marks=io.marks <<-\EOF &&
+ blob
+ mark :1
+ data 3
+ hi
+
+ EOF
+ test_cmp expect io.marks
+'
+
cat >input << EOF
feature import-marks=marks.out
feature export-marks=marks.new
--
1.7.4.rc1
^ permalink raw reply related
* Re: clone breaks replace
From: Jeff King @ 2011-01-11 17:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Phillip Susi, git, Christian Couder,
Stephen Bash
In-Reply-To: <7vr5cj49vi.fsf@alter.siamese.dyndns.org>
On Tue, Jan 11, 2011 at 09:40:17AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Sure, I think that is a sane way for the user to think about it, but do
> > we actually support multiple views? I thought replacement objects were
> > all or nothing.
>
> It is not implausible for a long running large project to restart their
> history from a physical root commit every year, stiching the year-long
> segments together at their ends with replacements, to make a default clone
> to get a year's worth of the most recent history while allowing people to
> get more by asking, no?
Oh, absolutely I think it is reasonable. I just meant that we do not
have a convenient way of saying "fetch these replace objects, but only
use this particular subset". I think you are stuck with something manual
like:
# grab "view" from upstream and name it; let's imagine it links 2010
# history into 2009
git fetch origin refs/replace/$sha1 refs/views/2009/$sha1
# now we feel like using them
git for-each-ref --shell --format='%(refname)' refs/views/2009 |
while read ref; do
git update-ref "refs/replace/${ref#refs/views/2009}" "$ref"
done
Which is a little overkill for the simple example you gave, but would
also handle something as complex as a view like "pretend the foo/
subtree never existed" or even "pretend the foo/ subtree existed all
along".
Not that I'm sure such things are actually sane to do, performance-wise.
The replace system is fast, but it was designed for a handful of
objects, not hundreds or thousands.
Anyway. My point is that we don't have the porcelain to do something
like managing views or enabling/disabling them in a sane manner.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Junio C Hamano @ 2011-01-11 17:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan Nieder, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4D2C1AAE.1040002@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 1/11/2011 9:37, schrieb Jonathan Nieder:
>> I suspect that the reader will end up wondering "why does this have to
>> be so complicated" no matter what.
>
> Unfortunately, yes. Therefore, I'd like to keep the paragraph minimal,
> focused on how expected values should be constructed, which is where
> errors will happen primarily.
I really was hoping for something simple like "never use $PWD" myself,
though X-<.
Anyway, will queue for 1.7.4. Thanks.
^ permalink raw reply
* Re: clone breaks replace
From: Junio C Hamano @ 2011-01-11 17:40 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, Phillip Susi, git, Christian Couder,
Stephen Bash
In-Reply-To: <20110111053653.GB10094@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Sure, I think that is a sane way for the user to think about it, but do
> we actually support multiple views? I thought replacement objects were
> all or nothing.
It is not implausible for a long running large project to restart their
history from a physical root commit every year, stiching the year-long
segments together at their ends with replacements, to make a default clone
to get a year's worth of the most recent history while allowing people to
get more by asking, no?
Of course, if you trust shallow-clones, you do not have to do that kind of
history surgery ;-).
^ permalink raw reply
* Re: clone breaks replace
From: Jeff King @ 2011-01-11 17:39 UTC (permalink / raw)
To: Phillip Susi; +Cc: Jonathan Nieder, git, Christian Couder, Stephen Bash
In-Reply-To: <4D2C7611.6060204@cfl.rr.com>
On Tue, Jan 11, 2011 at 10:24:01AM -0500, Phillip Susi wrote:
> Yes, either a new branch or separate historical repository could be
> published to pull the original history from, or git would need to pass
> the --no-replace-objects flag to git-upload-pack on the server, causing
> it to ignore the replace and send the original history.
AFAIK, git can't pass --no-replace-objects to the server over git:// (or
smart http). You would need a protocol extension.
And here's another corner case I thought of:
Suppose you have some server S1 with this history:
A--B--C--D
and a replace object truncating history to look like:
B'--C--D
You clone from S1 and have only commits B', C, and D (or maybe even B,
depending on the implementation). But definitely not A, nor its
associated tree and blobs.
Now you want to fetch from another server S2, which built some commits
on the original history:
A--B--C--D--E--F
You and S2 negotiate that you both have D, which implies that you have
all of the ancestors of D. S2 therefore sends you a thin pack containing
E and F, which may contain deltas against objects found in D or its
ancestors. Some of which may be only in A, which means you do not have
them.
Aside from fetching the entire real history, the only solution is that
you somehow have to communicate to S2 exactly which objects you have,
presumably by telling them which replacements you have used to arrive at
the object set you have. Which in the general case would mean actually
shipping them your replacement refs and objects (simply handling the
special case of commit truncation isn't sufficient; you could have
replaced any object with any other one).
-Peff
^ permalink raw reply
* [PATCH] fast-import: Don't barf if import-marks file is missing
From: Ramkumar Ramachandra @ 2011-01-11 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List
In-Reply-To: <7vwrmd7kxe.fsf@alter.siamese.dyndns.org>
The --import-marks option used to barf when the specified marks file
doesn't exist. Change its meaning to "read marks file if it exists" so
that callers don't have to handle bootstraping as a special case.
Requested-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/git-fast-import.txt | 2 +-
fast-import.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index f56dfca..94fbe54 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -72,7 +72,7 @@ OPTIONS
--import-marks=<file>::
Before processing any input, load the marks specified in
- <file>. The input file must exist, must be readable, and
+ <file>, if it exists. The input file must be readable, and
must use the same format as produced by \--export-marks.
Multiple options may be supplied to import more than one
set of marks. If a mark is defined to different values,
diff --git a/fast-import.c b/fast-import.c
index 7857760..cbd5124 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1795,7 +1795,11 @@ static void read_marks(void)
{
char line[512];
FILE *f = fopen(import_marks_file, "r");
- if (!f)
+ if (f)
+ ;
+ else if (errno == ENOENT)
+ return; /* Marks file does not exist */
+ else
die_errno("cannot read '%s'", import_marks_file);
while (fgets(line, sizeof(line), f)) {
uintmax_t mark;
--
1.7.2.2.409.gdbb11.dirty
^ permalink raw reply related
* Re: bug? in checkout with ambiguous refnames
From: Junio C Hamano @ 2011-01-11 17:02 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Uwe Kleine-König, git
In-Reply-To: <20110111065207.GF10094@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jan 07, 2011 at 03:17:22PM -0800, Junio C Hamano wrote:
>
>> ... And this comes on top (should probably be squashed into one) to really
>> favor a branch over a tag.
>>
>> builtin/checkout.c | 26 ++++++++++----------------
>> t/t2019-checkout-amiguous-ref.sh | 2 +-
>> 2 files changed, 11 insertions(+), 17 deletions(-)
>
> Yeah, that looks sane to me (assuming all three patches squashed
> together). It took me a minute to figure out one subtlety, though:
>
>> + if ((check_ref_format(new.path) != CHECK_REF_FORMAT_OK) ||
>> + !resolve_ref(new.path, rev, 1, NULL))
>> + new.path = NULL; /* not an existing branch */
>> +
>> + if (!(new.commit = lookup_commit_reference_gently(rev, 1))) {
>
> We are relying on the fact that resolve_ref leaves "rev" alone in the
> case that it does not find anything. Which is mostly true (the only
> exception seems to be if you have a ref with non-hex garbage in it, in
> which case you will get some bogus sha1 in the output). I dunno if it is
> worth making it more explicit, like:
I've thought about it when I sent the patch. I think this is safe as that
particular resolve is done on a full ref "refs/heads/$something" and upon
seeing the first 'r' get_sha1_hex() would give up without touching rev[],
but I agree it is too subtle.
> Also, one other question while we are on the subject. I think we all
> agree that "git checkout $foo" should prefer $foo as a branch. But what
> about "git checkout -b $branch $start_point"?
That has always been defined as a synonym for
git branch $branch $start_point && git checkout $branch
so $start_point is just a random extended SHA-1 expression.
> I was surprised to find that the current behavior is to die(), due to an
> explicit case in branch.c:create_branch.
Good eyes. At that point, "refname <start> is ambiguous." warning has
already been issued, and there is no sane reason to die there. I'd call
it a bug.
^ permalink raw reply
* Re: git-repack & big files
From: Phillip Susi @ 2011-01-11 15:43 UTC (permalink / raw)
To: Pietro Battiston; +Cc: git
In-Reply-To: <1294731438.3300.973.camel@voubian.casa>
On 1/11/2011 2:37 AM, Pietro Battiston wrote:
> Since it perfectly does what it is not optimized to do... I then wonder
> when it does not do what it declares: if I run git-repack² with the
> parameter --window-memory set to, for instance, "100m", it takes
> hundreds and hundreds of MB of memory until it runs out of memory, fails
> a malloc and aborts.
> So, two questions:
--window-memory reduces the window size to try and stay under the limit,
but the window size can not be reduced below 1.
> 2) do I have any hope that in one way or another my 500+ MB mailboxes
> with relatively small changes over time are archived smartly (=diffs) by
> git at the current state of development? If I understand correctly, the
> project git-bigfiles³ would just "solve" my problems by not making
> differences of big files.
Git is not a backup tool. You should use rsync rdiff-backup instead.
^ permalink raw reply
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-11 15:37 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, git, Christian Couder, Stephen Bash
In-Reply-To: <20110111065244.GB8631@burratino>
On 1/11/2011 1:52 AM, Jonathan Nieder wrote:
> I have two worries:
>
> - first, how easily can the replacement be undone? (as you mention
> below)
git replace -d id, or git --no-replace-objects. It also might be nice
to add a new switch to git replace to disable a replace without deleting
it, so that it can later be enabled again.
> - second, what happens if the two ends of transport have different
> replacements?
Then you have a conflict, just like if the two ends have different tags
with the same name.
> That second worry is the more major in my opinion. Shallow clones are
> a different story --- they do not fundamentally change the history and
> they have special support in git protocol. It is possible to punt on
> both by saying that (1) replacements _cannot_ be undone --- a second
> replacement is needed --- and (2) the receiving end of a connection is
> not allowed to have any replacements for objects in common that the
> sending end does not have, but then does that buy you anything
> significant over a filter-branch?
One of the major advantages of replacements is that they can easily be
undone, so defeating that would be silly. Just like with conflicting
tags, if the receiving end has conflicting replacements, they will be
kept instead of the remote version and a warning issued. If you want
the remote version, delete your local one and fetch again.
What it buys you over filter-branch is:
1) Those tracking your repo don't have breakage when they next fetch
because the chain of commits they were tracking has been destroyed and
replaced by a completely different one.
2) It is obvious when a replace has been done, and the original is
still available. This is good for auditing and traceability. Paper
trails are good.
3) Inserting a replace record takes a lot less cpu and IO than
filter-branch rewriting the entire chain.
^ permalink raw reply
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-11 15:24 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git, Christian Couder, Stephen Bash
In-Reply-To: <20110111054735.GC10094@sigill.intra.peff.net>
On 1/11/2011 12:47 AM, Jeff King wrote:
> Once you have fetched with that view, how locked into that view are you?
> Certainly you can never push to or be the fetch remote for another
> repository that does not want to respect that view, because you simply
> don't have the objects to complete the history for them.
If you want to fetch the original history, then it is as simple as git
--no-replace-objects fetch. Unless of course, the upstream repository
actually removed the original history ( or you are pulling from someone
else who only pulled the truncated history ), possibly transplanting it
to a historical repository that they should refer you to in the message
of the replace commit. Then you just fetch from there instead, and
viola! You have the complete original history.
> I guess you can get the parent pointer from the real, "non-replaced"
> object and ask for it. But you can't ask for a specific commit, so for
> every such truncation, the parent needs to publish an extra ref (but
> _not_ make it one of the ones fetched by default, or it would nullify
> your original shallow fetch), and we need to contact them and find that
> ref.
Yes, either a new branch or separate historical repository could be
published to pull the original history from, or git would need to pass
the --no-replace-objects flag to git-upload-pack on the server, causing
it to ignore the replace and send the original history.
^ permalink raw reply
* Re[2]: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Алексей Шумкин @ 2011-01-11 15:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3lj2rbmq5.fsf@localhost.localdomain>
There is one more method using grafts and fast-export/import
http://ben.straubnet.net/post/939181602/git-grafting-repositories
Let it be here too
^ permalink raw reply
* Re[2]: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Алексей Шумкин @ 2011-01-11 14:58 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Martin Krüger, git
In-Reply-To: <4D2C500F.6070203@op5.se>
AE> On 01/11/2011 01:33 PM, Алексей Шумкин wrote:
>> Thank you for the answer, but it's not what I want ))
>> Applying patches is the same as rebasing, I guess.
>> But I do not want to change v2.5-repo (let's call it so) that much.
>> I'd like to know is there any method (low-level I suppose, as far as Git
>> manages tree-objects as files) to make v2.4 LAST commit to be the
>> parent of v2.5 FIRST commit?
>>
AE> You want grafts. Check them up in the docs. Googling for "git graft"
AE> should get you a good starting point.
Yes, you`re right, but unfortunately grafts ('info/grafts' file) cannot be cloned unless
'git filter-branch' is executed, but this command changes all the
"v2.5-repo" which is "equivalent" to 'git rebase' and what I aspire
to avoid.
But Jakub Narebski <jnareb@gmail.com> gave a solution which suits for
me great.
Thank you for your reply
^ permalink raw reply
* Re[2]: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Алексей Шумкин @ 2011-01-11 14:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3lj2rbmq5.fsf@localhost.localdomain>
Hello, Jakub.
Thank you very much. Your method works great and it suits for me well
>> 1.5 years ago I had sources of a project in a SVN repository (actually it does not
>> matter what SCM was used before). And I had two branches: v2.4 and v2.5.
>> They differed enough at that moment and (as usual for SVN branches)
>> laid in two different folders.
>> Then I had known of Git and I decided to try to use this powerful DVCS.
>> But as I was a newbie I created two git-repositories: one per each
>> branch. So v2.4 has its own git-repo. v2.5 (and above) has another one.
>>
>> Now I'd like to merge them as v2.5 was a continuos branch from v2.4,
>> but without a rebasing (i.e. without a global changing of v2.5
>> repository, which already has another branches)
>> It must look like LAST commit of v2.4 should be a PARENT of FIRST commit of v2.5
>>
>> Now there's a question: Is it possible to do so (no rebasing!), and If
>> "yes" then how to?
JN> As Andreas Ericsson wrote, you can do this using grafts (and you can
JN> make history with grafts permanent using "git filter-branch").
JN> Better solution might be to use more modern replace mechanism, see
JN> e.g. "git replace" manpage. Below there is untested step-by-step
JN> instruction.
JN> First, you have put history of v2.4 and of v2.5 in a single repository
JN> (e.g. using "git remote add"). Then you need to find FIRST commit of
JN> v2.5 among
JN> $ git rev-list master --parents | grep -v ' '
JN> The above finds all parent-less commits in 'master' branch; replace it
JN> with branch holding v2.5 history. Then you need to find LAST commit
JN> of v2.4 and its SHA-1, e.g. via
JN> $ git rev-parse v2.4
JN> Save current state of FIRST commit of v2.5 to a file
JN> $ git cat-file -p FIRST > tmp
JN> Edit this file, adding 'parent' line between 'tree' and 'author'
JN> headers, so the header of this file looks like the following:
JN> tree 13d050266e05f7c66000240814199fcf3b559d43
JN> parent ada9983c4256f5a7bac1f7f0e29d52011741d6aa
JN> author Jakub Narebski <jnareb@gmail.com> 1294231771 +0100
JN> (trailing space added for better readibility).
JN> Then you need to add newly created object to repository:
JN> $ git hash-object -t commit -w tmp
JN> and then use it as replacement
JN> $ git replace <SHA-1 of FIRST> <SHA-1 returned by hash-object>
JN> Finally check that replacement works, e.g.:
JN> $ git show FIRST
JN> $ git log --graph --oneline -3 FIRST
JN> The anyone who would fetch refs/replace/ would get joined history, and
JN> who doesn't would see it not connected.
JN> P.S. This probably should made it into Documentation/howto
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Thomas Rast @ 2011-01-11 14:42 UTC (permalink / raw)
To: Jonathan Nieder, Ramkumar Ramachandra
Cc: Git List, Stephen Kelly, Erik Faye-Lund
In-Reply-To: <20110109172431.GA7718@burratino>
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
> > The 'user.name' and 'user.email' configuration
> > options set both author and committer information. To solve this,
> > introduce 'user.committername' and 'user.committeremail' configuration
> > options to override committer name and email respectively.
>
> Predictably, I don't like this idea at all. How would we explain this
> to a new user that is reading over gitconfig(5) for the first time?
> It makes the semantics of the committer and author name (that are mostly
> meant for giving credit and a contact address) much more murky.
Well, now that I'm rethinking it, the weird thing is that it does not
override in the way that the user intuitively might expect.
Assume we also had user.authoremail for completeness, and you do
git config --global user.authoremail author@example.com
git config --global user.committeremail committer@example.com
git config user.email user@example.com
Probably the user would expect this to result in a uniform
user@example.com identity for the current repo, but I don't think we
can twist it that way with the current config infrastructure. The
obvious option of having user.{author,committer}* override the more
generic user.* would be contrary to that intuition.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Ramkumar Ramachandra @ 2011-01-11 14:19 UTC (permalink / raw)
To: Stephen Kelly; +Cc: Jonathan Nieder, Git List, Thomas Rast, Erik Faye-Lund
In-Reply-To: <AANLkTi=t98=4p=R2DXeCJ0OVPey8EtTLxHQ=3KfqrQpE@mail.gmail.com>
Hi,
Stephen Kelly writes:
> On Sun, Jan 9, 2011 at 6:24 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Ramkumar Ramachandra wrote:
> >
> >> The 'user.name' and 'user.email' configuration
> >> options set both author and committer information. To solve this,
> >> introduce 'user.committername' and 'user.committeremail' configuration
> >> options to override committer name and email respectively.
> >
> > Predictably, I don't like this idea at all. How would we explain this
> > to a new user that is reading over gitconfig(5) for the first time?
> > It makes the semantics of the committer and author name (that are mostly
> > meant for giving credit and a contact address) much more murky.
>
> It's like the difference between who are you, and what is your log-in
> identity on remote service X.
This feature should not be widely advertised- while it can confuse
many new users, I think it's useful to have in some scenarios like
this one.
-- Ram
^ permalink raw reply
* [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Matthieu Moy @ 2011-01-11 14:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpq1v4nirzz.fsf@bauges.imag.fr>
Since the message advise to fix the configuration first, the advantage
of this command is that it is cut-and-paste ready, while using
--author='...' requires the user to type his name and email a second
time.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
builtin/commit.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 22ba54f..440223c 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -47,7 +47,11 @@ static const char implicit_ident_advice[] =
"\n"
"If the identity used for this commit is wrong, you can fix it with:\n"
"\n"
-" git commit --amend --author='Your Name <you@example.com>'\n";
+" git commit --amend --author='Your Name <you@example.com>'\n"
+"\n"
+"or\n"
+"\n"
+" git commit --amend --reset-author\n";
static const char empty_amend_advice[] =
"You asked to amend the most recent commit, but doing so would make\n"
--
1.7.4.rc0.2.g3e22c.dirty
^ permalink raw reply related
* Re: Applying .gitattributes text/eol changes
From: Marc Strapetz @ 2011-01-11 14:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4D2C4902.4010705@drmicha.warpmail.net>
On 11.01.2011 13:11, Michael J Gruber wrote:
> Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
>> I'm looking for an unobtrusive way to apply (committed) changes for
>> text/eol attributes to the working tree. For instance, after having
>> changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
>> converted from CRLF to LF endings. The only advice I found so far is to
>> remove .git/index and do a reset --hard. The disadvantage of this
>> approach is that every file will be touched:
>>
>> - although the content does not change, timestamps will be changed. This
>
> The bytewise content does change.
The content has only changed for *.txt files, but the timestamps of
*all* files are updated. I guess (but didn't verify from code), that in
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
>> One solution I could think of which might be helpful in other situations
>> as well would be to have an "--unobtrusive" option for reset which would
>> only replace a file if the content has actually been changed.
>
> How about
>
> git ls-files \*.txt | xargs touch -a
> git ls-files \*.txt | git checkout
That won't be helpful as it requires me to know what has changed.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: [RFC] Support for arbitrary tags in commits
From: Thomas Rast @ 2011-01-11 13:53 UTC (permalink / raw)
To: Philipp Marek; +Cc: git
In-Reply-To: <edec2e42a531b00ffd6a2689095460d5.squirrel@webmail.hitco.org>
Philipp Marek wrote:
> > In particular, in what way do notes (as in git-notes(1)) fail to solve
> > your problem?
> Well, my biggest concerns are that users might trash them, and that they are
> voided by amend, rebase etc. (which I tried to address by collecting header
> lines).
They aren't lost any more (since 1.7.1) if you properly configure
notes.rewriteRef.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC] Support for arbitrary tags in commits
From: Philipp Marek @ 2011-01-11 13:48 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201101111340.50508.trast@student.ethz.ch>
Hello Thomas,
thank you very much for the quick answer.
>> The best way I've found (so far) is to put an additional header line in the
>> commit header that references an additional blob.
>
> This comes up every few months. The last large discussion about this
> that we had IIRC was
>
> http://thread.gmane.org/gmane.comp.version-control.git/138848
>
> Can you please look through that thread and state in what way your
> use-case invalidates the previous reasoning?
Thank you, just reading it.
> In particular, in what way do notes (as in git-notes(1)) fail to solve
> your problem?
Well, my biggest concerns are that users might trash them, and that they are
voided by amend, rebase etc. (which I tried to address by collecting header
lines).
Well, from this thread I suppose the "best" (or at least easiest) way forward
is to use notes, if necessary.
Thank you!
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
^ permalink raw reply
* Re: [PATCH] gitk: Take only numeric version components when computing $git_version
From: Mathias Lafeldt @ 2011-01-11 13:46 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Paul Mackerras, Junio C Hamano, git
In-Reply-To: <1294360953.21006.2.camel@fixed-disk>
Anders Kaseorg wrote:
> This fixes errors running with release candidate versions of Git:
> Error in startup script: expected version number but got "1.7.4-rc0"
>
> Also, $git_version is no longer artificially limited to three
> components. That limitation was added by commit
> 194bbf6cc8c2f3c14a920c841841d66b7667a848 to deal with msysGit version
> strings like “1.6.4.msysgit.0”, and we don’t need it now. Hence as
> another side effect, this enables showing notes with git version
> 1.6.6.2 or 1.6.6.3, as originally intended by commit
> 7defefb134270b6e8ab3e422b343b41a4a383f5d.
>
> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
> ---
> gitk-git/gitk | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index e82c6bf..9cbc09d 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -11581,7 +11581,7 @@ if {![info exists have_ttk]} {
> set use_ttk [expr {$have_ttk && $want_ttk}]
> set NS [expr {$use_ttk ? "ttk" : ""}]
>
> -set git_version [join [lrange [split [lindex [exec git version] end] .] 0 2] .]
> +regexp {^git version ([\d.]*\d)} [exec git version] _ git_version
>
> set show_notes {}
> if {[package vcompare $git_version "1.6.6.2"] >= 0} {
Seems to work well.
However, an "Reported-by" would have been nice.
People don't seem to use gitk with the RC releases because nobody else
complains...
-Mathias
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Stephen Kelly @ 2011-01-11 13:41 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, Thomas Rast, Erik Faye-Lund
In-Reply-To: <20110109172431.GA7718@burratino>
On Sun, Jan 9, 2011 at 6:24 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ramkumar Ramachandra wrote:
>
>> The 'user.name' and 'user.email' configuration
>> options set both author and committer information. To solve this,
>> introduce 'user.committername' and 'user.committeremail' configuration
>> options to override committer name and email respectively.
>
> Predictably, I don't like this idea at all. How would we explain this
> to a new user that is reading over gitconfig(5) for the first time?
> It makes the semantics of the committer and author name (that are mostly
> meant for giving credit and a contact address) much more murky.
It's like the difference between who are you, and what is your log-in
identity on remote service X.
>
> Stephen Kelly:
>
>> In KDE the committer email address is used to be able to use keywords in
>> commit messages to automatically close bugs.
>
> Is it impossible to fix this on the KDE side? I would think a
> many-to-one mapping from committer identities to bugzilla account
> names could be a useful thing to have in any case.
I asked that before coming here, and apparently that is not possible.
Thanks,
Steve.
>
> Hopeful,
> Jonathan
>
^ permalink raw reply
* Re: [BUG] difference of info from diff and blame
From: Thomas Rast @ 2011-01-11 13:40 UTC (permalink / raw)
To: Semyon Kirnosenko; +Cc: git
In-Reply-To: <4D2C333A.3010401@gmail.com>
Semyon Kirnosenko wrote:
[Word wrap fixed.]
>
> I have jquery repo (https://github.com/jquery/jquery.git)
> Let's get blame for some file in some revision:
> git blame -l -s 2ad223aedd1f93c783d98d60adc9fda3bdfbb4b6 -- src/event/event.js
> According to blame, line 127 was added in revision
> 2ad223aedd1f93c783d98d60adc9fda3bdfbb4b6.
The surrounding context (with authorship and some whitespace snipped,
obviously it's always the same) is
2ad223ae (124)
2ad223ae (125) // Pass along a fake event
2ad223ae (126) data.unshift( this.fix({ type: type, target: element }) );
2ad223ae (127)
2ad223ae (128) // Trigger the event
2ad223ae (129) if ( (val = this.handle.apply( element, data )) !== false )
2ad223ae (130) this.triggered = true;
> Let's get diff for that revision:
> git diff-tree -p 2ad223aedd1f93c783d98d60adc9fda3bdfbb4b6 -- src/event/event.js
> We can see this:
> @@ -105,19 +120,16 @@ jQuery.event = {
>
> // Handle triggering a single element
> else {
> - var handler = element["on" + type ], val,
> - fn = jQuery.isFunction( element[ type
> + var val, ret, fn = jQuery.isFunction( element
> +
> + // Pass along a fake event
> + data.unshift( this.fix({ type: type, target:
>
[this blank context line is line 127 in the postimage]
> - if ( handler ) {
>
> As you can see line 127 is not marked with '+' char, which means it was
> not added in this revision. But blame sad otherwise.
git-blame internally runs a diff with no context lines to "pass
blame". On all lines in this diff, the current commit can pass on
blame to the parent, thus avoiding having to take it for itself.
And indeed, running
git show -U0 2ad223ae -- src/event/event.js
in your repository gives a hunk
@@ -108,11 +123,8 @@ jQuery.event = {
- var handler = element["on" + type ], val,
- fn = jQuery.isFunction( element[ type ] );
-
- if ( handler ) {
- // Pass along a fake event
- data.unshift( this.fix({ type: type, target: element }) );
-
- // Trigger the event
- if ( (val = handler.apply( element, data )) !== false )
- this.triggered = true;
- }
+ var val, ret, fn = jQuery.isFunction( element[ type ] );
+
+ // Pass along a fake event
+ data.unshift( this.fix({ type: type, target: element }) );
+
+ // Trigger the event
+ if ( (val = this.handle.apply( element, data )) !== false )
+ this.triggered = true;
So I would tend to agree with the blame implementation. If anything
it's a bug in git-diff when not using any context.
Do you have a reproduction recipe that exhibits the flaw on a
non-whitespace line? I'm not up to speed on the diff implementation
(maybe someone else can help?), but I wouldn't be too surprised if it
had heuristics that put lines consisting only of whitespace at a lower
importance than "actual" lines.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Jonathan Nieder @ 2011-01-11 13:27 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Elijah Newren
In-Reply-To: <20110108000131.GR6040@onerussian.com>
Yaroslav Halchenko wrote [abbreviated]:
> CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD
> % git ls-files -u
> 160000 a2b5787 2 frontiers/code
> % git diff-tree todonotloose
> a00c497
> :040000 040000 40427e3 c7ba910 M poster-hbm2011_neurodebian
> % git diff-tree todonotloose^ HEAD
> :100644 100644 378e137 c39ced7 M .gitmodules
> :000000 040000 0000000 141dbc1 A challenge-execpapers
> :040000 040000 401fd66 ee190f0 M frontiers
> :040000 040000 26c884a ad3e829 M sty
Here is what happens.
In the heart of merge_trees:
/*
* If there are D/F conflicts, and the paths currently exist
* in the working copy as a file, remove them to make room
* for the corresponding directory. Such paths will later be
* processed in process_df_entry() at the end.
*
* If the corresponding directory ends up being removed by the
* merge, then the file will be reinstated at that time;
* otherwise, if the file is not supposed to be removed by the
* merge, the contents of the file will be placed in another
* unique filename.
*/
make_room_for_directories_of_df_conflicts(o, entries);
In this case I suppose it is rather a directory/submodule conflict; in
any case, there are no regular files involved, so this logic does not
kick in and the directory is left alone.
Next comes rename handling, which is irrelevant for our purposes.
Next comes the per entry merge.
/*
* Per entry merge. D/F conflicts are deferred so files
* contained in such a directory can be resolved first.
*/
for (i = 0; i < entries->nr; i++) {
const char *path = entries->items[i].string;
struct stage_data *e = entries->items[i].util;
if (!e->processed
&& !process_entry(o, path, e))
clean = 0;
}
This is case B: "added in one" (like all directories, the
frontiers/code directory does not have an index entry, while the
submodule does have one). Since that path is in the current directory
set, it is deferred for later processing.
Next comes the per entry merge for D/F conflicts (process_df_entry in
merge-recursive.c). This is the case "directory -> (directory,
file)". Unfortunately the check that the old and new directories
match is not implemented. Even worse, git checks for a directory
(which was not moved out of the way before) and does not realize that
a submodule might be another reason for a directory in the worktree.
In any event, we get a spurious conflict.
Thanks, that was interesting (no patch yet, alas).
^ 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