* Re: git notes: notes
From: Sverre Rabbelier @ 2010-01-24 14:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Michael J Gruber, Joey Hess, git
In-Reply-To: <vpq7hr7zism.fsf@bauges.imag.fr>
Heya,
On Sun, Jan 24, 2010 at 15:20, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> OTOH, format-patch could give the notes, below the ---, where it will
> be ignored by apply. That would make notes handy to prepare a patch
> serie with additional messages: prepare everything within Git, and use
> git send-email to send it.
I like that idea, but as an orthogonal feature, prepare notes in a
special namespace, say refs/notes/format-patch/, and then teach
format-patch a flag to honor that namespace.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git notes: notes
From: Matthieu Moy @ 2010-01-24 14:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Joey Hess, git
In-Reply-To: <7veilk1o3s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> No, but outputting the note as part of the log is the standard. So for
>> example, when you do a format-patch | apply cycle, format-patch will
>> insert the note as part of the commit message, and apply will *store*
>> the note text (including Note:\n) as part of the commit message of the
>> new commit.
>
> Thanks; that was the kind of breakage report I was looking for (and wished
> to have heard a lot earlier). Personally I find it is unexcusable that
> format-patch defaults to giving notes.
OTOH, format-patch could give the notes, below the ---, where it will
be ignored by apply. That would make notes handy to prepare a patch
serie with additional messages: prepare everything within Git, and use
git send-email to send it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #07; Fri, 22)
From: Jens Lehmann @ 2010-01-24 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hr8d1xg.fsf@alter.siamese.dyndns.org>
Am 23.01.2010 21:03, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> A patch that teaches "git diff --submodule" to display if the submodule
>> contains new untracked and/or modified files is also almost ready.
>
> How does "git submodule summary" show them? If it doesn't, then I don't
> think we would want to show them, either, as my understanding is that a
> longer-term plan is to use "diff --submodule" in git-gui to replace it.
Shawn applied the patch doing that yesterday, now gitk and git gui both
use "git diff --submodule" and not "git submodule summary" anymore. And
it would be really nice if both of these tools would show the dirtiness
of submodules in 1.7.0 (and after 1.7.0 i plan to teach "git submodule
summary" about dirtiness too).
>> Would
>> you consider it for inclusion into 1.7.0 too or shall i wait until after
>> the release?
>
> If a feature is not in 'master' already, I think it is too late to be
> included in 1.7.0, if that is what you are asking. But if you start the
> usual cycle of working on, asking others to review and polishing it before
> the release, it would give us better designed and more tested version in
> 1.7.1, no?
Sure, I'm fine with having the full functionality in 1.7.1. But a part of
it looks like a fix to me, let me explain:
Right now "git diff --submodule" doesn't show the dirty status of a
submodule at all (like it does when using it without that option and
having paid the cost to get the necessary information). So IMHO something
like the patch below should go into 1.7.0 to fix that. When applied the
output looks like this:
Submodule sub 3f35670..3f35670-dirty:
which is now consistent with the output of "git diff" without that option:
diff --git a/sub b/sub
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 3f356705649b5d566d97ff843cf193359229a453
+Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
This is a stripped down version of the patch i had in mind. I would post
the rest after 1.7.0 to give detailed output about the reasons a submodule
is dirty.
What do you think?
-- >8 --
Subject: Teach diff --submodule that modified submodule directory is dirty
Since commit 8e08b4 git diff does append "-dirty" to the work tree side
if the working directory of a submodule contains new or modified files.
Lets do the same when the --submodule option is used.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
diff.c | 2 +-
submodule.c | 3 ++
submodule.h | 1 +
t/t4041-diff-submodule.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index f130a36..381cc8d 100644
--- a/diff.c
+++ b/diff.c
@@ -1615,7 +1615,7 @@ static void builtin_diff(const char *name_a,
const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
show_submodule_summary(o->file, one ? one->path : two->path,
- one->sha1, two->sha1,
+ one->sha1, two->sha1, two->dirty_submodule,
del, add, reset);
return;
}
diff --git a/submodule.c b/submodule.c
index f657bee..ca0527f 100644
--- a/submodule.c
+++ b/submodule.c
@@ -36,6 +36,7 @@ static int add_submodule_odb(const char *path)
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
+ unsigned dirty_submodule,
const char *del, const char *add, const char *reset)
{
struct rev_info rev;
@@ -85,6 +86,8 @@ void show_submodule_summary(FILE *f, const char *path,
if (!fast_backward && !fast_forward)
strbuf_addch(&sb, '.');
strbuf_addf(&sb, "%s", find_unique_abbrev(two, DEFAULT_ABBREV));
+ if (dirty_submodule)
+ strbuf_add(&sb, "-dirty", 6);
if (message)
strbuf_addf(&sb, " %s\n", message);
else
diff --git a/submodule.h b/submodule.h
index 0773121..2336965 100644
--- a/submodule.h
+++ b/submodule.h
@@ -3,6 +3,7 @@
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
+ unsigned dirty_submodule,
const char *del, const char *add, const char *reset);
int is_submodule_modified(const char *path);
diff --git a/t/t4041-diff-submodule.sh b/t/t4041-diff-submodule.sh
index 5bb4fed..4643054 100755
--- a/t/t4041-diff-submodule.sh
+++ b/t/t4041-diff-submodule.sh
@@ -191,6 +191,73 @@ EOF
"
commit_file sm1 &&
+test_expect_success 'submodule is up to date' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+EOF
+"
+
+test_expect_success 'submodule contains untracked content' "
+ echo new > sm1/new-file &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head6-dirty:
+EOF
+"
+
+test_expect_success 'submodule contains untracked and modifed content' "
+ echo new > sm1/foo6 &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head6-dirty:
+EOF
+"
+
+test_expect_success 'submodule contains modifed content' "
+ rm -f sm1/new-file &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head6-dirty:
+EOF
+"
+
+(cd sm1; git commit -mchange foo6 >/dev/null) &&
+head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7) &&
+test_expect_success 'submodule is modified' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head8:
+ > change
+EOF
+"
+
+test_expect_success 'modified submodule contains untracked content' "
+ echo new > sm1/new-file &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head8-dirty:
+ > change
+EOF
+"
+
+test_expect_success 'modified submodule contains untracked and modifed content' "
+ echo modification >> sm1/foo6 &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head8-dirty:
+ > change
+EOF
+"
+
+test_expect_success 'modified submodule contains modifed content' "
+ rm -f sm1/new-file &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6..$head8-dirty:
+ > change
+EOF
+"
+
rm -rf sm1
test_expect_success 'deleted submodule' "
git diff-index -p --submodule=log HEAD >actual &&
--
1.6.6.1.559.g4914
^ permalink raw reply related
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Thomas Rast @ 2010-01-24 13:57 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Sixt, Junio C Hamano, Robin Rosenberg, git,
Linus Torvalds
In-Reply-To: <fabb9a1e1001231301o149bb13es236a7150f57ce161@mail.gmail.com>
On Saturday 23 January 2010 22:01:38 Sverre Rabbelier wrote:
> Heya,
>
> On Sat, Jan 23, 2010 at 21:41, Johannes Sixt <j6t@kdbg.org> wrote:
>
> > OTOH, it can be worked around easily by the user (just insert the drive
> > prefix). Dunno...
>
> I think it's preferable to keep the old behavior where we fail if the
> user gives us an invalid argument, rather than fix a user error and
> break on a a valid argument instead. I think we should be correct
> first, and try and fix incorrect user behavior after.
I can't really comment on the Windows side of things, but I tried to
come up with some more data points.
POSIX specifies that multiple slashes must be treated as if they were
a single slash (except as in the next bullet point). Leading _double_
slashes may be treated implementation-dependently. [1] Non-leading
double slashes do not seem to be specified.
There's a manpage path_resolution(7) on my system, which can also be
found on the web quite easily, e.g. [2]. It doesn't say anything
about multiple slashes, but experimentally my Linux resolves them as
if they were single slashes (even a leading double slash).
Junio's patch is already in maint, so I suppose we're in the somewhat
unfortunate situation where the old version didn't work in all cases
on Linux, but the current one breaks on Windows in some cases. Then
again, shouldn't windows get special support to figure out that /c/foo
[3] is a prefix of /foo and vice versa, assuming you're currently in
C:?
[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
Actually the server doesn't work for me, but google has a cached copy:
http://209.85.129.132/search?q=cache:QUuajH7Dp5gJ:www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html+http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11&cd=1&hl=en&ct=clnk&gl=uk
[2] http://www.kernel.org/doc/man-pages/online/pages/man7/path_resolution.7.html
[3] Don't blame me if I didn't get that syntax right, I'm actively
trying to forget I ever used Windows and it shows.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [RFC PATCH 11/10] gitweb: Ajax-y "Generating..." page when regenerating cache (WIP)
From: Jakub Narebski @ 2010-01-24 13:54 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <cover.1264198194.git.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch, as you can see, lack proper commit message: it is work in
progress (and very much proof of concept patch).
This is Ajax-y JavaScript-based activity indicator. It is very
bare-bones, without any error checking or fallback in the case we
misdetected and JavaScript is turned off. Also currently it would
work only for subsequent links from gitweb, with 'js=1' added.
We need to mark Ajax request to _not_ create "Generating..." page.
I have used there custon 'X-Ajax' HTTP header; we could use
'Pragma: wait', or ejen additional query parameter for that.
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++++++++--------------
1 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cb46b8c..d422a4b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3219,6 +3219,9 @@ sub blob_contenttype {
sub git_generating_data_html {
my ($cache, $key, $lock_fh) = @_;
+ if ($cgi->http('X-Ajax')) {
+ return;
+ }
if ($action eq 'atom' || $action eq 'rss' || $action eq 'opml' || # feeds
$action eq 'blob_plain' || # unknown mimetype
$action eq 'commitdiff_plain' || # text/plain
@@ -3241,6 +3244,7 @@ sub git_generating_data_html {
}
}
+ my $use_javascript = $cgi->param('js');
my $mod_perl_version = $ENV{'MOD_PERL'} ? " $ENV{'MOD_PERL'}" : '';
print STDOUT $cgi->header(-type => 'text/html', -charset => 'utf-8',
-status=> '200 OK', -expires => 'now');
@@ -3253,31 +3257,58 @@ sub git_generating_data_html {
<!-- git core binaries version $git_version -->
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
-<meta http-equiv="refresh" content="0" />
+EOF
+ if (!$use_javascript) {
+ print STDOUT qq!<meta http-equiv="refresh" content="0" />\n!;
+ }
+ print STDOUT <<"EOF";
<meta name="generator" content="gitweb/$version git/$git_version$mod_perl_version" />
<meta name="robots" content="noindex, nofollow" />
<title>$title</title>
</head>
<body>
EOF
- print STDOUT 'Generating..';
-
- my $ready;
- my ($wait, $wait_step, $wait_max); # in seconds
- $wait = 0;
- $wait_step = 2;
- $wait_max = 20;
- $| = 1; # autoflush
- do {
- print STDOUT '.';
-
- sleep $wait_step if ($wait > 0);
- $wait += $wait_step;
-
- $ready = flock($lock_fh, LOCK_SH|LOCK_NB)
- if $lock_fh;
-
- } while (!$ready && ($wait < $wait_max));
+ if ($use_javascript) {
+ my $url_self = href(-replay=>1);
+ print STDOUT <<"EOF";
+Generating...<br />
+<script type="text/javascript" src="$javascript"></script>
+<script type="text/javascript">
+window.onload = function () {
+ xhr = createRequestObject();
+ xhr.onreadystatechange = function () {
+ if (xhr.readyState === 4 && xhr.status === 200) {
+ // intentionally overwrite document
+ document.write(xhr.responseText);
+ }
+ }
+ xhr.open('GET', $url_self);
+ // mark request to not show "Generating..." page
+ xhr.setRequestHeader('X-Ajax', 'Yes');
+ xhr.send(null);
+}
+</script>
+EOF
+ } else {
+ print STDOUT 'Generating..';
+
+ my $ready;
+ my ($wait, $wait_step, $wait_max); # in seconds
+ $wait = 0;
+ $wait_step = 2;
+ $wait_max = 20;
+ $| = 1; # autoflush
+ do {
+ print STDOUT '.';
+
+ sleep $wait_step if ($wait > 0);
+ $wait += $wait_step;
+
+ $ready = flock($lock_fh, LOCK_SH|LOCK_NB)
+ if $lock_fh;
+
+ } while (!$ready && ($wait < $wait_max));
+ }
print STDOUT <<"EOF";
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] clarify 'git merge' documentation
From: Thomas Rast @ 2010-01-24 13:25 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <20100123092551.GA7571@progeny.tock>
On Saturday 23 January 2010 10:25:51 Jonathan Nieder wrote:
> Jonathan Nieder (7):
> Documentation: merge: move configuration section to end
> Documentation: suggest `reset --merge` in How Merge Works section
> Documentation: merge: move merge strategy list to end
> Documentation: merge: add an overview
> Documentation: emphasize when git merge terminates early
> Documentation: merge: add a section about fast-forward
> Documentation: simplify How Merge Works
[and in the other thread]
> Jonathan Nieder (1):
> Documentation: merge: use MERGE_HEAD to refer to the remote branch
Thanks Jonathan! Ack on all of them.
I still had the following patches in my little documentation queue:
Jonathan Nieder (2):
Documentation: git gc packs refs by default now
Documentation: tiny git config manual tweaks
Thomas Rast (2):
Documentation: show-files is now called git-ls-files
Documentation: emphasise 'git shortlog' in its synopsis
I actually forgot to post the last one, which I'll do shortly, but
it's trivial so I just included it at the bottom.
Junio, I gathered all of the above patches and pushed them again to
git://repo.or.cz/git/trast.git doc-style/for-next
If that's ok and you merge it, I'll declare this the end of this
little topic. Admittedly it grew a bit outside the original area of
style fixes into a half-rewrite of git-merge(1).
-- 8< --
Subject: [PATCH] Documentation: emphasise 'git shortlog' in its synopsis
The accepted style in the SYNOPSIS section is for a command to be
'emphasised'. Do so for the git-shortlog(1) manpage.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index ecf9e27..dfd4d0c 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
-git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
+'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
DESCRIPTION
-----------
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: cherry picking several patches at once
From: Felipe Contreras @ 2010-01-24 13:10 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <1264330354.14140.1.camel@gandalf>
On Sun, Jan 24, 2010 at 12:52 PM, Felipe Balbi <me@felipebalbi.com> wrote:
> On Sat, 2010-01-23 at 01:57 +0200, Felipe Contreras wrote:
>> Have you tried something like:
>> git format-patch old-base --full-diff -- /path
>> git am -3 *.patch
>
> yes, sure that can be done, but the idea is to avoid having
> format-patch, switch branches and git am those patches ;-)
When you do a 'git rebase' you are also doing a format-patch/am, but
that happens inside the script; you can write a script that does what
you want in a way that you wouldn't notice it: save the old branch,
git stash, switch to new branch, generate the patches, apply the
patches, switch back to the old branch, git stash pop.
>> I think that would not be possible because of the challenges when
>> dealing with conflicts.
>
> there shouldn't be any. I have the same driver internally and publicly
> and would be cherry-picking only the patches for that particular driver.
Ok, in that case we would just need a cherry-pick that can commit to a
separate branch, however I don't think git internals allow that kind
of thing.
--
Felipe Contreras
^ permalink raw reply
* Re: git 1.6.6.1 on glibc 2.2
From: Jonathan Nieder @ 2010-01-24 12:27 UTC (permalink / raw)
To: Gabor Z. Papp; +Cc: git
In-Reply-To: <x6y6jn4txy@gzp>
Hi!
Gabor Z. Papp wrote:
> Hello all,
>
> trying to compile git 1.6.6.1 on Linux 2.4.37.7, glibc 2.2.5:
>
> read-cache.c: In function 'fill_stat_cache_info':
> read-cache.c:72: error: 'struct stat' has no member named 'st_ctim'
Thanks for the report. Perhaps:
$ grep -C3 st_ctim Makefile
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).
#
# Define USE_ST_TIMESPEC if your "struct stat" uses "st_ctimespec" instead of
# "st_ctim"
#
# Define NO_NSEC if your "struct stat" does not have "st_ctim.tv_nsec"
# available. This automatically turns USE_NSEC off.
#
# Define USE_STDEV below if you want git to care about the underlying device
Hope that helps,
Jonathan
^ permalink raw reply
* git 1.6.6.1 on glibc 2.2
From: Gabor Z. Papp @ 2010-01-24 11:35 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hello all,
trying to compile git 1.6.6.1 on Linux 2.4.37.7, glibc 2.2.5:
read-cache.c: In function 'fill_stat_cache_info':
read-cache.c:72: error: 'struct stat' has no member named 'st_ctim'
read-cache.c:73: error: 'struct stat' has no member named 'st_mtim'
read-cache.c: In function 'read_index_from':
read-cache.c:1316: error: 'struct stat' has no member named 'st_mtim'
read-cache.c: In function 'write_index':
read-cache.c:1581: error: 'struct stat' has no member named 'st_mtim'
make: *** [read-cache.o] Error 1
[-- Attachment #2: log.make --]
[-- Type: application/octet-stream, Size: 5267 bytes --]
GIT_VERSION = 1.6.6.1
* new build flags or prefix
CC fast-import.o
CC abspath.o
CC advice.o
CC alias.o
CC alloc.o
CC archive.o
CC archive-tar.o
CC archive-zip.o
CC attr.o
CC base85.o
CC bisect.o
bisect.c: In function 'bisect_next_all':
bisect.c:869: warning: dereferencing pointer '__u' does break strict-aliasing rules
bisect.c:869: note: initialized from here
CC blob.o
CC branch.o
CC bundle.o
bundle.c: In function 'verify_bundle':
bundle.c:125: warning: dereferencing pointer '__u' does break strict-aliasing rules
bundle.c:125: note: initialized from here
CC cache-tree.o
CC color.o
CC combine-diff.o
combine-diff.c: In function 'show_patch_diff':
combine-diff.c:223: warning: dereferencing pointer '__u' does break strict-aliasing rules
combine-diff.c:223: note: initialized from here
CC commit.o
CC config.o
CC connect.o
CC convert.o
convert.c: In function 'apply_filter':
convert.c:291: warning: dereferencing pointer '__u' does break strict-aliasing rules
convert.c:291: note: initialized from here
convert.c:291: warning: dereferencing pointer '__u' does break strict-aliasing rules
convert.c:291: note: initialized from here
convert.c:291: warning: dereferencing pointer '__u' does break strict-aliasing rules
convert.c:291: note: initialized from here
convert.c:291: warning: dereferencing pointer '__u' does break strict-aliasing rules
convert.c:291: note: initialized from here
CC copy.o
CC csum-file.o
CC ctype.o
CC date.o
CC decorate.o
CC diffcore-break.o
CC diffcore-delta.o
CC diffcore-order.o
CC diffcore-pickaxe.o
CC diffcore-rename.o
CC diff-delta.o
CC diff-lib.o
CC diff-no-index.o
CC diff.o
diff.c: In function 'diff_words_show':
diff.c:711: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:711: note: initialized from here
diff.c: In function 'diff_get_patch_id':
diff.c:3317: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:3317: note: initialized from here
diff.c:3328: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:3328: note: initialized from here
diff.c: In function 'builtin_diffstat':
diff.c:1815: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:1815: note: initialized from here
diff.c: In function 'run_diff_cmd':
diff.c:1718: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:1718: note: initialized from here
diff.c: In function 'diff_flush':
diff.c:1862: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:1862: note: initialized from here
diff.c:3461: warning: dereferencing pointer '__u' does break strict-aliasing rules
diff.c:3461: note: initialized from here
CC dir.o
CC editor.o
CC entry.o
CC environment.o
CC exec_cmd.o
CC fsck.o
CC graph.o
CC grep.o
CC hash.o
CC help.o
help.c: In function 'help_unknown_cmd':
help.c:308: warning: dereferencing pointer '__u' does break strict-aliasing rules
help.c:308: note: initialized from here
help.c:309: warning: dereferencing pointer '__u' does break strict-aliasing rules
help.c:309: note: initialized from here
help.c:310: warning: dereferencing pointer '__u' does break strict-aliasing rules
help.c:310: note: initialized from here
CC ident.o
CC levenshtein.o
CC list-objects.o
CC ll-merge.o
ll-merge.c: In function 'll_xdl_merge':
ll-merge.c:79: warning: dereferencing pointer '__u' does break strict-aliasing rules
ll-merge.c:79: note: initialized from here
CC lockfile.o
CC log-tree.o
CC mailmap.o
CC match-trees.o
CC merge-file.o
merge-file.c: In function 'merge_file':
merge-file.c:64: warning: dereferencing pointer '__u' does break strict-aliasing rules
merge-file.c:64: note: initialized from here
merge-file.c:33: warning: dereferencing pointer '__u' does break strict-aliasing rules
merge-file.c:33: note: initialized from here
CC merge-recursive.o
CC name-hash.o
CC notes.o
CC object.o
CC pack-check.o
CC pack-refs.o
pack-refs.c: In function 'pack_refs':
pack-refs.c:89: warning: dereferencing pointer '__u' does break strict-aliasing rules
pack-refs.c:89: note: initialized from here
pack-refs.c:89: warning: dereferencing pointer '__u' does break strict-aliasing rules
pack-refs.c:89: note: initialized from here
pack-refs.c:89: warning: dereferencing pointer '__u' does break strict-aliasing rules
pack-refs.c:89: note: initialized from here
CC pack-revindex.o
CC pack-write.o
CC pager.o
CC parse-options.o
CC patch-delta.o
CC patch-ids.o
CC path.o
CC pkt-line.o
CC preload-index.o
CC pretty.o
CC progress.o
CC quote.o
CC reachable.o
CC read-cache.o
read-cache.c: In function 'fill_stat_cache_info':
read-cache.c:72: error: 'struct stat' has no member named 'st_ctim'
read-cache.c:73: error: 'struct stat' has no member named 'st_mtim'
read-cache.c: In function 'read_index_from':
read-cache.c:1316: error: 'struct stat' has no member named 'st_mtim'
read-cache.c: In function 'write_index':
read-cache.c:1581: error: 'struct stat' has no member named 'st_mtim'
make: *** [read-cache.o] Error 1
^ permalink raw reply
* Re: cherry picking several patches at once
From: Felipe Balbi @ 2010-01-24 10:52 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4531001221557n7a892f03u5e5d1c5e5ba5fea0@mail.gmail.com>
Hi,
On Sat, 2010-01-23 at 01:57 +0200, Felipe Contreras wrote:
> Have you tried something like:
> git format-patch old-base --full-diff -- /path
> git am -3 *.patch
yes, sure that can be done, but the idea is to avoid having
format-patch, switch branches and git am those patches ;-)
> I think that would not be possible because of the challenges when
> dealing with conflicts.
there shouldn't be any. I have the same driver internally and publicly
and would be cherry-picking only the patches for that particular driver.
--
balbi
^ permalink raw reply
* [ANNOUNCE] TortoiseGit 1.3.2.0 Release
From: Frank Li @ 2010-01-24 10:25 UTC (permalink / raw)
To: git, tortoisegit-dev, tortoisegit-users, tortoisegit-announce,
tortoisegit
Download:
http://tortoisegit.googlecode.com/files/TortoiseGit-1.3.2.0-32bit.msi
http://tortoisegit.googlecode.com/files/TortoiseGit-1.3.2.0-64bit.msi
This release build Git source as a DLL. LogDialog will call gitdll to
fetch log instead of capture git.exe output.
Improve refresh and all branch user experience. refresh can abort
runing fetch log commit.
KNOWN ISSUE:
gitdll.dll will miss if install on the 1.2.1.0 or previous version.
work around: Remove previous version before install 1.3.2.0, or launch
1.3.2.0 setup and repair it.
I am sorry for this issue.
= Release 1.3.2.0 =
== Bug Fix ==
* Fixed issue #276: Crash on seeing diff with previous version
* Fixed issue #275: Load gitweb for 'Browse' button
* Fixed issue #265: Log dialog: Date picker throws multiple error
messages when date is before 1.1.1970
* Fix RefLogDlg crash
= Release 1.3.1.0 =
== Features ==
* Improve Log Dialog. Speed up log fetch speed.
Build Git source as a DLL. LogDialog will call gitdll to fetch log
instead of capture git.exe output.
Improve refresh and all branch user experience. refresh can abort
runing fetch log commit.
* Improve icon-overlay
Give up igit.exe and use tgit which build from git source by VS.
use tgit.exe statusex to get file status.
Don't list all untracked files.
* Improve commit and checkout modify dialog
Don't show file that is only time stamp change and no context change.
Run git-update-index first when open commit and checkout out modify dialog.
== Bug Fix ==
* Fixed issue #234: First log(first commit in history) was missing...
* Fixed issue #232: "No Commit" Option always acitve
* Fix Issue 236: CGit::GetRemoteList uses bad regular expression
* Fix blame show wrong when first char is '^'
* Workaround show "fail" even git run success at sometime by remove
"fail" message.
* Issue 265: Log dialog: Date picker throws multiple error messages
when date is before 1.1.1970
^ permalink raw reply
* Re: Advice for "pseudo public" repository on a USB key for a single contributer project
From: Wincent Colaiuta @ 2010-01-24 10:21 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Maxime Lévesque, git
In-Reply-To: <be6fef0d1001231817s265dac68v646d71b688e0ed1e@mail.gmail.com>
El 24/01/2010, a las 03:17, Tay Ray Chuan escribió:
> Hi,
>
> 2010/1/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>> Since there are no servers involved, I have used pull command
>> to move my 'HEAD' around :
>>
>> after working on machine1 I do :
>>
>> commit to machine1Repo
>> machine1Repo --pull--> USBKeyRepo
>
> I think you mean "push", since what you want is to make the changes in
> machine1Repo available in USBKeyRepo.
>
>> when I switch on machine2 I start by bringing it up to date from
>> the key :
>>
>>
>> machine2Repo <--pull-- USBKeyRepo
>>
>> and when I'm finished :
>>
>> commit to machine2Repo
>> machine1Repo --pull--> USBKeyRepo
>
> I think you mean "push" here and s/machine1/machine2/ too, so that
> would read
>
> machine2Repo --push--> USBKeyRepo
>
> When you make changes on machine2 and go back to machine1, you need to
> fetch/pull in your changes, just like you do for machine2Repo:
>
> machine1Repo <--pull-- USBKeyRepo
>
>> From what I have read my USBKey repo is like a public repo,
>> so I have tried using a bare repo, because since I never work
>> directly on the usb key, the souces on this repo are just
>> adding unnecessary complexity. So far I had no success,
>> because the pull command doesn't recognize my bare repo,
>> it seems that bare repos must me accessed via a daemon process.
For this kind of workflow I generally use pull in both directions.
Push works only if it results in fast-forward merges in both
directions, and if you are a little forgetful like me it's fairly easy
to sooner or later forget to update one of the repos and end up making
commits in both of them, leading to a situation in which at least one
of the merges would have to be a non-fast-forward.
If you always pull, you are at least working in a non-bare repo at
that point and you can choose to either (non-fast-forward) merge or
rebase.
Unless you are really disciplined about synchronizing the repos before
you ever start any work, then I think "pull" in both directions is the
way to go.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Windows: Remove dependency on pthreadGC2.dll
From: Michael Lukashov @ 2010-01-24 10:10 UTC (permalink / raw)
To: git; +Cc: Andrzej K. Haczewski, Johannes Sixt, Michael Lukashov
Commit 44626dc7 (MSVC: Windows-native implementation for subset
of threads API, 2010-01-15) introduces builtin replacement of
pthreadGC2.dll functionality, thus we can completely drop
dependency on this dll.
Signed-off-by: Michael Lukashov <michael.lukashov@gmail.com>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index c0dbee2..af08c8f 100644
--- a/Makefile
+++ b/Makefile
@@ -994,6 +994,7 @@ ifeq ($(uname_S),Windows)
COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
EXTLIBS = advapi32.lib shell32.lib wininet.lib ws2_32.lib
+ PTHREAD_LIBS =
lib =
ifndef DEBUG
BASIC_CFLAGS += -GL -Os -MT
@@ -1036,11 +1037,12 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PYTHON = YesPlease
BLK_SHA1 = YesPlease
THREADED_DELTA_SEARCH = YesPlease
- COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/fnmatch
+ COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/fnmatch -Icompat/win32
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
COMPAT_OBJS += compat/mingw.o compat/fnmatch/fnmatch.o compat/winansi.o \
compat/win32/pthread.o
EXTLIBS += -lws2_32
+ PTHREAD_LIBS =
X = .exe
ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
htmldir=doc/git/html/
--
1.6.6.1599.gaed1a
^ permalink raw reply related
* Re: Modern Git GUI
From: Matthieu Moy @ 2010-01-24 9:50 UTC (permalink / raw)
To: André Harms; +Cc: git
In-Reply-To: <e39c1dcf1001231340p67448584pfdbc453cc8fb9ca7@mail.gmail.com>
André Harms <andre.harms@kuhlsolutions.de> writes:
> So I thought about developing a new kind of GUI for Git that looks
> modern and attractive
Every once in a while, someone comes and says "Git GUIs aren't as good
as I'd expect, I'll write my own". The result is that we have a myriad
of GUIs (see
http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces ),
many of them being half-finished and/or abandonned. I don't believe
adding yet-another-one is going to improve the situation, and
pick-one-and-improve-it is IMHO a much better approach.
> (you know... some eye-candy stuff) and that is easy to use.
I use mostly the command-line, so I couldn't make a detailed review of
the existing, but tools like git-cola and a few others sound "modern"
to me (Qt4 & co).
If you decide to go on with your project, either you want to carry it
out alone, or you'll have to convince other developers to join. In the
second case, a good starting point would be to explain why the other
GUI are not good enough, and why you can't just contribute to them.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: basic question about push
From: Jeff King @ 2010-01-24 8:15 UTC (permalink / raw)
To: Russ Paielli; +Cc: git
In-Reply-To: <loom.20100124T074722-510@post.gmane.org>
On Sun, Jan 24, 2010 at 07:04:59AM +0000, Russ Paielli wrote:
> warning: updating the current branch
> [...]
> What does this mean in English? And what is the correct way to transfer my
> revisions from my home computer to my work computer? Thanks.
It means your workflow will cause problems as the pusher magically
changes your repository's concept of "the latest commit" behind the
pushee's back. The workflow you want is described here:
http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #07; Fri, 22)
From: Junio C Hamano @ 2010-01-24 8:10 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, Linus Torvalds
In-Reply-To: <7veilg9rqp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think we need to clarify the rule for ce_uptodate(ce).
A first step to do so may look like this.
-- >8 --
Subject: Make ce_uptodate() trustworthy again
The rule has always been that a cache entry that is ce_uptodate(ce)
means that we already have checked the work tree entity and we know
there is no change in the work tree compared to the index, and nobody
should have to double check. Note that false ce_uptodate(ce) does not
mean it is known to be dirty---it only means we don't know if it is
clean.
There are a few codepaths (refresh-index and preload-index are among
them) that mark a cache entry as up-to-date based solely on the return
value from ie_match_stat(); this function uses lstat() to see if the
work tree entity has been touched, and for a submodule entry, if its
HEAD points at the same commit as the commit recorded in the index of
the superproject (a submodule that is not even cloned is considered
clean).
A submodule is no longer considered unmodified merely because its HEAD
matches the index of the superproject these days, in order to prevent
people from forgetting to commit in the submodule and updating the
superproject index with the new submodule commit, before commiting the
state in the superproject. However, the patch to do so didn't update
the codepath that marks cache entries up-to-date based on the updated
definition and instead worked it around by saying "we don't trust the
return value of ce_uptodate() for submodules."
This makes ce_uptodate() trustworthy again by not marking submodule
entries up-to-date.
The next step _could_ be to introduce a few "in-core" flag bits to
cache_entry structure to record "this entry is _known_ to be dirty",
call is_submodule_modified() from ie_match_stat(), and use these new
bits to avoid running this rather expensive check more than once, but
that can be a separate patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff-lib.c | 2 +-
preload-index.c | 2 ++
read-cache.c | 6 ++++--
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 23e180e..c6c425e 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -161,7 +161,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
continue;
}
- if ((ce_uptodate(ce) && !S_ISGITLINK(ce->ce_mode)) || ce_skip_worktree(ce))
+ if (ce_uptodate(ce) || ce_skip_worktree(ce))
continue;
/* If CE_VALID is set, don't look at workdir for file removal */
diff --git a/preload-index.c b/preload-index.c
index 9289933..e3d0bda 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -47,6 +47,8 @@ static void *preload_thread(void *_data)
if (ce_stage(ce))
continue;
+ if (S_ISGITLINK(ce->ce_mode))
+ continue;
if (ce_uptodate(ce))
continue;
if (!ce_path_match(ce, p->pathspec))
diff --git a/read-cache.c b/read-cache.c
index 79938bf..309b77a 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -612,7 +612,8 @@ int add_to_index(struct index_state *istate, const char *path, struct stat *st,
if (alias && !ce_stage(alias) && !ie_match_stat(istate, alias, st, ce_option)) {
/* Nothing changed, really */
free(ce);
- ce_mark_uptodate(alias);
+ if (!S_ISGITLINK(alias->ce_mode))
+ ce_mark_uptodate(alias);
alias->ce_flags |= CE_ADDED;
return 0;
}
@@ -1050,7 +1051,8 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
* because CE_UPTODATE flag is in-core only;
* we are not going to write this change out.
*/
- ce_mark_uptodate(ce);
+ if (!S_ISGITLINK(ce->ce_mode))
+ ce_mark_uptodate(ce);
return ce;
}
}
^ permalink raw reply related
* basic question about push
From: Russ Paielli @ 2010-01-24 7:04 UTC (permalink / raw)
To: git
I am just starting to learn git. I would like to start by using git to work
remotely. My work computer and home computer both run Linux. I can log into my
work computer from home, but not vice versa. For several years, I have been
using ssh (with X forwarding) to login to my work computer from home. I have
been basically using my home computer as an X terminal. I would like to start
actually working locally on my home computer and use git to stay sync'd with my
work computer.
I created a git repository on my work machine, and I cloned it on my home
machine. As a test, I edited a file on my home machine and pushed it to my work
machine. I guess I don't understand how to use push. I got this:
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 278 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning:
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning:
warning: To squelch this message, you can set it to 'warn'.
warning:
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.
To ssh://localhost:6666/home/paielli/scala
7ea65c7..c52864c master -> master
What does this mean in English? And what is the correct way to transfer my
revisions from my home computer to my work computer? Thanks.
Russ P.
^ permalink raw reply
* Re: [PATCH 3/3] rebase -i: Export GIT_AUTHOR_* variables explicitly
From: Michael Haggerty @ 2010-01-24 5:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, tarmigan+git, j.sixt
In-Reply-To: <7viqatu9rv.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> [...]
> So I tend to think this patch would be the cleanest and safest
> alternative, albeit it may cost an extra fork.
>
> What do you think?
>
> -- >8 --
> Subject: rebase -i: Export GIT_AUTHOR_* variables explicitly
Your version is fine with me.
Michael
^ permalink raw reply
* Re: Advice for "pseudo public" repository on a USB key for a single contributer project
From: Tay Ray Chuan @ 2010-01-24 2:17 UTC (permalink / raw)
To: Maxime Lévesque; +Cc: git
In-Reply-To: <554f5f781001231027vd322045hf84e2a16208bcc9f@mail.gmail.com>
Hi,
2010/1/24 Maxime Lévesque <maxime.levesque@gmail.com>:
> Since there are no servers involved, I have used pull command
> to move my 'HEAD' around :
>
> after working on machine1 I do :
>
> commit to machine1Repo
> machine1Repo --pull--> USBKeyRepo
I think you mean "push", since what you want is to make the changes in
machine1Repo available in USBKeyRepo.
> when I switch on machine2 I start by bringing it up to date from the key :
>
>
> machine2Repo <--pull-- USBKeyRepo
>
> and when I'm finished :
>
> commit to machine2Repo
> machine1Repo --pull--> USBKeyRepo
I think you mean "push" here and s/machine1/machine2/ too, so that would read
machine2Repo --push--> USBKeyRepo
When you make changes on machine2 and go back to machine1, you need to
fetch/pull in your changes, just like you do for machine2Repo:
machine1Repo <--pull-- USBKeyRepo
> From what I have read my USBKey repo is like a public repo,
> so I have tried using a bare repo, because since I never work
> directly on the usb key, the souces on this repo are just
> adding unnecessary complexity. So far I had no success,
> because the pull command doesn't recognize my bare repo,
> it seems that bare repos must me accessed via a daemon process.
What's your config?
Assuming you use master everywhere, I think you could use this in your config:
[remote "USBKeyRepo"]
url = /path/to/repo
fetch = master
[branch "master"]
remote = USBKeyRepo
merge = master
> Is it wise to use pulls instead of pushes ?
See above. You can't use one "instead of" another - they serve
different purposes and don't replace one another.
> Should I be using a bare repo on my key ?
Definitely, or else you would have a working tree in that repo too but
it never gets updated - not to mention all the warnings git would
show.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #07; Fri, 22)
From: Junio C Hamano @ 2010-01-24 2:11 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <7v7hr8d1xg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> ...
>> @@ -220,7 +224,7 @@ static int get_stat_data(struct cache_entry *ce,
>> const unsigned char **sha1p,
>> unsigned int *modep,
>> int cached, int match_missing,
>> - unsigned *dirty_submodule, int output_format)
>> + unsigned *dirty_submodule, struct diff_options *diffopt)
>> {
>> const unsigned char *sha1 = ce->sha1;
>> unsigned int mode = ce->ce_mode;
>
> Below the context of this hunk, we seem to do this:
>
> if (!cached && !ce_uptodate(ce)) {
> ...
> if gitlink then call is_submodule_modified()
> }
>
> But isn't it inconsistent with hunk at the beginning of this patch (ll 161-170)
> that essentially says "entries that is ce_uptodate() is Ok, but if it is a
> gitlink we need to look deeper"? Why isn't this function looking deeper
> even when we see that the submodule entry is ce_uptodate()?
>
> Side note: the lack of ce_skip_worktree() check is Ok. The callers of
> get_stat_data() are show_new_file() and show_mododified() but they are
> never called from their sole caller, do_oneway_diff(), on a skipped
> worktree entry.
I think we need to clarify the rule for ce_uptodate(ce).
The rule has always been that an entry that is ce_uptodate(ce) is _known_
to be clean, and nobody should have to dig deeper to double check. We
should keep it that way.
We at least need to fix preload_index() not to mark any gitlink entries
with ce_mark_uptodate(ce), as your series changes the definition of a
dirty submodule. It used to be that if a submodule is checked out and its
HEAD matches what is recorded in the index of the superproject, then the
submodule is clean. The checks made in preload_thread() is consistent
with this definition.
With the update, we consider that having local changes in the submodule
(either to the index or to the work tree files) makes it modified (which
by the way is a right definition, and prevents people from forgetting to
commit in the submodule and updating the superproject index with the new
submodule commit, before commiting the state in the superproject).
Because the checks in preload_thread() does not cover this kind of change
that is_submodule_modified() reports, it shouldn't mark a gitlink entry as
ce_uptodate(ce).
Another possibility is to run the is_submodule_modified() check inside
ie_match_stat(), but (1) I don't know if that function is thread-safe, and
(2) I don't think we would want to do it in preload-index time (it is
rather expensive).
The reason preload_index() passes CE_MATCH_RACY_IS_DIRTY to ie_match_stat()
is to avoid doing a rather expensive ce_modified_check_fs() --- it avoids
the overhead and leaves the expensive check to the true callers that care
if the entry is really clean. In the same sense, even if we were to run
is_submodule_modified() there, we would want to avoid doing so when we are
running ie_match_stat() from preload codepath.
We need to also see if there other codepaths that call
ce_mark_uptodate(ce) on a gitlink that hasn't been checked with
is_submodule_modified(), and eliminate them.
Then we can fix the "even though ce_uptodate(ce) says this entry is clean,
if it is gitlink, we need to double check" insanity around ll 164 of
diff-lib.c. We should be able to trust ce_uptodate(ce) even for gitlinks.
What do you think?
^ permalink raw reply
* Re: [PATCH] git-gui: set GIT_DIR and GIT_WORK_TREE after setup
From: Shawn O. Pearce @ 2010-01-24 0:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1264291140-16595-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> Rather than juggling with the env var GIT_DIR around the invocation of
> gitk, set it and GIT_WORK_TREE after finishing setup, ensuring that any
> external tool works with the setup we're running with.
>
> This also allows us to remove a couple of conditionals when running gitk
> or git gui in a submodule, as we know that the variables are present and
> have to be unset and reset before and after the invocation.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> git-gui.sh | 43 ++++++++++++++++++++-----------------------
> 1 files changed, 20 insertions(+), 23 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* [PATCH] git-gui: set GIT_DIR and GIT_WORK_TREE after setup
From: Giuseppe Bilotta @ 2010-01-23 23:59 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <20100123232215.GI12679@spearce.org>
Rather than juggling with the env var GIT_DIR around the invocation of
gitk, set it and GIT_WORK_TREE after finishing setup, ensuring that any
external tool works with the setup we're running with.
This also allows us to remove a couple of conditionals when running gitk
or git gui in a submodule, as we know that the variables are present and
have to be unset and reset before and after the invocation.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
git-gui.sh | 43 ++++++++++++++++++++-----------------------
1 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 5d39955..81143c7 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1171,6 +1171,9 @@ if {[lindex $_reponame end] eq {.git}} {
set _reponame [lindex $_reponame end]
}
+set env(GIT_DIR) $_gitdir
+set env(GIT_WORK_TREE) $_gitworktree
+
######################################################################
##
## global init
@@ -1979,7 +1982,7 @@ set starting_gitk_msg [mc "Starting gitk... please wait..."]
proc do_gitk {revs {is_submodule false}} {
global current_diff_path file_states current_diff_side ui_index
- global _gitworktree
+ global _gitdir _gitworktree
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
@@ -1991,19 +1994,12 @@ proc do_gitk {revs {is_submodule false}} {
} else {
global env
- if {[info exists env(GIT_DIR)]} {
- set old_GIT_DIR $env(GIT_DIR)
- } else {
- set old_GIT_DIR {}
- }
-
set pwd [pwd]
if {!$is_submodule} {
if {![is_bare]} {
cd $_gitworktree
}
- set env(GIT_DIR) [file normalize [gitdir]]
} else {
cd $current_diff_path
if {$revs eq {--}} {
@@ -2024,15 +2020,18 @@ proc do_gitk {revs {is_submodule false}} {
}
set revs $old_sha1...$new_sha1
}
- if {[info exists env(GIT_DIR)]} {
- unset env(GIT_DIR)
- }
+ # GIT_DIR and GIT_WORK_TREE for the submodule are not the ones
+ # we've been using for the main repository, so unset them.
+ # TODO we could make life easier (start up faster?) for gitk
+ # by setting these to the appropriate values to allow gitk
+ # to skip the heuristics to find their proper value
+ unset env(GIT_DIR)
+ unset env(GIT_WORK_TREE)
}
eval exec $cmd $revs "--" "--" &
- if {$old_GIT_DIR ne {}} {
- set env(GIT_DIR) $old_GIT_DIR
- }
+ set env(GIT_DIR) $_gitdir
+ set env(GIT_WORK_TREE) $_gitworktree
cd $pwd
ui_status $::starting_gitk_msg
@@ -2053,22 +2052,20 @@ proc do_git_gui {} {
error_popup [mc "Couldn't find git gui in PATH"]
} else {
global env
+ global _gitdir _gitworktree
- if {[info exists env(GIT_DIR)]} {
- set old_GIT_DIR $env(GIT_DIR)
- unset env(GIT_DIR)
- } else {
- set old_GIT_DIR {}
- }
+ # see note in do_gitk about unsetting these vars when
+ # running tools in a submodule
+ unset env(GIT_DIR)
+ unset env(GIT_WORK_TREE)
set pwd [pwd]
cd $current_diff_path
eval exec $exe gui &
- if {$old_GIT_DIR ne {}} {
- set env(GIT_DIR) $old_GIT_DIR
- }
+ set env(GIT_DIR) $_gitdir
+ set env(GIT_WORK_TREE) $_gitworktree
cd $pwd
ui_status $::starting_gitk_msg
--
1.6.6.rc1.295.g3a4e71
^ permalink raw reply related
* More on svn workflows
From: tom fogal @ 2010-01-23 22:57 UTC (permalink / raw)
To: git
I have recently (1, 1.5 months ago?) started using a workflow similar
to the one described here:
http://www.spinics.net/lists/git/msg109896.html
(short summary: work in private branch, "merge --no-ff" into svn
upstream, "merge" from svn upstream.)
... with the minor modification that I use "--squash" instead of
"--no-ff". If I use --no-ff, I end up with a lot of "merge from master
into <myprivatebranch>" commits on my master branch before I dcommit.
It also merges in a lot of history that I feel like I shouldn't see--
that is, both the svn commit and my private branch's commit, and I'm
worried about what might happen if I dcommit that. That said, I might
be in that situation because I used --squash 3 or 4 times before I
realized I was misremembering that thread.
Anyway, my current issue is that whenever I do a `git commit' after a
"merge --squash", I end up with *everything* I've done since starting
the branch in the commit message. To be more explicit, say I've got
this setup:
o--o--o master
\
o--o--o private branch started
then I'll update master and merge it into my private branch:
o--o--o--------D master
\ \
A--B--C--o private
test, merge --squash private into master and dcommit:
o--o--o--------D---A'--B'--C'--D'' master
\ \ /
A--B--C--D' private
something happens upstream:
o--o--o--------D---A'--B'--C'--D''--E master
\ \ /
A--B--C--D' private
which I merge to private:
o--o--o--------D---A'--B'--C'--D''--E master
\ \ / \
A--B--C--D'-------------------E' private
I do some work, commit F, and decide I want to push it upstream, so
I'll do a merge --squash into master:
o--o--o--------D---A'--B'--C'--D''--E-------F' master
\ \ / \ /
A--B--C--D'-------------------E'--F private
Now the issue is when I `git commit' the merge from private, git says
this is a "squashed commit of the following", and lists the commit
messages for A, B, C, D, D', D'' E, E' and F. I really just want the
commit message for "F" in this case -- every other message is already
on the trunk, in a different commit. This wasn't such a big issue
at first: git picked up a few extra commits, so I hacked out the log
messages before committing them on master. After doing this for a
while though, there's something like 100 commits I have to wade through
while doing this, and it's only going to get worse and worse.
On the other hand, I'm sure there's some option I could use so "git
commit" would startup with an empty commit message in this case, but I
do *want* the partial history, as it helps me design the commit message
that I want the svn trunk's history to have.
What am I doing wrong?
-tom
^ permalink raw reply
* Re: [PATCHv4 4/5] git-gui: set GIT_DIR and GIT_WORK_TREE after setup
From: Shawn O. Pearce @ 2010-01-23 23:22 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Markus Heidelberg
In-Reply-To: <1264241018-6616-5-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> Rather than juggling $GIT_DIR around the invocation of gitk, set it
> (and $GIT_WORK_TREE) after finishing setup, ensuring that any external
> tool works with the setup we're running with.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> git-gui/git-gui.sh | 15 +++------------
> 1 files changed, 3 insertions(+), 12 deletions(-)
This patch has merge conflicts with changes from Jens Lehmann
related to starting gitk inside of a submodule. Since I merged
his menu code first, I would appreciate it if you could rebase this
one patch on top of my latest master:
git://git.spearce.org/git-gui.git master
The other 4 patches in this series are already applied, thanks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Make it possible to apply a range of changes at once
From: Shawn O. Pearce @ 2010-01-23 23:05 UTC (permalink / raw)
To: jepler; +Cc: git, Heiko Voigt, Peter Baumann
In-Reply-To: <1260231763-19194-3-git-send-email-jepler@unpythonic.net>
jepler@unpythonic.net wrote:
> From: Jeff Epler <jepler@unpythonic.net>
>
> Signed-off-by: Jeff Epler <jepler@unpythonic.net>
> ---
> git-gui.sh | 15 +++-
> lib/diff.tcl | 242 ++++++++++++++++++++++++++++++++++------------------------
> 2 files changed, 153 insertions(+), 104 deletions(-)
Thanks, applied.
--
Shawn.
^ 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