* [PATCH v2 14/15] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
If you try and update a submodule with a dirty working directory, you
get an error message like:
$ git submodule update
error: Your local changes to the following files would be overwritten by checkout:
...
Please, commit your changes or stash them before you can switch branches.
Aborting
...
Mention this in the submodule notes. The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index dbd0143..8024758 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3751,7 +3751,9 @@ module a
NOTE: The changes are still visible in the submodule's reflog.
-This is not the case if you did not commit your changes.
+If you did not commit your submodule changes, the changes will *not*
+be silently overwritten. Instead, you get the usual warning about not
+being able switch from a dirty branch.
[[low-level-operations]]
Low-level Git operations
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
There is no need to use here documents to setup this configuration.
It is easier, less confusing, and more robust to use Git's
configuration tools directly.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8524c08..53f73c3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,14 +1994,17 @@ default. See the description of the receive.denyCurrentBranch option
in linkgit:git-config[1] for details.
As with `git fetch`, you may also set up configuration options to
-save typing; so, for example, after
+save typing; so, for example, after either
--------------------------------------------------
-$ cat >>.git/config <<EOF
-[remote "public-repo"]
- url = ssh://yourserver.com/~you/proj.git
-EOF
--------------------------------------------------
+------------------------------------------------
+$ git remote add public-repo ssh://yourserver.com/~you/proj.git
+------------------------------------------------
+
+or, more explicitly,
+
+------------------------------------------------
+$ git config remote.public-repo.url ssh://yourserver.com/~you/proj.git
+------------------------------------------------
you should be able to perform the above push with just
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: demerphq @ 2013-02-10 13:26 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ramkumar Ramachandra, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <20130210111732.GA24377@lanh>
On 10 February 2013 12:17, Duy Nguyen <pclouds@gmail.com> wrote:
> Bear in mind though this is Linux, where lstat is fast. On systems
> with slow lstat, these timings could look very different due to the
> large number of lstat calls compared to open+getdents. I really like
> to see similar numbers on Windows.
Is windows stat really so slow? I encountered this perception in
windows Perl in the past, and I know that on windows Perl stat
*appears* slow compared to *nix, because in order to satisfy the full
*nix stat interface, specifically the nlink field, it must open and
close the file*. As of 5.10 this can be disabled by setting a magic
var ${^WIN32_SLOPPY_STAT} to a true value, which makes a significant
improvement to the performance of the Perl level stat implementation.
I would not be surprised if the cygwin implementation of stat() has
the same issue as Perl did, and that stat appears much slower than it
actually need be if you don't care about the nlink field.
Yves
* http://perl5.git.perl.org/perl.git/blob/HEAD:/win32/win32.c#l1492
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] fixup! graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-10 13:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy
In-Reply-To: <7vtxplt5u2.fsf@alter.siamese.dyndns.org>
---
On Sat, Feb 09, 2013 at 03:39:33PM -0800, Junio C Hamano wrote:
> * jk/diff-graph-cleanup (2013-02-07) 6 commits
> - combine-diff.c: teach combined diffs about line prefix
> - diff.c: use diff_line_prefix() where applicable
> - diff: add diff_line_prefix function
> - diff.c: make constant string arguments const
> - diff: write prefix to the correct file
> - graph: output padding for merge subsequent parents
>
> Refactors a lot of repetitive code sequence from the graph drawing
> code and adds it to the combined diff output.
>
> Will merge to 'next'.
Can you squash this into the first commit before you do?
Matthieu is correct that the graph_is_commit_finished() check isn't
needed in the loop now that we've pulled it out to be checked first -
the value returned can't change during the loop. I've left the early
return out.
graph.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/graph.c b/graph.c
index 2a3fc5c..56f970f 100644
--- a/graph.c
+++ b/graph.c
@@ -1237,7 +1237,7 @@ void graph_show_commit(struct git_graph *graph)
shown_commit_line = 1;
}
- while (!shown_commit_line && !graph_is_commit_finished(graph)) {
+ while (!shown_commit_line) {
shown_commit_line = graph_next_line(graph, &msgbuf);
fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
if (!shown_commit_line)
--
1.8.1.2
^ permalink raw reply related
* Re: Feature request: Allow extracting revisions into directories
From: Thomas Koch @ 2013-02-10 12:16 UTC (permalink / raw)
To: Robert Clausecker, git
In-Reply-To: <1359980045.24730.32.camel@t520>
Robert Clausecker:
> I have a server that hosts a bare git repository. This git repository
> contains a branch production. Whenever somebody pushes to production a
> hook automatically puts a copy of the current production branch
> into /var/www/foo. I could of course use pull for that but it just does
> not feels right. Why should I have a repository twice on the server?
Hallo Robert,
I've mostly the same requirement for a friend with a PHP webshop and started
to implement my own git_export with the additional feature that it tries to
reuse already exported trees as hardlink targets instead of writing the same
file again. (I'm aware of the dangers of hardlinks.)
https://github.com/thkoch2001/git_export_hardlinks
See also the current mailing list thread: "[Request] Git export with
hardlinks".
Beste Grüße,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 11:22 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <20130210111732.GA24377@lanh>
On Sun, Feb 10, 2013 at 06:17:32PM +0700, Duy Nguyen wrote:
> The following patch eliminates untracked search code. As we can see,
> open+getdents also disappears with this patch:
>
> 0.462909 40950 lstat 0.462909 40950 lstat
> 0.003417 129 brk 0.003417 129 brk
> 0.000762 53 read 0.000762 53 read
> 0.000720 36 open 0.000720 36 open
> 0.000544 12 munmap 0.000454 33 close
.. and the patch is missing:
-- 8< --
diff --git a/dir.c b/dir.c
index 57394e4..1963c6f 100644
--- a/dir.c
+++ b/dir.c
@@ -1439,8 +1439,10 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
+#if 0
if (!len || treat_leading_path(dir, path, len, simplify))
read_directory_recursive(dir, path, len, 0, simplify);
+#endif
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
-- 8< --
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 11:17 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <CACsJy8DeM5--WVXg3b65RxLBS7Jho-7KmcGwWk7B5uAx77yOEw@mail.gmail.com>
On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote:
> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
> > Finn notes in the commit message that it offers no speedup, because
> > .gitignore files in every directory still have to be read. I think
> > this is silly: we really should be caching .gitignore, and touching it
> > only when lstat() reports that the file has changed.
> >
> > ...
> >
> > Really, the elephant in the room right now seems to be .gitignore.
> > Until that is fixed, there is really no use of writing this inotify
> > daemon, no? Can someone enlighten me on how exactly .gitignore files
> > are processed?
>
> .gitignore is a different issue. I think it's mainly used with
> read_directory/fill_directory to collect ignored files (or not-ignored
> files). And it's not always used (well, status and add does, but diff
> should not). I think wee need to measure how much mass lstat
> elimination gains us (especially on big repos) and how much
> .gitignore/.gitattributes caching does.
OK let's count. I start with a "standard" repository, linux-2.6. This
is the number from strace -T on "git status" (*). The first column is
accumulated time, the second the number of syscalls.
top syscalls sorted top syscalls sorted
by acc. time by number
----------------------------------------------
0.401906 40950 lstat 0.401906 40950 lstat
0.190484 5343 getdents 0.150055 5374 open
0.150055 5374 open 0.190484 5343 getdents
0.074843 2806 close 0.074843 2806 close
0.003216 157 read 0.003216 157 read
The following patch pretends every entry is uptodate without
lstat. With the patch, we can see refresh code is the cause of mass
lstat, as lstat disappears:
0.185347 5343 getdents 0.144173 5374 open
0.144173 5374 open 0.185347 5343 getdents
0.071844 2806 close 0.071844 2806 close
0.004918 135 brk 0.003378 157 read
0.003378 157 read 0.004918 135 brk
-- 8< --
diff --git a/read-cache.c b/read-cache.c
index 827ae55..94d8ed8 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1018,6 +1018,10 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
if (ce_uptodate(ce))
return ce;
+#if 1
+ ce_mark_uptodate(ce);
+ return ce;
+#endif
/*
* CE_VALID or CE_SKIP_WORKTREE means the user promised us
* that the change to the work tree does not matter and told
-- 8< --
The following patch eliminates untracked search code. As we can see,
open+getdents also disappears with this patch:
0.462909 40950 lstat 0.462909 40950 lstat
0.003417 129 brk 0.003417 129 brk
0.000762 53 read 0.000762 53 read
0.000720 36 open 0.000720 36 open
0.000544 12 munmap 0.000454 33 close
So from syscalls point of view, we know what code issues most of
them. Let's see how much time we gain be these patches, which is an
approximate of the gain by inotify support. This time I measure on
gentoo-x86.git [1] because this one has really big worktree (100k
files)
unmodified read-cache.c dir.c both
real 0m0.550s 0m0.479s 0m0.287s 0m0.213s
user 0m0.305s 0m0.315s 0m0.201s 0m0.182s
sys 0m0.240s 0m0.157s 0m0.084s 0m0.030s
and the syscall picture on gentoo-x86.git:
1.106615 101942 lstat 1.106615 101942 lstat
0.667235 47083 getdents 0.641604 47114 open
0.641604 47114 open 0.667235 47083 getdents
0.286711 23573 close 0.286711 23573 close
0.005842 350 brk 0.005842 350 brk
We can see that shortcuting untracked code gives bigger gain than
index refresh code. So I have to agree that .gitignore may be the big
elephant in this particular case.
Bear in mind though this is Linux, where lstat is fast. On systems
with slow lstat, these timings could look very different due to the
large number of lstat calls compared to open+getdents. I really like
to see similar numbers on Windows.
read_directory/fill_directory code is mostly used by "git add" (not
with -u) and "git status", while refresh code is executed in add,
checkout, commit/status, diff, merge. So while smaller gain, reducing
lstat calls could benefit in more cases.
A relatively slow "git add" is acceptable. "git status" should be
fast. Although in my workflow, I do "git diff [--stat] [--cached]"
much more often than "git status" so relatively slow "git status" does
not hurt me much. But people may do it differently.
On speeding up read_directory with inotify support. I haven't thought
it through, but I think we could save (or get it via socket) a list of
untracked files in .git, regardless ignore status, with the help from
inotify. When this list is verified valid, read_directory could be
modified to traverse the tree using this list (plus the index) instead
of opendir+readdir. Not sure how the change might look though.
[1] http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
(*) the script to produce those numbers is
-- 8< --
#!/bin/sh
export LANG=C
strace -T "$@" 2>&1 >/dev/null |
sed 's/\(^[^(]*\)(.*<\([0-9.]*\)>$/\1 \2/' |
awk '{
sec[$1]+=$2;
count[$1]++;
}
END {
for (i in sec)
printf("%f %d %s\n", sec[i], count[i], i);
}' >/tmp/s
sort -nr /tmp/s | head -n5
sort -nrk2 /tmp/s | head -n5
-- 8< --
^ permalink raw reply related
* Re: [Request] Git export with hardlinks
From: Thomas Koch @ 2013-02-10 10:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130208095819.GA17220@sigill.intra.peff.net>
Jeff King:
> [...]
> So a full checkout is 24M. For the next deploy, we'll start by asking
> "cp" to duplicate the old, using hard links:
Hi Jeff,
thank you very much for your idea! It's good and simple. It just breaks down
for the case when a large folder got renamed.
But I already hacked the basic layout of the algorithm and it's not
complicated at all, I believe:
https://github.com/thkoch2001/git_export_hardlinks/blob/master/git_export_hardlinks.py
I had to interrupt work on this and could not yet finish and test it. But I
thought you might be interested. Maybe something like this might one day be
rewritten in C and become part of git core?
Regards,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 5:24 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <CALkWK0=6_n4rf6AWci6J+uhGHpjTUmK7YFdVHuSJedN2zLWtMA@mail.gmail.com>
On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Finn notes in the commit message that it offers no speedup, because
> .gitignore files in every directory still have to be read. I think
> this is silly: we really should be caching .gitignore, and touching it
> only when lstat() reports that the file has changed.
>
> ...
>
> Really, the elephant in the room right now seems to be .gitignore.
> Until that is fixed, there is really no use of writing this inotify
> daemon, no? Can someone enlighten me on how exactly .gitignore files
> are processed?
.gitignore is a different issue. I think it's mainly used with
read_directory/fill_directory to collect ignored files (or not-ignored
files). And it's not always used (well, status and add does, but diff
should not). I think wee need to measure how much mass lstat
elimination gains us (especially on big repos) and how much
.gitignore/.gitattributes caching does. I don't think .gitignore has
such a big impact though. strace on git.git tells me "git status"
issues about 2500 lstat calls, and just 740 open+getdents calls (on
total 3800 syscalls). I will think if we can do something about
.gitignore/.gitattributes.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 0/8] Hiding refs
From: Jed Brown @ 2013-02-10 4:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Jeff King, Shawn Pearce
In-Reply-To: <7v38x5ul4s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I am not sure about "pushing" part, but the jc/fetch-raw-sha1 topic
> (split from the main jc/hidden-refs topic) should allow your script,
> after the client learns the set of smudged object names, to ask for
>
> git fetch $there $sha1_1 $sha1_2 ...
Well, my out-of-band knowledge is currently the sha1 of the data
contained in the blob I want, not the blob sha1 itself [1]. After
experimenting with jc/hidden-refs, I think it already does exactly what
I want. Specifically, I set this on the server
git config uploadpack.hiderefs refs/fat
so that 'git ls-remote' no longer transfers these refs. Then on the
client, I do
contentid=$(sha1sum thefile | cut -f1 -d \ )
blobid=$(git hash-object -w thefile)
git update-ref refs/fat/$contentid $blobid
.... more like this
git push the-remote refs/fat/$contentid ...
and later, I can fetch specific refs using
git fetch the-remote refs/fat/$wanted:refs/fat/$wanted ...
The client knows the desired refs out-of-band so this looks okay. It
would be convenient to have '--stdin' options to 'git push' and 'git
fetch'. Would a patch for that be welcome?
[1] The reason for using $contentid instead of $blobid in the key here
is to avoid etching the backend=git detail into the cleaned commits.
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Jonathan Nieder @ 2013-02-10 4:19 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git
In-Reply-To: <1360469440.6610.8.camel@t520>
Robert Clausecker wrote:
> That is actually a pretty interesting approach. I can use a different
> index file for different deployments. How does this cooperate with bare
> repositories? Aren't they supposed to have no index file at all?
It should work fine in a bare repo.
If you can think of a good place to sneak hints about this into the
documentation (maybe as an example in git-archive(1) or a new
gitenvironment(7) page), that would be very welcome.
Thanks,
Jonathan
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-10 4:10 UTC (permalink / raw)
To: Jonathan Nieder, git
In-Reply-To: <20130210040621.GA8584@elie.Belkin>
That is actually a pretty interesting approach. I can use a different
index file for different deployments. How does this cooperate with bare
repositories? Aren't they supposed to have no index file at all?
Am Samstag, den 09.02.2013, 20:06 -0800 schrieb Jonathan Nieder:
> My advice is to keep a separate index file for your exported files.
> Like this:
>
> GIT_DIR=$(readlink -f $(git rev-parse --git-dir))
> GIT_INDEX_FILE=$GIT_DIR/index-for-deployment
> export GIT_DIR GIT_INDEX_FILE
>
> cd $dest
> git read-tree -m -u <tree>
>
> Hope that helps,
> Jonathan
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Jonathan Nieder @ 2013-02-10 4:06 UTC (permalink / raw)
To: Robert Clausecker; +Cc: Junio C Hamano, git
In-Reply-To: <1360468628.6610.5.camel@t520>
Hi Robert,
Robert Clausecker wrote:
> There are two things git archive is missing that are needed in my use
> case:
>
> First, git archive in combination with tar won't remove unneeded files.
> You have to run rm -rf before manually which brings me to the next
> point; git archive can't really make incremental updates.
My advice is to keep a separate index file for your exported files.
Like this:
GIT_DIR=$(readlink -f $(git rev-parse --git-dir))
GIT_INDEX_FILE=$GIT_DIR/index-for-deployment
export GIT_DIR GIT_INDEX_FILE
cd $dest
git read-tree -m -u <tree>
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-10 3:57 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vpq08u903.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
There are two things git archive is missing that are needed in my use
case:
First, git archive in combination with tar won't remove unneeded files.
You have to run rm -rf before manually which brings me to the next
point; git archive can't really make incremental updates. Consider an
export that overwrites a tree that resembles the state of an export two
commits before and contains a lot of files. I don't like to idea of
needing to remove all files and write all of them again just to change
one or two lines.
Perhaps my real problem is not "export" but rather "Can I have multiple
work trees with multiple checked out revisions?"...
Am Samstag, den 09.02.2013, 19:45 -0800 schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I am not Phil, but if you ask me, I think it is borderline between
> > "meh" and "no way we would give a short-and-sweet -i to something
> > like this".
>
> I think one reason it was "meh" for me is that we never did an
> equivalent of "cvs export" and "svn export", primarily because
> we had "tar-tree" (aka "archive --format=tar") first, and it was
> sufficient to pipe its outputto "tar xf -" if somebody wanted to do
> the non-existent "git export". Also "tar-tree" was more useful for
> people who wanted to eventually want to have a tarball (you can
> first "export" and then "tar cf" the resulting directory).
>
> But I think it is fine to add "git export <revision> <directory>",
> which may look like this, perhaps.
>
> #!/bin/sh
> # git export <rev> <directory>
> rev=${1?revision} dir=${2?directory}
> . $(git --exec-path)/git-sh-setup
>
> mkdir -p "$dir" || exit
> git archive --format=tar "$rev" |
> tar Cxf "$dir" -
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-10 3:45 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git, Phil Hord
In-Reply-To: <7vehgpum7n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I am not Phil, but if you ask me, I think it is borderline between
> "meh" and "no way we would give a short-and-sweet -i to something
> like this".
I think one reason it was "meh" for me is that we never did an
equivalent of "cvs export" and "svn export", primarily because
we had "tar-tree" (aka "archive --format=tar") first, and it was
sufficient to pipe its outputto "tar xf -" if somebody wanted to do
the non-existent "git export". Also "tar-tree" was more useful for
people who wanted to eventually want to have a tarball (you can
first "export" and then "tar cf" the resulting directory).
But I think it is fine to add "git export <revision> <directory>",
which may look like this, perhaps.
#!/bin/sh
# git export <rev> <directory>
rev=${1?revision} dir=${2?directory}
. $(git --exec-path)/git-sh-setup
mkdir -p "$dir" || exit
git archive --format=tar "$rev" |
tar Cxf "$dir" -
^ permalink raw reply
* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Jonathan Nieder @ 2013-02-10 1:49 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, Andreas Mohr
In-Reply-To: <5e23d4c420f150b700dd5100bffb38d32f874200.1360439176.git.git@drmicha.warpmail.net>
Hi,
Michael J Gruber wrote:
> "reset" can be easily misunderstood as resetting a bisect session to its
> start without finishing it. Clarify that it actually finishes the bisect
> session.
FWIW,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Addressing Andreas's original concern about the discoverability of
'git bisect reset' would presumably require doing two more things:
1. adding an example of the normal bisection workflow to the EXAMPLES
section
2. training users to look to the EXAMPLES section
That is, something like the below. But I'm not happy with it, because
it just runs over the same material as the current Description
section. Maybe the current tutorial material could be moved to
examples and replaced with something terser that fleshes out the
descriptions in "git bisect -h" output. What do you think?
diff --git i/Documentation/git-bisect.txt w/Documentation/git-bisect.txt
index e4f46bc1..b89abd78 100644
--- i/Documentation/git-bisect.txt
+++ w/Documentation/git-bisect.txt
@@ -356,6 +356,54 @@ $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
This shows that you can do without a run script if you write the test
on a single line.
+* Bisect to find which patch caused a boot failure:
++
+Install a recent kernel:
++
+------------
+$ cd ~/src/linux
+$ git checkout origin/master
+$ make deb-pkg # or binrpm-pkg, or tar-pkg
+$ dpkg -i ../<name of package> # as root (or rpm -i, or tar -C / -xf)
+$ reboot # as root
+------------
++
+Hopefully it fails to boot, so tell git so and begin bisection:
++
+------------
+$ cd ~/src/linux
+$ git bisect start HEAD v3.2 # assuming 3.2 works fine
+-------------
++
+A candidate revision to test is automatically checked out.
+Test it:
++
+-------------
+$ make deb-pkg # or binrpm-pkg, or tar-pkg
+$ dpkg -i ../<name of package> # as root (or rpm -i, or tar -C / -xf)
+$ reboot # as root
+-------------
++
+Record the result:
++
+-------------
+$ cd ~/src/linux
+$ git bisect good # if it booted correctly
+$ git bisect bad # if it failed to boot
+$ git bisect skip # if some other bug made it hard to test
+-------------
++
+Repeat until bored or git prints the "first bad commit". When
+done:
++
+-------------
+$ git bisect log >log # let others pick up where you left off
+$ git bisect reset HEAD # exit the bisecting state
+-------------
++
+At any step, you can run `git bisect visualize` to watch the
+regression range narrowing.
+
* Locate a good region of the object graph in a damaged repository
+
------------
^ permalink raw reply related
* [PATCH] mergetools,difftool: fix printf usage
From: David Aguilar @ 2013-02-10 1:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Asheesh Laroia
Prevent environment variables and filenames from masquerading
as format strings for printf.
Reported-by: Asheesh Laroia <asheesh@asheesh.org>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-difftool--helper.sh | 2 +-
mergetools/p4merge | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 3d0fe0c..b00ed95 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -40,7 +40,7 @@ launch_merge_tool () {
# the user with the real $MERGED name before launching $merge_tool.
if should_prompt
then
- printf "\nViewing: '$MERGED'\n"
+ printf "\nViewing: '%s'\n" "$MERGED"
if use_ext_cmd
then
printf "Launch '%s' [Y/n]: " \
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 52f7c8f..8a36916 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -30,5 +30,5 @@ create_empty_file () {
empty_file="${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$"
>"$empty_file"
- printf "$empty_file"
+ printf "%s" "$empty_file"
}
--
1.8.1.3.696.gfd94e3d.dirty
^ permalink raw reply related
* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Andreas Mohr @ 2013-02-10 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Mohr, Michael J Gruber, git
In-Reply-To: <7vy5ext60o.fsf@alter.siamese.dyndns.org>
On Sat, Feb 09, 2013 at 03:35:35PM -0800, Junio C Hamano wrote:
> Andreas Mohr <andi@lisas.de> writes:
> > The main point of my mail was to stretch the (whether actually intended)
> > *perceived* start <-> stop symmetry
>
> Actually, in that sense, I do no think finish is exactly a good
> wording. The majority of use case would be to finish up after you
> found the sole culprit, so in that sense "finish" is not too bad,
> but in general, when you "reset", there is not necessarily any
> symmmetry with "start". We should definitely not be giving you an
> illusion that there is one by using "stop" [*1*].
Yeah, of course, but the whole point was that the *user* will *directly*
and *immediately* mentally go from a bisect "start" parameter to "stop",
and end up failing to find it.
Thus the "stop" *KEYWORD* *has* to be mentioned in the man page
(even if only to then expressly state that reset is not quite about "stop"iing
things).
> *1* another reason to avoid "stop" is that it could mean "I stop
> here for now, to later come back and start digging again from
> there", which is not "reset" is about at all.
Such reasons for not listing "stop" might even be stronger
than the reason of
users being required to successfully look up the symmetric "stop" keyword.
If that was decided to be the case, then "stop" would indeed have to be
omitted in the man page - to the detriments of usability.
Thanks,
Andreas Mohr
^ permalink raw reply
* Re: [PATCH v2 06/10] sequencer.c: teach append_signoff how to detect duplicate s-o-b
From: Brandon Casey @ 2013-02-09 23:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, Jonathan Nieder, pclouds@gmail.com,
git@vger.kernel.org
In-Reply-To: <7v7gmhulya.fsf@alter.siamese.dyndns.org>
On 2/9/2013 3:06 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Brandon Casey <drafnel@gmail.com> writes:
>>
>>> On Tue, Jan 22, 2013 at 12:38 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>>> Brandon Casey wrote:
>>>>
>>>>> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
>>>>> This is in preparation to unify the append_signoff implementations in
>>>>> log-tree.c and sequencer.c.
>>>> [...]
>>>>> --- a/sequencer.c
>>>>> +++ b/sequencer.c
>>>>> @@ -1082,9 +1101,10 @@ int sequencer_pick_revisions(struct replay_opts *opts)
>>>>> return pick_commits(todo_list, opts);
>>>>> }
>>>>>
>>>>> -void append_signoff(struct strbuf *msgbuf, int ignore_footer)
>>>>> +void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
>>>>
>>>> Isn't the behavior of passing '1' here just a bug in "format-patch -s"?
>>>
>>> I think that is an open question.
>>
>> Yes. as I said in a previous review round, I think it was a mistake
>> that format-patch chose to pay attention to any S-o-b in the patch
>> trail, not only the last one, and we may want to correcct it once
>> this series solidifies as a separate "bugfix" change on top.
>
> This is a tangent, but I _think_ (didn't check, though) "git am -s"
> implements this incorrrectly. Just another LHF somebody may want to
> take a look.
(I haven't checked the 'git am -s' behavior, but ...)
One distinction between commit, cherry-pick, am, and format-patch is
that the first three are related to importing commits _into_ your own
repository while format-patch is related to exporting patches _from_
your repository.
Not sure if an "exporting" operation should be treated differently from
an "importing" operation and mean "add my sign-off only if I did not
previously do so when I did commit, cherry-pick, or am" or whether it
should mean the same thing i.e. "append my sign-off, unless it's already
last".
Just pointing something out that may or may not be useful.
Hmm, actually, this series could provide a data point. When I submitted
the first series, I used 'format-patch -s' to append my sob. When
Jonathan reviewed the series, he provided Acked-by and Reviewed-by which
I collected and added as I reworked the series. When I added Jonathan's
Ack's/Rev-by's, I _appended_ them to the commits that I had already
submitted, so they appeared _after_ my own sob. When I submitted the
later iterations of the series, I probably used 'format-patch -s' again
and I of course did not want an additional sob to be appended after
Jonathan's Acks.
-Brandon
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* What's cooking in git.git (Feb 2013, #04; Sat, 9)
From: Junio C Hamano @ 2013-02-09 23:39 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 late next week. I expect that topics that are not
mentioned in this message will not have enough time to be in the
upcomming release (unless they are obvious regression fixes or
documentation updates).
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* ab/gitweb-use-same-scheme (2013-01-28) 1 commit
(merged to 'next' on 2013-02-02 at 7e4a108)
+ gitweb: refer to picon/gravatar images over the same scheme
Avoid mixed contents on a page coming via http and https when
gitweb is hosted on a https server.
* ct/autoconf-htmldir (2013-02-02) 1 commit
(merged to 'next' on 2013-02-05 at bba4f8c)
+ Honor configure's htmldir switch
The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
* da/mergetool-docs (2013-02-02) 5 commits
(merged to 'next' on 2013-02-03 at f822dcf)
+ doc: generate a list of valid merge tools
+ mergetool--lib: list user configured tools in '--tool-help'
+ mergetool--lib: add functions for finding available tools
+ mergetool--lib: improve the help text in guess_merge_tool()
+ mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
* jc/combine-diff-many-parents (2013-02-05) 2 commits
(merged to 'next' on 2013-02-05 at e382aa6)
+ t4038: add tests for "diff --cc --raw <trees>"
+ combine-diff: lift 32-way limit of combined diff
We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
* jk/apply-similaritly-parsing (2013-02-03) 1 commit
(merged to 'next' on 2013-02-05 at ccf1c97)
+ builtin/apply: tighten (dis)similarity index parsing
Make sure the similarity value shown in the "apply --summary"
output is sensible, even when the input had a bogus value.
* jk/doc-makefile-cleanup (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at 86ff373)
+ Documentation/Makefile: clean up MAN*_TXT lists
* jk/mergetool (2013-01-28) 8 commits
(merged to 'next' on 2013-02-03 at 2ff5dee)
+ mergetools: simplify how we handle "vim" and "defaults"
+ mergetool--lib: don't call "exit" in setup_tool
+ mergetool--lib: improve show_tool_help() output
+ mergetools/vim: remove redundant diff command
+ git-difftool: use git-mergetool--lib for "--tool-help"
+ git-mergetool: don't hardcode 'mergetool' in show_tool_help
+ git-mergetool: remove redundant assignment
+ git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
* jk/python-styles (2013-01-30) 1 commit
(merged to 'next' on 2013-02-02 at 293edc1)
+ CodingGuidelines: add Python coding guidelines
* jk/remote-helpers-doc (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at ce1461a)
+ Rename {git- => git}remote-helpers.txt
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
* mk/tcsh-complete-only-known-paths (2013-02-03) 1 commit
(merged to 'next' on 2013-02-05 at 4409b08)
+ completion: handle path completion and colon for tcsh script
(this branch uses mp/complete-paths.)
Manlio's "complete with known paths only" update to completion
scripts returns directory names without trailing slash to
compensate the addition of '/' done by bash that reads from our
completion result. tcsh completion code that reads from our
internal completion result does not add '/', so let it ask our
complletion code to keep the '/' at the end.
* mp/complete-paths (2013-01-11) 1 commit
(merged to 'next' on 2013-01-30 at 70e4f1a)
+ git-completion.bash: add support for path completion
(this branch is used by mk/tcsh-complete-only-known-paths.)
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
* nd/branch-error-cases (2013-01-31) 6 commits
(merged to 'next' on 2013-02-02 at cf5e745)
+ branch: let branch filters imply --list
+ docs: clarify git-branch --list behavior
+ branch: mark more strings for translation
+ Merge branch 'nd/edit-branch-desc-while-detached' into HEAD
+ branch: give a more helpful message on redundant arguments
+ branch: reject -D/-d without branch name
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
* sb/gpg-i18n (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at 7a54574)
+ gpg: allow translation of more error messages
* sb/run-command-fd-error-reporting (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at be7e970)
+ run-command: be more informative about what failed
* ss/mergetools-tortoise (2013-02-01) 2 commits
(merged to 'next' on 2013-02-03 at d306b83)
+ mergetools: teach tortoisemerge to handle filenames with SP correctly
+ mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
--------------------------------------------------
[New Topics]
* jc/fetch-raw-sha1 (2013-02-07) 4 commits
- fetch: fetch objects by their exact SHA-1 object names
- upload-pack: optionally allow fetching from the tips of hidden refs
- fetch: use struct ref to represent refs to be fetched
- parse_fetch_refspec(): clarify the codeflow a bit
(this branch uses jc/hidden-refs.)
Allows requests to fetch objects at any tip of refs (including
hidden ones). It seems that there may be use cases even outside
Gerrit (e.g. $gmane/215701).
* jk/diff-graph-cleanup (2013-02-07) 6 commits
- combine-diff.c: teach combined diffs about line prefix
- diff.c: use diff_line_prefix() where applicable
- diff: add diff_line_prefix function
- diff.c: make constant string arguments const
- diff: write prefix to the correct file
- graph: output padding for merge subsequent parents
Refactors a lot of repetitive code sequence from the graph drawing
code and adds it to the combined diff output.
Will merge to 'next'.
* mn/send-email-works-with-credential (2013-02-07) 5 commits
- git-send-email: use git credential to obtain password
- Git.pm: add interface for git credential command
- Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe
- Git.pm: fix example in command_close_bidi_pipe documentation
- Git.pm: allow command_close_bidi_pipe to be called as method
Hooks the credential system to send-email.
Expecting a reroll.
$gmane/215752
* tz/perl-styles (2013-02-06) 1 commit
(merged to 'next' on 2013-02-09 at c8cff17)
+ Update CodingGuidelines for Perl
Add coding guidelines for writing Perl scripts for Git.
Will merge to 'master'.
* al/mergetool-printf-fix (2013-02-08) 1 commit
- git-mergetool: print filename when it contains %
Will merge to 'next'.
* jk/error-const-return (2013-02-08) 1 commit
- Use __VA_ARGS__ for all of error's arguments
Will merge to 'next'.
* mm/allow-contrib-build (2013-02-07) 2 commits
- perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other directories
- Makefile: extract perl-related rules to make them available from other dirs
Will merge to 'next'.
* mm/remote-mediawiki-build (2013-02-08) 2 commits
- git-remote-mediawiki: use toplevel's Makefile
- Makefile: make script-related rules usable from subdirectories
Will merge to 'next'.
* nd/branch-show-rebase-bisect-state (2013-02-08) 1 commit
- branch: show rebase/bisect info when possible instead of "(no branch)"
Will merge to 'next'.
* nd/count-garbage (2013-02-08) 3 commits
- count-objects: report how much disk space taken by garbage files
- count-objects: report garbage files in pack directory too
- git-count-objects.txt: describe each line in -v output
Expecting a reroll.
$gmane/215843
* wk/gc-auto-is-available-these-days (2013-02-08) 1 commit
- user-manual: Rewrite git-gc section for automatic packing
Will merge to 'next'.
* wk/man-deny-current-branch-is-default-these-days (2013-02-08) 1 commit
- user-manual: Update for receive.denyCurrentBranch=refuse
Will merge to 'next'.
* bw/get-tz-offset-perl (2013-02-09) 3 commits
- cvsimport: format commit timestamp ourselves without using strftime
- perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases
- Move Git::SVN::get_tz to Git::get_tz_offset
Will merge to 'next'.
* mg/bisect-doc (2013-02-09) 1 commit
- git-bisect.txt: clarify that reset finishes bisect
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
Expecting a follow-up to add tests.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
--------------------------------------------------
[Cooking]
* jc/extended-fake-ancestor-for-gitlink (2013-02-05) 1 commit
(merged to 'next' on 2013-02-09 at 2d3547b)
+ apply: verify submodule commit object name better
Instead of requiring the full 40-hex object names on the index
line, we can read submodule commit object names from the textual
diff when synthesizing a fake ancestore tree for "git am -3".
Will merge to 'master'.
* tz/credential-authinfo (2013-02-05) 1 commit
- Add contrib/credentials/netrc with GPG support
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
Expecting a reroll.
$gmane/215556
* jx/utf8-printf-width (2013-02-09) 1 commit
- Add utf8_fprintf helper that returns correct number of columns
Use a new helper that prints a message and counts its display width
to align the help messages parse-options produces.
Will merge to 'next'.
* dg/subtree-fixes (2013-02-05) 6 commits
(merged to 'next' on 2013-02-09 at 8f19ebe)
+ contrib/subtree: make the manual directory if needed
+ contrib/subtree: honor DESTDIR
+ contrib/subtree: fix synopsis
+ contrib/subtree: better error handling for 'subtree add'
+ contrib/subtree: use %B for split subject/body
+ contrib/subtree: remove test number comments
contrib/subtree updates, but here are only the ones that looked
ready to be merged to 'next'. For the remainder, they will have
another day.
Will merge to 'master'.
* jl/submodule-deinit (2013-02-06) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will merge to 'next'.
* jc/remove-export-from-config-mak-in (2013-02-03) 1 commit
(merged to 'next' on 2013-02-07 at 33f7d4f)
+ config.mak.in: remove unused definitions
config.mak.in template had an "export" line to cause a few
common makefile variables to be exported; if they need to be
expoted for autoconf/configure users, they should also be exported
for people who write config.mak the same way. Move the "export" to
the main Makefile.
* nd/status-show-in-progress (2013-02-05) 1 commit
- status: show the branch name if possible in in-progress info
Will merge to 'next'.
* sp/smart-http-content-type-check (2013-02-06) 3 commits
(merged to 'next' on 2013-02-06 at 8bc6434)
+ http_request: reset "type" strbuf before adding
(merged to 'next' on 2013-02-05 at 157812c)
+ t5551: fix expected error output
(merged to 'next' on 2013-02-04 at d0759cb)
+ Verify Content-Type from smart HTTP servers
The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
Will merge to 'master'.
* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
- doc: mention tracking for pull.default
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
This is my "don't list it to catch readers' eyes, but make sure it
can be found if the reader looks for it" version; I'm not married
to the layout and will be happy to take a replacement patch.
Waiting for couter-proposal patches.
* jc/hidden-refs (2013-02-07) 3 commits
- upload/receive-pack: allow hiding ref hierarchies
- upload-pack: simplify request validation
- upload-pack: share more code
(this branch is used by jc/fetch-raw-sha1.)
Allow the server side to redact the refs/ namespace it shows to the
client.
I think this is ready for 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will cook in 'next'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Waiting for the final round of reroll before merging to 'next'.
After that we will go incremental.
--------------------------------------------------
[Discarded]
* mn/send-email-authinfo (2013-01-29) 1 commit
. git-send-email: add ~/.authinfo parsing
Instead of making send-email directly read from .netrc/.authinfo,
mn/send-email-works-with-credential topic hooks the program to our
credential framework, and tz/credential-authinfo topic gives access
to these file formats to credential consumers.
^ permalink raw reply
* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Junio C Hamano @ 2013-02-09 23:35 UTC (permalink / raw)
To: Andreas Mohr; +Cc: Michael J Gruber, git
In-Reply-To: <20130209232455.GA31027@rhlx01.hs-esslingen.de>
Andreas Mohr <andi@lisas.de> writes:
> On Sat, Feb 09, 2013 at 01:53:04PM -0800, Junio C Hamano wrote:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> > After a bisect session, to clean up the bisection state and return to
>> > -the original HEAD, issue the following command:
>> > +the original HEAD (i.e., to finish bisect), issue the following command:
>>
>> Makes sense.
>
> Doesn't ;)
>
> [aww, very sorry for this blunt reply]
>
> The main point of my mail was to stretch the (whether actually intended)
> *perceived* start <-> stop symmetry
Actually, in that sense, I do no think finish is exactly a good
wording. The majority of use case would be to finish up after you
found the sole culprit, so in that sense "finish" is not too bad,
but in general, when you "reset", there is not necessarily any
symmmetry with "start". We should definitely not be giving you an
illusion that there is one by using "stop" [*1*].
It is more like "abort".
I may be done with bisection after running the bisection to the very
end, of I may have realized that the problem is not bisectable due
to many reasons (e.g. the sympotom may be intermittent, or it has
already become apparent that there are more than one cause of the
observed breakage) way before we found "the first bad commit".
And "reset" cleans the bisectoin state and returns to the original
HEAD, regardless of the reason why you are cleaning up. If we were
to add any explanation to the sentence, I think "finish" makes a lot
more sense than "stop".
[Footnote]
*1* another reason to avoid "stop" is that it could mean "I stop
here for now, to later come back and start digging again from
there", which is not "reset" is about at all.
^ permalink raw reply
* Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
From: Andreas Mohr @ 2013-02-09 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git, Andreas Mohr
In-Reply-To: <7v8v6xw3wf.fsf@alter.siamese.dyndns.org>
Hi,
On Sat, Feb 09, 2013 at 01:53:04PM -0800, Junio C Hamano wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> > After a bisect session, to clean up the bisection state and return to
> > -the original HEAD, issue the following command:
> > +the original HEAD (i.e., to finish bisect), issue the following command:
>
> Makes sense.
Doesn't ;)
[aww, very sorry for this blunt reply]
The main point of my mail was to stretch the (whether actually intended)
*perceived* start <-> stop symmetry
(which a *user* quite likely would end up searching for in the document,
and fail to find any "stop" keyword, thus not getting to the relevant
reset parameter section in time).
Quite likely I failed to properly word things to make that obvious,
in my quickly carved mail.
To clarify intent behind these docs, I would thus propose to have
the sentence improved to something quite similar to
the original HEAD (i.e., to finish - "stop" a started - bisect),
issue the following command:
Thanks a ton for your immediate handling of my wishlist item!
Andreas Mohr
^ permalink raw reply
* Re: [PATCH v3 0/8] Hiding refs
From: Junio C Hamano @ 2013-02-09 23:23 UTC (permalink / raw)
To: Jed Brown; +Cc: Michael Haggerty, git, Jeff King, Shawn Pearce
In-Reply-To: <87pq0c15h3.fsf@59A2.org>
Jed Brown <jed@59A2.org> writes:
> I believe that my use case would be well supported if git could push and
> pull unadvertised refs, as long as basic operations were not slowed down
> by the existence of a very large number of such refs.
I am not sure about "pushing" part, but the jc/fetch-raw-sha1 topic
(split from the main jc/hidden-refs topic) should allow your script,
after the client learns the set of smudged object names, to ask for
git fetch $there $sha1_1 $sha1_2 ...
or
git fetch $there $sha1_1:refs/fat/$sha1_1 $sha1_2:refs/fat/$sha1_2 ...
I think.
^ permalink raw reply
* Re: [PATCH v2 06/10] sequencer.c: teach append_signoff how to detect duplicate s-o-b
From: Junio C Hamano @ 2013-02-09 23:06 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jonathan Nieder, pclouds, git, Brandon Casey
In-Reply-To: <7v7gmy12op.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> On Tue, Jan 22, 2013 at 12:38 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Brandon Casey wrote:
>>>
>>>> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
>>>> This is in preparation to unify the append_signoff implementations in
>>>> log-tree.c and sequencer.c.
>>> [...]
>>>> --- a/sequencer.c
>>>> +++ b/sequencer.c
>>>> @@ -1082,9 +1101,10 @@ int sequencer_pick_revisions(struct replay_opts *opts)
>>>> return pick_commits(todo_list, opts);
>>>> }
>>>>
>>>> -void append_signoff(struct strbuf *msgbuf, int ignore_footer)
>>>> +void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
>>>
>>> Isn't the behavior of passing '1' here just a bug in "format-patch -s"?
>>
>> I think that is an open question.
>
> Yes. as I said in a previous review round, I think it was a mistake
> that format-patch chose to pay attention to any S-o-b in the patch
> trail, not only the last one, and we may want to correcct it once
> this series solidifies as a separate "bugfix" change on top.
This is a tangent, but I _think_ (didn't check, though) "git am -s"
implements this incorrrectly. Just another LHF somebody may want to
take a look.
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-09 23:00 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git, Phil Hord
In-Reply-To: <1360425499.3369.10.camel@t520>
Robert Clausecker <fuzxxl@gmail.com> writes:
> After thinking a while about how to solve the problems I have, I
> consider the following things as a solution to my problem.
>
> Add an option --isolated, -i to git checkout: Check out a branch / tag /
> revision but do not touch the index. This could be used together with
> --work-tree to check out a branch into an arbitrary directory. Also, it
> satisfies all 4 criteria from [1] and therefore is perfect for
> deployment from a bare repository.
>
> What do you think about this feature request?
I am not Phil, but if you ask me, I think it is borderline between
"meh" and "no way we would give a short-and-sweet -i to something
like this".
^ 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