* [PATCH] docs: brush up obsolete bits of git-fsck manpage
From: Jeff King @ 2011-12-16 11:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
After the description and options, the fsck manpage contains
some discussion about what it does. Over time, this
discussion has become somewhat obsolete, both in content and
formatting. In particular:
1. There are many options now, so starting the discussion
with "It tests..." makes it unclear whether we are
talking about the last option, or about the tool in
general. Let's start a new "discussion" section and
make our antecedent more clear.
2. It gave an example for --unreachable using for-each-ref
to mention all of the heads, saying that it will do "a
_lot_ of verification". This is hopelessly out-of-date,
as giving no arguments will check much more (reflogs,
the index, non-head refs).
3. It goes on to mention tests "to be added" (like tree
object sorting). We now have these tests.
Signed-off-by: Jeff King <peff@peff.net>
---
I posted this here:
http://thread.gmane.org/gmane.comp.version-control.git/181673/focus=181701
and I think it simply got lost in the discussion.
We ended up discussing the possibility of deprecating refs on the
command-line to fsck. I still think that's reasonable, but in the
meantime, this patch is a reasonable improvement.
Documentation/git-fsck.txt | 26 ++++++++------------------
1 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 0a17b42..6c47395 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -81,30 +81,20 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
progress status even if the standard error stream is not
directed to a terminal.
-It tests SHA1 and general object sanity, and it does full tracking of
-the resulting reachability and everything else. It prints out any
-corruption it finds (missing or bad objects), and if you use the
-'--unreachable' flag it will also print out objects that exist but
-that aren't reachable from any of the specified head nodes.
-
-So for example
-
- git fsck --unreachable HEAD \
- $(git for-each-ref --format="%(objectname)" refs/heads)
+DISCUSSION
+----------
-will do quite a _lot_ of verification on the tree. There are a few
-extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if 'git fsck' is happy, you
-do have a valid tree.
+git-fsck tests SHA1 and general object sanity, and it does full tracking
+of the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+'--unreachable' flag it will also print out objects that exist but that
+aren't reachable from any of the specified head nodes (or the default
+set, as mentioned above).
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
-Of course, "valid tree" doesn't mean that it wasn't generated by some
-evil person, and the end result might be crap. git is a revision
-tracking system, not a quality assurance system ;)
-
Extracted Diagnostics
---------------------
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* [PATCH] use custom rename score during --follow
From: Jeff King @ 2011-12-16 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If you provide a custom rename score on the command line,
like:
git log -M50 --follow foo.c
it is completely ignored, and there is no way to --follow
with a looser rename score. Instead, let's use the same
rename score that will be used for generating diffs. This is
convenient, and mirrors what we do with the break-score.
You can see an example of it being useful in git.git:
$ git log --oneline --summary --follow \
Documentation/technical/api-string-list.txt
86d4b52 string-list: Add API to remove an item from an unsorted list
1d2f80f string_list: Fix argument order for string_list_append
e242148 string-list: add unsorted_string_list_lookup()
0dda1d1 Fix two leftovers from path_list->string_list
c455c87 Rename path_list to string_list
create mode 100644 Documentation/technical/api-string-list.txt
$ git log --oneline --summary -M40 --follow \
Documentation/technical/api-string-list.txt
86d4b52 string-list: Add API to remove an item from an unsorted list
1d2f80f string_list: Fix argument order for string_list_append
e242148 string-list: add unsorted_string_list_lookup()
0dda1d1 Fix two leftovers from path_list->string_list
c455c87 Rename path_list to string_list
rename Documentation/technical/{api-path-list.txt => api-string-list.txt} (47%)
328a475 path-list documentation: document all functions and data structures
530e741 Start preparing the API documents.
create mode 100644 Documentation/technical/api-path-list.txt
You could have two separate rename scores, one for following
and one for diff. But almost nobody is going to want that,
and it would just be unnecessarily confusing. Besides which,
we re-use the diff results from try_to_follow_renames for
the actual diff output, which means having them as separate
scores is actively wrong. E.g., with the current code, you
get:
$ git log --oneline --diff-filter=R --name-status \
-M90 --follow git.spec.in
27dedf0 GIT 0.99.9j aka 1.0rc3
R084 git-core.spec.in git.spec.in
f85639c Rename the RPM from "git" to "git-core"
R098 git.spec.in git-core.spec.in
The first one should not be considered a rename by the -M
score we gave, but we print it anyway, since we blindly
re-use the diff information from the follow (which uses the
default score). So this could also be considered simply a
bug-fix, as with the current code "-M" is completely ignored
when using "--follow".
Signed-off-by: Jeff King <peff@peff.net>
---
I posted this a long time ago as a "you could do it like this" patch:
http://thread.gmane.org/gmane.comp.version-control.git/160681
but never actually dug more to make sure it wasn't having any weird
effects on the diff output. As it turns out, I think it is not only not
having a bad effect, but is actively fixing a bug. :)
tree-diff.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 7a51d09..28ad6db 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -209,6 +209,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->pathspec.raw[0];
diff_opts.break_opt = opt->break_opt;
+ diff_opts.rename_score = opt->rename_score;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-12-16 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
We already provide sane hunk-header patterns for specific
languages.
However, the user has to manually map common extensions to
use them. It's not that hard to do, but it's an extra step
that the user might not even know is an option. Let's be
nice and do it automatically.
It could be a problem in the future if the builtin userdiff
drivers started growing more invasive options, like
automatically claiming to be non-binary (e.g., setting
diff.cpp.binary = false by default), but right now we do not
do that, so it should be safe. To help safeguard against
future changes, we add a new test to t4012 making sure that
we don't consider binary files as text by their extension.
We also have to update t4018, which assumed that without a
.gitattributes file, we would receive the default funcname
pattern for a file matching "*.java". Changing this behavior
is not covering up a regression, but rather the feature
working as intended.
Signed-off-by: Jeff King <peff@peff.net>
---
I forgot to send this out in time for v1.7.8.
Prior discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/180103
and here:
http://thread.gmane.org/gmane.comp.version-control.git/181253
The list of extensions is collected from those threads. The tests are
new since the last time I posted (and the t4018 is slightly different
than what you queued in pu).
I punted on the question of case-sensitivity. Brandon mentioned using
fnmatch_icase to handle this, which sounds sane, but I think it is
really a separate topic.
attr.c | 24 ++++++++++++++++++++++++
t/t4012-diff-binary.sh | 13 +++++++++++++
t/t4018-diff-funcname.sh | 10 +++++++++-
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index 76b079f..2ad7cc4 100644
--- a/attr.c
+++ b/attr.c
@@ -306,6 +306,30 @@ static void free_attr_elem(struct attr_stack *e)
static const char *builtin_attr[] = {
"[attr]binary -diff -text",
+ "*.html diff=html",
+ "*.htm diff=html",
+ "*.java diff=java",
+ "*.perl diff=perl",
+ "*.pl diff=perl",
+ "*.php diff=php",
+ "*.py diff=python",
+ "*.rb diff=ruby",
+ "*.bib diff=bibtex",
+ "*.tex diff=tex",
+ "*.c diff=cpp",
+ "*.cc diff=cpp",
+ "*.cxx diff=cpp",
+ "*.cpp diff=cpp",
+ "*.h diff=cpp",
+ "*.hpp diff=cpp",
+ "*.cs diff=csharp",
+ "*.[Ff] diff=fortran",
+ "*.[Ff][0-9][0-9] diff=fortran",
+ "*.m diff=objc",
+ "*.mm diff=objc",
+ "*.pas diff=pascal",
+ "*.pp diff=pascal",
+ "*.lpr diff=pascal",
NULL,
};
diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
index 2d9f9a0..b2fc807 100755
--- a/t/t4012-diff-binary.sh
+++ b/t/t4012-diff-binary.sh
@@ -90,4 +90,17 @@ test_expect_success 'diff --no-index with binary creation' '
test_cmp expected actual
'
+test_expect_success 'binary files are not considered text by file extension' '
+ echo Q | q_to_nul >binary.c &&
+ git add binary.c &&
+ cat >expect <<-\EOF &&
+ diff --git a/binary.c b/binary.c
+ new file mode 100644
+ index 0000000..1f2a4f5
+ Binary files /dev/null and b/binary.c differ
+ EOF
+ git diff --cached binary.c >actual &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 4bd2a1c..a6227ef 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -124,7 +124,9 @@ do
done
test_expect_success 'default behaviour' '
- rm -f .gitattributes &&
+ cat >.gitattributes <<-\EOF &&
+ *.java diff=default
+ EOF
test_expect_funcname "public class Beer\$"
'
@@ -187,4 +189,10 @@ test_expect_success 'alternation in pattern' '
test_expect_funcname "public static void main("
'
+test_expect_success 'custom diff drivers override built-in extension matches' '
+ test_config diff.foo.funcname "int special" &&
+ echo "*.java diff=foo" >.gitattributes &&
+ test_expect_funcname "int special"
+'
+
test_done
--
1.7.7.4.13.g57bf4
^ permalink raw reply related
* git 1.7.7.5
From: Jonathan Nieder @ 2011-12-16 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
I noticed that v1.7.7.5 was tagged a few days ago (b36dcd72), but
there is no corresponding tarball at
http://code.google.com/p/git-core/downloads/list
Will there be an official tarball?
I don't mind either way, but it would be useful to know whether
distributors should make their own or just wait.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] Add '-P' as a synonym for '--no-pager' in the git command
From: Matthieu Moy @ 2011-12-16 9:30 UTC (permalink / raw)
To: Joe Ratterman; +Cc: gitster, git
In-Reply-To: <1323982541-18995-1-git-send-email-jratt0@gmail.com>
Joe Ratterman <jratt0@gmail.com> writes:
> Also, add both -P|--no-pager to the existing -p|--paginate in bash
> completion.
A good commit message should always answer the question "why?". In this
case, I really don't see why this is needed. If you don't like Git's
auto-paginate feature, turn it off with core.pager or pager.<cmd>. If
you like it, you very rarely need --no-pager (IIRC, I'm the one who
introduced --no-pager, and I don't think I've ever used it outside a
script).
So, I'd rather keep -P free in case we need it later for something
really useful (or possibly a better commit message).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v3 2/3] grep: enable threading with -p and -W using lazy attribute lookup
From: Johannes Sixt @ 2011-12-16 8:22 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Junio C Hamano, René Scharfe, Jeff King, Eric Herman
In-Reply-To: <138b930c0c96029f2fb9a816e73e70a4d5bce1de.1323723759.git.trast@student.ethz.ch>
Am 12/12/2011 22:16, schrieb Thomas Rast:
> diff --git a/grep.h b/grep.h
> index a652800..15d227c 100644
> --- a/grep.h
> +++ b/grep.h
> @@ -115,6 +115,7 @@ struct grep_opt {
> int show_hunk_mark;
> int file_break;
> int heading;
> + int use_threads;
> void *priv;
>
> void (*output)(struct grep_opt *opt, const void *data, size_t size);
> @@ -131,4 +132,10 @@ struct grep_opt {
> extern struct grep_opt *grep_opt_dup(const struct grep_opt *opt);
> extern int grep_threads_ok(const struct grep_opt *opt);
>
> +#ifndef NO_PTHREADS
> +/* Mutex used around access to the attributes machinery if
> + * opt->use_threads. Must be initialized/destroyed by callers! */
> +extern pthread_mutex_t grep_attr_mutex;
> +#endif
> +
> #endif
This is the first time we use pthread_mutex_t in a header file. We need at
least the following squashed in. An alternative would be to include
"thread-utils.h", but thread-utils is really more about implementation
helpers functions, not about types, and therefore does not look right to
be #included in a header.
---
grep.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/grep.h b/grep.h
index 15d227c..754b270 100644
--- a/grep.h
+++ b/grep.h
@@ -133,6 +133,7 @@ extern struct grep_opt *grep_opt_dup(const struct
grep_opt *opt);
extern int grep_threads_ok(const struct grep_opt *opt);
#ifndef NO_PTHREADS
+#include <pthread.h>
/* Mutex used around access to the attributes machinery if
* opt->use_threads. Must be initialized/destroyed by callers! */
extern pthread_mutex_t grep_attr_mutex;
--
1.7.8.1436.gb3021
^ permalink raw reply related
* Re: error: insufficient permission
From: Manish Patel @ 2011-12-16 8:09 UTC (permalink / raw)
To: git
In-Reply-To: <4AB73A07.3020703@bioinf.uni-leipzig.de>
Very simple.. just find out .git directory give 0777 permission to objects
dir.. such as..
chmod -R 0777 objects
--
View this message in context: http://git.661346.n2.nabble.com/error-insufficient-permission-tp3683868p7099986.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Revisiting metadata storage
From: Jonathan Nieder @ 2011-12-16 7:52 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Richard Hartmann, Ronan Keryell, Git List
In-Reply-To: <CAE1pOi2TGWmFErcKhQu-a37JjLh22O1zFYoBaVRyfBDFjOTE9Q@mail.gmail.com>
Hilco Wijbenga wrote:
> Right now every rebase means a full (and almost
> completely unnecessary) rebuild.
It sounds like what you are suffering from is that "git rebase" uses
the worktree as its workspace instead of doing all that work
in-memory, right?
If I were in your situation, I would do the following:
1. Don't rebase so often. When wanting to take advantage of features
from a new upstream version, use "git merge" to pull it in. Only
rebase when it is time to make the history presentable for other
people.
This way, "git log --first-parent" will give easy access to
the intermediate versions you have hacked on and tested recently.
2. When history gets ugly and you want to rebase to make the series
easier to make sense of, use a separate workdir:
$ git branch tmp; # make a copy to rebase
$ cd ..
$ git new-workdir repo rebase-scratch tmp
$ cd rebase-scratch
$ git rebase -i origin/master
...
$ cd ..
$ rm -fr rebase-scratch
$ cd repo
$ git diff HEAD tmp; # Does the rebased version look better?
$ git reset --keep tmp; # Yes. Use it.
$ git branch -d tmp
3. Once the rebased history looks reasonably good, be sure to rebase
one final time and test each commit before submitting for other
people's use.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Branch names with slashes
From: Johannes Sixt @ 2011-12-16 7:02 UTC (permalink / raw)
To: Leonardo Kim; +Cc: git
In-Reply-To: <CAGcUY13TOodu1BO3DCoNnVvNZ9QkWAbD-RmyqQX6P1q6tcO+yg@mail.gmail.com>
Am 12/14/2011 11:17, schrieb Leonardo Kim:
> Branch names can contain slashes, so we can use 'development/foo' as a
> branch name. If I choose 'development' as a branch name, it doesn't
> work. There is a directory named development at '.git/refs/heads'
> directory. So we cannot create a file named development for
> 'refs/heads/development'.
>
> An error message may occurs like below. Unfortunately, It is not of help to me.
> 'error: 'refs/heads/development/foo' exists; cannot create
> 'refs/heads/development'.
>
> I think that dealing with a file system and an error message above is
> not sufficient for a novice like me. I hope that it should be
> improved.
Sorry, I don't see anything in the error message that makes a connection
between refs and a file system; it only says "foo/bar exists; cannot
create foo". I really don't see how this can be improved to avoid confusion.
-- Hannes
^ permalink raw reply
* How to generate pull-request with info of signed tag
From: Aneesh Kumar K.V @ 2011-12-16 6:35 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Hi,
I am using git from master branch and wanted to try the signed pull
request. I have pushed the signed tag to repo.or.cz, but not sure how to
generate pull request with signed tag information ? git-pull-request
insist on a branch on the server and put the branch details in the
pull-request text, It do add tag description but not the tag name and
still put "repo-name branch" name in the txt. Shouldn't that be
"repo-name tag-name" so that one can cut-paste that in pull request ?
-aneesh
^ permalink raw reply
* Re: How to commit incomplete changes?
From: Tomas Carnecky @ 2011-12-16 1:49 UTC (permalink / raw)
To: Hallvard B Furuseth; +Cc: git
In-Reply-To: <4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no>
On 12/15/11 12:24 AM, Hallvard B Furuseth wrote:
> I'm about to commit some small edits which go together with bigger
> generated changes. It seems both more readable and more cherry-pick-
> friendly to me to keep these in separate commits.
Why do you store generated code? Usually you only store what is
absolutely necessary. That means generated code should be generated as
needed (part of the build process for example).
tom
^ permalink raw reply
* Re: How to commit incomplete changes?
From: Junio C Hamano @ 2011-12-16 0:21 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Hallvard B Furuseth, git
In-Reply-To: <4EEA79E0.4070700@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
> A main purpose for the squash and fixup options is ...
> "To make it look like you
> did it all perfectly without making any mistakes" (or a reasonable
> facsimile thereof). You insights on the cherry-picking of fixes is
> interesting, but makes no sense in the context of unpublished work.
> Why would you need to cherry-pick fixes to mistakes that have not yet
> been propagated (published)?
> ...
> I assume by 'generated changes' you mean the automerge in git...
My reading of the "need to split" example was not "bulk of work plus fixes
to mistakes". Imagine you are working on somebody else's code and for some
reason you want to do
s/setenv/xsetenv/g
all over the code, and also add a wrapper to implement xsetenv() function.
You _could_ do it in one single commit, but what happens when you try to
adjust to the updated upstream code, which may have added new callsites to
setenv()?
If you keep it as two patches, one is mechanical (i.e. s/setenv/xsetenv/g)
and the other is manual (i.e. implementation of xsetenv()), then you can
discard the text of the "mechanical" one from the old series and instead
run the substitution on the updated code, and then cherry-pick the
"manual" one.
If you did the mechanical one first, the resulting code would not compile
(lacks xsetenv() implementation), and then the second "manual" one would
"fix" it. In this simplified example, it is easy to flip the orders and
keep things work, but then you would get a complaint from clever compiler
or linker that xsetenv() implementation is defined but nobody uses it,
which is another kind of breakage. So it _is_ possible that you cannot
avoid breaking the system inside two patches, making them "all-or-none"
series.
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #05; Thu, 15)
From: Junio C Hamano @ 2011-12-16 0:11 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'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* ef/setenv-putenv (2011-12-14) 2 commits
- compat/setenv.c: error if name contains '='
- compat/setenv.c: update errno when erroring out
(this branch is used by ef/x-setenv-putenv.)
* jk/maint-do-not-feed-stdin-to-tests (2011-12-15) 1 commit
- test-lib: redirect stdin of tests
* jn/test-cleanup-7006 (2011-12-14) 1 commit
- test: errors preparing for a test are not special
* nd/war-on-nul-in-commit (2011-12-15) 3 commits
- commit_tree(): refuse commit messages that contain NULs
- Convert commit_tree() to take strbuf as message
- merge: abort if fails to commit
* jk/git-prompt (2011-12-12) 10 commits
- contrib: add credential helper for OS X Keychain
- Makefile: OS X has /dev/tty
- Makefile: linux has /dev/tty
- credential: use git_prompt instead of git_getpass
- prompt: use git_terminal_prompt
- add generic terminal prompt function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- imap-send: don't check return value of git_getpass
- imap-send: avoid buffer overflow
(this branch uses jk/credentials.)
Will merge to 'next' after taking another look.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
(this branch uses mh/ref-api.)
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler.
--------------------------------------------------
[Graduated to "master"]
* bc/maint-apply-check-no-patch (2011-12-05) 2 commits
(merged to 'next' on 2011-12-09 at fc780cd)
+ builtin/apply.c: report error on failure to recognize input
+ t/t4131-apply-fake-ancestor.sh: fix broken test
* cn/maint-lf-to-crlf-filter (2011-11-28) 1 commit
(merged to 'next' on 2011-12-09 at c374d14)
+ convert: track state in LF-to-CRLF filter
* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
+ archive: don't let remote clients get unreachable commits
(this branch is used by jk/maint-upload-archive.)
* jk/maint-fetch-status-table (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at 159415e)
+ fetch: create status table using strbuf
* jk/maint-upload-archive (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 03deb16)
+ Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archive
(this branch uses jk/maint-1.6.2-upload-archive.)
* jl/submodule-status-failure-report (2011-12-08) 1 commit
(merged to 'next' on 2011-12-09 at 53eb3b3)
+ diff/status: print submodule path when looking for changes fails
* jn/branch-move-to-self (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 7d27260)
+ Allow checkout -B <current-branch> to update the current branch
+ branch: allow a no-op "branch -M <current-branch> HEAD"
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
(merged to 'next' on 2011-12-09 at 7662e58)
+ gitweb: Add navigation to select side-by-side diff
+ gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
+ t9500: Add basic sanity tests for side-by-side diff in gitweb
+ t9500: Add test for handling incomplete lines in diff by gitweb
+ gitweb: Give side-by-side diff extra CSS styling
+ gitweb: Add a feature to show side-by-side diff
+ gitweb: Extract formatting of diff chunk header
+ gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* ks/tag-cleanup (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at cbea045)
+ git-tag: introduce --cleanup option
* nd/ignore-might-be-precious (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 1a94553)
+ checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
+ Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-precious
* tj/maint-imap-send-remove-unused (2011-11-23) 2 commits
(merged to 'next' on 2011-12-09 at 877cc11)
+ Merge branch 'maint' into tj/imap-send-remove-unused
+ imap-send: Remove unused 'use_namespace' variable
* tr/userdiff-c-returns-pointer (2011-12-06) 1 commit
(merged to 'next' on 2011-12-09 at 0b6a092)
+ userdiff: allow * between cpp funcname words
--------------------------------------------------
[Cooking]
* ci/stripspace-docs (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at 35b2cdf)
+ Update documentation for stripspace
* jk/maint-mv (2011-12-12) 5 commits
(merged to 'next' on 2011-12-13 at 58caedb)
+ mv: be quiet about overwriting
+ mv: improve overwrite warning
+ mv: make non-directory destination error more clear
+ mv: honor --verbose flag
+ docs: mention "-k" for both forms of "git mv"
* jk/maint-snprintf-va-copy (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at d37a7e1)
+ compat/snprintf: don't look at va_list twice
* jn/maint-sequencer-fixes (2011-12-12) 7 commits
(merged to 'next' on 2011-12-13 at 5b3950c)
+ revert: stop creating and removing sequencer-old directory
+ Revert "reset: Make reset remove the sequencer state"
+ revert: do not remove state until sequence is finished
+ revert: allow single-pick in the middle of cherry-pick sequence
+ revert: pass around rev-list args in already-parsed form
+ revert: allow cherry-pick --continue to commit before resuming
+ revert: give --continue handling its own function
(this branch is used by rr/revert-cherry-pick.)
* mh/ref-api (2011-12-12) 16 commits
(merged to 'next' on 2011-12-15 at d65a830)
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ repack_without_ref(): remove temporary
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
(this branch is used by mh/ref-api-rest.)
Later part split out to expedite moving the earlier good bits forward.
* nd/resolve-ref (2011-12-13) 3 commits
(merged to 'next' on 2011-12-13 at c7002e9)
+ Rename resolve_ref() to resolve_ref_unsafe()
+ Convert resolve_ref+xstrdup to new resolve_refdup function
+ revert: convert resolve_ref() to read_ref_full()
* tr/grep-threading (2011-12-12) 3 commits
- grep: disable threading in non-worktree case
- grep: enable threading with -p and -W using lazy attribute lookup
- grep: load funcname patterns for -W
Will merge to 'next' after taking another look.
* tr/pty-all (2011-12-12) 3 commits
- t/lib-terminal: test test-terminal's sanity
- test-terminal: set output terminals to raw mode
- test-terminal: give the child an empty stdin TTY
* jc/push-ignore-stale (2011-12-14) 2 commits
- push: --ignore-stale option
- set_ref_status_for_push(): use transport-flags abstraction
* jk/fetch-no-tail-match-refs (2011-12-13) 4 commits
(merged to 'next' on 2011-12-13 at 805c018)
+ connect.c: drop path_match function
+ fetch-pack: match refs exactly
+ t5500: give fully-qualified refs to fetch-pack
+ drop "match" parameter from get_remote_heads
* jk/maint-push-over-dav (2011-12-13) 2 commits
(merged to 'next' on 2011-12-13 at 45e376c)
+ http-push: enable "proactive auth"
+ t5540: test DAV push with authentication
* rr/revert-cherry-pick (2011-12-15) 6 commits
- t3502, t3510: clarify cherry-pick -m failure
- t3510 (cherry-pick-sequencer): use exit status
- revert: simplify getting commit subject in format_todo()
- revert: tolerate extra spaces, tabs in insn sheet
- revert: make commit subjects in insn sheet optional
- revert: free msg in format_todo()
(this branch uses jn/maint-sequencer-fixes.)
Picked up only the earlier bits that are reasonably clear for now.
* ew/keepalive (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 1b5d5c4)
+ enable SO_KEEPALIVE for connected TCP sockets
* jc/checkout-m-twoway (2011-12-15) 3 commits
(merged to 'next' on 2011-12-15 at cc64fed)
+ checkout_merged(): squelch false warning from some gcc
(merged to 'next' on 2011-12-11 at b61057f)
+ Test 'checkout -m -- path'
(merged to 'next' on 2011-12-09 at c946009)
+ checkout -m: no need to insist on having all 3 stages
* tr/cache-tree (2011-12-06) 5 commits
(merged to 'next' on 2011-12-13 at e0da64d)
+ reset: update cache-tree data when appropriate
+ commit: write cache-tree data when writing index anyway
+ Refactor cache_tree_update idiom from commit
+ Test the current state of the cache-tree optimization
+ Add test-scrap-cache-tree
* jc/commit-amend-no-edit (2011-12-08) 5 commits
(merged to 'next' on 2011-12-09 at b9cfa4e)
+ test: commit --amend should honor --no-edit
+ commit: honour --no-edit
+ t7501 (commit): modernize style
+ test: remove a porcelain test that hard-codes commit names
+ test: add missing "&&" after echo command
Will merge to 'master'.
* rr/test-chaining (2011-12-11) 7 commits
(merged to 'next' on 2011-12-13 at b08445e)
+ t3401: use test_commit in setup
+ t3401: modernize style
+ t3040 (subprojects-basic): fix '&&' chaining, modernize style
+ t1510 (worktree): fix '&&' chaining
+ t3030 (merge-recursive): use test_expect_code
+ test: fix '&&' chaining
+ t3200 (branch): fix '&&' chaining
* aw/rebase-i-stop-on-failure-to-amend (2011-11-30) 1 commit
(merged to 'next' on 2011-12-09 at a117e83)
+ rebase -i: interrupt rebase when "commit --amend" failed during "reword"
Will merge to 'master'.
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
(this branch uses jc/stream-to-pack.)
Not ready. At least pack-objects and fsck need to learn the new encoding
for the series to be usable locally, and then index-pack/unpack-objects
needs to learn it to be used remotely.
* jh/fast-import-notes (2011-11-28) 3 commits
(merged to 'next' on 2011-12-09 at 2b01132)
+ fast-import: Fix incorrect fanout level when modifying existing notes refs
+ t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
+ t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
Will merge to 'master'.
* jk/credentials (2011-12-12) 14 commits
(merged to 'next' on 2011-12-12 at 7a6d658)
+ t: add test harness for external credential helpers
+ credentials: add "store" helper
+ strbuf: add strbuf_add*_urlencode
+ Makefile: unix sockets may not available on some platforms
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ credential: make relevance of http path configurable
+ credential: add credential.*.username
+ credential: apply helper config
+ http: use credential API to get passwords
+ credential: add function for parsing url components
+ introduce credentials API
+ t5550: fix typo
+ test-lib: add test_config_global variant
(this branch is used by jk/git-prompt.)
Later part split out to expedite moving the earlier good bits forward.
* jk/upload-archive-use-start-command (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 88cb83a)
+ upload-archive: use start_command instead of fork
Will merge to 'master'.
* ab/enable-i18n (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 65af8cd)
+ i18n: add infrastructure for translating Git with gettext
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
Not exactly urgent.
* jc/stream-to-pack (2011-12-01) 5 commits
(merged to 'next' on 2011-12-09 at d0fd605)
+ bulk-checkin: replace fast-import based implementation
+ csum-file: introduce sha1file_checkpoint
+ finish_tmp_packfile(): a helper function
+ create_tmp_packfile(): a helper function
+ write_pack_header(): a helper function
(this branch is used by jc/split-blob.)
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. The codepath to
move data from worktree to repository is made aware of streaming, just
like the checkout codepath that goes the other way, which was done in the
previous "large file support" topic in the 1.7.7 cycle.
Will merge to 'master'.
^ permalink raw reply
* Re: Branch names with slashes
From: Junio C Hamano @ 2011-12-16 0:10 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Neal Kreitzinger, Leonardo Kim, git
In-Reply-To: <4EEA777C.6040607@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I don't believe that it would be possible to relax this limitations
> without at least a little breakage of backwards compatibility.
I do not think it is worth it, but you _could_ update your git to use a
file whose name is "refs/heads/.foo/bar" as the representation of foo/bar
branch and refs.c API, especially the ones close to resolve_ref(), should
be the only ones that need to know about this. While walking the filesystem
in refs/ hierarchy, any directory you see whose name do not begin with dot
you would treat it as a legacy one and perhaps rename it to match the new
convention on the fly.
> What is the bottom line? Feel free to submit patches to improve the
> documentation or error reporting. But I doubt that the underlying
> limitation will be removed.
I do not think so either. It is not even a limitation but is a basic
nature of "hierarchical names".
^ permalink raw reply
* Re: git help prune accuracy?
From: Junio C Hamano @ 2011-12-16 0:04 UTC (permalink / raw)
To: Martin Fick; +Cc: Git List
In-Reply-To: <201112151601.52968.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> ... The summary line reads:
>
> git-prune - Prune all unreachable objects from the object
> database
Yea, prune itself has always been primarily about getting rid of
unreachable objects. I suspect (I didn't check) that we did not even have
a call to prune-packed in its original implementation and it was later
added as "we are doing the pruning anyway, why not do this as well while
at it".
Yeah, I just checked. Before 51890a6 (Call prune-packed from "git prune"
as well., 2005-08-19), we didn't. And 2396ec8 (Add "git-prune-packed"
that removes objects that exist in a pack., 2005-07-03) explains it rather
nicely:
Add "git-prune-packed" that removes objects that exist in a pack.
This, together with "git repack" can be used to clean up unpacked
git archives.
> I don't quite have an alternative suggestion for a better
> summary, the best I could do (but don't like) is:
>
> git-prune - Prune loose objects (unreachable or packed)
For a one-liner description, "Remove unnecessary or redundant loose
objects" without parentheses may be better. Explaining "git prune" as
"this prunes" does not add as much information as restating it using a
different and more common verb.
The body text can clarify what we mean by "unnecessary" and "redundant".
A loose object that is old may be unreachable from any of the refs,
i.e. unused, and hence unnecessary. Or the same object as a loose one may
be found in a pack, which would make the loose one redundant.
^ permalink raw reply
* Re: [PATCH 10/10] revert: report fine-grained error messages from insn parser
From: Ramkumar Ramachandra @ 2011-12-15 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder
In-Reply-To: <7vsjklmsvt.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Three kinds of errors can arise from parsing '.git/sequencer/todo':
>> 1. Unrecognized action
>> 2. Missing space after valid action prefix
>
> I think these two are the same and shouldn't result in different error
> messages, i.e. the first one in this sequence is still an "Unrecognized
> action" error and does not have anything to do with "pick" action.
>
> pickle rr/cherry-pick~4
> pick rr/cherry-pick~3
Good point. I'll change the parser to check for "pick " || "pick\t"
and "revert " || "revert\t" explicitly in the re-roll.
Thanks.
-- Ram
^ permalink raw reply
* Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path
From: Paul Mackerras @ 2011-12-15 22:59 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Pat Thoyts, Johannes Schindelin, Junio C Hamano, David Aguilar,
Git, msysGit
In-Reply-To: <CAOeW2eHD7Xutf+pHDyMOo=uZC9PSFZi+aMq1Rx80iTKPFApr8A@mail.gmail.com>
On Thu, Dec 15, 2011 at 11:42:38AM -0800, Martin von Zweigbergk wrote:
> git://git.kernel.org/pub/scm/gitk/gitk.git is still down.
I have just created a repository on ozlabs.org for gitk, since I don't
have kernel.org access at this point. The repository is:
git://ozlabs.org/~paulus/gitk.git
> Paul and Junio, the patches I sent in April are still not in git.git,
> are they? Can we use another repo until the kernel.org one is up? More
> than eight months to get a patch (or eight) merged is way too long,
> IMO.
Your patches are in the master branch. I applied them back in July
but then kernel.org went down.
Paul.
^ permalink raw reply
* Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path
From: Paul Mackerras @ 2011-12-15 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git
In-Reply-To: <7v1us5obqa.fsf@alter.siamese.dyndns.org>
On Thu, Dec 15, 2011 at 11:50:53AM -0800, Junio C Hamano wrote:
> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
>
> > Paul and Junio, the patches I sent in April are still not in git.git,
> > are they? Can we use another repo until the kernel.org one is up? More
> > than eight months to get a patch (or eight) merged is way too long,
> > IMO.
>
> I tend to agree.
>
> I have this slight suspicion that Paul would appreciate if somebody who
> cares about gitk who is capable and willing steps forward and takes over
> the maintainership of gitk, as he is busy in his other projects.
Indeed. For now I have put up a repository on ozlabs.org:
git://ozlabs.org/~paulus/gitk.git
but if someone wants to take on the gitk maintainership, please let me
know.
Paul.
^ permalink raw reply
* Re: git help prune accuracy?
From: Martin Fick @ 2011-12-15 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v1us5mqc4.fsf@alter.siamese.dyndns.org>
On Thursday, December 15, 2011 03:18:19 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> >> objects from the object database. In addition, it
> >>
> >> prunes the unpacked objects that are also found in
> >> packs by running git prune-packed.
> >>
> >> The last sentence seems like it should maybe have the
> >> following fix:
> >>
> >> s/it prunes the unpacked/it prunes the unreferenced/
> >
> > Ack, I meant:
> >
> > s/it prunes the unpacked/it prunes the unreachable/
>
> "In addition" part is about objects that exist in loose
> format that are also found in packs and has nothing to
> do with reachability.
>
> Running "git pack-objects" to collect loose objects into
> a new pack will not remove these loose objects that are
> copied into that new pack. Because we try to access
> objects from an already open packfile before trying a
> loose object file, removing these now-redundant loose
> ones after they are packed makes sense. And that is what
> "git prune-packed" does.
Thanks Junio, that makes a lot of sense. I don't know why I
was not getting that from the description even though that
was exactly what I was looking for. Maybe it was because of
the intro/summary line? Now that I think I understand what
it is doing, it seems like this command is more about
"pruning loose objects" (whether unreachable or already
packed) than it is about "pruning unreachable objects"
(which could be loose or packed)? The summary line reads:
git-prune - Prune all unreachable objects from the object
database
Maybe I am not familiar enough with git terminology, but
does "object database" imply loose objects only? Because
the word "all" in that summary makes it sound like it will
prune all unreachable objects (loose and packed).
I don't quite have an alternative suggestion for a better
summary, the best I could do (but don't like) is:
git-prune - Prune loose objects (unreachable or packed)
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [BUG] in rev-parse
From: Michael Haggerty @ 2011-12-15 22:53 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, nathan.panike, git
In-Reply-To: <20111215070521.GB1327@sigill.intra.peff.net>
On 12/15/2011 08:05 AM, Jeff King wrote:
> On Wed, Dec 14, 2011 at 07:20:41PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> On the other hand, it has been like this since it was introduced in
>>> 2006, and I wonder if scripts rely on the --verify side effect.
>>
>> It would have been nicer if it did not to imply --verify at all; a long
>> hexdigit that do not name an existing object at all will be shortened to
>> its prefix that still do not collide with an abbreviated object name of an
>> existing object, and even in such a case, the command should not error out
>> only because it was fed a non-existing object (of course, if "--verify" is
>> given at the same time, its "one input that names existing object only"
>> rule should also kick in).
>
> Dropping the implied verify is easy (see below). But handling
> non-existant sha1s is a much more complicated change, as the regular
> abbreviation machinery assumes that they exist. E.g., with the patch
> below:
>
> $ good=73c6b3575bc638b7096ec913bd91193707e2265d
> $ bad=${good#d}e
> $ git rev-parse --short $good
> 73c6b35
> $ git rev-parse --short $bad
> [no output]
>
> Anyway, I'm not sure it's worth changing at this point. It's part of the
> plumbing API that has been that way forever, it's kind of a rare thing
> to ask for, and I've already shown a workaround using rev-list.
I believe that the OP was more inconvenienced that "git rev-parse
--short" chokes on multiple objects than by the fact that it insists
that the objects exist. (And shortening the SHA1s of non-existent
objects doesn't sound very useful anyway.) So I think that a useful
compromise would be for "git rev-parse --short" to accept multiple args
but continue to insist that each of the args is a valid object.
If that is considered too big a break with backwards compatibility, one
could add a --no-verify option that turns off the verification behavior
of --short. But IMHO this problem is not important enough to justify
adding an extra option.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: How to commit incomplete changes?
From: Neal Kreitzinger @ 2011-12-15 22:51 UTC (permalink / raw)
To: Hallvard B Furuseth; +Cc: git
In-Reply-To: <4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no>
On 12/14/2011 5:24 PM, Hallvard B Furuseth wrote:
> Do people have any feelings or conventions for how and when to publish
> a series of commits where the first one(s) break something and the next
> ones clear it up? I've found some discussion, but with vague results.
>
> I'm about to commit some small edits which go together with bigger
> generated changes. It seems both more readable and more cherry-pick-
> friendly to me to keep these in separate commits.
>
> What I've found is I can use a line in the commit message like
> "Incomplete change, requires next commit (update foo/ dir)."
> and, if there is any point, do a no-ff merge past the breakage.
>
A main purpose for the squash and fixup options is (as Randall Schwartz
put it in his git video http://www.youtube.com/watch?v=8dhZ9BXQgc4) "To
make it look like you did it all perfectly without making any mistakes"
(or a reasonable facsimile thereof). You insights on the cherry-picking
of fixes is interesting, but makes no sense in the context of
unpublished work. Why would you need to cherry-pick fixes to mistakes
that have not yet been propagated (published)? If the cherry-picks of
fixes are for your other already merged local branches then just save
the pre-squash/fixup version of the branch to another branch, (ie, git
branch mybranch-b4-fixup) and cherry-pick from that unsquashed copy to
patch up your other unpublished branches. Keep in mind that cherry-pick
is not alway the best way to apply fixes. A merge or rebase to get the
fix is the sign of a better workflow in many cases, TBOMK. On the other
hand, if the bugs have been published then you have no choice but to
commit the fix separately because you can't rearrage/edit published
history. Keep in mind that ideally commits should be logical. You can
use the rearrage feature of interactive rebase to squash fixes into the
feature commit they go to. IOW, I don't think squashing everything into
a giant commit just to consolidate bugfixes into a single commit makes
sense if that would mean losing the distinct separation between
differing feature commits.
I assume by 'generated changes' you mean the automerge in git that is a
wonderful default for vast systems like the linux kernel in which code
is unlikely to overlap logically, but very dangerous in legacy
application systems where changes to the same file can create logical
bugs despite not being on the 'exact same line of code'. You are
supposed to review all your merged files after a merge regardless.
However, we don't trust ourselves that much in our shop so we force
conflicts on same-file edits by making "user-date stamp" updates on
"line 1" (depends on language-dependent comment line rules) in our
pre-commit hook. That way we are forced to manually review the merge of
same-file edits "by hand" thus avoiding "generated results". Of course,
unique-file edits can still break things and thus a merge review is
still in order.
Hope this helps. I'm not a git workflow expert, but my comments are
based on experience. I too am still looking for better ways to manage
workflow while leveraging the flexibity and agility of git for
concurrent development.
v/r,
neal
^ permalink raw reply
* Re: Branch names with slashes
From: Michael Haggerty @ 2011-12-15 22:41 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Leonardo Kim, git
In-Reply-To: <4EEA5B55.1040405@gmail.com>
On 12/15/2011 09:40 PM, Neal Kreitzinger wrote:
> On 12/14/2011 4:17 AM, Leonardo Kim wrote:
>> Branch names can contain slashes, so we can use 'development/foo' as
>> a branch name. If I choose 'development' as a branch name, it doesn't
>> work. There is a directory named development at '.git/refs/heads'
>> directory. So we cannot create a file named development for
>> 'refs/heads/development'.
>>
>> An error message may occurs like below. Unfortunately, It is not of
>> help to me. 'error: 'refs/heads/development/foo' exists; cannot
>> create 'refs/heads/development'.
>>
>> I think that dealing with a file system and an error message above is
>> not sufficient for a novice like me. I hope that it should be
>> improved.
>>
> FYI, We also use slashes in our branchnames to leverage some of the
> benefits of a path-like namespace like pattern matching and the logical
> expression of hierarchies using descriptive compound names. (We use git
> 1.7.1 on linux.) Here's something to keep in mind: You have to plan
> (think ahead) for your naming conventions so that the namespaces will
> maintain uniqueness at a peer level over time that cannot be confused as
> subdirs under .git/refs/heads. For example:
>
> branchnames:
> /mysystem/generic
> /mysystem/generic/project1
>
> will not work because /mysystem/generic appears to be a parent dir to
> /mysystem/generic/project1 under .git/refs/heads. The solution is:
>
> /mysystem/generic/base
> /mysystem/generic/project1
>
> these branches can coexist because they are unique without one appearing
> to be a parent dir of the other. IOW, their namespaces are peers in
> their entirety. To carry the example a little further,
>
> /mysystem/generic/project1/part2
> will not work because once again it appears to be a subdir of an
> existing branchname (ref). However,
> /mysystem/generic/project1-part2
> will work.
>
> I think the reason for this is that if you look at .git/refs/heads you
> will see that these slash delimited branch names are actually stored as
> subdirs in the filesystem sense. Therefore, git will get confused and
> error out as it tries to find branchnames that are not entirely unique
> by their full path namespace under .git/refs/heads because a branch
> namespace that is a prefix (in the filesystem sense) of another branch
> name would occupy the same path under .git/refs/heads without being
> distinguishable as unique, and vice versa.
Everything that you say is correct. And it is known, at least to a few
git implementers (i.e., not a bug but a conscious design decision). For
example, the function is_refname_available() is used explicitly to
prevent refnames that conflict in the way that you describe *even if*
the refnames in question are packed and therefore not 1:1 with
filesystem paths. This is all a limitation of the fact that references
*can* be represented by files and therefore they inherit the filesystem
constraint that a file and subdirectory within a single parent directory
cannot have the same name.
I don't believe that it would be possible to relax this limitations
without at least a little breakage of backwards compatibility.
What is the bottom line? Feel free to submit patches to improve the
documentation or error reporting. But I doubt that the underlying
limitation will be removed.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Gitweb: Avoid warnings when a repo does not have a valid HEAD
From: Junio C Hamano @ 2011-12-15 22:28 UTC (permalink / raw)
To: Joe Ratterman; +Cc: git, jnareb
In-Reply-To: <7v62hhmr2s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Joe Ratterman <jratt0@gmail.com> writes:
>
>> It is possible that the HEAD reference does not point to an existing
>> branch. When viewing such a repository in gitweb, a message like this
>> one was sent to the error log:
>>
>> gitweb.cgi: Use of uninitialized value in string eq at /usr/src/git/gitweb/gitweb.cgi line 5115.
>>
> ..., but in that case a repository with
> a HEAD that points at an unborn branch _and_ have other refs that do point
> at existing commit is already screwed-up, so if we want to be extremely
> pedantic then perhaps ...
>
> my $curr = ((defined $head && exists $ref{"id"} && defined $ref{"id"})
> ? ($ref{"id"} eq $head)
> : 0);
Just in case, I was not suggesting to update the patch to look like the
above by "if we want to be extremely pedantic".
After all, that error message in the log may be a good thing that notifies
the site administrators about a suspicious repository so that it can be
fixed (even though it was not a designed "feature" but something that
happens to work).
^ permalink raw reply
* Re: git help prune accuracy?
From: Junio C Hamano @ 2011-12-15 22:18 UTC (permalink / raw)
To: Martin Fick; +Cc: Git List
In-Reply-To: <201112151453.52157.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
>> objects from the object database. In addition, it
>> prunes the unpacked objects that are also found in packs
>> by running git prune-packed.
>>
>> The last sentence seems like it should maybe have the
>> following fix:
>>
>> s/it prunes the unpacked/it prunes the unreferenced/
>
> Ack, I meant:
>
> s/it prunes the unpacked/it prunes the unreachable/
"In addition" part is about objects that exist in loose format that are
also found in packs and has nothing to do with reachability.
Running "git pack-objects" to collect loose objects into a new pack will
not remove these loose objects that are copied into that new pack. Because
we try to access objects from an already open packfile before trying a
loose object file, removing these now-redundant loose ones after they are
packed makes sense. And that is what "git prune-packed" does.
^ permalink raw reply
* Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path
From: Pat Thoyts @ 2011-12-15 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, Paul Mackerras, git
In-Reply-To: <7v1us5obqa.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
>
>> Paul and Junio, the patches I sent in April are still not in git.git,
>> are they? Can we use another repo until the kernel.org one is up? More
>> than eight months to get a patch (or eight) merged is way too long,
>> IMO.
>
>I tend to agree.
>
>I have this slight suspicion that Paul would appreciate if somebody who
>cares about gitk who is capable and willing steps forward and takes over
>the maintainership of gitk, as he is busy in his other projects.
I can do this one along with git-gui if this is the case.
--
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
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