* Re: [PATCH/RFC 0/3] git rerere unresolve file
From: Johannes Sixt @ 2009-11-22 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v6393mfqz.fsf@alter.siamese.dyndns.org>
On Sonntag, 22. November 2009, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > ... But
> > there is no other way to remove an incorrect resolution short of purging
> > the whole rr-cache.
>
> No, no no, no. You do not have to.
Oh, yeah, I know. But even for people who know how to drive plumbing commands,
this:
> "ls -t1 .git/rr-cache/*/thisimage | head"
> would be one way to manually find out which one it is.
does not count as "you can" in my book. ;) It assumes that there are at most a
handful conflicted files. In my case, for example, I have to fix a merge
where there are ~100 conflicted files.
> * Then the user tells rerere that "this is the corrected resolution",
> perhaps
>
> $ git rerere update Documentation/git-commit.txt
>
> This will
>
> - Internally recompute the original conflicted state, i.e. run
> "checkout --conflict=merge Documentation/git-commit.txt" in-core;
>
> - feed it to rerere.c::handle_file() to learn the conflict hash;
>
> - read the user's updated resolution from the work tree, and update
> "postimage" with it.
>
> ...
>
> The "forget" subcommand may be useful, but the real implementation should
> be the first half of the "update", iow, recreate conflict in-core in order
> to compute the conflict hash, and drop existing "postimage", without
> replacing it from the work tree. We should leave it up to the user using
> "checkout --conflict" to reproduce the conflict in the work tree.
Thank you for your elaborate feedback and the guidelines about how to move
forward.
I actually think that 'forget' should be the primary subcommand. Because after
the postimage was purged, the next implicit or explicit 'git rerere' will
record the resolution anyway. I'll see what I can do.
-- Hannes
^ permalink raw reply
* git-svn: Fails to drop leading path from empty dir name
From: Björn Steinbrink @ 2009-11-22 13:46 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Hi Eric,
the stuff to create empty directories fails to strip leading path
components, e.g. when using
"git svn clone -s svn://whatever/project/trunk".
Instead of creating the empty directory "foo" in the repo root, it
creates "project/trunk/foo".
Ad hoc patch for the test case below.
Björn
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
index 5948544..9e22089 100755
--- a/t/t9146-git-svn-empty-dirs.sh
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -82,4 +82,27 @@ test_expect_success 'git svn mkdirs -r works' '
)
'
+test_expect_success 'initialize trunk' '
+ for i in trunk trunk/a trunk/"weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
+
+test_expect_success 'empty directories in trunk exist' '
+ (
+ cd cloned &&
+ for i in trunk/a trunk/"weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-22 12:37 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <94a0d4530911211159l1fadad0ldb0d760439ceb57@mail.gmail.com>
On Sat, Nov 21, 2009 at 9:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sat, Nov 21, 2009 at 9:36 PM, Jeff King <peff@peff.net> wrote:
>> --envelope-from is IMHO confusingly similar to
>> --envelope-sender. Maybe --use-from-in-envelope would be a better name?
>
> Ok. I don't have any opinion on the name.
I thought a bit more about this, and in the end what we really want is
to add the sender envelope. The most typical case would be to use the
'from' address, but we should be able to override it (we do both by
using --envelope-sender).
So here are other options.
a) --add-envelope: add the sender envelope, by default it would be the
'from' address, but could be overridden by --envelope-sender.
b) --envelope-sender="" or "auto": this would require minimal changes
but looks a bit strange.
Any thoughts?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-22 12:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v1vjrmfjw.fsf@alter.siamese.dyndns.org>
On Sun, Nov 22, 2009 at 4:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> There are no tests for 'envelope-sender', so I don't think it should
>> be a requirement for this patch to do so....
>
> The fact that the lack of test was pointed out as a problem makes it a
> requirement. Others' earlier mistakes are not an excuse for you to do a
> poor job.
Maybe I should wait until somebody adds the tests to --envelope-sender
before pushing this patch.
> I do use --envelope-sender when sending patches out via msmtp. What
> wonderful things this patch adds am I missing in my current setup?
You need to specify your mail address when setting the variable,
right? I use multiple email addresses, so that when I change it
($EMAIL or user.email) the right one will be used in the envelope. If
I use 'sendemail.envelopesender' I would
need to change it as well.
Another option is to do something like 'sendemail.envelopesender=auto'.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] User Manual: Write "Git" instead of "GIT"
From: Björn Gustavsson @ 2009-11-22 9:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In the Table of Contents, there is a notable inconsistency:
first there is "GIT Glossary", followed by "Git Quick Reference"
on the very next line.
Running "grep -c" on user-manual.txt, I find 780 occurrrences of
"git", 37 occurrences of "Git", and 9 occurrences of "GIT".
In general, "git" is the preferred spelling, except at the
beginning of a sentence.
Therefore, change "GIT Glossary" to "Git Glossary" for consistency
with the rest of the document.
Looking at the other eight occurrences of "GIT" I found one other
occurrence that should be changed:
* The mention of "StGIT". Looking at the web pages for "Stacked Git"
at http://www.procode.org/stgit, I only saw the spelling "StGit",
except in http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial,
but that page was last updated in 2006.
The other seven occurrences should not be changed:
* Three occurrences were in the output of 'git show-branch' run
on the git.git repository.
* One occurrence was in the output of 'git cat-file'.
* One occurrence was as part of the file name "GIT-VERSION-GEN".
* Two occurrences were in comments in scripts quoted in a description
of Tony Luck's workflow.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/user-manual.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..27d97b6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2569,7 +2569,7 @@ them again with linkgit:git-am[1].
Other tools
-----------
-There are numerous other tools, such as StGIT, which exist for the
+There are numerous other tools, such as StGit, which exist for the
purpose of maintaining a patch series. These are outside of the scope of
this manual.
@@ -4275,7 +4275,7 @@ You see, Git is actually the best tool to find out about the source of Git
itself!
[[glossary]]
-GIT Glossary
+Git Glossary
============
include::glossary-content.txt[]
--
1.6.5.3.298.g39add
^ permalink raw reply related
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Laszlo Papp @ 2009-11-22 8:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Laszlo Papp, git
In-Reply-To: <19205.2740.244981.703612@cargo.ozlabs.ibm.com>
On Thu, Nov 19, 2009 at 10:07 AM, Paul Mackerras <paulus@samba.org> wrote:
> Laszlo Papp writes:
>
>> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
>> ---
>> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Is there a patch 1/2 that needs to be applied first, as the subject
> line might imply?
>
> Paul.
>
It's the file of the new hungarian translation, it can be applied
alone without any plus file/patch.
Best Regards,
Laszlo Papp
^ permalink raw reply
* [PATCH v4 2/4] replace: use a GIT_NO_REPLACE_OBJECTS env variable
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state, and
the "--no-replace-objects" option can be used from the command
line to do so.
But the effects of this command line option were not propagated
to git commands called by the original command that was passed
this option.
The goal of this patch is to propagate these effects by using
a new GIT_NO_REPLACE_OBJECTS environment variable.
This environment variable is set when the --no-replace-objects
flag is passed to git, and it is read when other environment
variables are read.
It is useful for example for scripts, as the git commands used in
them can now be aware that they must not read replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 1 +
connect.c | 1 +
environment.c | 2 ++
git.c | 3 +++
t/t6050-replace.sh | 17 +++++++++++++++++
5 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 22a06d6..fcdc954 100644
--- a/cache.h
+++ b/cache.h
@@ -374,6 +374,7 @@ static inline enum object_type object_type(unsigned int mode)
#define CONFIG_ENVIRONMENT "GIT_CONFIG"
#define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
#define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
+#define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
#define ATTRIBUTE_MACRO_PREFIX "[attr]"
diff --git a/connect.c b/connect.c
index 839a103..db965c9 100644
--- a/connect.c
+++ b/connect.c
@@ -609,6 +609,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
GIT_WORK_TREE_ENVIRONMENT,
GRAFT_ENVIRONMENT,
INDEX_ENVIRONMENT,
+ NO_REPLACE_OBJECTS_ENVIRONMENT,
NULL
};
conn->env = env;
diff --git a/environment.c b/environment.c
index ed17043..c7ebc54 100644
--- a/environment.c
+++ b/environment.c
@@ -85,6 +85,8 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = git_pathdup("info/grafts");
+ if (read_replace_refs && getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
+ read_replace_refs = 0;
}
int is_bare_repository(void)
diff --git a/git.c b/git.c
index 743ee57..11544cd 100644
--- a/git.c
+++ b/git.c
@@ -89,6 +89,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--no-replace-objects")) {
read_replace_refs = 0;
+ setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "1", 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index d4818b4..203ffdb 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -77,6 +77,11 @@ test_expect_success 'test --no-replace-objects option' '
git --no-replace-objects show $HASH2 | grep "A U Thor"
'
+test_expect_success 'test GIT_NO_REPLACE_OBJECTS env variable' '
+ GIT_NO_REPLACE_OBJECTS=1 git cat-file commit $HASH2 | grep "author A U Thor" &&
+ GIT_NO_REPLACE_OBJECTS=1 git show $HASH2 | grep "A U Thor"
+'
+
cat >tag.sig <<EOF
object $HASH2
type commit
@@ -202,6 +207,18 @@ test_expect_success 'fetch branch with replacement' '
cd ..
'
+test_expect_success 'bisect and replacements' '
+ git bisect start $HASH7 $HASH1 &&
+ test "$S" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset &&
+ GIT_NO_REPLACE_OBJECTS=1 git bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset &&
+ git --no-replace-objects bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 4/4] Documentation: replace: talk a little bit about GIT_NO_REPLACE_OBJECTS
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
It may be useful to know that this environment variable can be used
to prevent commands from using replacement refs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 69f704f..65a0da5 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -44,6 +44,9 @@ $ git cat-file commit foo
shows information about commit 'bar'.
+The 'GIT_NO_REPLACE_OBJECTS' environment variable can be set to
+achieve the same effect as the `--no-replace-objects` option.
+
OPTIONS
-------
-f::
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 3/4] gitk: add "--no-replace-objects" option
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state, and
"--no-replace-objects" option can be used from the command
line to do so.
This option simply sets the GIT_NO_REPLACE_OBJECTS environment
variable, and that is enough to make gitk ignore replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
gitk-git/gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..c586b93 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -128,7 +128,7 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
+ global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
# git rev-parse doesn't understand --merge
lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
}
+ "--no-replace-objects" {
+ set env(GIT_NO_REPLACE_OBJECTS) "1"
+ }
"-*" {
# Other flag arguments including -<n>
if {[string is digit -strict [string range $arg 1 end]]} {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 1/4] Documentation: fix typos and spelling in git-replace documentation
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
This patch fix a missing "s" at the end of an occurence of
"--no-replace-objects" and, while at it, it also improves spelling
and rendering of the git-replace man page.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 8adc1ef..69f704f 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -17,31 +17,32 @@ DESCRIPTION
Adds a 'replace' reference in `.git/refs/replace/`
The name of the 'replace' reference is the SHA1 of the object that is
-replaced. The content of the replace reference is the SHA1 of the
+replaced. The content of the 'replace' reference is the SHA1 of the
replacement object.
-Unless `-f` is given, the replace reference must not yet exist in
+Unless `-f` is given, the 'replace' reference must not yet exist in
`.git/refs/replace/` directory.
-Replace references will be used by default by all git commands except
-those doing reachability traversal (prune, pack transfer and fsck).
+Replacement references will be used by default by all git commands
+except those doing reachability traversal (prune, pack transfer and
+fsck).
-It is possible to disable use of replacement refs for any command
-using the --no-replace-objects option just after "git".
+It is possible to disable use of replacement references for any
+command using the `--no-replace-objects` option just after 'git'.
-For example if commit "foo" has been replaced by commit "bar":
+For example if commit 'foo' has been replaced by commit 'bar':
------------------------------------------------
-$ git --no-replace-object cat-file commit foo
+$ git --no-replace-objects cat-file commit foo
------------------------------------------------
-show information about commit "foo", while:
+shows information about commit 'foo', while:
------------------------------------------------
$ git cat-file commit foo
------------------------------------------------
-show information about commit "bar".
+shows information about commit 'bar'.
OPTIONS
-------
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 0/4] add new GIT_NO_REPLACE_OBJECTS env variable
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
Here are all the patches together.
The other change (except putting them together) is that I tried to
improve the commit messages as suggested by Paul and Junio.
The first patch contains documentation fixes and could be applied to
"maint".
Christian Couder (4):
Documentation: fix typos and spelling in git-replace documentation
replace: use a GIT_NO_REPLACE_OBJECTS env variable
gitk: add "--no-replace-objects" option
Documentation: replace: talk a little bit about
GIT_NO_REPLACE_OBJECTS
Documentation/git-replace.txt | 24 ++++++++++++++----------
cache.h | 1 +
connect.c | 1 +
environment.c | 2 ++
git.c | 3 +++
gitk-git/gitk | 5 ++++-
t/t6050-replace.sh | 17 +++++++++++++++++
7 files changed, 42 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH] submodule.c: Squelch a "use before assignment" warning
From: Junio C Hamano @ 2009-11-22 3:32 UTC (permalink / raw)
To: Christoph Bartoschek; +Cc: git
In-Reply-To: <7vws1jl0xp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Christoph Bartoschek <bartoschek@gmx.de> writes:
>
>> Why is the compiler not complaining about the fake initalization? For
>> initialization a value is used that is not initialized.
>
> That is a fairly well established idiom to tell gcc "you may mistakenly
> think it isn't, but this is used".
Sorry, but I was called away from the keyboard in mid sentence. It should
have read "...this is used after getting assigned, so do not worry".
But I need to clarify a few things about this issue.
As the maintainer, I do not like a fake initialisation myself very much.
It is a declaration that "left" is always assigned before getting used by
the person who wrote _that particular version_, but later updates to the
code might introduce a codepath to incorrectly use "left" before getting
assinged to, and the fake initialisation will prevent the compiler from
catching it.
When the variable in question is a pointer, assigning NULL instead of
"left = left" will at least give us a predictable and more reproducible
breakage when later updates break the code. I wouldn't have minded if
David's patch were to update both the existing fake initialisation and the
new one to assign NULL. At least dereferencing such a pointer will give
us a segfault reliably. But unfortunately there is no such "magic" values
for variables of other types (e.g. int) to help us catch uninitialized use
of variables at runtime.
By the way, if a static analyser is meant to be useful for real-world
programs, as opposed to merely an academic exercise, it should know this
convention; like it or not, it is used fairly widely. That is, it should
check "left" is assigned before used in the rest of the function without
this "gcc hack" initializer, and if the only questionable use of "left" is
the RHS of this fake initialisation, should refrain from warning.
^ permalink raw reply
* Re: [PATCH] submodule.c: Squelch a "use before assignment" warning
From: Junio C Hamano @ 2009-11-22 2:59 UTC (permalink / raw)
To: Christoph Bartoschek; +Cc: git
In-Reply-To: <c5plt6-5me.ln1@burns.bruehl.pontohonk.de>
Christoph Bartoschek <bartoschek@gmx.de> writes:
> Why is the compiler not complaining about the fake initalization? For
> initialization a value is used that is not initialized.
That is a fairly well established idiom to tell gcc "you may mistakenly
think it isn't, but this is used".
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Junio C Hamano @ 2009-11-22 2:58 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <94a0d4530911211159l1fadad0ldb0d760439ceb57@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> There are no tests for 'envelope-sender', so I don't think it should
> be a requirement for this patch to do so....
The fact that the lack of test was pointed out as a problem makes it a
requirement. Others' earlier mistakes are not an excuse for you to do a
poor job.
I do use --envelope-sender when sending patches out via msmtp. What
wonderful things this patch adds am I missing in my current setup?
^ permalink raw reply
* Re: [PATCH/RFC 0/3] git rerere unresolve file
From: Junio C Hamano @ 2009-11-22 2:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200911211958.40872.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> ... But
> there is no other way to remove an incorrect resolution short of purging the
> whole rr-cache.
No, no no, no. You do not have to.
As long as you can find out the <preimage,postimage> pair, iow, the
subdirectory used by .git/rr-cache/, you can remove only "postimage" from
there and redo your merge. "ls -t1 .git/rr-cache/*/thisimage | head"
would be one way to manually find out which one it is.
For example, let's take this merge as an example.
commit 697eb20061dfa00838df32ac24c414dfb4a1f920
Merge: bba637b 46b77a6
Author: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/1.7.0-status' into jch
You may not have rerere entries for this, so follow me along for a while.
$ git checkout bba637b
$ git merge 46b77a6
This will have a conflict. We are priming your rerere database, so we
cheat (notice the last dot ".").
$ git checkout 697eb200 -- .
$ git rerere
Now reset it away, and redo the merge
$ git reset --hard
$ git checkout bba637b
$ git merge 46b77a6
It will autoresolve the way I resolved in 697eb200
Suppose you do not like the resolution; you can do:
$ git checkout --conflict=merge Documentation/git-commit.txt
$ git rerere
to force updating "thisimage". The newest one is the entry you are
looking for.
$ ls -1t .git/rr-cache/*/thisimage | head -n 1
.git/rr-cache/02aac459b0c777f92a8ca6f1e449e6760d366c20/thisimage
I can remove "postimage" from the directory, recreate conflict again,
run rerere to remember it anew, resolve and have rerere remember the new
resolution.
A tool support to compute the conflict hash would be part of a nice
solution.
$ git checkout --conflict=merge Documentation/git-commit.txt
$ git rerere hash
02aac459b0c777f92a8ca6f1e449e6760d366c20 Documentation/git-commit.txt
Instead of giving "hash" subcommand and having the user to remove
postimage from the directory, the tool can remove it, of course.
$ git checkout --conflict=merge Documentation/git-commit.txt
$ git rerere forget Documentation/git-commit.txt
02aac459b0c777f92a8ca6f1e449e6760d366c20 Documentation/git-commit.txt
$ edit Documentation/git-commit.txt ;# come up with a better resolution
$ git rerere ;# record it
The attached are rough sketch of such "hash/forget" subcommands.
I however think the best user experience would go like this:
* Run "git merge"; rerere replays an earlier resolution.
$ git merge ...
User decides that it is not a desirable one.
* User fixes it and creates a better resolution in the work tree. The
user may fix-up the autoresolution or the user may first do "checkout
--conflict=merge" and resolves the conflict from scratch.
It does not matter how the updated resolution is prepared in the work
tree.
* Then the user tells rerere that "this is the corrected resolution",
perhaps
$ git rerere update Documentation/git-commit.txt
This will
- Internally recompute the original conflicted state, i.e. run
"checkout --conflict=merge Documentation/git-commit.txt" in-core;
- feed it to rerere.c::handle_file() to learn the conflict hash;
- read the user's updated resolution from the work tree, and update
"postimage" with it.
There is no need to change MERGE_RR at all if you did it the way outlined
in the above.
My "hash" would be more-or-less a useless command. It still might be
useful as a plumbing command, but it is mostly for debugging.
The "forget" subcommand may be useful, but the real implementation should
be the first half of the "update", iow, recreate conflict in-core in order
to compute the conflict hash, and drop existing "postimage", without
replacing it from the work tree. We should leave it up to the user using
"checkout --conflict" to reproduce the conflict in the work tree.
builtin-rerere.c | 4 +++
rerere.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
rerere.h | 2 +
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 343d6cd..8865313 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -108,6 +108,10 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
if (!strcmp(argv[1], "-h"))
usage(git_rerere_usage);
+ else if (!strcmp(argv[1], "hash"))
+ return rerere_report_hash();
+ else if (!strcmp(argv[1], "forget"))
+ return rerere_forget(argv + 2);
fd = setup_rerere(&merge_rr);
if (fd < 0)
diff --git a/rerere.c b/rerere.c
index 29f95f6..4899219 100644
--- a/rerere.c
+++ b/rerere.c
@@ -392,3 +392,61 @@ int rerere(void)
return 0;
return do_plain_rerere(&merge_rr, fd);
}
+
+int rerere_forget(const char **path)
+{
+ struct string_list conflict = { NULL, 0, 0, 1 };
+ int i;
+
+ find_conflict(&conflict);
+
+ /*
+ * Note note note. I am being lazy here. The loop should not
+ * iterate over "path" like this.
+ *
+ * It should instead iterate over conflict entries, using "path"
+ * as pathspec to filter, so that you can say "I am done with
+ * all the conflict in Documentation/ area".
+ */
+ for (i = 0; path[i]; i++) {
+ unsigned char sha1[20];
+ const char *postimage;
+ int ret;
+
+ if (!string_list_has_string(&conflict, path[i])) {
+ error("No such conflicted path %s\n", path[i]);
+ continue;
+ }
+ ret = handle_file(path[i], sha1, NULL);
+ if (ret < 1) {
+ error("No conflict in work tree %s\n", path[i]);
+ continue;
+ }
+ postimage = rerere_path(sha1_to_hex(sha1), "postimage");
+ if (!unlink(postimage))
+ fprintf(stderr, "forgot resolution for %s\n", path[i]);
+ else if (errno == ENOENT)
+ error("no remembered resolution for %s", path[i]);
+ else
+ error("cannot unlink %s: %s", postimage, strerror(errno));
+ }
+ return 0;
+}
+
+int rerere_report_hash(void)
+{
+ struct string_list conflict = { NULL, 0, 0, 1 };
+ int i;
+
+ find_conflict(&conflict);
+ for (i = 0; i < conflict.nr; i++) {
+ const char *path = conflict.items[i].string;
+ unsigned char sha1[20];
+ int ret;
+ ret = handle_file(path, sha1, NULL);
+ if (ret < 1)
+ continue;
+ printf("%s %s\n", sha1_to_hex(sha1), path);
+ }
+ return 0;
+}
diff --git a/rerere.h b/rerere.h
index 13313f3..a10dea9 100644
--- a/rerere.h
+++ b/rerere.h
@@ -7,5 +7,7 @@ extern int setup_rerere(struct string_list *);
extern int rerere(void);
extern const char *rerere_path(const char *hex, const char *file);
extern int has_rerere_resolution(const char *hex);
+extern int rerere_report_hash(void);
+extern int rerere_forget(const char **path);
#endif
^ permalink raw reply related
* Re: Per file configurable eol-style transformations with Git?
From: Junio C Hamano @ 2009-11-22 1:24 UTC (permalink / raw)
To: Alexander Veit; +Cc: git
In-Reply-To: <1050CAACABF64864A0CF79C957BF773B@helium>
"Alexander Veit" <alexander.veit@gmx.net> writes:
> Jakub Narebski wrote:
>
>> See `crlf` attribute, which can be set, unset, unspecified, set
>> to "input", and used together with core.autocrlf ("true", "false",
>> "input") and core.safecrlf. Attributes can be set per path (using
>> globbing patterns) in .gitattributes file in tree, or in
>> .git/info/attributes (per repository).
>
> I've already tried
>
> [core]
> autoCRLF = true
>
> in the global gitconfig under Windows.
That would not be per-file anyway.
What Jakub suggested makes sense. You want to read up on
gitattributes(5).
^ permalink raw reply
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Junio C Hamano @ 2009-11-22 1:21 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4B072D98.6020101@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> I haven't tried this patch, but I think you may need to add something like
> the following (*not tested*):
>
> --- >8 ---
> diff --git a/compat/cygwin.c b/compat/cygwin.c
> index b4a51b9..7e9edec 100644
> --- a/compat/cygwin.c
> +++ b/compat/cygwin.c
> @@ -53,6 +53,7 @@ static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
> buf->st_size = (off_t)fdata.nFileSizeLow;
> #endif
> buf->st_blocks = size_to_blocks(buf->st_size);
> + buf->st_blksize = 512;
> filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
> filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
> filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
> --- >8 ---
Doesn't this contradict with everything you said?
You are forcing st_blksize to 512 but still return the same old st_blocks;
I do not understand what that would achieve.
In your experiments, st_blocks was reported in 1024-byte blocks and that
size coincided with what was reported in st_blksize, and that was the
whole point of the approach taken by the ST_BLOCKS_COUNTS_IN_BLKSIZE
patch.
^ permalink raw reply
* Re: Per file configurable eol-style transformations with Git?
From: Alexander Veit @ 2009-11-21 23:49 UTC (permalink / raw)
To: git
In-Reply-To: <m3tywnbmpj.fsf@localhost.localdomain>
Jakub Narebski wrote:
> See `crlf` attribute, which can be set, unset, unspecified, set
> to "input", and used together with core.autocrlf ("true", "false",
> "input") and core.safecrlf. Attributes can be set per path (using
> globbing patterns) in .gitattributes file in tree, or in
> .git/info/attributes (per repository).
I've already tried
[core]
autoCRLF = true
in the global gitconfig under Windows. After git clone an immediate
git diff shows every line changed in certain files:
diff --git a/c_crlf_text.txt b/c_crlf_text.txt
index 3b0a76f..3473745 100644
--- a/c_crlf_text.txt
+++ b/c_crlf_text.txt
@@ -1,5 +1,5 @@
-z1
-z2
-z3
-z4
-
+z1
+z2
+z3
+z4
+
file * on Windows:
c___lf_text.txt; ASCII text, with CRLF line terminators
c_crlf_text.txt; ASCII text, with CRLF line terminators
file * on Linux
c_crlf_text.txt: ASCII text, with CRLF line terminators
c___lf_text.txt: ASCII text
I don't know if this behaviour is supposed to be correct,
but to me it seems to be wrong.
git version 1.6.5.1.1367.gcd48
--
Cheers,
Alex
^ permalink raw reply related
* [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.
From: Matthieu Moy @ 2009-11-21 22:00 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <4B06A7EE.2090801@atlas-elektronik.com>
Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
is a sane default.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Change since v1 : just changed gitignore -> gitexcludes.
Documentation/config.txt | 1 +
dir.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 39d1226..13871a6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -384,6 +384,7 @@ core.excludesfile::
of files which are not meant to be tracked. "~/" is expanded
to the value of `$HOME` and "~user/" to the specified user's
home directory. See linkgit:gitignore[5].
+ Default: ~/.gitexcludes.
core.editor::
Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index d0999ba..cf3d8b4 100644
--- a/dir.c
+++ b/dir.c
@@ -914,9 +914,16 @@ void setup_standard_excludes(struct dir_struct *dir)
dir->exclude_per_dir = ".gitignore";
path = git_path("info/exclude");
+ if (!excludes_file) {
+ const char *home = getenv("HOME");
+ char *user_gitignore = malloc(strlen(home) + strlen("/.gitexcludes") + 1);
+ strcpy(user_gitignore, home);
+ strcat(user_gitignore, "/.gitexcludes");
+ excludes_file = user_gitignore;
+ }
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
- if (excludes_file && !access(excludes_file, R_OK))
+ if (!access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: David Aguilar @ 2009-11-21 21:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paul Mackerras, peff@peff.net, sam@vilain.net,
git@vger.kernel.org, markus.heidelberg@web.de
In-Reply-To: <7veinsx6lj.fsf@alter.siamese.dyndns.org>
On Nov 20, 2009, at 12:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I do not read Tcl very well but I am guessing that in gitk you specify
>>>
>>
> what tool to run (e.g. "frobanodiff -z"), gitk feeds you two temporary
> files on the filesystem to compare (e.g. "frobanodiff -z $tmp1
> $tmp2"),
> and your command line is responsible for giving satisfying diff
> experience
> to the end user.
>
> I see three possible approaches:
>
> * Teach "git-difftool" a mode to compare two arbitrary files on the
> filesytem, and set that as "External Diff" command that takes the
> filenames as extra two parameters, just like any other "External
> Diff"
> programs given to gitk does. This is the least palatable, as it
> won't
> solve the read-only repository issue at all (it only allows you the
> logic to choose the configured difftool backend program).
>
> * Instead of disabling the traditional "External Diff" and taking it
> over
> like your patch did, add a new codepath for "Difftool" that feeds
> the
> commit IDs and paths the way git-difftool expects. The user can use
> both, and the issue of read-only repository is solved when
> "Difftool"
> is used (but not "External Diff").
>
> * Take over "External Diff" codepath exactly like your patch did, but
> teach "git-difftool" a new command line option to name an
> unconfigured
> external program that takes two filenames. When "External Diff"
> program is *not* configured in gitk, the command line to invoke
> difftool would be exactly as in your patch, i.e. "difftool --no-
> prompt
> $from $to -- $path". Otherwise, when gitk is configured to use an
> external program, e.g. "frobanodiff -z", for "External Diff", you
> pass
> that command line to "git-difftool" via that new option, e.g.
>
> difftool --no-prompt --extcmd="frobanodiff -z" $from $to -- $path
>
> Then difftool is responsible for preparing the two necessary
> temporary
> files out of the given information ($from/$to/$path) and feeding
> them
> to "frobanodiff -z" command line.
>
> Maybe such --extcmd support already exists in difftool, in which
> case
> my earlier suspicion that difftool is not as flexible would be
> false.
Sounds good. Adding --extcmd should be nice and straightforward.
Markus mentioned the need for a diff.guitool variable that would be
tested for in the gitk case so it sounds like having a --gui option to
let difftool know to do that should then cover all the bases.
It's looking like we'll have ourselves a small difftool patch series
soon. Thanks all,
--
David
^ permalink raw reply
* Re: Per file configurable eol-style transformations with Git?
From: Jakub Narebski @ 2009-11-21 21:18 UTC (permalink / raw)
To: Alexander Veit; +Cc: git
In-Reply-To: <9ED0EB52C33C41209726C6F4DB7FC194@helium>
"Alexander Veit" <alexander.veit@gmx.net> writes:
> we have projects that contain text files that need to
> have different end-of-line sequences, depending on the
> type of file, and depending on the operating system where
> they are checked out.
>
> There are files that have
>
> - LF line breaks on each platform,
> - CR LF line breaks on each platform, or
> - either LF or CR LF line breaks, depending on the
> platform's native end-of-line style.
>
> With Subversion, the correct behaviour in checkouts, commits,
> diffs, or merges can easily be achieved by setting the appropriate
> svn:eol-style [*].
>
> As I understand the Git documentation there's no such concept as a
> repository end-of-line style, or as an end-of-line transformation
> between repository and working copy.
>
> So I wonder if it is possible to mimic Subversion's end-of-line handling
> with Git, especially for the svn:eol-style=native.
See `crlf` attribute, which can be set, unset, unspecified, set to
"input", and used together with core.autocrlf ("true", "false", "input")
and core.safecrlf. Attributes can be set per path (using globbing
patterns) in .gitattributes file in tree, or in .git/info/attributes
(per repository).
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] submodule.c: Squelch a "use before assignment" warning
From: Christoph Bartoschek @ 2009-11-21 18:46 UTC (permalink / raw)
To: git
In-Reply-To: <7v8we17ha9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) compiler
>> (and probably others) mistakenly thinks variable 'right' is used
>> before assigned. Work it around by giving it a fake initialization.
>
> We see the same "fake initialization" of 'left' on the same line. By
> initializing it to NULL, you are hinting that initializing 'right' to
> NULL actually means something.
Why is the compiler not complaining about the fake initalization? For
initialization a value is used that is not initialized.
At least a static analyzer complains:
"submodule.c", line 41: The variable `left' is used before its
initialization
Christoph
^ permalink raw reply
* Per file configurable eol-style transformations with Git?
From: Alexander Veit @ 2009-11-21 20:21 UTC (permalink / raw)
To: git
Hi,
we have projects that contain text files that need to
have different end-of-line sequences, depending on the
type of file, and depending on the operating system where
they are checked out.
There are files that have
- LF line breaks on each platform,
- CR LF line breaks on each platform, or
- either LF or CR LF line breaks, depending on the
platform's native end-of-line style.
With Subversion, the correct behaviour in checkouts, commits,
diffs, or merges can easily be achieved by setting the appropriate
svn:eol-style [*].
As I understand the Git documentation there's no such concept as a
repository end-of-line style, or as an end-of-line transformation
between repository and working copy.
So I wonder if it is possible to mimic Subversion's end-of-line handling
with Git, especially for the svn:eol-style=native.
--
Regards,
Alex
[*]
http://svnbook.red-bean.com/nightly/de/svn-book.html#svn.advanced.props.special.eol-style
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-21 19:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091121193600.GA3296@coredump.intra.peff.net>
On Sat, Nov 21, 2009 at 9:36 PM, Jeff King <peff@peff.net> wrote:
> So my first thought was "how in the world is this different from setting
> the envelope sender?"
>
> Reading the code, it seems:
[...]
> that this is a boolean to mean "use the from address as the envelope
> sender".
>
> It was of course all the more confusing for not being documented at all,
> but even if documented,
Right, I forgot the one-liner for the help.
> --envelope-from is IMHO confusingly similar to
> --envelope-sender. Maybe --use-from-in-envelope would be a better name?
Ok. I don't have any opinion on the name.
> And of course, your patch is missing docs and tests.
There are no tests for 'envelope-sender', so I don't think it should
be a requirement for this patch to do so. I'll add the documentation
though.
Will resend v2.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Jeff King @ 2009-11-21 19:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1258825410-28592-1-git-send-email-felipe.contreras@gmail.com>
On Sat, Nov 21, 2009 at 07:43:30PM +0200, Felipe Contreras wrote:
> Some MTAs make smart decisions based on the 'from' envelope (i.e. msmtp)
So my first thought was "how in the world is this different from setting
the envelope sender?"
Reading the code, it seems:
> - $raw_from = $envelope_sender if (defined $envelope_sender);
> + if (defined $envelope_sender) {
> + $raw_from = $envelope_sender;
> + $envelope_from = 1;
> + }
> $raw_from = extract_valid_address($raw_from);
> unshift (@sendmail_parameters,
> - '-f', $raw_from) if(defined $envelope_sender);
> + '-f', $raw_from) if(defined $envelope_from);
that this is a boolean to mean "use the from address as the envelope
sender".
It was of course all the more confusing for not being documented at all,
but even if documented, --envelope-from is IMHO confusingly similar to
--envelope-sender. Maybe --use-from-in-envelope would be a better name?
And of course, your patch is missing docs and tests.
-Peff
^ 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