* [StGit PATCH 3/5] Do not create an empty patch if import failed without --reject
From: Catalin Marinas @ 2009-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
If the import failed, do not leave an empty patch on the stack. If this
is required, the --reject option should be passed. The patch also fixes
a lowercase typo in the --reject option description.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/imprt.py | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index aa75065..de77635 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -68,7 +68,7 @@ options = [
opt('-b', '--base', args = [argparse.commit],
short = 'Use BASE instead of HEAD for file importing'),
opt('--reject', action = 'store_true',
- short = 'leave the rejected hunks in corresponding *.rej files'),
+ short = 'Leave the rejected hunks in corresponding *.rej files'),
opt('-e', '--edit', action = 'store_true',
short = 'Invoke an editor for the patch description'),
opt('-d', '--showdiff', action = 'store_true',
@@ -154,8 +154,13 @@ def __create_patch(filename, message, author_name, author_email,
base = git_id(crt_series, options.base)
else:
base = None
- git.apply_patch(diff = diff, base = base, reject = options.reject,
- strip = options.strip)
+ try:
+ git.apply_patch(diff = diff, base = base, reject = options.reject,
+ strip = options.strip)
+ except git.GitException:
+ if not options.reject:
+ crt_series.delete_patch(patch)
+ raise
crt_series.refresh_patch(edit = options.edit,
show_patch = options.showdiff,
author_date = author_date,
^ permalink raw reply related
* [StGit PATCH 4/5] Add the -p option to fold
From: Catalin Marinas @ 2009-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström, git
In-Reply-To: <20090916214049.6622.44662.stgit@toshiba-laptop>
This option was added to import, so it makes sense for fold to have it
as well.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/fold.py | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/fold.py b/stgit/commands/fold.py
index 28e824c..ce0459e 100644
--- a/stgit/commands/fold.py
+++ b/stgit/commands/fold.py
@@ -39,6 +39,8 @@ options = [
short = 'Perform a three-way merge with the current patch'),
opt('-b', '--base', args = [argparse.commit],
short = 'Use BASE instead of HEAD when applying the patch'),
+ opt('-p', '--strip', type = 'int', metavar = 'N',
+ short = 'Remove N leading slashes from diff paths (default 1)'),
opt('--reject', action = 'store_true',
short = 'Leave the rejected hunks in corresponding *.rej files')]
@@ -75,11 +77,13 @@ def func(parser, options, args):
crt_patch = crt_series.get_patch(current)
bottom = crt_patch.get_bottom()
git.apply_patch(filename = filename, base = bottom,
- reject = options.reject)
+ strip = options.strip, reject = options.reject)
elif options.base:
git.apply_patch(filename = filename, reject = options.reject,
+ strip = options.strip,
base = git_id(crt_series, options.base))
else:
- git.apply_patch(filename = filename, reject = options.reject)
+ git.apply_patch(filename = filename, strip = options.strip,
+ reject = options.reject)
out.done()
^ permalink raw reply related
* [PATCH v2] Update the usage bundle string.
From: Thiago Farina @ 2009-09-16 21:32 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Currently the usage bundle string is not well formatted.
Now it is formatted and the user can read the string much more easily.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-bundle.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 9b58152..9946592 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -9,7 +9,11 @@
* bundle supporting "fetch", "pull", and "ls-remote".
*/
-static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
+static const char builtin_bundle_usage[] = "\
+ git bundle create <file> <git-rev-list args>\n\
+ git bundle verify <file>\n\
+ git bundle list-heads <file> [refname...]\n\
+ git bundle unbundle <file> [refname...]";
int cmd_bundle(int argc, const char **argv, const char *prefix)
{
@@ -19,8 +23,8 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
int bundle_fd = -1;
char buffer[PATH_MAX];
- if (argc < 3)
- usage(bundle_usage);
+ if (argc < 3)
+ usage(builtin_bundle_usage);
cmd = argv[1];
bundle_file = argv[2];
@@ -59,5 +63,5 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
return !!unbundle(&header, bundle_fd) ||
list_bundle_refs(&header, argc, argv);
} else
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: Behavior of 'git add \*.txt': bug or feature?
From: Matthieu Moy @ 2009-09-16 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbplazl7s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> It this the intended behavior? If so, what's the rationale for this?
>
> I strongly suspect that it comes from the fact that we have two
> definitions and three implementations of pathspec-aware tree traversal.
> One family is unaware of shell-glob wildcards (they only do leading
> directory path match) while the other know both leading directory path and
> shell-glob.
>
> It is on the list of long-term items to fix, as the change required is
> quite involved.
OK, that answers my question.
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Update the usage bundle string.
From: Thiago Farina @ 2009-09-16 21:20 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Currently the usage bundle string is not well formatted.
Now it is formatted and the user can read the string much more easily.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-bundle.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 9b58152..2e98907 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -11,6 +11,12 @@
static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
+static const char builtin_bundle_usage[] = "\
+ git bundle create <file> <git-rev-list args>\n\
+ git bundle verify <file>\n\
+ git bundle list-heads <file> [refname...]\n\
+ git bundle unbundle <file> [refname...]";
+
int cmd_bundle(int argc, const char **argv, const char *prefix)
{
struct bundle_header header;
@@ -19,8 +25,8 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
int bundle_fd = -1;
char buffer[PATH_MAX];
- if (argc < 3)
- usage(bundle_usage);
+ if (argc < 3)
+ usage(builtin_bundle_usage);
cmd = argv[1];
bundle_file = argv[2];
@@ -59,5 +65,5 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
return !!unbundle(&header, bundle_fd) ||
list_bundle_refs(&header, argc, argv);
} else
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: [PATCH] gitk: restore wm state to normal before saving geometry information
From: Pat Thoyts @ 2009-09-16 21:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexey Borzenkov, git
In-Reply-To: <19120.48177.116508.251237@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>> patch fixes this issue by storing window geometry in normal state.
>
>Hmmm, shouldn't we be also saving the window state (zoomed/normal) and
>restoring that as well?
>
>Paul.
We do. That got added in c876dbad
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: Behavior of 'git add \*.txt': bug or feature?
From: Junio C Hamano @ 2009-09-16 20:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljke7jv8.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> It this the intended behavior? If so, what's the rationale for this?
I strongly suspect that it comes from the fact that we have two
definitions and three implementations of pathspec-aware tree traversal.
One family is unaware of shell-glob wildcards (they only do leading
directory path match) while the other know both leading directory path and
shell-glob.
It is on the list of long-term items to fix, as the change required is
quite involved.
^ permalink raw reply
* [PATCH] Exporter for code_swarm
From: Giuseppe Bilotta @ 2009-09-16 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
This simple Perl script echoes the entire project history into a format
suitable for consumption from the organic project development visualizer
code_swarm http://vis.cs.ucdavis.edu/~ogawa/codeswarm/ and any other
software that expects a file event XML file in the same format.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
contrib/git-file-events.perl | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
create mode 100755 contrib/git-file-events.perl
I had actually considered writing a patch to add the format as a predefined
format for git log, but on second thoughts I decided it was not really worth
the effort. This script, although it's just a quick hack, serves the purpose
just as well, although it's obviously not suited for anything more than
contrib/, if for anything at all.
Enjoy.
diff --git a/contrib/git-file-events.perl b/contrib/git-file-events.perl
new file mode 100755
index 0000000..b5fd5e5
--- /dev/null
+++ b/contrib/git-file-events.perl
@@ -0,0 +1,28 @@
+#!/usr/bin/perl
+
+# Output full repository log as a list of file events, in the format expected by
+# code_swarm http://vis.cs.ucdavis.edu/~ogawa/codeswarm/
+#
+# Usage: perl git-file-events.perl > events.xml
+
+open(LOG, 'git log --reverse --date-order --format="%x09%at000%x09%aN" --name-only|');
+
+my $date = undef;
+my $author = undef;
+
+print "<?xml version=\"1.0\" ?>\n<file_events>\n";
+while (<LOG>) {
+ chomp;
+ if (/^\t(\d+)\t(.*)/) {
+ $date = $1;
+ $author = $2;
+ } else {
+ next unless $_;
+ die "Malformed log: no author!\n'$_'\n" unless $author;
+ $file = $_;
+ $file =~ s/\n//g;
+ $file =~ s/"//g;
+ print "<event date=\"$date\" filename=\"$_\" author=\"$author\" />\n";
+ }
+}
+print "</file_events>\n";
--
1.6.4.1.345.ge2d8f
^ permalink raw reply related
* Re: [PATCH 04/15] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Alexey Borzenkov @ 2009-09-16 20:00 UTC (permalink / raw)
To: Johannes Sixt
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, msysgit, gitster,
j6t, lznuaa, raa.lkml, Marius Storm-Olsen
In-Reply-To: <4AB10F01.9010703@viscovery.net>
On Wed, Sep 16, 2009 at 8:14 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> MinGW set the _CRT_fmode to set both the default fmode and
>> _O_BINARY on stdin/stdout/stderr. Rather use the main()
>> define in mingw.h to set this for both MinGW and MSVC.
>>
>> This will ensure that a MinGW and MSVC build will handle
>> input and output identically.
> This one breaks t5302-pack-index.sh (test 15, "[index v1] 2) create a
> stealth corruption in a delta base reference") in my MinGW build. I have
> yet to find out what exactly goes wrong and how it could be fixed.
Looks like calling _setmode in main is too late for something. :-/
I tried defining int _fmode in mingw.c (which sets msvcrt's _fmode
early, without calling _setmode), and it didn't work either (i.e. the
bug was still happening). So the culprit must be in _setmode. I also
tried logging what index_obj_offset and index_obj_nr are showing, and
here are results:
/* with _CRT_fmode = _O_BINARY */
index_obj_offset: 844032
index_obj_nr: 205
/* without _CRT_fmode = _O_BINARY */
index_obj_offset: 844235
index_obj_nr: 298
I then tried to see what git show-index actually returns there, and
here are several top lines of the results:
/* with _CRT_fmode = _O_BINARY */
850186 0106e17481932f5c223fafadc1d26abc6adf40d6
203652 01179d82b18c252824e20e190543e0e84950d820
15576 0246ff570c396c37ff08c0f5f9d88c84fc21a297
851536 035e7e54cee9eb197af435b6b6dcced489c233f6
376062 03a6f56dbbb556425ef8c43c31519b32eb5629a4
39452 0471b3b8ab8da19f3968dc238e9555f4e48ce858
8230 0483297992ed4cd5ab3b5790912b1f03598ea660
72292 0508b858e01f0367552fb14722388ba48dbd36f7
/* without _CRT_fmode = _O_BINARY */
844235 01a8d3f6d063d48baf40ee656804aa58486a34b2
851754 035e7e54cee9eb197af435b6b6dcced489c233f6
851844 04ff7bd225fbb4842697af96c147a4ddecb6a657
848233 088ddcb945af72c47348b65a63992c71b6b9dbe8
849676 088e69e7ab273e35b4f63ecb1b915a3997f13dff
14825 09bd72201f82a0da14a52230e2ccd0e43529e779
9848 0a5916ad398380ba103d98bad6fa4f2b20b74e75
695905 0ae5469e687083bbf954262873ee8c0c7d017e75
As you can see the hashes are completely different! Unfortunately I
also can't pinpoint where this actually happens... :-/
*several minutes later*
Searching which executables set _fmode and which don't I found the
culprit. test-genrandom.c didn't include git-compat-util.h, so mingw.h
was never included. This caused different random data to be generated,
and as it seems more importantly, of different sizes. Can be fixed
with this patch:
diff --git a/test-genrandom.c b/test-genrandom.c
index 8ad276d..b3c28d9 100644
--- a/test-genrandom.c
+++ b/test-genrandom.c
@@ -4,8 +4,7 @@
* Copyright (C) 2007 by Nicolas Pitre, licensed under the GPL version 2.
*/
-#include <stdio.h>
-#include <stdlib.h>
+#include "git-compat-util.h"
int main(int argc, char *argv[])
{
Or maybe there's a hidden bug in git that gets uncovered with slightly
different random data, I don't know. I'm glad I could finally solve
this mindbending issue. :)
^ permalink raw reply related
* Behavior of 'git add \*.txt': bug or feature?
From: Matthieu Moy @ 2009-09-16 19:46 UTC (permalink / raw)
To: git
Hi,
I find the behavior of 'git add \*.txt' strange: for adding untracked
files, it considers \*.txt as a pattern to match, but for updating
existing file's staged content, it seems to consider it as a filename:
$ git status
# On branch master
# Changed but not updated:
#
# modified: three.txt
# modified: two.txt
#
# Untracked files:
#
# one.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ git add -v '*.txt'
add 'one.txt'
$ git add -v '*.txt'
$
I would have expected this "git add -v '*.txt'" to update the staged
content of two.txt and three.txt too.
It this the intended behavior? If so, what's the rationale for this?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 3/4] reset: add option "--merge-safe" to "git reset"
From: Junio C Hamano @ 2009-09-16 18:37 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds, Paolo Bonzini
In-Reply-To: <20090916041443.3737.63217.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> From: Stephan Beyer <s-beyer@gmx.net>
>
> This option is nearly like "--merge" except that it is
> safer. The table below show the differences between these
> options.
>
> working index HEAD target working index HEAD
> B B A A --m-s B A A
> --merge A A A
> B B A C --m-s (disallowed)
> --merge C C C
>
> In this table, A, B and C are some different states of
> a file. For example the first 2 lines of the table mean
> that if a file is in state B in the working tree and
> the index, and in a different state A in HEAD and in
> the target, then "git reset --merge-safe target" will
> put the file in state B in the working tree and in
> state A in the index and HEAD.
At first, I had to spend a few minutes guessing what you meant by "target"
in the table. All the other words are well known and do not need to be
explained, but you can make it even easier to understand by updating the
sentence before the table, perhaps like:
When running "git reset --option target" to reset the HEAD to another
commit (as a special case "target" could be the same as HEAD), here
is what happens to paths in various state.
As you mentioned in the proposed commit log message of the other entry,
you have a different behaviour for unmerged case. Can you add that case
to the table as well?
The original use case of Linus's "reset --merge" was:
$ edit ... ;# you may have some local changes to the work tree
$ git merge/pull ...
... (1) it merges cleanly;
... (2) you see conflicts and do not commit, or
... (3) you resolve conflicts and commit, while leaving the earlier
... modified paths alone.
... In any of the three cases, you inspect the result, and say
... "ah, crap!"
... You want to go back to the state before the merge, i.e.
... target = HEAD^ in (1) or (3) above and target = HEAD in (2).
$ git reset --merge $target
Recall that "git merge/pull ..." step does not even touch anything if you
have a dirty index (i.e. "diff --cached" is non-empty), so any difference
between the index and HEAD to reset the failed merge away must come from
the merge itself
Immediately before you run "reset --merge" in the above sequence, you can
categorize the paths in various states this way:
work index HEAD how that path got into this state...
A A A not involved in this merge.
B A A not involved in this merge, originally modified.
B B A cleanly merged.
B B B cleanly merged (and committed if (1) or (3)).
C U A merge left conflicts
where U denotes unmerged path in the index, and C is a file in the work
tree with conflict markers. The path had content A in HEAD before the
start of the merge that you are resetting away.
Note that the target is A in all cases in the above table.
We would want to go back to HEAD == index == target for all of these
cases, and discarding B in "cleanly merged" entries is absolutely the
right thing to do. Clearly, --merge-safe is _not_ designed to work in
this scenario.
Don't get me wrong. I am not saying --merge-safe is unsafe nor useless.
I am trying to show a way with an intended use-case (and the mechanical
notation you and Daniel wrote up, which is very nice to illustrate what
exactly happens) to explain how --merge works, and more importantly why
it works that way.
That is because I would like to see an intended use case of this new
feature in a bigger picture. With the table, I can see what it does (or
at least what you wanted it to do), but it does not clearly explain what
this new mode of operation is good for, in what context it is designed
to be used, and what problem it intends to solve. I think you find it
very clear, by reading my explanation above, what Linus's --merge is
intended to solve:
After a (possibly conflicted) merge modified my index and my work
tree, "reset --hard" to the commit before I started the merge will
discard the local modifications I had in the work tree before the
merge. "reset --merge" was invented to let me go back to the
state before the merge, without discarding such local changes I
had before the merge.
I want to be able to explain to others what --merge-safe is for in a
similar way myself before I have it in my tree, and I can't (yet).
^ permalink raw reply
* Re: [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdjizrgg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Short answer: trust me, without the patch, you get the non-fast
>> forward (and valgrind tells you about conditional jump on
>> uninitialized value), with, you don't ;-).
>
> I understand valgrind one; I can trace the codepath with eyeballs without
> it, and that is why I said it looks correct to begin with.
(in case it wasn't clear, "you" in my message should have been read as
"one", no harm intended)
> My puzzlement was that the following in the log message did not seem to
> reproduce for me:
> ... where "git push ... nonexisting-branch" was complaining about
> non-fast forward.
It's comming from an uninitialized variable, so it may have worked
just "by chance". For me, it seems to do it reproducibly, with for
example:
$ mkdir repo
$ rm -rf repo/
$ git init repo
Initialized empty Git repository in /tmp/repo/.git/
$ cd repo; touch foo; git add .; git commit -m foo > /dev/null
$ git push . nonexisting-branch
error: src refspec nonexisting-branch does not match any.
error: failed to push some refs to '.'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'non-fast forward'
section of 'git push --help' for details.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Junio C Hamano @ 2009-09-16 18:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqfxamby33.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Short answer: trust me, without the patch, you get the non-fast
> forward (and valgrind tells you about conditional jump on
> uninitialized value), with, you don't ;-).
I understand valgrind one; I can trace the codepath with eyeballs without
it, and that is why I said it looks correct to begin with.
My puzzlement was that the following in the log message did not seem to
reproduce for me:
... where "git push ... nonexisting-branch" was complaining about
non-fast forward.
I would be eventually writing an entry in the Release Notes about this
fix, and I do not want to say:
"git push $there no-such-ref" incorrectly said no-such-ref does not
fast forward; fixed.
when I know that command line would produce something entirely different
error.
^ permalink raw reply
* Re: [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 17:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr9q24oa.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> The variable is assigned unconditionally in print_push_status, but
>> print_push_status is not reached by all codepaths. In particular, this
>> fixes a bug where "git push ... nonexisting-branch" was complaining about
>> non-fast forward.
>
> Hmm, the patch looks correct but I am scratching my head to see how this
> is triggered. "git push ... nonexisting-branch" seems to get:
Short answer: trust me, without the patch, you get the non-fast
forward (and valgrind tells you about conditional jump on
uninitialized value), with, you don't ;-).
Longer one:
int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
int * nonfastforward)
{
[...]
if (match_refs(local_refs, &remote_refs,
refspec_nr, refspec, match_flags)) {
return -1; /* <------------------------------ you stop here */
}
[...]
if (!quiet || push_had_errors(remote_refs))
print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
nonfastforward); /* <----- you would have updated nonfastforward there */
[...]
}
Actually, my initial version probably had the condition of the second
if too. And with the first "return" statement in transport_push.
Writting this, I'm wondering if it wouldn't be a better coding style
to initialize nonfastforward to 0 within transport_push (in case other
callers to transport_push appear one day, they won't get the the same
bug). Second version of the patch is comming.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 17:28 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpqfxamby33.fsf@bauges.imag.fr>
The variable is assigned unconditionally in print_push_status, but
print_push_status is not reached by all codepaths. In particular, this
fixes a bug where "git push ... nonexisting-branch" was complaining about
non-fast forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
New version initializing nonfastforward inside transport()
transport.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/transport.c b/transport.c
index 4cb8077..18db3d3 100644
--- a/transport.c
+++ b/transport.c
@@ -871,6 +871,7 @@ int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
int * nonfastforward)
{
+ *nonfastforward = 0;
verify_remote_names(refspec_nr, refspec);
if (transport->push)
--
1.6.5.rc1.11.g2d184.dirty
^ permalink raw reply related
* Re: [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Junio C Hamano @ 2009-09-16 17:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1253119020-26547-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The variable is assigned unconditionally in print_push_status, but
> print_push_status is not reached by all codepaths. In particular, this
> fixes a bug where "git push ... nonexisting-branch" was complaining about
> non-fast forward.
Hmm, the patch looks correct but I am scratching my head to see how this
is triggered. "git push ... nonexisting-branch" seems to get:
error: src refspec nonexisting-branch does not match any.
error: failed to push some refs to '...'
^ permalink raw reply
* Re: self contained executable
From: Matthieu Moy @ 2009-09-16 16:51 UTC (permalink / raw)
To: Joel Saltzman; +Cc: git
In-Reply-To: <ED42F58A-A814-467B-A37D-B485B2E267ED@gmail.com>
Joel Saltzman <saltzmanjoelh@gmail.com> writes:
> is it possible to compile git with all its dependencies so I can run
> it on a server that does not have root access?
Compiling with LDFLAGS='-static' is a first step, I'm not sure it's
sufficient.
But as Alex already pointed out, you don't have to be root to install
Git anyway (I'm using a git that I compiled myself, without being root
on my machine).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: self contained executable
From: Alex Riesen @ 2009-09-16 16:44 UTC (permalink / raw)
To: Joel Saltzman; +Cc: Git Mailing List
In-Reply-To: <C3C630B6-7B54-42BE-9312-20BC20B7F051@gmail.com>
On Wed, Sep 16, 2009 at 18:36, Joel Saltzman <saltzmanjoelh@gmail.com> wrote:
> The last part is what I am trying to figure out. How do I set those linking
> flags?
Below, I assume you're a familiar with compilation.
Open Makefile and find the line "Platform specific tweaks".
That should be an example(s) for variables to set. Don't
mind the ifeq's.
Open config.mak and put there all the -I$$HOME/... and
-L$$HOME/... you need to reach the missing headers and
libraries. Your configuration will override the preset values.
That's almost it: you have to find out what exactly you're
missing on your own (for example, you may actually have
curl and openssl).
^ permalink raw reply
* Re: git workflow for fully distributed mini-teams
From: Nicolas Sebrecht @ 2009-09-16 16:43 UTC (permalink / raw)
To: Rustom Mody; +Cc: Git Mailing List, Nicolas Sebrecht
In-Reply-To: <f46c52560909160035o6b09800eh5219d49e7569cf23@mail.gmail.com>
The 16/09/09, Rustom Mody wrote:
>
> A's best practices (and invariants) are:
> I (ie A) develop on dev (or other topic branches).
> I only merge onto master; never commit.
> I never work on nor merge onto B and C.
> When B sends me patches I apply them to the B branch likewise for C.
> Thereafter I merge that branch onto dev or master.
> There are no tracking branches because there are no remotes -- no
> central repo. [not clear about this]
>
> B and C have corresponding practices/behavior.
>
> So the questions...
>
> Is there a better way of doing things?
> Can some of these practices/invariants be enforced by scripts/options etc?
What's may be hard here is about "releasing topic". With a "maintainer
oriented workflow", the status of each topic is clear (either "won't
merge as is, needs more work" or "should be good enough, is merged and
aims to be in the next release").
In the fully-distributed workflow you describe, the state of the topics
looks hard to know. Who releases what is not clear.
Also, I see a duplication of the same work for all the developers in a
team: "merge my topics with topics from others". This could be solved
with one more common repository wich could stand as a "virtual
maintainer repository" where each developer could release any topic.
Topics that don't need any more work would have to be merged in a
dedicated public branch ("next"?) for testing, and topics that aren't
good enough into another dedicated branch ("pu"?). So, each developer
would have to push publishable merges into this repository. This way,
everyone could use the merges done by another developer (by doing a
fetch and rebasing of his current work on top of it).
Notice that this is all about "everybody uses the same base for his
current work" (to avoid per-developer scratch on merges) and "don't let
everyone do the same work on his own" (to avoid duplicate work).
> What about checkpointing and restoring from botches?
I think this is be easily doable (against your described workflow) with
good conventions in branch names. Topics like "pending-topicA",
"pending-topicB", etc that would have to be merged (using a script) into
a "all pending topics" branch should do what you want, no? Restoring
from botches would mean removing the crappy branch and re-execute the
script.
Hope this helps.
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 16:37 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
The variable is assigned unconditionally in print_push_status, but
print_push_status is not reached by all codepaths. In particular, this
fixes a bug where "git push ... nonexisting-branch" was complaining about
non-fast forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
(I'm the one to blame, sorry for introducing this bug)
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..a73333b 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -140,7 +140,7 @@ static int do_push(const char *repo, int flags)
struct transport *transport =
transport_get(remote, url[i]);
int err;
- int nonfastforward;
+ int nonfastforward = 0;
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
--
1.6.5.rc1.11.g2d184.dirty
^ permalink raw reply related
* Re: [PATCH] Initial manually svn property setting support for git-svn
From: Thiago Farina @ 2009-09-16 16:18 UTC (permalink / raw)
To: David Fraser; +Cc: git, David Moore
In-Reply-To: <1927112650.1281253084529659.JavaMail.root@klofta.sjsoft.com>
On Wed, Sep 16, 2009 at 4:02 AM, David Fraser <davidf@sjsoft.com> wrote:
> This basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
>
> Issues remaining:
> * The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
> * It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
> * It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
> * No support for deleting properties
>
> Usage is:
> git svn propset PROPNAME PROPVALUE PATH
>
> Added minimal documentation for git-svn propset
>
> Signed-off-by: David Fraser <davidf@sjsoft.com>
> ---
> Documentation/git-svn.txt | 5 ++
> git-svn.perl | 95 ++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 99 insertions(+), 1 deletions(-)
>
David, please read this, line 28:
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=76fc84d8780762e083cd4ca584b9d783b8c0cd81;hb=HEAD
Patches need to be send as plain text, not attached.
^ permalink raw reply
* Re: [PATCH 04/15] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Johannes Sixt @ 2009-09-16 16:14 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, j6t, lznuaa, raa.lkml,
snaury, Marius Storm-Olsen
In-Reply-To: <929c5a34cd2621af24bcda7e47ff2e76b51c2e09.1253088099.git.mstormo@gmail.com>
Marius Storm-Olsen schrieb:
> From: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
>
> MinGW set the _CRT_fmode to set both the default fmode and
> _O_BINARY on stdin/stdout/stderr. Rather use the main()
> define in mingw.h to set this for both MinGW and MSVC.
>
> This will ensure that a MinGW and MSVC build will handle
> input and output identically.
This one breaks t5302-pack-index.sh (test 15, "[index v1] 2) create a
stealth corruption in a delta base reference") in my MinGW build. I have
yet to find out what exactly goes wrong and how it could be fixed.
-- Hannes
^ permalink raw reply
* [PATCH] Updated the usage string of git reset
From: Jan Stępień @ 2009-09-16 15:29 UTC (permalink / raw)
To: git, gitster; +Cc: Jan Stępień
Now the usage string reflects the behaviour of git reset and contents of
the man page.
Signed-off-by: Jan Stępień <jan@stepien.cc>
---
builtin-reset.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..78103ab 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -21,7 +21,7 @@
static const char * const git_reset_usage[] = {
"git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
- "git reset [--mixed] <commit> [--] <paths>...",
+ "git reset [-q] <commit> [--] <paths>...",
NULL
};
--
1.6.4.3
^ permalink raw reply related
* Re: Direct ancestors from commit to HEAD
From: Gonsolo @ 2009-09-16 15:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3vdjj2ceq.fsf@localhost.localdomain>
> I don't know whether --first-parent or --simplify-by-decoration, or
> perhaps --dense is what you want (you can also use --graph for better
> visualization).
Thank you. I think
git log --topo-order --dense --merges firstmerge..HEAD
comes very near. I still have to use "git log --topo-order", find the
commit of interest, and search upwards for the next merge that is used
as firstmerge above.
Unfortunately there are many merges in the net branch but it basically
does the job.
An example:
1. git log --topo-order, search for "Wakeup fixes" gives commit edd7fc.
2. Search backward for "^Merge" gives commit a8519d.
3. git log --topo-order --dense --merges edd7fc.., search for a8519d.
4. A search backwards for Linus gives you the merge into mainline: d7e966.
This commit is basically what I wanted to know. Even nicer would be a
three-commit-line only consisting of the merge into wireless, the merge
into net and the merge into mainline.
> Or use git-show-branch... :-)
I don't think I can use that since I have only a master branch sitting
around.
^ permalink raw reply
* Re: Direct ancestors from commit to HEAD
From: Jakub Narebski @ 2009-09-16 14:26 UTC (permalink / raw)
To: Gonsolo; +Cc: git
In-Reply-To: <4AB0EFC0.8020005@googlemail.com>
Gonsolo <gonsolo@gmail.com> writes:
> Is there a way to see only the direct line of (merge) ancestors from
> patch to HEAD? Something like:
>
> commit 0cb583fd2862f19ea88b02eb307d11c09e51e2f8
> Merge: 723e9db... a2d1056...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue Sep 15 10:01:16 2009 -0700
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>
> commit 88512935a24305fea7aecc9ba4d675869e97fc2a
> Merge: 8a62bab... 6b26dea...
> Author: David S. Miller <davem@davemloft.net>
> Date: Fri Aug 14 12:27:19 2009 -0700
>
> Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
>
> commit edd7fc7003f31da48d06e215a93ea966a22c2a03
> Author: Nick Kossifidis <mick@madwifi-project.org>
> Date: Mon Aug 10 03:29:02 2009 +0300
>
> ath5k: Wakeup fixes
>
>
> Here I can see exactly how the ath5k patch came to mainline and since
> when it is there.
I don't know whether --first-parent or --simplify-by-decoration, or
perhaps --dense is what you want (you can also use --graph for better
visualization).
Or use git-show-branch... :-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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