[PATCH] Ensure SHELL_PATH is the hash bang for test suite askpass helper script.
The askpass script that is created for use by the test suite should
use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024
introduced the use of idioms not supported in some legacy /bin/sh
implementations.
Use write_script to ensure this happens automatically. This lets us
remove the chmod step as well, since write_script handles that.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
t/lib-credential.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/t/lib-credential.sh b/t/lib-credential.sh
index 9e7d796..d8e41f7 100755
--- a/t/lib-credential.sh
+++ b/t/lib-credential.sh
@@ -278,12 +278,10 @@ helper_test_timeout() {
'
}
-cat askpass \EOF
-#!/bin/sh
+write_script askpass \EOF
echo 2 askpass: $*
what=$(echo $1 | cut -d -f1 | tr A-Z a-z | tr -cd a-z)
echo askpass-$what
EOF
-chmod +x askpass
GIT_ASKPASS=$PWD/askpass
export GIT_ASKPASS
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Code changes in merge commits
Hi, Our team just struggled with this problem, and I've created a simple, 3 commit large, example git repository to demonstrate the problem: https://github.com/johnflux/ExampleEvilness2 The code: Adds a file, adds a security fix commit, then removes the fix during a merge. This happened by accident in our code during a merge, but nobody noticed, and it was not easy to track down. In this example, you can see that the security fix was removed by doing: $ git log -m -p However the following do NOT show that the security fix was removed: $ git log -m -p . $ git log -m -p tmp.c $ git log -c -p tmp.c And so on. In a large code base, this a problem. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Code changes in merge commits
Rereading what I wrote, I came across as unintentionally harsh and rude. Sorry about that - I was trying to be concise and terse, and it went a bit wrong :) What I was thinking to improve this is two short-term fixes: 1. Can we get git log -m -p . in the top level directory to show the same commits as just git log -m -p ? 2. Can we get git log -m -p somefile to show all the changes to that file? Including when lines are added and then removed by the merge somehow? But in the longer term, I was thinking about how this could be improved... What if merge commits were forced into being always trivial? i.e. prevent merges with conflicts or code changes? Then conflict resolution and code changes are pushed into a second ordinary commit. That way you can always see what changes have been made to the code. E.g. If you have branch master and branch A, and there are conflicts when you merge, you could end up with: merge commit | \ | preparation changes to fix conflicts with oldmaster oldmaster | A I know this isn't great, but maybe something along these lines? Ideally I'd like to see all the code changes to a code base just with git log -p. Any thoughts? Thanks, John Tapsell -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com writes:
I think you meant to say that we may find a better source to calculate
the exact set of commits to rebase,...
Yes.
It is debatable if we should do the same when the user tells us to
rebase with respect to a specific _branch_ by giving the 'upstream'
argument, but that is an entirely separate issue. We might want to
do a similar command line heuristics to tell between the branch
switching git checkout master (which is an operation about a
branch) and head detaching git checkout refs/heads/master^0 (which
is an operation about a commit) if we want to help the users by
auto-enabling fork-point mode.
Well, IMHO git rebase and git rebase @{u} must do exactly the same
thing.
That is not part of the current discussion is what I meant by It
is debatable... We might want to. There is no such patch to git
rebase itself in this topic ;-).
Yes, but to suggest better documentation I figure I need to understand
all the related issues, so it is still somewhat relevant.
With the We might want to, I mean git rebase, git rebase @{u}
and git rebase origin/master (if your @{u} happens to be that
branch) may want to do exactly the same thing. The last one however
is very questionable, as sometimes you would want the --fork-point
heuristics, and some other times you would want no digging of the
reflogs involved (i.e. I want everything not in this _exact_ commit
to be rebased).
On the other hand, I'm afraid different defaults were chosen for
backward compatibility?
There is no backward compatibility issue involved with the current
behaviour. Changing it _will_ break compatibility, of course.
It is more like the command used not to guess with fork-point at
all, i.e. we liked its exactness, but git rebase (no argument)
case is so obviously not about an exact commit but is about branch
that it is safe to use --fork-point guess without being confusing.
Well, that's exactly what ended-up being /extremely/ confusing in my
case.
Once you start giving the commit/branch with respect to which you
conduct your rebase, it no longer is so cut-and-dried obvious that
by git rebase @{u} if the user wants us to guess by digging the
reflog of @{u} to find a better fork point, or if the user wants to
do an exact rebase with respect to the commit at the tip of that
branch.
Whatever excuses are, to me it still looks entirely unnatural that 'git
rebase' and 'git rebase @{u}' mean almost the same /except/ the default
value of --fork-point is different, sorry.
P.S. I'll prepare improved patch for the documentation shortly.
--
Segey.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Code changes in merge commits
John Tapsell johnf...@gmail.com writes: What if merge commits were forced into being always trivial? It would be relatively easy to force a client to always have trivial merges, but much harder to prevent an attacker to forge a non-trivial merge commit (e.g. modifying his local git command) and push it. Ideally I'd like to see all the code changes to a code base just with git log -p. What I'd love to see with git log -p is the diff between a trivial merge (possibly including conflict markers) and the actual merge commit. That would imply that git log would redo the merge before computing the diff (rather heavyweight :-( ), but an empty diff would mean no change other than merge, and if any, we would see the conflict resolution or additional changes in the diff. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Code changes in merge commits
What I'd love to see with git log -p is the diff between a trivial merge (possibly including conflict markers) and the actual merge commit. That would imply that git log would redo the merge before computing the diff (rather heavyweight :-( ), but an empty diff would mean no change other than merge, and if any, we would see the conflict resolution or additional changes in the diff. This would be wonderful. And I'd rather have git do the heavyweight work than doing it myself :-/ I don't know the git internals at all - would it be possible to save the results of the diff? This is what I was aiming for in my idea of making the merge and conflict-resolution as separate commits. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.
Vanilla git rebase defaults to --fork-point that in some cases
makes behavior very different from git rebase upstream,
where --no-fork-point is assumed. This fact was not mentioned in
the DESCRIPTION section of the manual page, even though the case of
omitted upstream was otherwise discussed. That in turn made actual
behavior of vanilla git rebase hardly discoverable.
While we are at it, clarify the --fork-point description itself as well.
Signed-off-by: Sergey Organov sorga...@gmail.com
---
As asked by Junio C Hamano gits...@pobox.com, the newly introduced
'fork_point' term has been described.
Documentation/git-rebase.txt | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 4138554..2e6f125 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -21,15 +21,17 @@ If branch is specified, 'git rebase' will perform an
automatic
it remains on the current branch.
If upstream is not specified, the upstream configured in
-branch.name.remote and branch.name.merge options will be used; see
-linkgit:git-config[1] for details. If you are currently not on any
-branch or if the current branch does not have a configured upstream,
-the rebase will abort.
+branch.name.remote and branch.name.merge options will be used (see
+linkgit:git-config[1] for details) and the `--fork-point` option is
+assumed. If you are currently not on any branch or if the current
+branch does not have a configured upstream, the rebase will abort.
All changes made by commits in the current branch but that are not
in upstream are saved to a temporary area. This is the same set
-of commits that would be shown by `git log upstream..HEAD` (or
-`git log HEAD`, if --root is specified).
+of commits that would be shown by `git log upstream..HEAD`; or by
+`git log 'fork_point'..HEAD`, if --fork-point is either specified or
+assumed (see --fork-point description below); or by `git log HEAD`, if
+--root is specified.
The current branch is reset to upstream, or newbase if the
--onto option was supplied. This has the exact same effect as
@@ -327,13 +329,18 @@
link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details)
--fork-point::
--no-fork-point::
- Use 'git merge-base --fork-point' to find a better common ancestor
- between `upstream` and `branch` when calculating which commits have
- have been introduced by `branch` (see linkgit:git-merge-base[1]).
+ Use reflog to find a better common ancestor between upstream
+ and branch when calculating which commits have been
+ introduced by branch.
+
-If no non-option arguments are given on the command line, then the default is
-`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally
-unless the `--fork-point` option is specified.
+When --fork-point is active, 'fork_point' will be used instead of
+upstream to calculate the set of commits to rebase, where
+'fork_point' is the result of `git merge-base --fork-point upstream
+branch` command (see linkgit:git-merge-base[1]). If 'fork_point'
+ends up being empty, the upstream will be used instead.
++
+If either upstream or --root is given on the command line, then the
+default is `--no-fork-point`, otherwise the default is `--fork-point`.
--ignore-whitespace::
--whitespace=option::
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Code changes in merge commits
On Mon, Sep 29, 2014 at 5:59 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Ideally I'd like to see all the code changes to a code base just with git log -p. What I'd love to see with git log -p is the diff between a trivial merge (possibly including conflict markers) and the actual merge commit. That would imply that git log would redo the merge before computing the diff (rather heavyweight :-( ), but an empty diff would mean no change other than merge, and if any, we would see the conflict resolution or additional changes in the diff. Topic tr/remerge-diff in 'pu'? I think --remerge-diff works with git-log, but I'm not sure. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not make trace.c/getnanotime an inlined function
On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton bdwal...@gmail.com wrote:
Oracle Studio compilers don't allow for static variables in functions
that are defined to be inline. GNU C does permit this. Let's reference
the C99 standard though, which doesn't allow for inline functions to
contain modifiable static variables.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace.c b/trace.c
index b6f25a2..4778608 100644
--- a/trace.c
+++ b/trace.c
@@ -385,7 +385,7 @@ static inline uint64_t gettimeofday_nanos(void)
* Returns nanoseconds since the epoch (01/01/1970), for performance tracing
* (i.e. favoring high precision over wall clock time accuracy).
*/
-inline uint64_t getnanotime(void)
+uint64_t getnanotime(void)
{
static uint64_t offset;
Would moving this offset outside getnanotime() work?
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.
Sergey Organov sorga...@gmail.com writes: Vanilla git rebase defaults to --fork-point that in some cases makes behavior very different from git rebase upstream, where --no-fork-point is assumed. This fact was not mentioned in the DESCRIPTION section of the manual page, even though the case of omitted upstream was otherwise discussed. That in turn made actual behavior of vanilla git rebase hardly discoverable. While we are at it, clarify the --fork-point description itself as well. Signed-off-by: Sergey Organov sorga...@gmail.com --- As asked by Junio C Hamano gits...@pobox.com, the newly introduced 'fork_point' term has been described. I suspect will be used as a fallback might be easier to understand what is going on instead of will be used instead, but other than that, the new explanation of what fork-point is is a very welcome update, I think. diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 4138554..2e6f125 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -21,15 +21,17 @@ If branch is specified, 'git rebase' will perform an automatic it remains on the current branch. If upstream is not specified, the upstream configured in +branch.name.remote and branch.name.merge options will be used (see +linkgit:git-config[1] for details) and the `--fork-point` option is +assumed. If you are currently not on any branch or if the current +branch does not have a configured upstream, the rebase will abort. All changes made by commits in the current branch but that are not in upstream are saved to a temporary area. This is the same set +of commits that would be shown by `git log upstream..HEAD`; or by +`git log 'fork_point'..HEAD`, if --fork-point is either specified or +assumed (see --fork-point description below); or by `git log HEAD`, if +--root is specified. It is easier to read with is either specified or assumed shortened to is active, I think, because that is the word you use to explain how the commit is computed for --fork-point processing. @@ -327,13 +329,18 @@ link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details) --fork-point:: --no-fork-point:: + Use reflog to find a better common ancestor between upstream + and branch when calculating which commits have been + introduced by branch. + +When --fork-point is active, 'fork_point' will be used instead of +upstream to calculate the set of commits to rebase, where +'fork_point' is the result of `git merge-base --fork-point upstream +branch` command (see linkgit:git-merge-base[1]). If 'fork_point' +ends up being empty, the upstream will be used instead. ++ +If either upstream or --root is given on the command line, then the +default is `--no-fork-point`, otherwise the default is `--fork-point`. --ignore-whitespace:: --whitespace=option:: The patch failed to apply Applying: Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION. fatal: corrupt patch at line 38 but the fix-up is trivial, so no need to resend. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
`git log relative_path_to_object` does not respect the --work-tree path
When passing objects to the `git log`, by just naming them or using the `--objects` option, relative paths are evaluated using the current working directory instead of the current working tree path. Even the error message is clearly wrong. unknown revision or path not in the working tree. Example: Given a repo at ~/path/to_repo containing a file such as README.md (~/path/to_repo/README.md) ~/path$ git --work-tree=~/path/to_repo log README.md fatal: ambiguous argument 'README.md': unknown revision or path not in the working tree. As you can see here (https://github.com/robertodecurnex/git/blob/master/setup.c#L147) git is trying to `lstat` the path as it was given when it should validate the file existence within the work tree (perpending the work-tree before the file name). Note: I now several workarounds for this, I'm not looking for a solution to the specific problem but to discuss the implementation and evaluate a change over the current behavior. Regards, -- Roberto Decurnex -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] Make 'git help everyday' work
The Everyday GIT With 20 Commands Or So is not accessible via the Git help system. Move everyday.txt to giteveryday.txt so that git help everyday works, and create a new placeholder file everyday.html to refer people who follow existing URLs to the updated location. giteveryday.txt now formats well with AsciiDoc as a man page and refreshed content to a more command modern style. Add 'everyday' to the help --guides list and update git(1) and 5 other links to giteveryday. Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/Makefile | 3 +- Documentation/everyday.txt | 447 - Documentation/everyday.txto| 9 + Documentation/git-push.txt | 2 +- Documentation/git.txt | 4 +- Documentation/gitcore-tutorial.txt | 2 +- Documentation/gitcvs-migration.txt | 2 +- Documentation/giteveryday.txt | 447 + Documentation/gitglossary.txt | 2 +- Documentation/gittutorial-2.txt| 4 +- Documentation/gittutorial.txt | 4 +- README | 2 +- builtin/help.c | 1 + 13 files changed, 470 insertions(+), 459 deletions(-) delete mode 100644 Documentation/everyday.txt create mode 100644 Documentation/everyday.txto create mode 100644 Documentation/giteveryday.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index 3b56714..8d0f709 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -27,6 +27,7 @@ MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt MAN7_TXT += gitcvs-migration.txt MAN7_TXT += gitdiffcore.txt +MAN7_TXT += giteveryday.txt MAN7_TXT += gitglossary.txt MAN7_TXT += gitnamespaces.txt MAN7_TXT += gitrevisions.txt @@ -38,11 +39,11 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) +OBSOLETE_HTML += everyday.html OBSOLETE_HTML += git-remote-helpers.html DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) ARTICLES += howto-index -ARTICLES += everyday ARTICLES += git-tools ARTICLES += git-bisect-lk2009 # with their own formatting rules. diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt deleted file mode 100644 index cd7f87c..000 --- a/Documentation/everyday.txt +++ /dev/null @@ -1,447 +0,0 @@ -giteveryday(7) -=== - -NAME - -giteveryday - A useful minimum set of commands for Everyday Git - -SYNOPSIS - - -Everyday Git With 20 Commands Or So - -DESCRIPTION - -Git users can broadly be grouped into four categories for the purposes of -describing here a small set of useful command for everyday Git. - -* STANDALONE,Individual Developer (Standalone) commands are essential - for anybody who makes a commit, even for somebody who works alone. - -* If you work with other people, you will need commands listed in - the PARTICIPANT,Individual Developer (Participant) section as well. - -* People who play the INTEGRATOR,Integrator role need to learn some - more commands in addition to the above. - -* ADMINISTRATION,Repository Administration commands are for system - administrators who are responsible for the care and feeding - of Git repositories. - - -Individual Developer (Standalone)[[STANDALONE]] - -A standalone individual developer does not exchange patches with -other people, and works alone in a single repository, using the -following commands. - - * linkgit:git-init[1] to create a new repository. - - * linkgit:git-log[1] to see what happened. - - * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch -branches. - - * linkgit:git-add[1] to manage the index file. - - * linkgit:git-diff[1] and linkgit:git-status[1] to see what -you are in the middle of doing. - - * linkgit:git-commit[1] to advance the current branch. - - * linkgit:git-reset[1] and linkgit:git-checkout[1] (with -pathname parameters) to undo changes. - - * linkgit:git-merge[1] to merge between local branches. - - * linkgit:git-rebase[1] to maintain topic branches. - - * linkgit:git-tag[1] to mark a known point. - -Examples - - -Use a tarball as a starting point for a new repository.:: -+ - -$ tar zxf frotz.tar.gz -$ cd frotz -$ git init -$ git add . 1 -$ git commit -m import of frotz source tree. -$ git tag v2.43 2 - -+ -1 add everything under the current directory. -2 make a lightweight, unannotated tag. - -Create a topic branch and develop.:: -+ - -$ git checkout -b alsa-audio 1 -$ edit/compile/test -$ git checkout -- curses/ux_audio_oss.c 2 -$ git add curses/ux_audio_alsa.c 3 -$ edit/compile/test -$ git diff HEAD 4 -$ git commit -a -s 5 -$ edit/compile/test -$ git diff HEAD^ 6 -$ git commit -a --amend 7 -$ git checkout master 8 -$ git merge alsa-audio 9 -$ git log --since='3 days
[PATCH v3 0/3] Make 'git help everyday' work
Here's version three of my patches to make 'git help everyday' work. It's taken awhile. Previous patches at [1] and [2]. Junio has provided guidance on modernisation of the text, which has been integrated into patch 1. Patch 2 regularises the OBSOLETE_HTML method in the make file, in line with the currently queued version on pu. Finally patch 3 swaps over the everyday.txt to the giteveryday.txt accessible through the regular help system, and changes over all the links. This follows from : Subject: What's cooking in git.git (Sep 2014, #06; Wed, 24) [...] * po/everyday-doc (2014-01-27) 1 commit - Make 'git help everyday' work This may make the said command to emit something, but the source is not meant to be formatted into a manual pages to begin with, and also its contents are a bit stale. It may be a good first step in the right direction, but needs more work to at least get the mark-up right before public consumption. Waiting for a reroll (thread ending at $gmane/254746) Philip [1] http://thread.gmane.org/gmane.comp.version-control.git/240286 [PATCH 0/6] Make 'git help everyday' work [2] http://thread.gmane.org/gmane.comp.version-control.git/240354 [PATCH v2] Make 'git help everyday' work Philip Oakley (3): doc: modernise everyday.txt wording and format in man page style doc: Makefile regularise OBSOLETE_HTML list building Make 'git help everyday' work Documentation/Makefile | 6 +- Documentation/everyday.txt | 413 -- Documentation/everyday.txto| 9 + Documentation/git-push.txt | 2 +- Documentation/git.txt | 4 +- Documentation/gitcore-tutorial.txt | 2 +- Documentation/gitcvs-migration.txt | 2 +- Documentation/giteveryday.txt | 447 + Documentation/gitglossary.txt | 2 +- Documentation/gittutorial-2.txt| 4 +- Documentation/gittutorial.txt | 4 +- README | 2 +- builtin/help.c | 1 + 13 files changed, 472 insertions(+), 426 deletions(-) delete mode 100644 Documentation/everyday.txt create mode 100644 Documentation/everyday.txto create mode 100644 Documentation/giteveryday.txt -- 1.9.4.msysgit.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] doc: Makefile regularise OBSOLETE_HTML list building
Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index cea0e7a..3b56714 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -5,6 +5,7 @@ MAN7_TXT = TECH_DOCS = ARTICLES = SP_ARTICLES = +OBSOLETE_HTML = MAN1_TXT += $(filter-out \ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ @@ -37,7 +38,7 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) -OBSOLETE_HTML = git-remote-helpers.html +OBSOLETE_HTML += git-remote-helpers.html DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) ARTICLES += howto-index -- 1.9.4.msysgit.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] doc: modernise everyday.txt wording and format in man page style
Refresh the contents of everyday.txt contents to a more modern command style. Also update the mark-up so that it can be formatted as a man page with AsciiDoc ready for transfer to the Git guides. The transfer is in subsequent commits. Guidance on modernising the command style provided by Junio at [1], [2] and [3]. [1] Individual Developer, both Standalone and Participant http://article.gmane.org/gmane.comp.version-control.git/254269 [2] Integrator http://article.gmane.org/gmane.comp.version-control.git/254502 [3] Administrator http://article.gmane.org/gmane.comp.version-control.git/254824 Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/everyday.txt | 246 ++--- 1 file changed, 140 insertions(+), 106 deletions(-) diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index b2548ef..cd7f87c 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -1,22 +1,37 @@ +giteveryday(7) +=== + +NAME + +giteveryday - A useful minimum set of commands for Everyday Git + +SYNOPSIS + + Everyday Git With 20 Commands Or So -=== -Individual Developer (Standalone) commands are essential for -anybody who makes a commit, even for somebody who works alone. +DESCRIPTION +--- + +Git users can broadly be grouped into four categories for the purposes of +describing here a small set of useful command for everyday Git. + +* STANDALONE,Individual Developer (Standalone) commands are essential + for anybody who makes a commit, even for somebody who works alone. -If you work with other people, you will need commands listed in -the Individual Developer (Participant) section as well. +* If you work with other people, you will need commands listed in + the PARTICIPANT,Individual Developer (Participant) section as well. -People who play the Integrator role need to learn some more -commands in addition to the above. +* People who play the INTEGRATOR,Integrator role need to learn some + more commands in addition to the above. -Repository Administration commands are for system -administrators who are responsible for the care and feeding -of Git repositories. +* ADMINISTRATION,Repository Administration commands are for system + administrators who are responsible for the care and feeding + of Git repositories. -Individual Developer (Standalone)[[Individual Developer (Standalone)]] --- +Individual Developer (Standalone)[[STANDALONE]] +--- A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the @@ -24,8 +39,6 @@ following commands. * linkgit:git-init[1] to create a new repository. - * linkgit:git-show-branch[1] to see where you are. - * linkgit:git-log[1] to see what happened. * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch @@ -45,7 +58,7 @@ following commands. * linkgit:git-rebase[1] to maintain topic branches. - * linkgit:git-tag[1] to mark known point. + * linkgit:git-tag[1] to mark a known point. Examples @@ -75,14 +88,12 @@ $ edit/compile/test $ git diff HEAD 4 $ git commit -a -s 5 $ edit/compile/test -$ git reset --soft HEAD^ 6 -$ edit/compile/test -$ git diff ORIG_HEAD 7 -$ git commit -a -c ORIG_HEAD 8 -$ git checkout master 9 -$ git merge alsa-audio 10 -$ git log --since='3 days ago' 11 -$ git log v2.43.. curses/ 12 +$ git diff HEAD^ 6 +$ git commit -a --amend 7 +$ git checkout master 8 +$ git merge alsa-audio 9 +$ git log --since='3 days ago' 10 +$ git log v2.43.. curses/ 11 + 1 create a new topic branch. @@ -90,22 +101,21 @@ $ git log v2.43.. curses/ 12 3 you need to tell Git if you added a new file; removal and modification will be caught if you do `git commit -a` later. 4 to see what changes you are committing. -5 commit everything as you have tested, with your sign-off. -6 take the last commit back, keeping what is in the working tree. -7 look at the changes since the premature commit we took back. -8 redo the commit undone in the previous step, using the message -you originally wrote. -9 switch to the master branch. -10 merge a topic branch into your master branch. -11 review commit logs; other forms to limit output can be +5 commit everything, as you have tested, with your sign-off. +6 look at all your changes including the previous commit. +7 amend the previous commit, adding all your new changes, +using your original message. +8 switch to the master branch. +9 merge a topic branch into your master branch. +10 review commit logs; other forms to limit output can be combined and include `--max-count=10` (show 10 commits), `--until=2005-12-10`, etc. -12 view only the changes that touch what's in `curses/` +11
Re: [PATCH] Ensure SHELL_PATH is the hash bang for test suite askpass helper script.
On Mon, Sep 29, 2014 at 08:02:07AM +0100, Ben Walton wrote: The askpass script that is created for use by the test suite should use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024 introduced the use of idioms not supported in some legacy /bin/sh implementations. Use write_script to ensure this happens automatically. This lets us remove the chmod step as well, since write_script handles that. Signed-off-by: Ben Walton bdwal...@gmail.com Thanks, this looks good to me. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not make trace.c/getnanotime an inlined function
Duy Nguyen pclo...@gmail.com writes:
On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton bdwal...@gmail.com wrote:
Oracle Studio compilers don't allow for static variables in functions
that are defined to be inline. GNU C does permit this. Let's reference
the C99 standard though, which doesn't allow for inline functions to
contain modifiable static variables.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace.c b/trace.c
index b6f25a2..4778608 100644
--- a/trace.c
+++ b/trace.c
@@ -385,7 +385,7 @@ static inline uint64_t gettimeofday_nanos(void)
* Returns nanoseconds since the epoch (01/01/1970), for performance tracing
* (i.e. favoring high precision over wall clock time accuracy).
*/
-inline uint64_t getnanotime(void)
+uint64_t getnanotime(void)
{
static uint64_t offset;
Would moving this offset outside getnanotime() work?
I am not sure what the definition of work is.
The function computes the difference between the returned value from
gettimeofday(2) and a custom highres_nanos() just once and returns
the value it got from gettimeofday the first time, and then for
subsequent calls massages the returned value from highres_nanos() to
be consistent with the value returned from gettimeofday using the
offset it computed in the first call.
If we have two copies of this function, two independent probes to
these pair of underlying functions will be made to compute their
offsets. With perfect pair of clocks that may not matter, but it
just feels wrong to me.
Besides, I wonder what happens if the computed offset happen to be
1, which is used as a sentinel.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ensure SHELL_PATH is the hash bang for test suite askpass helper script.
Ben Walton bdwal...@gmail.com writes:
The askpass script that is created for use by the test suite should
use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024
introduced the use of idioms not supported in some legacy /bin/sh
implementations.
Use write_script to ensure this happens automatically. This lets us
remove the chmod step as well, since write_script handles that.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
I'll leave out the some legacy shells we do not support want to use
`command` from the justification of this change. Use of the
write_script helper is the right thing to do---$SHELL_PATH points at
the shell the user told us s/he wants to use, and that is a reason
enough for this change. The reason why the user wants to use that
shell is immaterial.
Thanks.
t/lib-credential.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/t/lib-credential.sh b/t/lib-credential.sh
index 9e7d796..d8e41f7 100755
--- a/t/lib-credential.sh
+++ b/t/lib-credential.sh
@@ -278,12 +278,10 @@ helper_test_timeout() {
'
}
-cat askpass \EOF
-#!/bin/sh
+write_script askpass \EOF
echo 2 askpass: $*
what=$(echo $1 | cut -d -f1 | tr A-Z a-z | tr -cd a-z)
echo askpass-$what
EOF
-chmod +x askpass
GIT_ASKPASS=$PWD/askpass
export GIT_ASKPASS
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git log relative_path_to_object` does not respect the --work-tree path
Roberto Eduardo Decurnex Gorosito decurnex.robe...@gmail.com writes: ~/path$ git --work-tree=~/path/to_repo log README.md This does not seem to specify GIT_DIR explicitly (either with the $GIT_DIR environment variable or the --git-dir option), so I would assume that you are sitting in a directory that has .git/ subdirectory or a subdirectory of such a directory, but that .git/ is not a real repository that controls the working tree you have at the ~/path/to_repo directory. The --work-tree option and $GIT_WORK_TREE environment were primarily invented to solve this problem: When a user gives $GIT_DIR or --git-dir to disable the repository discovery (i.e. trying to see if the current directory has .git/ that looks like a repository, and if not try the parent directory until we find one), traditionally we assumed that the current directory is the top-level of the corresponding working tree. This makes it cumbersome to work inside a subdirectory, and by allowing $GIT_WORK_TREE or --work-tree to specify the top-level of the working tree, working from a subdirectory of a working tree becomes usable again. That is why it does not mix very well with repository discovery (i.e. letting Git crawl upward from the current directory to find a directory with .git/). It is unclear if the auto-discovered .git is the one to be be consulted for the log operation you asked, or the other repository you have at ~/path/to_repo/.git (or one of its parent directories, e.g. ~/path/.git). I _think_ the current implementation randomly chose to use the auto-discovered one, but it may have been better to forbid and always require both --git-dir and --work-tree to be given to avoid confusion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git log relative_path_to_object` does not respect the --work-tree path
Sorry, I left the --git-dir out of the example. I do set the --git-dir (and $GIT_DIR sometimes) too. It gives the same results. That's why I feels like it shouldn't be working as it is. In this specific case (log with object filter) the environment config is completely ignored. On Mon, Sep 29, 2014 at 3:06 PM, Junio C Hamano gits...@pobox.com wrote: Roberto Eduardo Decurnex Gorosito decurnex.robe...@gmail.com writes: ~/path$ git --work-tree=~/path/to_repo log README.md This does not seem to specify GIT_DIR explicitly (either with the $GIT_DIR environment variable or the --git-dir option), so I would assume that you are sitting in a directory that has .git/ subdirectory or a subdirectory of such a directory, but that .git/ is not a real repository that controls the working tree you have at the ~/path/to_repo directory. The --work-tree option and $GIT_WORK_TREE environment were primarily invented to solve this problem: When a user gives $GIT_DIR or --git-dir to disable the repository discovery (i.e. trying to see if the current directory has .git/ that looks like a repository, and if not try the parent directory until we find one), traditionally we assumed that the current directory is the top-level of the corresponding working tree. This makes it cumbersome to work inside a subdirectory, and by allowing $GIT_WORK_TREE or --work-tree to specify the top-level of the working tree, working from a subdirectory of a working tree becomes usable again. That is why it does not mix very well with repository discovery (i.e. letting Git crawl upward from the current directory to find a directory with .git/). It is unclear if the auto-discovered .git is the one to be be consulted for the log operation you asked, or the other repository you have at ~/path/to_repo/.git (or one of its parent directories, e.g. ~/path/.git). I _think_ the current implementation randomly chose to use the auto-discovered one, but it may have been better to forbid and always require both --git-dir and --work-tree to be given to avoid confusion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Will you come?? urgent, we must know
Dear Invited Authors After my previous email, we want to clarify some things: 1) Invited Authors represent only a 3-5% of our authors, see for example the papers with Italics here: http://www.wseas.org/main/conferences/2014/Salerno/Program.pdf ) 2) Invited Authors are selected very carefully according their recent publications and citations and they must fit to the topics of the conference. 3) You can discuss details with our Professors-Organizers in Lisbon after the opening (in the morning of the first day) 4) The list with the ISI Journals that host the extended papers are more and more longer. We started with 6 ISI Journals in March of 2014 and now we have collaboration with 19. So, practically, all the papers will be hosted in these ISI Journals. There are several topics in our conferences in Lisbon. So, select one of our conferences in Lisbon via http://www.wseas.org/wseas/cms.action?id=4#Conferences and upload your invited paper We must have the full paper until October 5 (for Invited Speakers) (Maximum 10 pages. Format see the web page of the conference) Invited Authors have == a) Additional publication in ISI, SCOPUS Journal. You select the Journal where you can publish the extended version of your paper. b) Priority in the conference program c) Double time for presentation d) Invited Papers are noted explicitly in the conference program as Invited Papers e) Invited Authors can be included in the Program Committee of our future conferences of 2015 After uploading your invited paper, send an email (using your email address git@vger.kernel.org) to me to mark your paper as invited in the data base Indexing === ISI (Thomson Reuters), ELSEVIER, SCOPUS, ACM - Association for Computing Machinery, Zentralblatt MATH, British Library, EBSCO, SWETS, EMBASE, CAS - American Chemical Society, CiteSeerx, Cabell Publishing, Electronic Journals, Library, SAO/NASA Astrophysics Data System EI Compendex, Engineering Village, CSA Cambridge Scientific Abstracts, DoPP, GEOBASE, Biobase, American Mathematical Society (AMS), Inspec - The IET, Ulrich's International Periodicals Directory NEW: We have already finished agreements with 19 ISI Journals (with Impact Factor from ISI Web of Knowledge) that will take the extended versions of all the papers after the conference. Our Team works very hard for the indexing of all the accepted papers in ISI and SCOPUS and we have impressive results. Best Regards Anna Papadimitriou WSEAS Editorial Office www.wseas.org -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.
Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: [...] As asked by Junio C Hamano gits...@pobox.com, the newly introduced 'fork_point' term has been described. I suspect will be used as a fallback might be easier to understand what is going on instead of will be used instead, but other than that, the new explanation of what fork-point is is a very welcome update, I think. Yeah, sure. Wasn't satisfied with the wording myself. [...] The patch failed to apply Sorry about it. Applying: Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION. fatal: corrupt patch at line 38 I rather get: $ git apply x.patch x.patch:38: trailing whitespace. introduced by branch. warning: 1 line adds whitespace errors. I've used 'git format-patch' to prepare the patch. Shouldn't it warn about such things? Or what should I do to avoid such problems in the future? but the fix-up is trivial, so no need to resend. Thanks. -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not make trace.c/getnanotime an inlined function
Am 28.09.2014 um 22:42 schrieb Ben Walton: On Sun, Sep 28, 2014 at 8:15 PM, Johannes Sixt j...@kdbg.org mailto:j...@kdbg.org wrote: Am 28.09.2014 um 09:50 schrieb Ben Walton: -inline uint64_t getnanotime(void) +uint64_t getnanotime(void) But then the function could stay static, no? This function is used in several places outside of the translation unit so while it's possible, I think it's more work than it's worth... I see. I didn't check myself, sorry. I assumed that due to the 'inline' the function would not have been available outside. Now your patch looks good. Thanks, -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH 12/14] Fix pointer - integer casts on IL32P64 systems
Am 28.09.2014 um 15:24 schrieb Marat Radchenko:
This commit touches regcomp.c and poll.c from Gnulib,
both were fixed upstream in 2012 the same way.
Wrt ShellExecute, see [1].
[1]: http://blogs.msdn.com/b/oldnewthing/archive/2006/11/08/1035971.aspx
Please do not force readers to visit a web site; provide at least a summary.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c
index 06f3088..d8bde06 100644
--- a/compat/regex/regcomp.c
+++ b/compat/regex/regcomp.c
@@ -2577,7 +2577,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp,
re_dfa_t *dfa,
old_tree = NULL;
if (elem-token.type == SUBEXP)
-postorder (elem, mark_opt_subexp, (void *) (long) elem-token.opr.idx);
+postorder (elem, mark_opt_subexp, (void *) (intptr_t)
elem-token.opr.idx);
tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK :
OP_ALT));
if (BE (tree == NULL, 0))
@@ -3806,7 +3806,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left,
bin_tree_t *right,
static reg_errcode_t
mark_opt_subexp (void *extra, bin_tree_t *node)
{
- int idx = (int) (long) extra;
+ int idx = (int) (intptr_t) extra;
if (node-token.type == SUBEXP node-token.opr.idx == idx)
node-token.opt_subexp = 1;
This breaks with
In file included from compat/regex/regex.c:77:
compat/regex/regcomp.c: In function 'parse_dup_op':
compat/regex/regcomp.c:2580: error: 'intptr_t' undeclared (first use in
this function)
when compiled using the msysgit environment.
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git log relative_path_to_object` does not respect the --work-tree path
Hi Roberto, Roberto Eduardo Decurnex Gorosito wrote: When passing objects to the `git log`, by just naming them or using the `--objects` option, relative paths are evaluated using the current working directory instead of the current working tree path. Why should they be relative to the worktree root? When you use relative paths within a worktree, they are not relative to the worktree root. For example, the following works within a clone of git.git: $ cd Documentation $ git log git.txt You might be looking for 'git -C directory', which chdirs to the named directory so paths are relative to there. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git for Windows 1.9.4.msysgit.2
Hi, the Git for Windows team just released the third maintenance release of the Windows-specific installers for git 1.9.4. It can be downloaded from the usual place [1] and I also attached some unsigned SHA sums [2]. New Features - Comes with Git 1.9.4 plus Windows-specific patches. Bugfixes - Update bash to patchlevel 3.1.20(4) (msysgit PR#254, msysgit issue #253). Fixes CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 and CVE-2014-7187. - gitk.cmd now works when paths contain the ampersand () symbol (msysgit PR #252) - Default to automatically close and restart applications in silent mode installation type - Git svn is now usable again (regression in previous update, msysgit PR#245) Have phun, Thomas [1]: https://github.com/msysgit/msysgit/releases/download/Git-1.9.4-preview20140929/Git-1.9.4-preview20140929.exe [2]: SHA1(Git-1.9.4-preview20140929.exe)= a7a50a18992a56de193e048b0205bf21b6721554 SHA1(PortableGit-1.9.4-preview20140929.7z)= 4b0698f2bf96b0dd64ecec477b3db9e3b3d46085 SHA1(msysGit-netinstall-1.9.4-preview20140929.exe)= 73ad668013941863e80e74bcf853d53eeed69714 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] (git commit --patch --message $MESSAGE) disallows hunk editing
Max Nanasy max.nanasy at gmail.com writes: Tested against v1.7.12.4 Steps to reproduce: A. cd $DIRTY_WORKING_COPY B. git commit --patch --message $MESSAGE C. Stage this hunk? e Expected behavior: After step C, the hunk opens in the user's editor Actual behavior: After step C, the hunk is selected unedited (as if the user had entered y) AFAICT, this occurs because of the following code in builtin/commit.c:parse_and_validate_options: if (... || message.len || ...) use_editor = 0; ... if (!use_editor) setenv(GIT_EDITOR, :, 1); Because --message is specified, GIT_EDITOR is set to :, which prevents the user from editing hunks, although the intent is most likely to just prevent the user from editing the commit message. It appears that this was fixed in version 2.0. The changelog entry says: * When it is not necessary to edit a commit log message (e.g. git commit -m is given a message without specifying -e), we used to disable the spawning of the editor by overriding GIT_EDITOR, but this means all the uses of the editor, other than to edit the commit log message, are also affected. (merge b549be0 bp/commit-p-editor later to maint). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] doc: modernise everyday.txt wording and format in man page style
Philip Oakley philipoak...@iee.org writes: @@ -45,7 +58,7 @@ following commands. * linkgit:git-rebase[1] to maintain topic branches. - * linkgit:git-tag[1] to mark known point. + * linkgit:git-tag[1] to mark a known point. I really appreciate your attention to details here. +10 review commit logs; other forms to limit output can be combined and include `--max-count=10` (show 10 commits), `--until=2005-12-10`, etc. s/--max-count=//; perhaps? @@ -131,27 +145,34 @@ Clone the upstream and work on it. Feed changes to upstream.:: $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 +$ git checkout -b mine master 1 +$ edit/compile/test; git commit -a -s 2 +$ git format-patch master 3 +$ git send-email --to=person em...@example.com 00*.patch 4 +$ git pull 5 This may be found somewhat questionable by some people, as mine does not build on the master at origin. Insert git checkout master before this step to cause 5 update the pristine copy of their master, perhaps? That way, the next step +$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 6 starts making more sense. +$ git fetch --tags 11 ... +11 from time to time, obtain official tags from the `origin` and store them under `.git/refs/tags/`. I am not sure if fetch --tags still needs to be taught, especially in a quick guide document, because fetch has auto-followed relevant tags for a long time since the original version of this document was written. +3 arrange `git push` to push all local branches to +their corresponding branch of the mothership machine. +4 push will stash all our work away on `remotes/satellite/*` +remote-tracking branches on the mothership machine. You could use this as a back-up method. The original mentions a back-up method, but a larger benefit of this kind of settings is that it lets you pretend that mothership fetched from you. We may want to say You can use this to pretend as if the origin, aka mothership, ran 'git fetch' from you, aka satellite. This is especially true because the next step 5 is about how to integrate your work done on 'satellite' into 'mothership' that cannot fetch from 'satellite' (imagine satellite is behind a NAT and it can only ssh out to mothership but not the other way around). -Integrator[[Integrator]] +Integrator[[INTEGRATOR]] A fairly central person acting as the integrator in a group @@ -213,6 +235,9 @@ project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants. +This section can also be applied to a git-request-pull workflow, +or the GitHub (www.github.com) pull-request flow. Clarify which end of that workflow this can be applied, perhaps? E.g. ... also be used by the person who responds to 'git request-pull' or pull-request on GitHub to integrate others' work into your history. @@ -225,23 +250,26 @@ commands in addition to the ones needed by participants. * linkgit:git-push[1] to publish the bleeding edge. + * linkgit:git-request-pull[1] to create a summary of changes +for your upstream to pull. + This new item looks somewhat out of place, doesn't it? It is because this is a participant item, not an integrator item. Yes, I know a sub-area lieutenant would request a pull by the top-level maintainer, but when you interact with your 'upstream', you are not acting as an integrator. If you really want to add request-pull to common 20-or-so commands, it would make more sense to do so in the participant's section and to explain that an sub-area lieutenant acts both as a participant and as an integrator. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Sep 2014, #08; Mon, 29)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * da/rev-parse-verify-quiet (2014-09-19) 4 commits (merged to 'next' on 2014-09-23 at 5ed184a) + stash: prefer --quiet over shell redirection of the standard error stream + refs: make rev-parse --quiet actually quiet + t1503: use test_must_be_empty + Documentation: a note about stdout for git rev-parse --verify --quiet rev-parse --verify --quiet $name is meant to quietly exit with a non-zero status when $name is not a valid object name, but still gave error messages in some cases. * hj/pretty-naked-decoration (2014-09-18) 1 commit (merged to 'next' on 2014-09-23 at fb699c4) + pretty: add %D format specifier The pretty-format specifier %d, which expanded to (tagname) for a tagged commit, gained a cousin %D that just gives the tagname without frills. * jk/mbox-from-line (2014-09-22) 2 commits (merged to 'next' on 2014-09-23 at 506b89b) + mailinfo: work around -Wstring-plus-int warning (merged to 'next' on 2014-09-19 at 314af77) + mailinfo: make From in-body header check more robust Some MUAs mangled a line in a message that begins with From to From when writing to a mailbox file and feeding such an input to git am used to lose such a line. * rs/graph-simplify (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at 72969e2) + graph: simplify graph_padding_line() * rs/remote-simplify (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at 176e316) + remote: simplify match_name_with_pattern() using strbuf * sb/t6031-typofix (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at aec57a9) + t6031-test-merge-recursive: do not forget to add file to be committed * sb/t9300-typofix (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at aa519bd) + t9300-fast-import: fix typo in test description -- [New Topics] * bw/use-write-script-in-tests (2014-09-29) 1 commit (merged to 'next' on 2014-09-29 at be4056e) + t/lib-credential: use write_script Will merge to 'master'. * bw/trace-no-inline-getnanotime (2014-09-29) 1 commit - trace.c: do not mark getnanotime() as inline No file-scope static variables in an inlined function, please. -- [Stalled] * rs/ref-transaction (2014-09-12) 20 commits . remote rm/prune: print a message when writing packed-refs fails . ref_transaction_commit: bail out on failure to remove a ref . lockfile: remove unable_to_lock_error . refs.c: do not permit err == NULL . for-each-ref.c: improve message before aborting on broken ref . refs.c: fix handling of badly named refs . branch -d: avoid repeated symref resolution . refs.c: change resolve_ref_unsafe reading argument to be a flags field . refs.c: make write_ref_sha1 static . fetch.c: change s_update_ref to use a ref transaction . refs.c: ref_transaction_commit: distinguish name conflicts from other errors . refs.c: pass a skip list to name_conflict_fn . refs.c: call lock_ref_sha1_basic directly from commit . refs.c: move the check for valid refname to lock_ref_sha1_basic . rename_ref: don't ask read_ref_full where the ref came from . refs.c: pass the ref log message to _create/delete/update instead of _commit . refs.c: add an err argument to delete_ref_loose . wrapper.c: add a new function unlink_or_msg . wrapper.c: remove/unlink_or_warn: simplify, treat ENOENT as success . mv test: recreate mod/ directory instead of relying on stale copy Rerolled and was asked to wait. Seems to break HEAD reflog upon checkout HEAD^0. Expecting another reroll. * tr/remerge-diff (2014-09-08) 8 commits - log --remerge-diff: show what the conflict resolution changed - name-hash: allow dir hashing even when !ignore_case - merge-recursive: allow storing conflict hunks in index - merge_diff_mode: fold all merge diff variants into an enum - combine-diff: do not pass revs-dense_combined_merges redundantly - merge-recursive: -Xindex-only to leave worktree unchanged - merge-recursive: internal flag to avoid touching the worktree - merge-recursive: remove dead conditional in update_stages() log -p output learns a new way to let users inspect a merge commit by showing the differences between the automerged result with conflicts the person who recorded the merge would have seen and the final conflict resolution that was recorded in the merge. Waiting for a reroll ($gmane/256591). * hv/submodule-config (2014-06-30) 4 commits - do not die on error of parsing fetchrecursesubmodules option - use new config API for worktree configurations of submodules - extract functions for
Strange behavior of git rev-list --first-parent --ancesty-path
Hello! Imagine following tree: A--B--C \ / D--E B is parent #1 of C. git rev-list --first-parent --ancestry-path D..C returns zero commits. This is correct, since one cannot find any commits between D and C traversing tree by first parent. git rev-list --first-parent --ancestry-path E..C returns SHA of C. This is strange, because --ancestry-path should restrict output to commits being both ancestors of C and descendants of E. Git did not return me any errors or warnings so I'm assuming that --first-parent and --ancestry-path are OK to be used together. So, is it a git bug or I'm doing smth wrong? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
