* Re: Subtree in Git
From: Herman van Rink @ 2012-10-20 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: dag, greened, Hilco Wijbenga, Git Users
In-Reply-To: <nng4npe6zsj.fsf@transit.us.cray.com>
On 07/11/2012 06:14 PM, dag@cray.com wrote:
> Herman van Rink <rink@initfour.nl> writes:
>
>>> It's hard to tell what's what with one big diff. Each command should
>>> get its own commit plus more if infrastructure work has to be done. I
>>> realize it's a bit of a pain to reformulate this but git rebase -i makes
>>> it easy and the history will be much better long-term.
>>>
>>> Each command should be described briefly in the commit log.
>> That would indeed be nice, but as some parts interdependent it would be
>> rather complicated.
> Do the interdependent parts first, then. These should be pure
> infrastructure.
>
>> And what is the use if their not fully independently testable.
> The command should be testable as soon as they are fully implemented,
> no?
>
> I'm thinking about a sequence like this:
>
> - Infrastructure for command A (and possibly B, C, etc. if they are
> interdependent).
> - Command A + tests
> - Infrastructure for command B
> - Command B + tests
> - etc.
>
>> If you want to fake a nice history tree then go ahead, I just don't have
>> the energy to go through these commits again just for that.
> Well, I can't do this either, both because it would take time to get up
> to speed on the patches and because I have a million other things going
> on at the moment. So unfortunately, this is going to sit until someone
> can take it up.
>
> Unless Junio accepts your patches, of course. :)
Junio, Could you please consider merging the single commit from my
subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
I've seen a few reactions on the git userlist refer to issues which have
long been solved in these collected updates.
>
>>> Some questions/comments:
>>>
>>> - Is .gittrees the right solution? I like the feature it provides but
>>> an external file feels a bit hacky. I wonder if there is a better way
>>> to track this metadata. Notes maybe? Other git experts will have to
>>> chime in with suggestions.
>> It's similar to what git submodule does. And when you add this file to
>> the index you can use it on other checkouts as well.
> Well, I guess I'm not strongly opposed, I was just asking the question.
>
>>> - This code seems to be repeated a lot. Maybe it should be a utility
>>> function.
>> Yes that's there three times...
> So you agree it should be factored?
>
>>> - I removed all this stuff in favor of the test library. Please don't
>>> reintroduce it. These new tests will have to be rewritten in terms of
>>> the existing test infrastructure. It's not too hard.
>> I've left it in to be able to verify your new tests. Once all the new
>> tests are passing we can get rid of the old one, not before.
>> And as all the old tests are contained in test.sh it should not interfere...
> No, I'm very strongly against putting this back in. The new tests will
> have to be updated to the upstream test infrastructure.
>
> -Dave
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
^ permalink raw reply
* Re: [PATCH] Add --unannotate option to git-subtree
From: Herman van Rink @ 2012-10-20 19:33 UTC (permalink / raw)
To: James Nylen; +Cc: git
In-Reply-To: <CABVa4NgdaiwfTvFe1CU+24QF-BA45tM2e3+9e2PJ_4ecuD0Cyg@mail.gmail.com>
On 10/16/2012 02:47 PM, James Nylen wrote:
> On Tue, Oct 9, 2012 at 4:26 PM, James Nylen <jnylen@gmail.com> wrote:
>> This new option does the reverse of --annotate, which is more useful
>> when contributing back to a library which is also included in the
>> repository for a larger project, and perhaps in other situations as
>> well.
>>
>> Rather than adding a marker to each commit when splitting out the
>> commits back to the subproject, --unannotate removes the specified
>> string (or bash glob pattern) from the beginning of the first line of
>> the commit message. This enables the following workflow:
>>
>> - Commit to a library included in a large project, with message:
>> Library: Make some amazing change
>>
>> - Use `git-subtree split` to send this change to the library maintainer
>>
>> - Pass ` --unannotate='Library: ' ` or ` --unannotate='*: ' `
>>
>> - This will turn the commit message for the library project into:
>> Make some amazing change
>>
>> This helps to keep the commit messages meaningful in both the large
>> project and the library project.
>>
>> Signed-off-by: James Nylen <jnylen@gmail.com>
>> ---
> Has anybody looked at this?
>
> It has been very useful for me.
The version of subtree in contrib is rather out-dated unfortunately.
Your patch looks interesting though. I can see how this could be useful.
I've collected a bunch of patches in
https://github.com/helmo/git/tree/subtree-updates
Apart from a line in git-subtree.txt ending in whitespace I think I can
merge it in there.
>
>> Let me know if gmail has munged this patch. You can also get at it
>> like this:
>>
>> $ git remote add nylen git://github.com/nylen/git.git
>> $ git fetch nylen
>> $ git show nylen/subtree-unannotate
>> ---
>> contrib/subtree/git-subtree.sh | 11 +++++++++--
>> contrib/subtree/git-subtree.txt | 15 +++++++++++++++
>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>> index 920c664..8d1ed05 100755
>> --- a/contrib/subtree/git-subtree.sh
>> +++ b/contrib/subtree/git-subtree.sh
>> @@ -21,6 +21,7 @@ P,prefix= the name of the subdir to split out
>> m,message= use the given message as the commit message for the merge commit
>> options for 'split'
>> annotate= add a prefix to commit message of new commits
>> +unannotate= remove a prefix from new commit messages (supports bash globbing)
>> b,branch= create a new branch from the split subtree
>> ignore-joins ignore prior --rejoin commits
>> onto= try connecting new tree to an existing one
>> @@ -43,6 +44,7 @@ onto=
>> rejoin=
>> ignore_joins=
>> annotate=
>> +unannotate=
>> squash=
>> message=
>>
>> @@ -80,6 +82,8 @@ while [ $# -gt 0 ]; do
>> -d) debug=1 ;;
>> --annotate) annotate="$1"; shift ;;
>> --no-annotate) annotate= ;;
>> + --unannotate) unannotate="$1"; shift ;;
>> + --no-unannotate) unannotate= ;;
>> -b) branch="$1"; shift ;;
>> -P) prefix="$1"; shift ;;
>> -m) message="$1"; shift ;;
>> @@ -310,8 +314,11 @@ copy_commit()
>> GIT_COMMITTER_NAME \
>> GIT_COMMITTER_EMAIL \
>> GIT_COMMITTER_DATE
>> - (echo -n "$annotate"; cat ) |
>> - git commit-tree "$2" $3 # reads the rest of stdin
>> + (
>> + read FIRST_LINE
>> + echo "$annotate${FIRST_LINE#$unannotate}"
>> + cat # reads the rest of stdin
>> + ) | git commit-tree "$2" $3
>> ) || die "Can't copy commit $1"
>> }
>>
>> diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
>> index 0c44fda..ae420aa 100644
>> --- a/contrib/subtree/git-subtree.txt
>> +++ b/contrib/subtree/git-subtree.txt
>> @@ -198,6 +198,21 @@ OPTIONS FOR split
>> git subtree tries to make it work anyway, particularly
>> if you use --rejoin, but it may not always be effective.
>>
>> +--unannotate=<annotation>::
>> + This option is only valid for the split command.
>> +
>> + When generating synthetic history, try to remove the prefix
>> + <annotation> from each commit message (using bash's "strip
>> + shortest match from beginning" command, which supports
>> + globbing). This makes sense if you format library commits
>> + like "library: Change something or other" when you're working
>> + in your project's repository, but you want to remove this
>> + prefix when pushing back to the library's upstream repository.
>> + (In this case --unannotate='*: ' would work well.)
>> +
>> + Like --annotate, you need to use the same <annotation>
>> + whenever you split, or you may run into problems.
>> +
>> -b <branch>::
>> --branch=<branch>::
>> This option is only valid for the split command.
>> --
>> 1.7.11.3
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Herman van Rink @ 2012-10-20 19:40 UTC (permalink / raw)
To: Yann Dirson; +Cc: git list
In-Reply-To: <20121019152158.4297707b@chalon.bertin.fr>
On 10/19/2012 03:21 PM, Yann Dirson wrote:
> As the examples in git-subtree.txt show, the synopsis in the same file should
> surely get a patch along the lines of:
>
> -'git subtree' add -P <prefix> <commit>
> +'git subtree' add -P <prefix> <repository> <commit>
>
> Failure to specify the repository (by just specifying a local commit) fails with
> the cryptic:
>
> warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> fatal: just how do you expect me to merge 0 trees?
>
>
> Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
> mentions a <refspec> which the synopsis does not show either.
>
>
> As a sidenote it someone wants to do some maintainance, using "." as repository when
> the branch to subtree-add is already locally available does not work well either
> (fails with "could not find ref myremote/myhead").
>
The version of subtree in contrib is rather out-dated unfortunately.
I've collected a bunch of patches in
https://github.com/helmo/git/tree/subtree-updates
The documentation issue is also fixed in there.
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
^ permalink raw reply
* Re: [PATCH] grep: remove tautological check
From: Peter Krefting @ 2012-10-20 19:23 UTC (permalink / raw)
To: David Soria Parra; +Cc: git
In-Reply-To: <1350753964-29346-1-git-send-email-dsp@php.net>
David Soria Parra:
> The enum grep_header_field is unsigned.
Enumerations can be either unsigned or signed, it is up to the
compiler to decide. Even if you assign only positive number to named
enumeration values, there are compilers that make them signed. I've
been bitten by that enough.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Report a bug, about track remote repository.
From: Cheeray Huang @ 2012-10-20 18:49 UTC (permalink / raw)
To: git
Hi,
I think I found a bug, when I used local branches to track remote
branch. But I'm not very sure, can anyone double check this? I'd like
to finger this out. I think you can reproduce this bug as below steps:
precondition:
Suppose that you have a remote branch in repository, named origin/work.
And then you want to track it with a local branch.
Steps:
1. So you can do this:
git checkout -t origin/work
now, you have a local branch also named "work" to track "origin/work".
It works nicely, you can use "push/pull" command without any detail
parameters to sync anything with the remote branch.
2. Create another branch, ex. named "work2", to track "origin/work"
again, though maybe there are not so many people that will do like this.
You will find that local branch "work2" can't "push" to "origin/work".
ex. After you committed something in work2, you typed "git status", git
would tell you:
Your branch is ahead of 'origin/work' by x commit.
And then you used "git push", git can't display the information about
changing hash value in remote branch, just printed "everything is up to
date".
Actually, you can use some exact parameters to solve this, such as:
git push origin work2:work
But, I still think it is a bug.
BTW, I found this bug when I used github. I don't know whether it is
related to github.
--
B&R,
Cheeray
^ permalink raw reply
* [PATCH] grep: remove tautological check
From: David Soria Parra @ 2012-10-20 17:26 UTC (permalink / raw)
To: git; +Cc: David Soria Parra
The enum grep_header_field is unsigned. Therefore the field part of the
grep_pat structure is unsigned and cannot be less then 0. We remove the
tautological check for p->field < 0.
Signed-off-by: David Soria Parra <dsp@php.net>
---
grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grep.c b/grep.c
index 4bd1b8b..db177ef 100644
--- a/grep.c
+++ b/grep.c
@@ -625,7 +625,7 @@ static struct grep_expr *prep_header_patterns(struct grep_opt *opt)
for (p = opt->header_list; p; p = p->next) {
if (p->token != GREP_PATTERN_HEAD)
die("bug: a non-header pattern in grep header list.");
- if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
+ if (GREP_HEADER_FIELD_MAX <= p->field)
die("bug: unknown header field %d", p->field);
compile_regexp(p, opt);
}
--
1.8.0.rc3.332.g181c802
^ permalink raw reply related
* Re: [PATCH v2] Add new remote-hg transport helper
From: Felipe Contreras @ 2012-10-20 16:04 UTC (permalink / raw)
To: Mike Hommey
Cc: git, Junio C Hamano, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <20121020154301.GA31829@glandium.org>
On Sat, Oct 20, 2012 at 5:43 PM, Mike Hommey <mh@glandium.org> wrote:
> On Sat, Oct 20, 2012 at 05:00:06PM +0200, Felipe Contreras wrote:
>> Changes since v1:
>>
>> * Improved documentation
>> * Use more common 'python' binary
>> * Warn, don't barf when a branch has multiple heads
>> * Fixed marks to fetch after cloned
>> * Support for cloning/pulling remote repositories
>> * Use a more appropriate internal directory (e.g. .git/hg/origin)
>> * Fixes for python3
>
> Are the resulting commits identical to what you'd get from using hg-git?
No, but should be easy to implement.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2] Add new remote-hg transport helper
From: Mike Hommey @ 2012-10-20 15:43 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <1350745206-28955-1-git-send-email-felipe.contreras@gmail.com>
On Sat, Oct 20, 2012 at 05:00:06PM +0200, Felipe Contreras wrote:
> Changes since v1:
>
> * Improved documentation
> * Use more common 'python' binary
> * Warn, don't barf when a branch has multiple heads
> * Fixed marks to fetch after cloned
> * Support for cloning/pulling remote repositories
> * Use a more appropriate internal directory (e.g. .git/hg/origin)
> * Fixes for python3
Are the resulting commits identical to what you'd get from using hg-git?
Mike
^ permalink raw reply
* [PATCH v2] Add new remote-hg transport helper
From: Felipe Contreras @ 2012-10-20 15:00 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow, Jeff King, Michael J Gruber, Felipe Contreras
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
I've looked at many hg<->git tools and none satisfy me. Too complicated, or too
slow, or to difficult to setup, etc.
The only one I've liked so far is hg-fast-export[1], which is indeed fast,
relatively simple, and relatively easy to use. But it's not properly maintained
any more.
So, I decided to write my own from scratch, using hg-fast-export as
inspiration, and voila.
This one doesn't have any dependencies, just put it into your $PATH, and you
can clone and fetch hg repositories. More importantly to me; the code is
simple, and easy to maintain.
One important remote-hg alternative is the one written by Sverre Rabbelier that
is now maintained and distributed in msysgit, however, in my opinion the code
is bloated, and there isn't even a standalone branch to take a look at the
patches, and give them a try.
This version has some features that Sverre's version doesn't:
* Support for tags
* Support to specify branchesto pull
Sverre's version has some features this one doesn't:
* Support for pushing
* Tests
[1] http://repo.or.cz/w/fast-export.git
Changes since v1:
* Improved documentation
* Use more common 'python' binary
* Warn, don't barf when a branch has multiple heads
* Fixed marks to fetch after cloned
* Support for cloning/pulling remote repositories
* Use a more appropriate internal directory (e.g. .git/hg/origin)
* Fixes for python3
contrib/remote-hg/git-remote-hg | 254 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 254 insertions(+)
create mode 100755 contrib/remote-hg/git-remote-hg
diff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg
new file mode 100755
index 0000000..cc53091
--- /dev/null
+++ b/contrib/remote-hg/git-remote-hg
@@ -0,0 +1,254 @@
+#!/usr/bin/python
+
+# Inspired by Rocco Rutte's hg-fast-export
+
+# Just copy to your ~/bin, or anywhere in your $PATH.
+# Then you can clone with:
+# git clone hg::/path/to/mercurial/repo/
+
+from mercurial import hg, ui
+
+import re
+import sys
+import os
+import json
+
+first = True
+
+def die(msg, *args):
+ sys.stderr.write('ERROR: %s\n' % (msg % args))
+ sys.exit(1)
+
+def warn(msg, *args):
+ sys.stderr.write('WARNING: %s\n' % (msg % args))
+
+def gitmode(flags):
+ return 'l' in flags and '120000' or 'x' in flags and '100755' or '100644'
+
+def export_file(fc):
+ if fc.path() == '.hgtags':
+ return
+ d = fc.data()
+ print "M %s inline %s" % (gitmode(fc.flags()), fc.path())
+ print "data %d" % len(d)
+ print d
+
+def get_filechanges(repo, ctx, parents):
+ l = [repo.status(p, ctx)[:3] for p in parents]
+ changed, added, removed = [sum(e, []) for e in zip(*l)]
+ return added + changed, removed
+
+author_re = re.compile('^((.+?) )?(<.+?>)$')
+
+def fixup_user(user):
+ user = user.replace('"', '')
+ m = author_re.match(user)
+ if m:
+ name = m.group(1)
+ mail = m.group(3)
+ else:
+ name = user
+ mail = None
+
+ if not name:
+ name = 'Unknown'
+ if not mail:
+ mail = '<unknown>'
+
+ return '%s %s' % (name, mail)
+
+def get_repo(path, alias):
+ global dirname
+
+ myui = ui.ui()
+ myui.setconfig('ui', 'interactive', 'off')
+
+ if hg.islocal(path):
+ repo = hg.repository(myui, path)
+ else:
+ local_path = os.path.join(dirname, 'clone')
+ if not os.path.exists(local_path):
+ srcpeer, dstpeer = hg.clone(myui, {}, path, local_path, update=False, pull=True)
+ repo = dstpeer.local()
+ else:
+ repo = hg.repository(myui, local_path)
+ peer = hg.peer(myui, {}, path)
+ repo.pull(peer, heads=None, force=True)
+
+ return repo
+
+def hg_branch(b):
+ if b == 'master':
+ return 'default'
+ return b
+
+def git_branch(b):
+ if b == 'default':
+ return 'master'
+ return b
+
+def export_tag(repo, tag):
+ global prefix
+ print "reset %s/tags/%s" % (prefix, tag)
+ print "from :%s" % (repo[tag].rev() + 1)
+ print
+
+def export_branch(repo, branch):
+ global prefix, marks, cache, branches
+
+ heads = branches[hg_branch(branch)]
+
+ # verify there's only one head
+ if (len(heads) > 1):
+ warn("Branch '%s' has more than one head, consider merging" % hg_branch(branch))
+
+ head = repo[heads[0]]
+ tip = marks.get(branch, 0)
+ # mercurial takes too much time checking this
+ if tip == head.rev():
+ # nothing to do
+ return
+ revs = repo.revs('%u:%u' % (tip, head))
+ count = 0
+
+ revs = [rev for rev in revs if not cache.get(rev, False)]
+
+ for rev in revs:
+
+ c = repo[rev]
+ (manifest, user, (time, tz), files, desc, extra) = repo.changelog.read(c.node())
+ rev_branch = git_branch(extra['branch'])
+
+ tz = '%+03d%02d' % (-tz / 3600, -tz % 3600 / 60)
+
+ print "commit %s/branches/%s" % (prefix, rev_branch)
+ print "mark :%d" % (rev + 1)
+ print "committer %s %d %s" % (fixup_user(user), time, tz)
+ print "data %d" % (len(desc) + 1)
+ print desc
+ print
+
+ parents = [p for p in repo.changelog.parentrevs(rev) if p >= 0]
+
+ if len(parents) == 0:
+ modified = c.manifest().keys()
+ removed = []
+ else:
+ added = []
+ changed = []
+ print "from :%s" % (parents[0] + 1)
+ if len(parents) > 1:
+ print "merge :%s" % (parents[1] + 1)
+ modified, removed = get_filechanges(repo, c, parents)
+
+ for f in removed:
+ print "D %s" % (f)
+ for f in modified:
+ export_file(c.filectx(f))
+ print
+
+ count += 1
+ if (count % 100 == 0):
+ print "progress revision %d '%s' (%d/%d)" % (rev, branch, count, len(revs))
+ print "#############################################################"
+
+ cache[rev] = True
+
+ # store the latest revision
+ marks[branch] = rev
+
+def do_capabilities(repo, args):
+ global prefix, dirname
+
+ print "import"
+ print "refspec refs/heads/*:%s/branches/*" % prefix
+ print "refspec refs/tags/*:%s/tags/*" % prefix
+ print
+
+def do_list(repo, args):
+ global branches
+
+ head = repo.dirstate.branch()
+ for branch in repo.branchmap():
+ heads = repo.branchheads(branch)
+ if len(heads):
+ branches[branch] = heads
+
+ for branch in branches:
+ print "? refs/heads/%s" % git_branch(branch)
+ for tag, node in repo.tagslist():
+ if tag == 'tip':
+ continue
+ print "? refs/tags/%s" % tag
+ print "@refs/heads/%s HEAD" % git_branch(head)
+ print
+
+def do_import(repo, args):
+ global first
+
+ ref = args[1]
+
+ if first:
+ path = os.path.join(dirname, 'marks-git')
+
+ if os.path.exists(path):
+ print "feature import-marks=%s" % path
+ print "feature export-marks=%s" % path
+ sys.stdout.flush()
+ first = False
+
+ if (ref == 'HEAD'):
+ return
+
+ if ref.startswith('refs/heads/'):
+ branch = ref[len('refs/heads/'):]
+ export_branch(repo, branch)
+ elif ref.startswith('refs/tags/'):
+ tag = ref[len('refs/tags/'):]
+ export_tag(repo, tag)
+
+def main(args):
+ global prefix, dirname, marks, cache, branches
+
+ alias = args[1]
+ url = args[2]
+
+ gitdir = os.environ['GIT_DIR']
+ dirname = os.path.join(gitdir, 'hg', alias)
+ cache = {}
+ branches = {}
+
+ repo = get_repo(url, alias)
+ prefix = 'refs/hg/%s' % alias
+
+ if not os.path.exists(dirname):
+ os.makedirs(dirname)
+
+ marks_path = os.path.join(dirname, 'marks-hg')
+ try:
+ fp = open(marks_path, 'r')
+ marks = json.load(fp)
+ fp.close()
+ except IOError:
+ marks = {}
+
+ line = True
+ while (line):
+ line = sys.stdin.readline().strip()
+ if line == '':
+ break
+ args = line.split()
+ cmd = args[0]
+ if cmd == 'capabilities':
+ do_capabilities(repo, args)
+ elif cmd == 'list':
+ do_list(repo, args)
+ elif cmd == 'import':
+ do_import(repo, args)
+ sys.stdout.flush()
+
+ fp = open(marks_path, 'w')
+ json.dump(marks, fp)
+ fp.close()
+
+sys.exit(main(sys.argv))
--
1.8.0.rc2.7.g0961fdf.dirty
^ permalink raw reply related
* Re: Problems with ./t9902-completion.sh
From: Torsten Bögershausen @ 2012-10-20 12:50 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Git Mailing List
In-Reply-To: <508292DC.8030700@web.de>
On 20.10.12 14:02, Torsten Bögershausen wrote:
> t9902 does not work on my Mac OS box,
> but only in one working directory.
>
> Any idea where the "check-ignore" comea from ?
> /Torsten
>
Oh, I find the answer myself:
git status
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# ../git-check-ignore
From some experiments there was a git-check-ignore left.
(and make clean doesn't delete it)
sorry for the noise.
^ permalink raw reply
* Problems with ./t9902-completion.sh
From: Torsten Bögershausen @ 2012-10-20 12:02 UTC (permalink / raw)
To: Git Mailing List; +Cc: Torsten Bögershausen
t9902 does not work on my Mac OS box,
but only in one working directory.
Any idea where the "check-ignore" comea from ?
/Torsten
[snip]
--- expected 2012-10-20 11:54:35.000000000 +0000
+++ out 2012-10-20 11:54:35.000000000 +0000
@@ -1 +1,2 @@
+check-ignore
checkout
This patch corrects the problem:
(s/check"/checko"/)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index cbd0fb6..0df751b 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -222,19 +222,19 @@ test_expect_success 'general options' '
'
test_expect_success 'general options plus command' '
- test_completion "git --version check" "checkout " &&
- test_completion "git --paginate check" "checkout " &&
- test_completion "git --git-dir=foo check" "checkout " &&
- test_completion "git --bare check" "checkout " &&
+ test_completion "git --version checko" "checkout " &&
+ test_completion "git --paginate checko" "checkout " &&
+ test_completion "git --git-dir=foo checko" "checkout " &&
+ test_completion "git --bare checko" "checkout " &&
test_completion "git --help des" "describe " &&
- test_completion "git --exec-path=foo check" "checkout " &&
- test_completion "git --html-path check" "checkout " &&
- test_completion "git --no-pager check" "checkout " &&
- test_completion "git --work-tree=foo check" "checkout " &&
- test_completion "git --namespace=foo check" "checkout " &&
- test_completion "git --paginate check" "checkout " &&
- test_completion "git --info-path check" "checkout " &&
- test_completion "git --no-replace-objects check" "checkout "
+ test_completion "git --exec-path=foo checko" "checkout " &&
+ test_completion "git --html-path checko" "checkout " &&
+ test_completion "git --no-pager checko" "checkout " &&
+ test_completion "git --work-tree=foo checko" "checkout " &&
+ test_completion "git --namespace=foo checko" "checkout " &&
+ test_completion "git --paginate checko" "checkout " &&
+ test_completion "git --info-path checko" "checkout " &&
+ test_completion "git --no-replace-objects checko" "checkout "
'
^ permalink raw reply related
* [PATCH] New "git status" format with --alternate
From: Nguyễn Thái Ngọc Duy @ 2012-10-20 9:36 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Another UI experiment, thrown at git@vger to see if it sticks. I've
been using this for a week and it feels good in general. But it may be
too specific to my taste to be useful for more people.
This format utilizes the screen estate as much as possible. It relies
on colors, so monochrome users are stuck with default format. In
short, it's a "GNU ls"-like output with footnotes:
- entries of all kinds (untracked, modified, cached...) are sorted in
a single list, laid out in columns
- different kinds of files have different colors, more on this later
- square brackets around a tracked file means differences between
index and HEAD (aka "git diff --cached").
- square brackets on untracked file means ignored file
- more information such as renames, unmerged tyes... is added in form
of footnotes
On a clean repository, "git status" prints nothing. Branch state
(rebasing/am-ing/....) is also printed.
This format is denser than the default format and easier to read (to
me) as there is only one table. Colors and brackets are the visual
clues. All the use of colors and brackets are explained in footnotes,
so new users should have no problems with it (provided that they know
basic concepts).
About colors, untracked files have no colors. Tracked files always do
(to catch your eyes). Added/Removed/Modified/Unmerged have different
colors. Text color reflects the changes between worktree and index
(aka "git diff"). Bracket color reflects changes between index and
HEAD (aka "git diff --cached").
If you see all magenta (modified) text without brackets, "git commit -a"
is your friend. If you see all yellow text (unmodified worktree)
and magenta brackets, "git commit" to go. A mix of magenta text and
brackets mean you need to do "git diff --cached" and "git diff" to
know what changes you are going to commit.
The merge of untracked/tracked files could be annoying if you don't
keep your repository clean, though. Not sure if mering is a good idea,
or just split them into two tables.
Final note: messy and incomplete implementation.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/commit.c | 11 ++
wt-status.c | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
wt-status.h | 1 +
3 files changed, 338 insertions(+), 13 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..758cf11 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,6 +114,7 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
+ STATUS_FORMAT_ALTERNATE,
STATUS_FORMAT_PORCELAIN
} status_format = STATUS_FORMAT_LONG;
@@ -451,6 +452,9 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
case STATUS_FORMAT_SHORT:
wt_shortstatus_print(s);
break;
+ case STATUS_FORMAT_ALTERNATE:
+ wt_altstatus_print(s);
+ break;
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
@@ -1154,6 +1158,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
OPT__VERBOSE(&verbose, N_("be verbose")),
OPT_SET_INT('s', "short", &status_format,
N_("show status concisely"), STATUS_FORMAT_SHORT),
+ OPT_SET_INT(0, "alternate", &status_format,
+ N_("show status concisely"), STATUS_FORMAT_ALTERNATE),
OPT_BOOLEAN('b', "branch", &s.show_branch,
N_("show branch information")),
OPT_SET_INT(0, "porcelain", &status_format,
@@ -1188,6 +1194,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
if (s.null_termination && status_format == STATUS_FORMAT_LONG)
status_format = STATUS_FORMAT_PORCELAIN;
+ if (s.null_termination && status_format == STATUS_FORMAT_ALTERNATE)
+ die(_("--alternate does not work with -z"));
handle_untracked_files_arg(&s);
if (show_ignored_in_status)
@@ -1213,6 +1221,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
wt_shortstatus_print(&s);
break;
+ case STATUS_FORMAT_ALTERNATE:
+ wt_altstatus_print(&s);
+ break;
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(&s);
break;
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..7502591 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -928,34 +928,40 @@ static void show_bisect_in_progress(struct wt_status *s,
wt_status_print_trailer(s);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_get_state(struct wt_status *s,
+ struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
struct stat st;
-
- memset(&state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
if (!stat(git_path("MERGE_HEAD"), &st)) {
- state.merge_in_progress = 1;
+ state->merge_in_progress = 1;
} else if (!stat(git_path("rebase-apply"), &st)) {
if (!stat(git_path("rebase-apply/applying"), &st)) {
- state.am_in_progress = 1;
+ state->am_in_progress = 1;
if (!stat(git_path("rebase-apply/patch"), &st) && !st.st_size)
- state.am_empty_patch = 1;
+ state->am_empty_patch = 1;
} else {
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
- state.rebase_interactive_in_progress = 1;
+ state->rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
- state.cherry_pick_in_progress = 1;
+ state->cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st))
- state.bisect_in_progress = 1;
+ state->bisect_in_progress = 1;
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -1224,6 +1230,313 @@ void wt_shortstatus_print(struct wt_status *s)
}
}
+static int cmp_items(const void *a, const void *b)
+{
+ const struct string_list_item *const *one = a;
+ const struct string_list_item *const *two = b;
+ return strcmp((*one)->string, (*two)->string);
+}
+
+static const char *col_unmerged = GIT_COLOR_CYAN;
+static const char *col_added = GIT_COLOR_GREEN;
+static const char *col_deleted = GIT_COLOR_RED;
+static const char *col_updated = GIT_COLOR_MAGENTA;
+static const char *col_tracked = GIT_COLOR_YELLOW;
+static const char *col_reset = GIT_COLOR_RESET;
+
+#define SHOW_TRACKED 8
+#define SHOW_UNMERGED 9
+#define SHOW_ADDED 10
+#define SHOW_DELETED 11
+#define SHOW_UPDATED 12
+#define SHOW_WORKTREE_DELETED 13
+#define SHOW_WORKTREE_UPDATED 14
+#define SHOW_UNTRACKED 15
+#define SHOW_IGNORED 16
+
+static void wt_altstatus_unmerged(struct wt_status *s,
+ const char *name,
+ struct wt_status_change_data *d,
+ struct strbuf *out,
+ struct string_list *footnotes,
+ int *shown_how)
+{
+ struct strbuf onebuf = STRBUF_INIT;
+ const char *one;
+ const char *how = "";
+
+ switch (d->stagemask) {
+ case 1: how = "DD"; break; /* both deleted */
+ case 2: how = "AU"; break; /* added by us */
+ case 3: how = "UD"; break; /* deleted by them */
+ case 4: how = "UA"; break; /* added by them */
+ case 5: how = "DU"; break; /* deleted by us */
+ case 6: how = "AA"; break; /* both added */
+ case 7: how = "UU"; break; /* both modified */
+ }
+
+ if (!shown_how[d->stagemask]) {
+ const char *legend = NULL;
+ shown_how[d->stagemask] = 1;
+ switch (d->stagemask) {
+ case 1: legend = "[DD] deleted by both"; break;
+ case 2: legend = "[AU] added by us"; break;
+ case 3: legend = "[UD] deleted by them"; break;
+ case 4: legend = "[UA] added by them"; break;
+ case 5: legend = "[DU] deleted by us"; break;
+ case 6: legend = "[AA] added by both"; break;
+ case 7: legend = "[UU] modified by both"; break;
+ }
+ if (legend)
+ string_list_append(footnotes, xstrdup(legend));
+ }
+
+ if (!shown_how[SHOW_UNMERGED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%sfile%s -> unmerged entry",
+ col_unmerged, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_UNMERGED] = 1;
+ }
+
+ one = quote_path(name, -1, &onebuf, s->prefix);
+ if (*one != '"' && strchr(one, ' ') != NULL) {
+ putchar('"');
+ strbuf_addch(&onebuf, '"');
+ one = onebuf.buf;
+ }
+ strbuf_addf(out," %s%s%s [%s]", col_unmerged, one, col_reset, how);
+ strbuf_release(&onebuf);
+}
+
+static void wt_altstatus_tracked(struct wt_status *s,
+ const char *name,
+ struct wt_status_change_data *d,
+ struct strbuf *out,
+ struct string_list *footnotes,
+ int *shown_how)
+{
+ struct strbuf onebuf = STRBUF_INIT;
+ const char *one;
+ const char *color;
+
+ one = quote_path(name, -1, &onebuf, s->prefix);
+ if (*one != '"' && strchr(one, ' ') != NULL) {
+ putchar('"');
+ strbuf_addch(&onebuf, '"');
+ one = onebuf.buf;
+ }
+
+ switch (d->worktree_status) {
+ case DIFF_STATUS_DELETED:
+ color = col_deleted;
+ if (!shown_how[SHOW_WORKTREE_DELETED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%s[ ]%s -> removed from worktree",
+ col_deleted, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_WORKTREE_DELETED] = 1;
+ }
+ break;
+ case 0:
+ color = col_tracked;
+ if (!shown_how[SHOW_TRACKED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%sfile%s -> worktree same as in index",
+ col_tracked, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_TRACKED] = 1;
+ }
+ break;
+ default:
+ color = col_updated;
+ if (!shown_how[SHOW_WORKTREE_UPDATED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%sfile%s -> modified in worktree",
+ col_updated, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_WORKTREE_UPDATED] = 1;
+ }
+ }
+
+ switch (d->index_status) {
+ case DIFF_STATUS_ADDED:
+ strbuf_addf(out, "%s[ %s%s%s ]%s",
+ col_added, color, one,
+ col_added, col_reset);
+ if (!shown_how[SHOW_ADDED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%sfile%s -> added to index",
+ col_added, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_ADDED] = 1;
+ }
+ break;
+ case DIFF_STATUS_DELETED:
+ strbuf_addf(out, "%s[ %s%s%s ]%s",
+ col_deleted, color, one,
+ col_deleted, col_reset);
+ if (!shown_how[SHOW_DELETED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%sfile%s -> removed from index",
+ col_deleted, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_DELETED] = 1;
+ }
+ break;
+ case 0:
+ strbuf_addf(out, " %s%s%s", color, one, col_reset);
+ break;
+ default:
+ strbuf_addf(out, "%s[ %s%s%s ]%s",
+ col_updated, color, one,
+ col_updated, col_reset);
+ if (!shown_how[SHOW_UPDATED]) {
+ struct strbuf legend = STRBUF_INIT;
+ strbuf_addf(&legend, "%s[ ]%s -> changes in index",
+ col_updated, col_reset);
+ string_list_append(footnotes, strbuf_detach(&legend, NULL));
+ shown_how[SHOW_UPDATED] = 1;
+ }
+ }
+
+ strbuf_release(&onebuf);
+
+ /* extra things at the end */
+ switch (d->worktree_status) {
+ case DIFF_STATUS_ADDED:
+ case DIFF_STATUS_DELETED:
+ break;
+ case DIFF_STATUS_TYPE_CHANGED:
+ /* FIXME */
+ strbuf_addf(out, "%s+x%s", GIT_COLOR_YELLOW,
+ GIT_COLOR_RESET);
+ break;
+ case 0:
+ break;
+ }
+
+ if (d->head_path) {
+ struct strbuf tmp = STRBUF_INIT;
+ int id = footnotes->nr + 1;
+ strbuf_addf(out, " [%d]", id);
+ one = quote_path(d->head_path, -1, &onebuf, s->prefix);
+ if (*one != '"' && strchr(one, ' ') != NULL) {
+ putchar('"');
+ strbuf_addch(&onebuf, '"');
+ one = onebuf.buf;
+ }
+ strbuf_addf(&tmp, "[%d] renamed from %s", id, onebuf.buf);
+ strbuf_release(&onebuf);
+ string_list_append(footnotes, strbuf_detach(&tmp, NULL));
+ }
+}
+
+void wt_altstatus_print(struct wt_status *s)
+{
+ int i, n;
+ struct string_list_item **all, **p;
+ struct string_list footnotes = STRING_LIST_INIT_NODUP;
+ struct string_list output = STRING_LIST_INIT_NODUP;
+ struct column_options copts;
+ struct wt_status_state state;
+ int shown_how[17];
+
+ n = s->untracked.nr + s->ignored.nr + s->change.nr;
+ p = all = xmalloc(sizeof(*all) * n);
+
+ for (i = 0; i < s->change.nr; i++)
+ *p++ = s->change.items + i;
+ for (i = 0; i < s->untracked.nr; i++)
+ *p++ = s->untracked.items + i;
+ for (i = 0; i < s->ignored.nr; i++)
+ *p++ = s->ignored.items + i;
+ qsort(all, n, sizeof(*all), cmp_items);
+
+ wt_status_get_state(s, &state);
+ if (state.merge_in_progress)
+ printf("%s(Merge in progress)%s\n",
+ GIT_COLOR_YELLOW,
+ GIT_COLOR_RESET);
+ else if (state.am_in_progress)
+ printf("%s(git-am in progress)%s\n",
+ GIT_COLOR_YELLOW,
+ GIT_COLOR_RESET);
+ else if (state.rebase_in_progress || state.rebase_interactive_in_progress)
+ printf("%s(Rebase in progress)%s\n",
+ GIT_COLOR_YELLOW,
+ GIT_COLOR_RESET);
+ else if (state.cherry_pick_in_progress)
+ printf("%s(Cherry-pick in progress)%s\n",
+ GIT_COLOR_YELLOW,
+ GIT_COLOR_RESET);
+ if (state.bisect_in_progress)
+ printf("%s(Bisect in progress)%s\n",
+ GIT_COLOR_YELLOW,
+ GIT_COLOR_RESET);
+
+ memset(shown_how, 0, sizeof(shown_how));
+
+ memset(&copts, 0, sizeof(copts));
+ copts.padding = 1;
+
+ for (i = 0; i < n; i++) {
+ struct string_list_item *it = all[i];
+ struct strbuf out = STRBUF_INIT;
+
+ if (it >= s->change.items &&
+ it < s->change.items + s->change.nr) {
+ struct wt_status_change_data *d;
+
+ d = it->util;
+ if (d->stagemask)
+ wt_altstatus_unmerged(s, it->string, d, &out, &footnotes, shown_how);
+ else
+ wt_altstatus_tracked(s, it->string, d, &out, &footnotes, shown_how);
+ } else {
+ struct strbuf onebuf = STRBUF_INIT;
+ const char *one;
+
+ one = quote_path(it->string, -1, &onebuf, s->prefix);
+ if (*one != '"' && strchr(one, ' ') != NULL) {
+ putchar('"');
+ strbuf_addch(&onebuf, '"');
+ one = onebuf.buf;
+ }
+
+ if (it >= s->untracked.items &&
+ it < s->untracked.items + s->untracked.nr) {
+ strbuf_addf(&out, " %s", one);
+ if (!shown_how[SHOW_UNTRACKED]) {
+ string_list_append(&footnotes, xstrdup("file -> untracked file"));
+ shown_how[SHOW_UNTRACKED] = 1;
+ }
+ } else if (it >= s->ignored.items &&
+ it < s->ignored.items + s->ignored.nr) {
+ strbuf_addf(&out, "[ %s ]", one);
+ if (!shown_how[SHOW_IGNORED]) {
+ string_list_append(&footnotes, xstrdup("[file] -> ignored file"));
+ shown_how[SHOW_IGNORED] = 1;
+ }
+ } else
+ die("Where does this item come from?");
+
+ strbuf_release(&onebuf);
+ }
+ string_list_append(&output, strbuf_detach(&out, NULL));
+ }
+ print_columns(&output, s->colopts, &copts);
+ string_list_clear(&output, 0);
+
+ if (footnotes.nr) {
+ printf("\n");
+ memset(&copts, 0, sizeof(copts));
+ copts.padding = 3;
+ print_columns(&footnotes, s->colopts, &copts);
+ }
+ string_list_clear(&footnotes, 0);
+}
+
void wt_porcelain_print(struct wt_status *s)
{
s->use_color = 0;
diff --git a/wt-status.h b/wt-status.h
index 236b41f..8804400 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -86,6 +86,7 @@ void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
void wt_shortstatus_print(struct wt_status *s);
+void wt_altstatus_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
void status_printf_ln(struct wt_status *s, const char *color, const char *fmt, ...)
--
1.8.0.rc2.25.gf0e8e5d
^ permalink raw reply related
* Re: [PATCH] Cache stat_tracking_info() for faster status and branch -v
From: Nguyen Thai Ngoc Duy @ 2012-10-20 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7gqmjl6n.fsf@alter.siamese.dyndns.org>
On Sat, Oct 20, 2012 at 2:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Not particularly interested in the cause, but not so strongly
> against it to veto it.
I wonder how many people keep old branches like I do, which are
usually far from remotes.
> Doesn't it make more sense to use a notes-cache that is keyed off of
> the commit object name X of the remote? You will have a single note
> that stores a blob for the commit object remotes/origin/master, and
> the blob tells you how far the commit at the tip of 'frotz' is from
> it, and the same for 'xyzzy'.
>
> You would obviouly need to run "gc" on such a notes-cache tree from
> time to time, removing notes for commits that are not tip of any
> branch that could be a fork point, and from the remaining notes
> blobs, entries that describe commits that are not tip of any branch,
> if you go that route.
The notes-cache route looks much nicer. Thanks. We can also use Jeff's
persistent hash table from his rename-cache series.
--
Duy
^ permalink raw reply
* Re: libgit2 status
From: Andreas Ericsson @ 2012-10-20 7:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Thiago Farina, git, dag, Nicolas Sebrecht,
greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
On 10/19/2012 10:13 PM, Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
>
Agreed. The way libgit2 does it is to have "src/tag.[ch]", which are
for internal use, and then "src/include/tag.h" which is the published
version that others can use to write code against the tag library.
src/tag.h always includes src/include/tag.h, so no code needs to be
duplicated, but internal parts of the library can still use lower-
level stuff if it wants to. It's a good compromise when creating a
library from application code and there were no opaque types from
the start.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] contrib/hooks: avoid requiring root access in usage instructions
From: Jonathan Nieder @ 2012-10-20 7:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Olivier Berger, Michael Haggerty, Kevin P. Fleming,
Chris Hiestand, Miklos Vajna
In-Reply-To: <7vzk3hhj1m.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> We already encourage casting-in-stone a particular version of the
> sample hook when a new repository is created by copying them from
> the template directory. This prevents from surprising users when an
> updated version of Git changes the behaviour of these samples. Even
> if you think bugs in older ones may be corrected in newer ones,
> silently updating the hook the user chose to use by inspecting one
> particular version is not something we would want to do lightly.
For context, the sample hooks you are talking about are the *.sample
files from the templates/ directory. Except for post-update.sample,
most are not very useful out of the box, and they are very much
intended as examples to start people's thinking, as opposed to
something one-size-fits-all.
By contrast, the post-receive-email script from contrib is a complete
program with a well-defined behavior and configuration that have
stayed consistent while the details of its implementation improved.
It can be used by symlinking into place, but maybe a better set of
instructions would say
# This script takes no arguments and expects the same input format
# as git's post-receive hook, so if this script is at
# /usr/share/git-core/contrib/hooks/post-receive-email (as it is
# on Debian and Fedora), you can do
#
# cd /path/to/your/repository.git
# echo '#!/bin/sh' >hooks/post-receive
# echo 'exec /usr/share/git-core/contrib/hooks/post-receive-email' \
# >>hooks/post-receive
# chmod +x hooks/post-receive
That would make it more obvious what I can do next if my post-receive
input should be passed both to post-receive-email and some other tool
(perhaps in a pipeline using "tee").
Hmm?
Jonathan
^ permalink raw reply
* Re: [PATCH] contrib/hooks: avoid requiring root access in usage instructions
From: Junio C Hamano @ 2012-10-20 4:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Olivier Berger, Michael Haggerty, Kevin P. Fleming,
Chris Hiestand, Miklos Vajna
In-Reply-To: <20121020003104.GA26596@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Comments in hooks/post-receive-email suggest:
>
> For example, on debian the hook is stored in
> /usr/share/git-core/contrib/hooks/post-receive-email:
>
> chmod a+x post-receive-email
> cd /path/to/your/repository.git
> ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
>
> Doing that means changing permissions on a file provided by a package,
> which is problematic in a number of ways: the permissions would be
> likely to change back in later upgrades, and changing them requires
> root access. Copying the script into each repo that uses it is not
> much better, since each copy would be maintained separately and not
> benefit from bugfixes in the master copy.
>
> Better to ship the hook with executable permission and remove the
> chmod line so enabling the hook becomes a one-step process: just
> symlink it into place.
>
> Likewise for the pre-auto-gc-battery hook.
>
> Reported-by: Olivier Berger <olivier.berger@it-sudparis.eu>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> From <http://bugs.debian.org/687391>.
>
> Thoughts?
We already encourage casting-in-stone a particular version of the
sample hook when a new repository is created by copying them from
the template directory. This prevents from surprising users when an
updated version of Git changes the behaviour of these samples. Even
if you think bugs in older ones may be corrected in newer ones,
silently updating the hook the user chose to use by inspecting one
particular version is not something we would want to do lightly. A
buggy devil you know is better than a devil that suddenly changes
its behaviour depending on when your sysadmin updates the version of
Git without your knowing.
I personally think the same applies to these contrib/ hooks, and I
would think it is simpler and more consistent to correct the
instruction in these files to tell users to copy them.
Adding +x bits to these files is a good idea but that is orthogonal
to copying vs symlinking, I think.
> Jonathan
>
> contrib/hooks/post-receive-email | 1 -
> contrib/hooks/pre-auto-gc-battery | 1 -
> 2 files changed, 2 deletions(-)
> mode change 100644 => 100755 contrib/hooks/pre-auto-gc-battery
>
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index 8ca6607a..359f1ad2 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -13,7 +13,6 @@
> # For example, on debian the hook is stored in
> # /usr/share/git-core/contrib/hooks/post-receive-email:
> #
> -# chmod a+x post-receive-email
> # cd /path/to/your/repository.git
> # ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
> #
> diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
> old mode 100644
> new mode 100755
> index 1f914c94..9d0c2d19
> --- a/contrib/hooks/pre-auto-gc-battery
> +++ b/contrib/hooks/pre-auto-gc-battery
> @@ -13,7 +13,6 @@
> # For example, if the hook is stored in
> # /usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
> #
> -# chmod a+x pre-auto-gc-battery
> # cd /path/to/your/repository.git
> # ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
> # hooks/pre-auto-gc
^ permalink raw reply
* Re: libgit2 status
From: Thiago Farina @ 2012-10-20 1:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, git, dag, Nicolas Sebrecht,
Andreas Ericsson, greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
On Fri, Oct 19, 2012 at 5:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
Which distinction are you talking about? This is not an issue of
header file versus source file, but a public header file to be
included by external projects versus internal header files that are
intended to be included only by git itself and that will probably live
under src/ directory.
^ permalink raw reply
* [PATCH] contrib/hooks: avoid requiring root access in usage instructions
From: Jonathan Nieder @ 2012-10-20 0:31 UTC (permalink / raw)
To: git
Cc: Olivier Berger, Michael Haggerty, Kevin P. Fleming,
Chris Hiestand, Miklos Vajna
Comments in hooks/post-receive-email suggest:
For example, on debian the hook is stored in
/usr/share/git-core/contrib/hooks/post-receive-email:
chmod a+x post-receive-email
cd /path/to/your/repository.git
ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
Doing that means changing permissions on a file provided by a package,
which is problematic in a number of ways: the permissions would be
likely to change back in later upgrades, and changing them requires
root access. Copying the script into each repo that uses it is not
much better, since each copy would be maintained separately and not
benefit from bugfixes in the master copy.
Better to ship the hook with executable permission and remove the
chmod line so enabling the hook becomes a one-step process: just
symlink it into place.
Likewise for the pre-auto-gc-battery hook.
Reported-by: Olivier Berger <olivier.berger@it-sudparis.eu>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
From <http://bugs.debian.org/687391>.
Thoughts?
Jonathan
contrib/hooks/post-receive-email | 1 -
contrib/hooks/pre-auto-gc-battery | 1 -
2 files changed, 2 deletions(-)
mode change 100644 => 100755 contrib/hooks/pre-auto-gc-battery
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 8ca6607a..359f1ad2 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -13,7 +13,6 @@
# For example, on debian the hook is stored in
# /usr/share/git-core/contrib/hooks/post-receive-email:
#
-# chmod a+x post-receive-email
# cd /path/to/your/repository.git
# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
old mode 100644
new mode 100755
index 1f914c94..9d0c2d19
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -13,7 +13,6 @@
# For example, if the hook is stored in
# /usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
#
-# chmod a+x pre-auto-gc-battery
# cd /path/to/your/repository.git
# ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
# hooks/pre-auto-gc
--
1.8.0.rc2
^ permalink raw reply related
* Re: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
From: Peter Krefting @ 2012-10-19 23:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Jiang Xin
In-Reply-To: <CACsJy8CS9TKGaT8+MQ_JOEQD+fgnc9HVAbr1pjQ3JE_3ZjE9=A@mail.gmail.com>
Nguyen Thai Ngoc Duy:
> It's the result of this discussion [1]. I don't remember exactly the
> open issues. But I think it involves drawing a line between team
> language vs local language, whether team language can be anything
> other than English, the maintenance cost for supporting it
Like I said, I can see that defaulting format-patch to output English
is a good idea (since its output is "protocol data" and not something
for human consumption), it is the output from diff and show that I
want to have localized.
I'll see if I can come up with a patch that cater for both use-cases.
Maybe I can also fix so that log output is fully localized at the same
time (translating "commit", "author", "date" and outputting locale
dates (although my locale usess ISO dates, so I can get proper
formatting there already)).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: libgit2 status
From: Junio C Hamano @ 2012-10-19 22:43 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thiago Farina, git, dag, Nicolas Sebrecht, Andreas Ericsson,
greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
Having said that, I do not mind moving codeblocks around to make
some files purely library-ish while others purely commands.
Ideally, if you run
$ nm --defined-only -g builtin/frotz.o
you should see nothing but "T cmd_frotz" (there are exceptions, most
notably, what the commands in the "log" family do are so close with
each other that builtin/log.o can define cmd_* for all of them).
$ nm --defined-only -og builtin/*.o | grep -v 'T cmd_'
a handful of offenders. If these functions with external linkage
are truly useful across subcommands, we should move them to a more
library-ish location.
It may require splitting the bits that are too closely tied to the
external interface they are implementing from these functions,
generalizing only the core-ish logic from them, and moving them to a
more library-ish file as a preparatory step. Such a library-ish file
may be created inside lib/ subdirectory from the get-go.
Until that kind of code restructure happens, I do not see much sense
in just moving files, e.g. renaming revision.c to src/revision.c or
lib/revision.c or somesuch.
^ permalink raw reply
* Re: Rebase doesn't restore branch pointer back on out of memory
From: Junio C Hamano @ 2012-10-19 22:24 UTC (permalink / raw)
To: Alexander Kostikov; +Cc: Andrew Wong, git
In-Reply-To: <CAGAhT3nNdPxtDKtVCnPAa4OWOhGygzoq6DqHVEckQ60XWAAKZA@mail.gmail.com>
Alexander Kostikov <alex.kostikov@gmail.com> writes:
> Sorry to bother but I was wondering what would be the release version
> that would have this patch.
That depends on how well the people who are interested in this
change test it to smoke out potential issues (if any) in it.
It currently is on the 'pu' branch.
^ permalink raw reply
* Re: libgit2 status
From: dag @ 2012-10-19 22:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Thiago Farina, git, Nicolas Sebrecht,
Andreas Ericsson, greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
+1
-David
^ permalink raw reply
* Re: [msysGit] Re: Git for Windows and line endings
From: John Szakmeister @ 2012-10-19 21:53 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
In-Reply-To: <CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com>
On Fri, Oct 19, 2012 at 10:39 AM, Chris B <chris.blaszczynski@gmail.com> wrote:
[snip]
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
That's simply not a true, across the board statement. I really wish
it was, because I find the issue troublesome as well. Unfortunately,
there are still plenty of applications that don't cope with mixed line
endings very well. We have a backend that targets several platforms,
and the Windows toolchain is quite keen on having CRLF endings, but we
like LF under Linux, and others.
I also wish that no developers were using Notepad either. Any time
I've run across it, I've tried to point folks at much more capable
environments... but that only has moderate success. Of course, it's
even worse these days because Notepad puts a BOM at the front of the
file, making Git think it's a binary file.
One thing I do wish is that I didn't have to do the song and dance to
convert all the files when I set gitattributes:
$ echo "* text=auto" >>.gitattributes
$ rm .git/index # Remove the index to force git to
$ git reset # re-scan the working directory
$ git status # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"
One thing that I like about Subversion was that when you set
svn:eol-style, it took.
-John
^ permalink raw reply
* Re: Rebase doesn't restore branch pointer back on out of memory
From: Alexander Kostikov @ 2012-10-19 21:49 UTC (permalink / raw)
To: Andrew Wong; +Cc: gitster, git
In-Reply-To: <1349927643-7195-1-git-send-email-andrew.kw.w@gmail.com>
Sorry to bother but I was wondering what would be the release version
that would have this patch.
-- Alexander
On Wed, Oct 10, 2012 at 8:54 PM, Andrew Wong <andrew.kw.w@gmail.com> wrote:
>
> For the 'format-patch' part, originally I was going to do something like:
>
> git format-patch ... || {
> ...
> }
>
> But later I thought it's better to use a consistent style as the following
> 'am' part.
>
> For the 'am' part, if we kept the following line at the end of the if-block:
>
> fi && move_to_original_branch
>
> then, before exiting the if-block, we would have to do something like:
>
> test 0 != $ret && false
>
> which seems a bit ugly to me. So I removed the use of '&&', and rearrange the
> 'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit
> better and easier to read.
>
> Andrew Wong (1):
> rebase: Handle cases where format-patch fails
>
> git-rebase--am.sh | 51 +++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 45 insertions(+), 6 deletions(-)
>
> --
> 1.8.0.rc0.19.gc58a63a.dirty
>
--
Alexander Kostikov
^ permalink raw reply
* Re: [PATCH] Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 21:49 UTC (permalink / raw)
To: szager; +Cc: git, daniel, sop, peff
In-Reply-To: <5081c896.cMdU6VySSwFm0uOa%szager@google.com>
Thanks.
^ 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