Re[2]: Feature request: implement '--follow' option for `git blame`
Здравствуйте, Junio. Вы писали 13 апреля 2015 г., 8:32:33: JCH Eugen Konkov kes-...@yandex.ru writes: I agree with your complex example. JCH Note that it is a norm, not anything complex, that we do not rename JCH a file wholesale. But it will be great to guess in simple case, when in version v1.0 only one file A which were renamed into C half year later. JCH So you used to have A and somebody renamed that into C in the past. JCH The content of C in the current version is what you used to have in JCH A. JCH What should happen if you also have A, whose contents do not have JCH any relation to that old A, in today's code? JCH What should happen if you also used to have C, whose contents do not JCH have any relation to that old A or current C? JCH What happens if you added such random guessing and you were not so JCH familiar with the project history to know these unrelated A's and JCH C's that used to exist in the past? JCH Current Git _consistently_ behaves, even in the presense of anything JCH that can lead to confusing behaviour. When you ask JCH git blame OLD -- A JCH it does not matter if you have an unrelated A in the revision that JCH you happen to have checked out in your working tree (i.e. HEAD). JCH The above command line talks about the old revision OLD and A talks JCH about the path A in that old revision. Yes. you are right. I do not think about these examples. -- С уважением, Eugen mailto:kes-...@yandex.ru -- 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
About the git merge tee-shirt
Hi, For those of you who weren't at the Git Merge conference last week, we goot a tee-shirt with this drawing: https://drive.google.com/file/d/1v9bfY0mI8Hi94m4SgqLccFnZ5L_OUlaJSA/view?usp=sharing I have to say I love that tee-shirt. I already had tee-shirts that only computer scientists could understand, now I have a tee-shirt that not even every computer scientist can understand. Now, I have a problem: I'm not sure I understand what the drawing represents. Initially, I thought the circles represented Git contributors, and links represented people contributing to the same parts of the codebase. But looking at the output of shortlog -s, I can't find a correspondance with the tee-shirt. My second guess is that they represent directories. But even then, I can't find which of the tee-shirt's circles represents which directory, and the count doesn't match. Does anybody have a better explanation? Or is it just a random drawing to say Git is bigger than it used to be? Thanks, -- 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: When and how to to contact the Git developers (gist)
Hi, Thomas Ferris Nicolaisen wrote: Perhaps someone here would prefer to use my gist when redirecting people with user questions away from this list, or inspire them to write better bug reports. This won't come as a surprise given what I said at Git Merge: I'd rather we don't redirect people with user questions away from this list. The current volume has been pleasant and manageable. I especially disagree with Generally speaking, Git has very few bugs, and if you're not sure what you are doing, it's probably a user-issue, and not an issue for the Git developers. User issues are an issue for git developers. The hardest part of making git work well is getting it to match how humans work, not getting it to be technically correct or theoretically bug free. So if I were writing it, I'd drop everything up to If you believe you've found a bug in Git for Windows. Another alternate forum to point people to is #git on freenode. It is reachable from https://webchat.freenode.net, so a person seeking quick help doesn't even have to set up an IRC client. It might be nice to add a note to the If you can find no existing discussions paragraph: if there's been a previous discussion, it's fine to raise the subject again. A good practice is to link to and summarize the previous discussion so people can learn from what has happened before. On the other hand inspiring people about how to tell stories better or write bug reports in a more useful way is always welcome. Thanks, 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
Re: [PATCH 1/7] path.c: implement xdg_config_home()
Paul Tan pyoka...@gmail.com writes: As such, implement a simpler function xdg_config_home() for constructing the XDG base dir spec configuration file path. This function, together with expand_user_path(), can replace all uses of home_config_paths(). Indeed. The code looks much better after your patch series than before. I agree with Dscho's remark that fn sounds like function more than filename. Perhaps just name would be better. Anyway, the series is Reviewed-by: Matthieu Moy matthieu@imag.fr -- 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
Requesting `git stash --cached` or something similar
I'm still fairly new to git (coming from svn) and have found `git stash` to be really useful for storing in-progress work to resume later, as one might otherwise do with diff/patch files. (With the git tools I use, I find `git stash pop` to be more convenient and reliable than creating and applying diffs, partially because the changes remained tied to my repository and easily accessible.) Since `git stash` defaults to stashing ALL local modifications, I'd like to request there be an easy way to stash *only* the changes I've already staged in the index. (The reason I suggested --cached is due to the similarity with `git diff --cached`, but I don't doubt there would be a better name for this option.) I tried staging everything *except* what I want to stash and using `git stash save --keep-index message`, but it isn't intended to support this case, and doesn't work when I have new untracked files. Instead, it stashes *all* local (tracked) changes — both staged and unstaged — but leaves the staged changes intact in the index. I understand that git's branching model is powerful and flexible, and that an experienced git user would generally create a private branch and commit to that, then merge the changes to mainline sometime later. However, for those like me for whom having many branches is generally more confusing than helpful, it would be fantastic to have more flexibility with `git stash`. Thanks in advance for considering my request. Regards, - Quinn smime.p7s Description: S/MIME cryptographic signature
Re: Requesting `git stash --cached` or something similar
On Mon, Apr 13, 2015 at 02:24:04PM -0700, Quinn Taylor wrote: I'm still fairly new to git (coming from svn) and have found `git stash` to be really useful for storing in-progress work to resume later, as one might otherwise do with diff/patch files. (With the git tools I use, I find `git stash pop` to be more convenient and reliable than creating and applying diffs, partially because the changes remained tied to my repository and easily accessible.) Since `git stash` defaults to stashing ALL local modifications, I'd like to request there be an easy way to stash *only* the changes I've already staged in the index. (The reason I suggested --cached is due to the similarity with `git diff --cached`, but I don't doubt there would be a better name for this option.) Ok, so this git stash --cached will save the state of the index in the stash, and reset the index to the state in HEAD. What happens to the working tree? I tried staging everything *except* what I want to stash and using `git stash save --keep-index message`, but it isn't intended to support this case, and doesn't work when I have new untracked files. Instead, it stashes *all* local (tracked) changes — both staged and unstaged — but leaves the staged changes intact in the index. What do you want this new command to do with untracked files? I would expect the answers to be it sets the working directories state to the state in HEAD, and leaves untracked files alone. If that's what you want you can do git commit -m message; git reset --hard; git reset --soft; git stash save to get the effect you want I believe. That said it seems like a kind of odd thing to want to do, what are you actually trying to do? Trev I understand that git's branching model is powerful and flexible, and that an experienced git user would generally create a private branch and commit to that, then merge the changes to mainline sometime later. However, for those like me for whom having many branches is generally more confusing than helpful, it would be fantastic to have more flexibility with `git stash`. Thanks in advance for considering my request. Regards, - Quinn -- 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: Requesting `git stash --cached` or something similar
Quinn:
On Mon, Apr 13, 2015 at 5:24 PM, Quinn Taylor quinntay...@mac.com wrote:
I'm still fairly new to git (coming from svn) and have found `git stash` to
be really useful for storing in-progress work to resume later, as one might
otherwise do with diff/patch files. (With the git tools I use, I find `git
stash pop` to be more convenient and reliable than creating and applying
diffs, partially because the changes remained tied to my repository and
easily accessible.)
Since `git stash` defaults to stashing ALL local modifications, I'd like to
request there be an easy way to stash *only* the changes I've already staged
in the index. (The reason I suggested --cached is due to the similarity with
`git diff --cached`, but I don't doubt there would be a better name for this
option.)
I tried staging everything *except* what I want to stash and using `git stash
save --keep-index message`, but it isn't intended to support this case, and
doesn't work when I have new untracked files. Instead, it stashes *all* local
(tracked) changes — both staged and unstaged — but leaves the staged changes
intact in the index.
I understand that git's branching model is powerful and flexible, and that an
experienced git user would generally create a private branch and commit to
that, then merge the changes to mainline sometime later. However, for those
like me for whom having many branches is generally more confusing than
helpful, it would be fantastic to have more flexibility with `git stash`.
I know that git-stash feels like a suitable solution for this, but it
really doesn't seem to have been built for it. Especially when you get
a little bit more experienced with Git and start experimenting with
branching more you will find that stashes quickly become difficult to
maintain. Branches are easier to manage, and they come with the full
power of Git for free. It just doesn't make sense to create a separate
system to manage this when it's precisely what Git does so well
already. That's my two cents.
Note that you don't have to merge these branches. You can rebase as
you please to formulate the history exactly as you want if you want.
You'll find that if you try you can more easily keep track of
branches. It helps to formulate a workflow for yourself. You can even
use namespaces in your branch names to keep them separate. For
example, instead of creating a branch with your stash changes called
foobar, you could create one called stash/foobar. It would help
you to differentiate between other branches, but you still have the
full power of Git. You can rebase the branch onto other history, or
you can merge if you so desire. It's easier to keep track of where the
work began and where it was first applied. There are just so many
advantages. The stash can be useful to quickly tuck a dirty tree away
while you do something else. Even so, often committing it is
sufficient. You can often just work around that commit and edit it
later if necessary.
I'm not a developer so I can't say that your suggestion isn't useful.
I know that I have had the same desire in the past. For example,
wanting git stash save --interactive or git stash save --patch (i.e.,
see git-add flags). Of course, Git already has stable code to do this
and it doesn't require introducing parallel APIs for the same exact
thing. If you give it a shot you may find that branches solve your
problem sufficiently.
Regards,
--
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bambams.ca/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
--
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] config.c: split some variables to $GIT_DIR/config.worktree
On Tue, Mar 31, 2015 at 07:14:39PM +0700, Nguyễn Thái Ngọc Duy wrote: core.worktree and core.bare, which are treated specially in 31e26eb [1], are now moved to info/core.worktree and the special treatment reverted. ... - if (get_common_dir(sb, gitdir)) - fn = check_repo_format; - else - fn = check_repository_format_version; By the way, after this '$GIT_DIR/common overrides core.worktree' from t1501 started failing. I don't know what would be better to do with the case, just remove maybe? -- Max -- 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: About the git merge tee-shirt
On Mon, Apr 13, 2015 at 10:50:55PM +0200, Matthieu Moy wrote: For those of you who weren't at the Git Merge conference last week, we goot a tee-shirt with this drawing: [...] Oops, you made me realize that I forgot to grab a t-shirt. :) I'm going to see if we had leftovers (which I guess we should, since there should have been one per attendee). If you attended but did not get one, let me know and I'll see if it's possible to get one shipped. Initially, I thought the circles represented Git contributors, and links represented people contributing to the same parts of the codebase. But looking at the output of shortlog -s, I can't find a correspondance with the tee-shirt. My second guess is that they represent directories. But even then, I can't find which of the tee-shirt's circles represents which directory, and the count doesn't match. Does anybody have a better explanation? Or is it just a random drawing to say Git is bigger than it used to be? I believe it is gource[1] output from 2005 and 2015, tweaked by a graphic designer to make it look nicer. I do like the design, but it's probably not the most meaningful representation of git's growth. It is showing that the tree has grown, but I think it is much more interesting how the number of contributors has grown (or the number of users!). Unfortunately, exponential graphs are not as interesting to look at. :) -Peff [1] https://github.com/acaudwell/Gource -- 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: Requesting `git stash --cached` or something similar
Trevor:
On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders tbsau...@tbsaunde.org wrote:
I would expect the answers to be it sets the working directories state
to the state in HEAD, and leaves untracked files alone. If that's what
you want you can do git commit -m message; git reset --hard; git reset
--soft; git stash save to get the effect you want I believe. That said
it seems like a kind of odd thing to want to do, what are you actually
trying to do?
That looks like a bad solution. git reset --hard is going to throw
away any remaining changes to the working tree. The previous commit
would have committed the staged changes, albeit, you should connect
the commands with instead of ; to account for errors. After a `git
reset --hard' there's no point in doing a `git reset --soft' because
hard does *everything*. --soft would try to reset the HEAD without
touching the index or working tree, but both have already been reset
with --hard.
The motivation is most likely stashing a few changes away so that you
can commit others that are ready to be committed while keeping others
around to continue working on them. This too is a good observation. It
could mean that the OP is inexperienced with a commit-often workflow.
You can use git -add -i or -p to commit the good stuff and keep the
bad stuff out to work on it more. The great thing about Git is that
the history is very malleable. You can also commit the bad and fix it
after, rebase the history to clean it up, and end up with perfect
history while still keeping your changes safely in history.
The OP should experiment with workflows because Git is already very
good at this. Stash isn't really needed. That said, I had forgotten
that --patch was added to stash some time ago so if that is what you
want then it already exists. It's not quite as easy as --cached, but
it still gives you some control. It's still not nearly as good as
using the full power of Git with a regular commit on a branch though.
Regards,
--
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bambams.ca/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
--
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 1/7] path.c: implement xdg_config_home()
On Mon, Apr 13, 2015 at 2:43 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Paul Tan pyoka...@gmail.com writes: As such, implement a simpler function xdg_config_home() for constructing the XDG base dir spec configuration file path. This function, together with expand_user_path(), can replace all uses of home_config_paths(). Indeed. The code looks much better after your patch series than before. I agree with Dscho's remark that fn sounds like function more than filename. Perhaps just name would be better. I'd go with fname but that's just bikeshedding now. Anyway, the series is Reviewed-by: Matthieu Moy matthieu@imag.fr and Reviewed-by: Stefan Beller sbel...@google.com -- 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 -- 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 add -p “Your edited hunk does not apply. Edit again”
I asked this question in stackoverflow a few days ago, but get no answer.
link:
http://stackoverflow.com/questions/29518944/git-add-p-your-edited-hunk-does-not-apply-
edit-again
---
An example, the original file:
test:
make clean
nosetests
clean:
rm -rf htmlcov
rm -rf build dist
coverage erase
The file after changed:
HTMLCOV=htmlcov/
test:
make clean
nosetests
clean:
coverage erase
rm -rf htmlcov
rm -rf build dist
covhtml:
make clean
nosetests
coverage html
cd ${HTMLCOV} python -m SimpleHTTPServer
This is the diff:
diff --git a/mf b/mf
index b9ca06e..6316e17 100644
--- a/mf
+++ b/mf
@@ -1,8 +1,16 @@
+HTMLCOV=htmlcov/# Hunk 1
+
test:
make clean
nosetests
clean:
+ coverage erase # Hunk 2
rm -rf htmlcov
rm -rf build dist
- coverage erase # Hunk 3
+
+covhtml:
+ make clean
+ nosetests
+ coverage html
+ cd ${HTMLCOV} python -m SimpleHTTPServer
I use git add -p, want only to add:
+ coverage erase
rm -rf htmlcov
rm -rf build dist
- coverage erase
So I first use s to split hunks, and n to ignore first add,
then use y to add second hunk, the third hunk
is:
- coverage erase
+
+covhtml:
+ make clean
+ nosetests
+ coverage html
+ cd ${HTMLCOV} python -m SimpleHTTPServer
So I use e to manually edit the hunk, I delete all the + lines, it seems:
# Manual hunk edit mode -- see bottom for a quick guide
@@ -6,3 +9,8 @@
rm -rf htmlcov
rm -rf build dist
- coverage erase
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
#
#
But when I saved, it says:
@@ -6,3 +9,8 @@
rm -rf htmlcov
rm -rf build dist
- coverage erase
+
+covhtml:
+ make clean
+ nosetests
+ coverage html
+ cd ${HTMLCOV} python -m SimpleHTTPServer
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? e
error: patch failed: mf:1
error: mf: patch does not apply
Your edited hunk does not apply. Edit again (saying no discards!) [y/n]?
And then I change to @@ from-file-range to-file-range @@ part to:
@@ -6,3 +9,2 @@
There is still the same problem.
If I first add only the second Hunk,
and then I run git add -p xxx again, and edit the hunk,
there is no problem. Why?
--
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] reduce progress updates in background
On Mon, Apr 13, 2015 at 11:48:50PM +1000, Luke Mewburn wrote: Hi, I've noticed that when a long-running git operation that generates progress output is suspended and converted to a background process, the terminal still gets spammed with progress updates (to stderr). I've explicitly separated the in_progress_fd() function so that it's easier to (a) reuse elsewhere where appropriate, and (b) make any portability changes to the test if necessary. I also used getpgid(0) versus getpgrp() to avoid portability issues with the signature in the latter with pre-POSIX. I like this patch. It's simple and seems like a sensible change, and I appreciated the opportunity to learn about tcgetpgrp(3). The Windows folks will probably need to stub that function out, but they're no worse off than they were before. I do agree with Nicolas that optimizing the code to avoid calling in_progress_fd as much as possible is a good idea, since system calls can be expensive on some systems. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH v2 1/4] t4059: test 'diff --cc' with a change from only few parents
On Sat, Apr 11, 2015 at 10:51:10PM -0700, Junio C Hamano wrote: Max Kirillov m...@max630.net writes: My exact case was that there was a change in one branch which was overwritten during merge conflict resolution by fully acepting the other branch - in a 2-parent merge. I started looking for a way to visualize such cases. They are not visible in usual diff, because they look same as accepting change compared to the unchange branch. Hmph, isn't that exactly why diff -c exists, not diff --cc that omits (usually) uninteresting hunks? No, this shows too many. If a change is done in one branch but the other branch did not introduce any changes since mergebase and they merged cleanly the merge should not be shown, and `diff -c` seems to show them. -- 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
Feature Request: provide cmdline args to git hooks
Hello,
Just a brief note about a feature I would find incredibly useful, were
it available.
A brief background of my use case:
I am wanting to write a pre-push hook to prevent tags being pushed to
our production servers. The production servers in our case are --bare
endpoints, and when we push a tag at them, they always checkout the
commit that tag is attached to via some post-receive magic (WPEngine,
FWIW). This behavior is even present when the tag was already pushed
to the repo previously, if for instance a normal push is made with the
--tags argument. In the past we have had problems when a developer is
using a GUI like SourceTree and accidentally leaves the 'push all
tags' option checked, pushing 100s of tags to the server, which then
dutifully begins checking out each in turn.
Currently I check for tag refs being pushed with:
#...SNIP...
while read local_ref local_sha remote_ref remote_sha
do
local_type=$(echo $local_ref | awk -F/ '{print $2}')
remote_type=$(echo $remote_ref | awk -F/ '{print $2}')
if [[ $no_tags -eq 1 ($local_type = tags || $remote_type = tags)]]
then
echo Detected attempt to push tags to a no_tags repo! Exiting without push...
exit 1
fi
#...SNIP...
which works fine the first time tags are pushed, but when they are
already up to date as of the last fetch, they are not passed to the
stdin for pre-push, so I cannot detect them.
in a linux environment we can inspect /proc/$PPID/cmdline or ps
-ocommand= -p $PPID to find the --tags argument (or any manually
specified tag refs, etc), however commonly developers are using
Windows with SourceTree, and the pseudo-nix environment it provides
lacks a /proc directory and uses the cut down cygwin version of ps. I
have considered going down the parsing route with general ps output,
reading line by line to find the appropriate ppid, then echoing the
output, but varying output and column order of ps between SourceTree
and various linux versions looks to make that infeasible as a portable
solution.
If we could access the original git push commandline inside the hook,
either through a parameter passed directly to the script or possibly a
GIT_* environment variable, it would make this possible. My specific
use case may not be incredibly common, but this could also be used to
check if, for example, a push is being forced in a portable fashion -
something I can see being useful for a pre-push hook in a variety of
circumstances.
Alternatively - am I missing the super easy (and probably super
obvious) way to do this with the existing tools?
--
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/RFC] combine-diff.c: make intersect_paths() behave like hunk filtering
* for `diff --cc` 2 cases:
* the path must be changed since at least 2 parents, which
should have the path different. In other words, the child and its
parents must contain at least 3 different versions of file.
Non-existing in the commit path counts as one version.
* All parents are the same, but child commit differs from them.
* for `diff -c`: the path must be changed since at least 1 parent.
Signed-off-by: Max Kirillov m...@max630.net
---
This what could be done to hide the added and removed files.
It also makes it work faster - diff --cc on the evil merge runs now 2.5 seconds
instead of 11 (or 0.4 without the series).
This also fails t4057, but I really don't see the logic of `diff -c`
othwerwise. It should show all changes, with trivial merges also, and it
is shown by long files in my t4059. But it uses same path filtering as
`diff --cc`, which is even more restrictive.
combine-diff.c | 91 ++
1 file changed, 66 insertions(+), 25 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 2285c7c..f44032a 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -50,20 +50,49 @@ static void insert_path(struct combine_diff_path **pos,
const char* path, int n,
*pos = p;
}
-static int changed_parents(struct combine_diff_path *p, int n)
+static int path_not_interesting(struct combine_diff_path *p, int n,
+ struct diff_filespec *new_parent)
{
int parent_idx;
- int result = 0;
+ struct object_id first_parent;
+ int found_first = 0;
+ int found_same_parent = 0;
for (parent_idx = 0; parent_idx n; parent_idx++) {
- if (p-parent[parent_idx].status != ' ')
- result++;
+ if (p-parent[parent_idx].status != ' ') {
+ if (found_first) {
+ if (hashcmp(p-parent[parent_idx].oid.hash,
first_parent.hash)) {
+ /* found second different unique parent
- non-trivial merge */
+ return 0;
+ }
+ } else {
+ found_first = 1;
+ hashcpy(first_parent.hash,
+ p-parent[parent_idx].oid.hash);
+ }
+ } else {
+ /* the new commit repeats some of parents */
+ found_same_parent = 1;
+ }
}
- return result;
+ if (new_parent) {
+ if (hashcmp(p-oid.hash, new_parent-sha1)) {
+ if (!found_same_parent || hashcmp(first_parent.hash,
new_parent-sha1)) {
+ return 0;
+ } else {
+ return 1;
+ }
+ } else {
+ found_same_parent = 1;
+ }
+ }
+
+ return found_same_parent;
}
-static struct combine_diff_path *intersect_paths(struct combine_diff_path
*curr, int n, int num_parent)
+static struct combine_diff_path *intersect_paths(
+ struct combine_diff_path *curr, int n, int num_parent, int dense)
{
struct diff_queue_struct *q = diff_queued_diff;
struct combine_diff_path *p, **tail = curr;
@@ -81,35 +110,46 @@ static struct combine_diff_path *intersect_paths(struct
combine_diff_path *curr,
if (cmp 0) {
/* p-path not in q-queue[] */
- if (num_parent 2 2 - changed_parents(p, n) =
num_parent - n - 1) {
- /* still can get 2 changed parents */
+ if (dense
+ n == num_parent - 1
+ path_not_interesting(p, n, NULL)) {
+ /* only 1 unique different parent
+ not interesting change */
+ *tail = p-next;
+ free(p);
+ } else {
+ /* already has or still can get 2 changed
parents */
hashcpy(p-parent[n].oid.hash, p-oid.hash);
p-parent[n].mode = p-mode;
p-parent[n].status = ' ';
tail = p-next;
- } else {
- *tail = p-next;
- free(p);
}
continue;
- }
-
- if (cmp 0) {
+ } else if (cmp 0) {
/* q-queue[i] not in p-path */
- if (1 = num_parent - n - 1) {
- insert_path(tail, q-queue[i]-two-path, n,
num_parent, q-queue[i]);
+ if
Re: Requesting `git stash --cached` or something similar
On Mon, Apr 13, 2015 at 10:05:02PM -0400, Brandon McCaig wrote:
Trevor:
On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders tbsau...@tbsaunde.org
wrote:
I would expect the answers to be it sets the working directories state
to the state in HEAD, and leaves untracked files alone. If that's what
you want you can do git commit -m message; git reset --hard; git reset
--soft; git stash save to get the effect you want I believe. That said
it seems like a kind of odd thing to want to do, what are you actually
trying to do?
That looks like a bad solution. git reset --hard is going to throw
away any remaining changes to the working tree. The previous commit
git reset --hard is there to do *exactly* that, which I'm assuming is
the desired thing for a hypothetical git stash save --cached to do
because its consistant with what git stash save does.
would have committed the staged changes, albeit, you should connect
the commands with instead of ; to account for errors. After a `git
it should be clear this is not actual code to run exactly as written.
reset --hard' there's no point in doing a `git reset --soft' because
hard does *everything*. --soft would try to reset the HEAD without
touching the index or working tree, but both have already been reset
with --hard.
yes, that was supposed to be git reset --soft HEAD~ in which case it
does do something, and it is there exactly to just reset HEAD so that
git stash can then pick up the changes from the temporary commit.
The motivation is most likely stashing a few changes away so that you
can commit others that are ready to be committed while keeping others
around to continue working on them. This too is a good observation. It
yes, it could be they are looking for something like git stash --patch,
but maybe not we don't know.
could mean that the OP is inexperienced with a commit-often workflow.
You can use git -add -i or -p to commit the good stuff and keep the
bad stuff out to work on it more. The great thing about Git is that
the history is very malleable. You can also commit the bad and fix it
after, rebase the history to clean it up, and end up with perfect
history while still keeping your changes safely in history.
git stash also stores changes in the git database. However if you
really like the stack / queue type workflow you might want to consider
stgit or stacked git or something (I personally really dislike that work
flow so I'm not really familiar with those tools).
The OP should experiment with workflows because Git is already very
good at this. Stash isn't really needed. That said, I had forgotten
that --patch was added to stash some time ago so if that is what you
want then it already exists. It's not quite as easy as --cached, but
it still gives you some control. It's still not nearly as good as
using the full power of Git with a regular commit on a branch though.
good is subjective and depends on what you need to do. There are
certainly times where the stash is a good way to solve problems, and if
people have ideas for things they think it can do better that's great.
Trev
Regards,
--
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bambams.ca/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
--
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
--
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 4/4] t4059: rewrite to be adaptive to hunk filtering
On Sat, Apr 11, 2015 at 10:48:22PM -0700, Junio C Hamano wrote:
Max Kirillov m...@max630.net writes:
Rather, it should verify that file
selection behaves the same as hunk selection.
Hrm, really? git diff --raw and git diff -p -w on two trees
would not show identical set of paths, when the blob object are
different byte-wise but are equivalent at the content level per
given definition of equivalence (e.g. -w). Given that --cc is
to look at the differences at hunk/content level to combine and omit
uninteresting ones from the output, relative to -c output, I would
imagine that the file selection and the hunk selection are expected
to behave differently.
I mean, that if a hunk is shown in some long file, which
have other changes, with some option (-c or --cc), it should
also be shown if it is the only change in file.
So, having said that I am a bit skeptical about the description of
the goals, there are a few nits on the implementation, too.
+# the difference in short file must be returned if and only if it is shown
in long file
+for fn in win1 win2 merge delete base only1 only2 only1discard
only2discard; do
+ if git diff --cc merge branch1 branch2 mergebase -- long/$fn | grep -q
'^[ +-]\{3\}2\(change[12]|merge\)\?$'
+ then
Just like the earlier parts of this patch, write a newline when you
do not have to write a semicolon, and split lines after pipe when
your pipeline gets long, i.e.
for fn in win2 win2 ...
do
if git diff --cc ... |
grep 'pattern'
then
Do I smell some GNUism in your grep patterns?
You have
'^[ +-]\{3\}2\(change[12]|merge\)\?$'
but matching zero-or-one repetition with ? is not in BRE, and \? to
use it in BRE is a GNU extension.
Also in BRE , '|' is not an alternation (and making it into such
with '\|' in BRE is a GNU extension IIRC.
Worse, you are not using backslash here to invoke GNU extension, so
I suspect the grep invocations in the patch may not be working as
you expect.
Thank you, I missed it. I suspect it was working because
single 2 still matching. Will fix it and other issues.
--
Max
--
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] CodingGuidelines: update 'rough' rule count
Julian Gindi wrote: Changed inaccurate count of rough rules from three to the more generic 'a few'. Signed-off-by: Julian Gindi juliangi...@gmail.com Reviewed-by: Jonathan Nieder jrnie...@gmail.com 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
Re: When and how to to contact the Git developers (gist)
Thomas Ferris Nicolaisen tfn...@gmail.com writes: At the Dev Summit, I mentioned this gist I've got lined up for whenever someone should consider sending an email to this list: https://gist.github.com/tfnico/4441562 It's a handy link to share in some encounters, exemplified by Konstantin here: https://groups.google.com/d/msg/git-users/Md72iVvPHqw/Zi3yFIRrR2AJ I see that Peff already improved the git-scm.com/community late last year to cover some of the same points, but it is weighed a bit differently. Perhaps someone here would prefer to use my gist when redirecting people with user questions away from this list, or inspire them to write better bug reports. As to better bug reports, I often find people pointing others to http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Even in a better report that gives specific precondition, input, environment and output, sometimes I see one thing that is crucial missing: what the user expected to see and how the output is different from that expectation. Such a bug report may report the designed behaviour, leaving the developers to scratch their heads, yeah, thanks for a detailed write-up, we can reproduce it exactly, and everything is working as expected---how did you expect it to work in what different way and why?. -- 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] Re: Sneak peek of the upcoming Git for Windows 2.x
Hi Rupert, On Mon, Apr 13, 2015 at 1:51 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On 2015-04-11 10:37, rupert thurner wrote: * the prompt is still as slow as before, calculating the branch name on pressing return without option to turn it off There is no explicit option in the installer to turn it off, but you can easily edit `/etc/profile.d/git-prompt.sh` to adjust it to your liking. If you think that more people would want to have an option in the installer to switch it off, you should read https://github.com/git-for-windows/git/wiki/Making-an-installer, edit /usr/src/build-extra/installer/install.iss.in after having a look at https://github.com/git-for-windows/build-extra/commit/cbcf69b9 and open a Pull Request. Personally I edit it away from PS1: https://github.com/rctay/msysgit/commit/4038833505bc2c088524546e923d64d69c0fa37f -- Cheers, Ray Chuan -- 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: When and how to to contact the Git developers (gist)
On Mon, Apr 13, 2015 at 8:01 AM, Junio C Hamano gits...@pobox.com wrote: As to better bug reports, I often find people pointing others to http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Thanks, I've added it to the gist. It is already linked on http://git-scm.com/community . -- 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] Re: Sneak peek of the upcoming Git for Windows 2.x
On Sun, 12 Apr 2015 19:51:29 +0200 Johannes Schindelin johannes.schinde...@gmx.de wrote: [...] * it is talking german to me would it be sufficient to delete c:\Apps\gitwin\mingw64\share\locale\de\LC_MESSAGES\ resp the whole locale directory to let it speak english? Probably. But the canonical solution is to set the `LC_ALL` or `LANG` environment variables accordingly. JFTR, that won't probably fix `git gui` and `gitk` as they are started directly, not via shell scripts, and hence are unaffected by whatever tweaks are done in ~/.bashrc *unless* they're started from the interactive Git bash shell and hence see that environment. I would hence just stick LC_MESSAGES=en (or LC_ALL, or LANG) into the environment variables (on the user's level) and solve this problem once and for all future programs making use of Unix-y locale setup conventions. -- 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: Draft of Git Rev News edition 2
Hi Thomas, On 2015-04-12 22:51, Thomas Ferris Nicolaisen wrote: On Sun, Apr 12, 2015 at 9:03 PM, Christian Couder christian.cou...@gmail.com wrote: A draft of Git Rev News edition 2 is available here: https://github.com/git/git.github.io/blob/master/rev_news/draft/edition-2.md There's also a secret live preview here now: http://git.github.io/rev_news/draft/edition-2 Btw, I've just added a bunch of Git-related releases, including the Git for Windows RC and the Git 2.4 RC. Thanks! I also like the new look (no offense, Peff)! Ciao, Dscho -- 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: Installing git binaries on a non-default directory (Ubuntu)
Gianpaolo Macario gianpaolo_maca...@mentor.com writes: By some googling and after reading the git sources and the commit logs I assumed that the `RUNTIME_PREFIX` option (see https://github.com/git/git/blob/master/exec_cmd.c) was designed for that purpose, I do not think so. The standard procedure to stage into a temporary with make install and then make a tarball is done by using DESTDIR, e.g. something like $ make DESTDIR=/var/tmp/gittt ...other args... install $ tar zCf /var/tmp/gittt git-version.tar.gz -- 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
inexact rename detection warning on git log -p
Out of idle curiosity, I cloned git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and chose to generate some statistics: $ find -not -iname '.git' | wc 52154 52154 1820305 That's a few files... $ git log | wc 8359290 37279781 334525133 Hmmm, well that's not too useful, let's see how many commits there are: $ git log | grep ^commit | wc 507296 1014592 24350208 and merges: $ git log | grep ^Merge: | wc 36019 46 854397 I wonder what the total size of all changes are: $ git log --patch | wc warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 779 and retry the command. 93295818 366207219 3072072294 My bug report is in reference to the warning: It's not clear whether this warning just warns the user (hence the warning rather than an error) or whether it actually had an fault and didn't complete the operation successfully. It's also not clear whether the detection was aborted halfway through, or whether the work it has so far done has been discarded and is therefore idempotent if I *lowered* the renameLimit value (as opposed to raising it to fix the warning). Could the wording be changed to indicate that the operation continued without the rename detection? My preferred wording would be: warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 779 and retry the command. warning: continuing processing without inexact rename detection I'm a native English speaker and even I found the wording a little confusing -- although people used to gcc will know warning is informational and error is abortive, not all git users are aware of the distinction. Additionally, is the renameLimit something that could potentially be something dynamic (i.e. it inspects how much free RAM is available and increases the buffer if appropriate) or is that a conscious decision not to give the process free reign? Cheers, Matthew Walster -- 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 + SFC Status Update
Here are the slides from my talk at Git Merge, along with the speaker notes and a few tidbits from the discussion that came afterwards. The talk was not recorded, so if you were there, please feel free to fill in details I've missed from the ensuing discussion. I'm sending the source format, since it has the notes and is easy to package in an email. If anybody really wants the rendered result, I can try to stick it somewhere (or finally get around to publishing my nasty rendering scripts). -- 8 -- # Git + Software Freedom Conservancy Overview Jeff Kingbr Git Mergebr April 8th, 2015 --- # Background - Software Freedom Conservancy is a not-for-profit organization to promote and help FLOSS projects. - Git joined as a member project in 2010 (The Git Project) - Primary motivation: legally handle GSoC money --- # Background (continued) - Conservancy is as close as Git gets to being a legal entity (e.g., holding monetary assets) - Conservancy does _not_ hold copyrights or have any control over the code - decisions are made by agreement of committee (Junio Hamano, Jeff King, Shawn Pearce) --- # Activities so far - money handling (GSoC and beyond) - holding domain names (git-scm.com, git-scm.org) - we own a Mac! - Git trademark // Actually, we don't technically have control over git-scm.com yet. // Scott Chacon has several times agreed to transfer it to us, but we // have not gone through with the actual transfer. We should probably do // that, as well as move the Heroku hosting for the site over to the // project, just to address any potential continuity issues (people // being hit by buses, etc). // // The Mac was purchased with money that was donated by GitHub, and is // held by Tim Harper, who uses it to make the OS X packages that are // linked from git-scm.com. Technically we own it and can ask for it // when we like. --- # Trademark - Written policy: https://git-scm.com/trademark - Informal goals: - avoid people pretending to be (or endorsed by) official git - avoid calling non-interoperable things git - Many names are OK or grandfathered (e.g., JGit, libgit2, Gitolite, Gitorious) // We have trademark both on the name Git and on the diamond logo. // GitHub is also a trademark, held by (surprise!) GitHub. We have an // agreement that both are OK, not confusing, and neither side will // annoy the other by claiming trademark infringement. --- # Money: How much do we have? - $19,059.25 (USD) // Disclaimer: this is not necessarily up-to-the-minute, as // SFC's reports to us sometimes lag a bit. And also because // I am fairly inexperienced using the `ledger` program, so // it's possible I've misinterpreted the results. However, we // shouldn't have any serious outstanding expenses, so this // is close to correct. --- # Money: Where does it come from? - 10% of everything we take in goes to Conservancy general fund; these numbers are actual inputs to Git account - Donations ($6577); we do not actively solicit, but people want to give us money - GSoC ($7236); this includes travel reimbursement money which flows through the project account; I believe $5500 is mentor stipend - Amazon affiliate links ($4255) - Packt Publishing royalties ($1724) // Disclaimer: these numbers were generated from a number of queries // that I performed manually against the ledger file. It's entirely // possible that I ended up missing some sources or double-counting // others. So please take the numbers as approximations, and if // somebody really wants to carefully audit the numbers, I can share // the source data. --- # Money: Where does it go? - Travel ($3692); all to GSoC mentor summit + GitTogether - Stickers ($135) - Trademark fees ($875); note that these are USPTO fees. The legal labor is provided by Conservancy. // Similar disclaimer on accuracy. // // The stickers were printed by me and handed out at a GSoC Mentor // Summit in 2011. --- center # Now what? That's the current state. Where do we want to go from here? --- # Governance (1/3) - Are we happy with the leadership structure? - Control of the project is held by committee, including power to remove or add people to committee. - Internal structure is up to us, not Conservancy. - Solicited opinions in 2010, and this is what we got. - Democracy is a hassle? - Still happy? // Keep in mind again that this is just The Git Project, holding // the money and any other assets. Not copyright on code, and with // no power over the day-to-day of the technical sides of the project. // // The current structure is essentially benevolent-committee-for-life. // We ended up with that because it was the simplest thing, and it // did not really seem to matter to anybody to do anything different. // I'm of the opinion that this is still the case, but I want to make it // clear that we are free to discuss alternatives without resorting to // violent revolution.
Re: [WIP/RFH/PATCH 3/3] t/lib-git-svn: adjust config to apache 2.4
Jeff King venit, vidit, dixit 10.04.2015 05:39: On Fri, Apr 10, 2015 at 05:23:17AM +0200, Jeff King wrote: Curiously, though, the git-svn tests seem to run fine for me on Apache 2.4 without your patch. I wonder if the fixes I mentioned above (which I definitely needed to get the regular http tests running on Debian back then) are not necessary on my system anymore (e.g., because the apache2 package now ships with better-compatible config). Ah, I see. I am not in fact running apache. If you do not set SVN_HTTPD_PORT (which I don't), then lib-git-svn.sh's start_httpd silently returns success without bothering to setup the apache server at all. And yet the rest of the tests run to completion just fine. Yep. It looks like setting this variable is a way to say run the same set of tests, but do it over svn-over-httpd instead of svn's direct filesystem access. Setting SVN_HTTPD_PORT does cause the tests to fail for me. Oh, I didn't even notice that. That's a bit weird. I don't know how important it is to run these tests over httpd. If so, it would be nice to do something like lib-httpd does: try the apache setup by default, and if it fails, gracefully skip the tests (or fallback to the non-httpd version). I'm also not sure if there's value in running both the httpd and local-filesystem forms of the test. IOW, should we be factoring out the tests and having two separate scripts that set $svnrepo as appropriate, and then runs the tests? -Peff Hmm, if those tests are run (with file://) I'm inclined to leave things as they are (scratch 3/3)... Though the fact that on my system, lib-git-svn starts the server but fails to connect isn't overly comforting. But git-svn is being used less and less. World domination is almost complete. Michael -- 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: Installing git binaries on a non-default directory (Ubuntu)
Hello Juno,
Gianpaolo Macario gianpaolo_maca...@mentor.com writes:
By some googling and after reading the git sources and the commit logs
I assumed that the `RUNTIME_PREFIX` option (see
https://github.com/git/git/blob/master/exec_cmd.c) was designed for
that purpose,
I do not think so.
The standard procedure to stage into a temporary with make install
and then make a tarball is done by using DESTDIR, e.g. something like
$ make DESTDIR=/var/tmp/gittt ...other args... install
$ tar zCf /var/tmp/gittt git-version.tar.gz
[Macario, Gianpaolo] Thanks for your reply.
Unfortunately it looks to me that the `--prefix=xxx` option provided to
configure will be hardcoded to the path returned by 'git --exec-path', and I do
not see how this may actually be made dependent on the directory where the
binary tarball will be extracted.
How should I configure/make git to have `install_path/bin/git --exec-path`
return a path which depends on `install_path` rather than what provided to
`./configure` ?
I tried the following
$ mkdir -p ~/tmp
$ cd ~/tmp
$ wget http://kernel.org/pub/software/scm/git/git-2.3.5.tar.gz
$ tar -xvzf git-2.3.5.tar.gz
$ cd git-2.3.5
$ ./configure --prefix= \
--with-curl --with-openssl --without-tcltk \
CFLAGS=${CFLAGS} `pkg-config --static --libs libcurl`
$ make
$ make DESTDIR=/var/tmp/gittt install
$ cd /var/tmp/gittt
$ tar -cvzf ~/git-install-2.3.5.tar.gz .
$ cd
$ rm -rf ~/tmp/git-2.3.5
$ rm -rf /var/tmp/gittt
then extracted the tarball
$ sudo mkdir -p /opt/tools
$ sudo chown $USER /opt/tools
$ cd /opt/tools
$ tar -xvzf ~/git-install-2.3.5.tar.gz
This is the result when executing
$ /opt/tools/bin/git --exec-path
/libexec/git-core
I wanted to have it return `/opt/tools/libexec/git-core` instead.
If I do not specify any `--prefix=xxx` when running `./configure`, this
defaults to `/usr/local` which is not good either.
Thanks in advance, and apologies if I am doing something stupid...
Gianpaolo
--
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] gitweb: Update logo and favicon
Thomas Schneider thosc...@gmail.com wrote: The new images were downloaded from https://git-scm.herokuapp.com/downloads/logos and converted with ImageMagick: convert -resize 72x30 Git-Logo-2Color.eps git-logo.png convert -resize 16x16 Git-Icon-1788C.eps git-favicon.png The old logo was only 27 pixels in height, the 3 additional pixels are necessary for the slightly different aspect ratio of the new one. This is a good improvement :-) I did something similar for the logos on my installation of gitweb, including exactly the same command to create the favicon. https://git.csx.cam.ac.uk/x/ucs/git/gitcam.git/blob/HEAD:/bin/make-icons.sh I think it is a bad idea to change the height of the logo: gitweb generates an img src element with a fixed 72x27 size, and the gitweb.conf documentation suggests that site admins can replace the logo with a custom one of the same size. My version of the new logo includes a bit of horizontal padding so that it matches this specification. (The higher-resolution icons are used by my server's documentation pages but not by gitweb.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames: Northwest backing south or southwest later, 4 or 5, occasionally 6 later. Slight or moderate. Fair. Moderate or good. -- 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] reduce progress updates in background
On Mon, Apr 13, 2015 at 10:11:09AM -0400, Nicolas Pitre wrote: | What if you suspend the task and push it into the background? Would be | nice to inhibit progress display in that case, and resume it if the task | returns to the foreground. That's what happens; the suppression only occurs if the process is currently background. If I start a long-running operation (such as git fsck), the progress is displayed. I then suspend background, and the progress is suppressed. If I resume the process in the foreground, the progress starts to display again at the appropriate point. In the proposed patch, the stop_progress display for a given progress (i.e. the one that ends in , done.) is displayed even if in the background so that there's some indication of progress. E.g. Checking object directories: 100% (256/256), done. Checking objects: 100% (184664/184664), done. Checking connectivity: 184667, done. This is the test 'if (is_foreground || done)'. I'm not 100% happy with my choice here, and the simpler behaviour of suppress all background progress output can be achieved by removing '|| done' from those two tests. That still doesn't suppress _all_ output whilst in the background. In order to do that, a larger refactor of various warning methods would be required. I would argue that's a separate orthoganal fix. | Also the display() function may be called quite a lot without | necessarily resulting in a display output. Therefore I'd suggest adding | in_progress_fd() to the if condition right before the printf() instead. That's an easy enough change to make (although I speculate that the testing of the foreground status is not that big a performance issue, especially compared the the existing performance overhead of printing the progress to stderr then forcing a flush :) Should I submit a revised patch with (1) call in_progress_fd() just before the fprintf() as requested, and (2) suppress all display output including the done call. ? regards, Luke. pgpTyBk7RgIJs.pgp Description: PGP signature
Re: Finding leaf nodes.
Jason Pyeron venit, vidit, dixit 12.04.2015 06:04:
I am trying to find all the unmerged commits [5].
Unmerged to which branch?
It's not clear to me which commits you are looking for. By leaf node I
would describe a commit without child commits. unmerged can only be
understood relative to a specific branch.
Maybe you are looking for commits from remote refs which are not on any
local branch?
I can find, as a human, all the commits by git log --oneline --graph --all
[1] but I am looking for a scripted way.
But git show-branch -a --independent misses some [2]
This finds refs which are not contained in (can be reached from) any
of the other refs. If a remote ref is contained in another remore ref it
is not listed.
find .git/refs/ -type f -exec cat '{}' ';' | sort -u; finds too much [3].
This finds all refs.
The closest I get is with refs=`git show-ref -s`; git log --format=%H $refs
--not $(echo $refs | sed 's/$/^/') but it too [4] gives me extra, but I am
really not sure why.
This finds all commits which are on some ref (branch/tag/..), excluding
those which are next to the tip or higher up from those refs.
* | a54a4fb
* | a0d2e63
* | dd4400d
| | * 68ea2c8
| | |\
| |/ /
|/| |
| | * c74d3c5 ??? Why is this the only extra commit listed ???
Because it is not next to the tip, more specifically: not a first
parent (foo^) of a referenced commit, and neither a predecessor of one.
| |/
|/|
* | 9c87570
* | 717e33d
* | 159799f
What should I do to automate this?
Please try and restate what you mean by unmerged commits. Maybe remote
commits not on any local branch, or remote commits not on master?
1:
0748f668b7fe0cba7a0edf1684ae84ddf87104ee
13916782bebe690149bfd1c3fb31d6d08942585b
383f3ae77393c2e303b3c32ef7dee122f0b623be
473093c214ba578cd7aecb6e2e5caaad70d173e4
4d0579c438e9d750f158124284bd740a5a0e0e26
68ea2c83978a7c023d76ebe438dd7d98fb1fd074
6900b076d790593a909bc84a1d062217e4a32941
9802bc44da0a35e4c7a917cd23468c387897cccd
982243cfde0dc6dfb1733d8e95748b7e687f57b8
c197b7f71cd6d601b99adbe0a5cf5bf6bc749b6e
c4bc3c4eb0015c73b50ea280a4a380e3cffc5160
c5234422373d0425fa9cd610cb0848b7c33fe436
d6af1c103b0cdeb7e7d45ffce2a838fa7a287aea
eb50b82c6f3f55b66693482a913a5c1cfc19a03d
f9c41c1a17df4358558a23a7c45bc2c60bf97e27
Fb962761aa2ce6fbf77e4769c9e418bbe6f9f47f
2:
4d0579c438e9d750f158124284bd740a5a0e0e26
68ea2c83978a7c023d76ebe438dd7d98fb1fd074
982243cfde0dc6dfb1733d8e95748b7e687f57b8
C4bc3c4eb0015c73b50ea280a4a380e3cffc5160
3:
00ea00e8e6a23a4243316f860aa07ed59203ab97
144eb9f673f14010c600766762b99cba1a64cc6e
2250af4ad29b92b07365320c5ccb7a22c17f588e
26bdfdfe71f7ceb4e0954bc5ab6c198481a280ae
283be0f77477fcd8c8bc878c602538f8a3451403
2f47330df8fb0357ef4e4d605d5c402150892a18
3ec60ab0dbdc63760429187605ede4549d7b2bad
43813b0fc44f7c41d2cdd4573145dbeb1aae1aee
4d5b52d440d3a64953a6d7ef3cbb81c8d289e392
556a5c2d759b51080e3bfe07a89b67e927749328
6fe0b6db2718625e5eeb3cbadeb58aa858ab4f1b
717e33d67ad3297a15cb432d3f70f7c12d353fa3
7587a45658aa689cc774d7253007be3feb2eec23
ad9b5fa90c8f52b3ca31dd433c2c4b408e5f2a8f
b3d7623b74dd75cc4f965d6b37dc461d2786f912
c19fc45c87de85122952d63d28a0c7d3a18b79d5
e8529e95d89d3f519a31ef7de5bd7f0d0d318e8c
f2e86371e7fe3391023adccd61856d088db773dd
fceca0050ceee8c4996a5740f7122e96c4948dd8
4:
c74d3c5cda60d8be7f38f1ec89c554a1346d57f8
5: My remotes:
https://github.com/CipherShed/CipherShed.git
https://github.com/pdinc-oss/CipherShed.git
https://github.com/discnl/CipherShed.git
https://github.com/eaglgenes101/CipherShed.git
https://github.com/erkinalp/CipherShed.git
https://github.com/GigabyteProductions/CipherShed.git
https://github.com/jeffallen/CipherShed.git
https://github.com/kaydiechii/CipherShed.git
https://github.com/srguglielmo/CipherShed.git
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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] reduce progress updates in background
On Mon, 13 Apr 2015, Luke Mewburn wrote: Hi, I've noticed that when a long-running git operation that generates progress output is suspended and converted to a background process, the terminal still gets spammed with progress updates (to stderr). Many years ago I fixed a similar issue in the NetBSD ftp progress bar code (which I wrote). I've experimented around with a couple of different solutions, including: 1. suppress all progress output whilst in the background 2. suppress in progress updates whilst in the background, but display the done message even if in the background. In both cases, warnings were still output to the terminal. I've attached a patch that implements (2) above. If the consensus is that all progress messages should be suppressed, I can provide the (simpler) patch for that. I've explicitly separated the in_progress_fd() function so that it's easier to (a) reuse elsewhere where appropriate, and (b) make any portability changes to the test if necessary. I also used getpgid(0) versus getpgrp() to avoid portability issues with the signature in the latter with pre-POSIX. A minor optimisation could be to pass in struct progress * and to cache getpgid(0) in a member of struct progress in start_progress_delay(), since this value shouldn't change during the life of the process. What if you suspend the task and push it into the background? Would be nice to inhibit progress display in that case, and resume it if the task returns to the foreground. Also the display() function may be called quite a lot without necessarily resulting in a display output. Therefore I'd suggest adding in_progress_fd() to the if condition right before the printf() instead. Nicolas -- 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] reduce progress updates in background
Hi,
I've noticed that when a long-running git operation that generates
progress output is suspended and converted to a background process,
the terminal still gets spammed with progress updates (to stderr).
Many years ago I fixed a similar issue in the NetBSD ftp progress
bar code (which I wrote).
I've experimented around with a couple of different solutions, including:
1. suppress all progress output whilst in the background
2. suppress in progress updates whilst in the background,
but display the done message even if in the background.
In both cases, warnings were still output to the terminal.
I've attached a patch that implements (2) above.
If the consensus is that all progress messages should be suppressed,
I can provide the (simpler) patch for that.
I've explicitly separated the in_progress_fd() function
so that it's easier to (a) reuse elsewhere where appropriate,
and (b) make any portability changes to the test if necessary.
I also used getpgid(0) versus getpgrp() to avoid portability
issues with the signature in the latter with pre-POSIX.
A minor optimisation could be to pass in struct progress *
and to cache getpgid(0) in a member of struct progress
in start_progress_delay(), since this value shouldn't change
during the life of the process.
regards,
Luke.
From 843a367bac87674666dafbaf7fdb7d6b0e1660f7 Mon Sep 17 00:00:00 2001
From: Luke Mewburn l...@mewburn.net
Date: Mon, 13 Apr 2015 23:30:51 +1000
Subject: [PATCH] progress: no progress in background
Disable the display of the progress if stderr is not the
current foreground process.
Still display the final result when done.
Signed-off-by: Luke Mewburn l...@mewburn.net
---
progress.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/progress.c b/progress.c
index 412e6b1..8094404 100644
--- a/progress.c
+++ b/progress.c
@@ -72,9 +72,15 @@ static void clear_progress_signal(void)
progress_update = 0;
}
+static int is_foreground_fd(int fd)
+{
+ return getpgid(0) == tcgetpgrp(fd);
+}
+
static int display(struct progress *progress, unsigned n, const char *done)
{
const char *eol, *tp;
+ const int is_foreground = is_foreground_fd(fileno(stderr));
if (progress-delay) {
if (!progress_update || --progress-delay)
@@ -98,16 +104,21 @@ static int display(struct progress *progress, unsigned n,
const char *done)
unsigned percent = n * 100 / progress-total;
if (percent != progress-last_percent || progress_update) {
progress-last_percent = percent;
- fprintf(stderr, %s: %3u%% (%u/%u)%s%s,
- progress-title, percent, n,
- progress-total, tp, eol);
- fflush(stderr);
+ if (is_foreground || done) {
+ fprintf(stderr, %s: %3u%% (%u/%u)%s%s,
+ progress-title, percent, n,
+ progress-total, tp, eol);
+ fflush(stderr);
+ }
progress_update = 0;
return 1;
}
} else if (progress_update) {
- fprintf(stderr, %s: %u%s%s, progress-title, n, tp, eol);
- fflush(stderr);
+ if (is_foreground || done) {
+ fprintf(stderr, %s: %u%s%s,
+ progress-title, n, tp, eol);
+ fflush(stderr);
+ }
progress_update = 0;
return 1;
}
--
2.3.5.dirty
pgp9CkCjLO94G.pgp
Description: PGP signature
Re: [PATCH v3] CodingGuidelines: update 'rough' rule count
Changed inaccurate count of rough rules from three to the more generic 'a few'. Signed-off-by: Julian Gindi juliangi...@gmail.com --- Documentation/CodingGuidelines | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 0f8cccf..2dd35bd 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -1,5 +1,5 @@ Like other projects, we also have some guidelines to keep to the -code. For Git in general, three rough rules are: +code. For Git in general, a few rough rules are: - Most importantly, we never say It's in POSIX; we'll happily ignore your needs should your system not conform to it. -- 2.3.5 -- 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
assert failed in submodule edge case
Reported by djanos_ in #git: git add segfaults when you manage to confuse it with a submodule in the index that is no longer a submodule. Here's his script to reproduce the segfault: mkdir segfault cd segfault mkdir subrepo cd subrepo git init . echo a a git add a git commit -m a cd .. git init . git add . cd subrepo rm -rf .git git add . This last git add will now barf: git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. These all work as I think they are intended to: $ git -C segfault add subrepo/a fatal: Pathspec 'subrepo/a' is in submodule 'subrepo' $ git -C segfault/subrepo add a fatal: Pathspec 'a' is in submodule 'subrepo' And this does nothing, it also doesn't crash: $ git -C segfault add subrepo GDB backtrace below, this is with next as of e6f3401. Starting program: /home/dennis/code/git/git -C segfault/subrepo add . [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. Program received signal SIGABRT, Aborted. 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7702c528 in __GI_abort () at abort.c:89 #2 0x77023ce6 in __assert_fail_base (fmt=0x77173c08 %s%s%s:%u: %s%sAssertion `%s' failed.\n%n, assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:92 #3 0x77023d92 in __GI___assert_fail (assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:101 #4 0x004d6a37 in prefix_pathspec (elt=0x7fffdaf1 ., prefixlen=8, prefix=0x7dd09f subrepo/, flags=50, raw=0x7fffd648, p_short_magic=synthetic pointer, item=optimized out) at pathspec.c:316 #5 parse_pathspec (pathspec=pathspec@entry=0x7fffd240, magic_mask=magic_mask@entry=0, flags=flags@entry=50, prefix=prefix@entry=0x7dd09f subrepo/, argv=argv@entry=0x7fffd648) at pathspec.c:417 #6 0x0040698c in cmd_add (argc=optimized out, argv=0x7fffd648, prefix=0x7dd09f subrepo/) at builtin/add.c:370 #7 0x00406001 in run_builtin (argv=0x7fffd640, argc=2, p=0x79d740 commands) at git.c:350 #8 handle_builtin (argc=2, argv=0x7fffd640) at git.c:532 #9 0x00405151 in run_argv (argv=0x7fffd458, argcp=0x7fffd43c) at git.c:578 #10 main (argc=2, av=optimized out) at git.c:686 I dig a bit into pathspec.c and it looks like the PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE code in prefix_pathspec is only stripping out paths inside the submodule, not the submodule itself. I also guess that it shouldn't as otherwise you can't ever 'git add' a submodule. So I have no idea how to proceed, or even what the correct behaviour of 'git add' should be in this case. I do think that failing an assert() to tell a user he's doing something unexpected/silly/wrong isn't the right thing to do though :) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: assert failed in submodule edge case
Err, ignore the 'segfault' bits. It's an assert() failure. He called it a segfault at first and that got stuck in my head. On ma, 2015-04-13 at 18:55 +0200, Dennis Kaarsemaker wrote: Reported by djanos_ in #git: git add segfaults when you manage to confuse it with a submodule in the index that is no longer a submodule. Here's his script to reproduce the segfault: mkdir segfault cd segfault mkdir subrepo cd subrepo git init . echo a a git add a git commit -m a cd .. git init . git add . cd subrepo rm -rf .git git add . This last git add will now barf: git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. These all work as I think they are intended to: $ git -C segfault add subrepo/a fatal: Pathspec 'subrepo/a' is in submodule 'subrepo' $ git -C segfault/subrepo add a fatal: Pathspec 'a' is in submodule 'subrepo' And this does nothing, it also doesn't crash: $ git -C segfault add subrepo GDB backtrace below, this is with next as of e6f3401. Starting program: /home/dennis/code/git/git -C segfault/subrepo add . [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. Program received signal SIGABRT, Aborted. 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7702c528 in __GI_abort () at abort.c:89 #2 0x77023ce6 in __assert_fail_base (fmt=0x77173c08 %s%s%s:%u: %s%sAssertion `%s' failed.\n%n, assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:92 #3 0x77023d92 in __GI___assert_fail (assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:101 #4 0x004d6a37 in prefix_pathspec (elt=0x7fffdaf1 ., prefixlen=8, prefix=0x7dd09f subrepo/, flags=50, raw=0x7fffd648, p_short_magic=synthetic pointer, item=optimized out) at pathspec.c:316 #5 parse_pathspec (pathspec=pathspec@entry=0x7fffd240, magic_mask=magic_mask@entry=0, flags=flags@entry=50, prefix=prefix@entry=0x7dd09f subrepo/, argv=argv@entry=0x7fffd648) at pathspec.c:417 #6 0x0040698c in cmd_add (argc=optimized out, argv=0x7fffd648, prefix=0x7dd09f subrepo/) at builtin/add.c:370 #7 0x00406001 in run_builtin (argv=0x7fffd640, argc=2, p=0x79d740 commands) at git.c:350 #8 handle_builtin (argc=2, argv=0x7fffd640) at git.c:532 #9 0x00405151 in run_argv (argv=0x7fffd458, argcp=0x7fffd43c) at git.c:578 #10 main (argc=2, av=optimized out) at git.c:686 I dig a bit into pathspec.c and it looks like the PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE code in prefix_pathspec is only stripping out paths inside the submodule, not the submodule itself. I also guess that it shouldn't as otherwise you can't ever 'git add' a submodule. So I have no idea how to proceed, or even what the correct behaviour of 'git add' should be in this case. I do think that failing an assert() to tell a user he's doing something unexpected/silly/wrong isn't the right thing to do though :) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: inexact rename detection warning on git log -p
Matthew Walster venit, vidit, dixit 13.04.2015 12:47: Out of idle curiosity, I cloned git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and chose to generate some statistics: $ find -not -iname '.git' | wc 52154 52154 1820305 git ls-files | wc -l That's a few files... $ git log | wc 8359290 37279781 334525133 ?? Hmmm, well that's not too useful, let's see how many commits there are: $ git log | grep ^commit | wc 507296 1014592 24350208 git rev-list --count HEAD and merges: $ git log | grep ^Merge: | wc 36019 46 854397 git rev-list --count --merges HEAD I wonder why people are so found of wc. I wonder what the total size of all changes are: $ git log --patch | wc That counts quite a bit more than just patch lines: Boiler plate, log messages, diff headers. warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 779 and retry the command. 93295818 366207219 3072072294 My bug report is in reference to the warning: It's not clear whether this warning just warns the user (hence the warning rather than an error) or whether it actually had an fault and didn't complete the operation successfully. It's also not clear whether the detection was aborted halfway through, or whether the work it has so far done has been discarded and is therefore idempotent if I *lowered* the renameLimit value (as opposed to raising it to fix the warning). Could the wording be changed to indicate that the operation continued without the rename detection? My preferred wording would be: warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 779 and retry the command. warning: continuing processing without inexact rename detection I'm a native English speaker and even I found the wording a little confusing -- although people used to gcc will know warning is informational and error is abortive, not all git users are aware of the distinction. was skipped and without foo sound pretty similar to me. But what's worse: continue processing without foo creates the impression that all further processing is done without foo, which is a bit misleading: in fact, foo was skipped for at least one diff. So I think the original is closer to the truth. Additionally, is the renameLimit something that could potentially be something dynamic (i.e. it inspects how much free RAM is available and increases the buffer if appropriate) or is that a conscious decision not to give the process free reign? I think it's more about time than memory. Note that this is quadratic in the number of files. If you want to take a shot at an automatic setting: grepping for rename_limit (especially needed_rename_limit and diff_rename_limit_default) will give you some pointers. Michael -- 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 4/5] t4202-log: add tests for --merges=
From: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
t/t4202-log.sh | 29 +
1 file changed, 29 insertions(+)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..3edcd81 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -270,6 +270,35 @@ cat expect \EOF
* initial
EOF
+test_expect_success 'setup merges=' '
+ git log --min-parents=2 --pretty=tformat:%s expect_only
+ git log --max-parents=1 --pretty=tformat:%s expect_hide
+ git log --min-parents=-1 --pretty=tformat:%s expect_show
+'
+
+test_log_merges() {
+ expect=expect_$1
+ config=${2:+-c log.merges=$2}
+ option=${3:+--merges=$3}
+ option=${4:-$option}
+ test_expect_success merges${config:+ $config}${option:+ $option}
+ git $config log $option --pretty=tformat:%s actual
+ test_cmp $expect actual
+
+}
+
+states=show only hide
+for c in '' $states
+do
+ for o in '' $states
+ do
+ test_log_merges ${o:-${c:-show}} $c $o
+ done
+done
+
+test_log_merges hide show '' --no-merges
+test_log_merges only hide '' '--merges --max-parents=2'
+
test_expect_success 'log --graph with merge' '
git log --graph --date-order --pretty=tformat:%s |
sed s/ *\$// actual
--
2.3.3.263.g095251d.dirty
--
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/5] revision: add --merges={show|only|hide} option
From: Junio C Hamano gits...@pobox.com
Add a new option 'merges=' with possible values of 'only', 'show' and
'hide'. The option is used when showing the list of commits. The value
'only' lists only merges. The value 'show' is the default behavior
which shows the commits as well as merges and the value 'hide' makes it
just list commit items.
[kk: chose names for options; wrote commit message]
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
revision.c | 20
revision.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/revision.c b/revision.c
index 6399a04..c3c3dcc 100644
--- a/revision.c
+++ b/revision.c
@@ -1678,6 +1678,23 @@ static void add_message_grep(struct rev_info *revs,
const char *pattern)
add_grep(revs, pattern, GREP_PATTERN_BODY);
}
+int parse_merges_opt(struct rev_info *revs, const char *param)
+{
+ if (!strcmp(param, show)) {
+ revs-min_parents = 0;
+ revs-max_parents = -1;
+ } else if (!strcmp(param, only)) {
+ revs-min_parents = 2;
+ revs-max_parents = -1;
+ } else if (!strcmp(param, hide)) {
+ revs-min_parents = 0;
+ revs-max_parents = 1;
+ } else {
+ return -1;
+ }
+ return 0;
+}
+
static int handle_revision_opt(struct rev_info *revs, int argc, const char
**argv,
int *unkc, const char **unkv)
{
@@ -1800,6 +1817,9 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
revs-show_all = 1;
} else if (!strcmp(arg, --remove-empty)) {
revs-remove_empty_trees = 1;
+ } else if (starts_with(arg, --merges=)) {
+ if (parse_merges_opt(revs, arg + 9))
+ die(unknown option: %s, arg);
} else if (!strcmp(arg, --merges)) {
revs-min_parents = 2;
} else if (!strcmp(arg, --no-merges)) {
diff --git a/revision.h b/revision.h
index 0ea8b4e..f9df58c 100644
--- a/revision.h
+++ b/revision.h
@@ -240,6 +240,7 @@ extern int setup_revisions(int argc, const char **argv,
struct rev_info *revs,
extern void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t
*ctx,
const struct option *options,
const char * const usagestr[]);
+extern int parse_merges_opt(struct rev_info *, const char *);
#define REVARG_CANNOT_BE_FILENAME 01
#define REVARG_COMMITTISH 02
extern int handle_revision_arg(const char *arg, struct rev_info *revs,
--
2.3.3.263.g095251d.dirty
--
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 5/5] bash-completion: add support for git-log --merges= and log.merges
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
contrib/completion/git-completion.bash | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index fbe5972..a75d7f5 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1406,7 +1406,7 @@ _git_ls_tree ()
__git_log_common_options=
--not --all
--branches --tags --remotes
- --first-parent --merges --no-merges
+ --first-parent --merges --merges= --no-merges
--max-count=
--max-age= --since= --after=
--min-age= --until= --before=
@@ -1451,7 +1451,11 @@ _git_log ()
__gitcomp long short ${cur##--decorate=}
return
;;
- --*)
+ --merges=*)
+ __gitcomp show hide only ${cur##--merges=}
+ return
+ ;;
+ --*)
__gitcomp
$__git_log_common_options
$__git_log_shortlog_options
@@ -1861,6 +1865,10 @@ _git_config ()
__gitcomp $__git_log_date_formats
return
;;
+ log.merges)
+ __gitcomp show hide only
+ return
+ ;;
sendemail.aliasesfiletype)
__gitcomp mutt mailrc pine elm gnus
return
@@ -2150,6 +2158,7 @@ _git_config ()
interactive.singlekey
log.date
log.decorate
+ log.merges
log.showroot
mailmap.file
man.
--
2.3.3.263.g095251d.dirty
--
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/5] Documentation: add git-log --merges= option and log.merges config. var
From: Junio C Hamano gits...@pobox.com
[kk: added documentation in git-log.txt]
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
Documentation/git-log.txt | 3 +++
Documentation/rev-list-options.txt | 17 +
2 files changed, 20 insertions(+)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 18bc716..e16f0f8 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -190,6 +190,9 @@ log.showRoot::
`git log -p` output would be shown without a diff attached.
The default is `true`.
+log.merges::
+Default for `--merges=` option. Defaults to `show`.
+
mailmap.*::
See linkgit:git-shortlog[1].
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index f620ee4..88f152f 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -96,6 +96,23 @@ if it is part of the log message.
--remove-empty::
Stop when a given path disappears from the tree.
+--merges={show|hide|only}::
+
+ Limit the output by type of commits.
+
+ `hide`;;
+ Hide merge commits from the output.
+
+ `only`;;
+ Hide non-merge commits from the output (i.e showing
+ only merge commits).
+
+ `show`;;
+ Do not hide either merge or non-merge commits. This
+ is primarily useful when the user has non-standard
+ setting of `log.merges` configuration variable that
+ needs to be overriden from the command line.
+
--merges::
Print only merge commits. This is exactly the same as `--min-parents=2`.
--
2.3.3.263.g095251d.dirty
--
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: Finding leaf nodes.
-Original Message-
From: Michael J Gruber
Sent: Monday, April 13, 2015 10:23
Jason Pyeron venit, vidit, dixit 12.04.2015 06:04:
I am trying to find all the unmerged commits [5].
Unmerged to which branch?
All. I was atempting to describe a leaf node.
It's not clear to me which commits you are looking for. By
leaf node I
would describe a commit without child commits. unmerged can only be
That is exactly what I meant.
understood relative to a specific branch.
Maybe you are looking for commits from remote refs which are
not on any
local branch?
Anywhere, that I know about. If the commit does not have a child, then that
commit needs to be in the list, I do not care about the branches.
I can find, as a human, all the commits by git log
--oneline --graph --all [1] but I am looking for a scripted way.
But git show-branch -a --independent misses some [2]
This finds refs which are not contained in (can be reached from) any
of the other refs. If a remote ref is contained in another
remore ref it
is not listed.
Your description is logical, but how can a commit be included in another
remote ref?
find .git/refs/ -type f -exec cat '{}' ';' | sort -u; finds
too much [3].
This finds all refs.
I know, the issue is I do not know how to filter it.
The closest I get is with refs=`git show-ref -s`; git log
--format=%H $refs --not $(echo $refs | sed 's/$/^/') but it
too [4] gives me extra, but I am really not sure why.
This finds all commits which are on some ref (branch/tag/..),
excluding
those which are next to the tip or higher up from those refs.
* | a54a4fb
* | a0d2e63
* | dd4400d
| | * 68ea2c8
| | |\
| |/ /
|/| |
| | * c74d3c5 ??? Why is this the only extra commit listed ???
Because it is not next to the tip, more specifically: not a first
parent (foo^) of a referenced commit, and neither a
predecessor of one.
I need to think on what you just said for this one.
| |/
|/|
* | 9c87570
* | 717e33d
* | 159799f
What should I do to automate this?
Please try and restate what you mean by unmerged commits.
Maybe remote
commits not on any local branch, or remote commits not on master?
Regardless of branch references, I need to list all commits which do not have
any child commits.
1:
See: yellow lines at
http://client.pdinc.us/git-leaf-nodes-334e98c075877ce78b1ef959cb1155f7.html
2:
4d0579c438e9d750f158124284bd740a5a0e0e26
68ea2c83978a7c023d76ebe438dd7d98fb1fd074
982243cfde0dc6dfb1733d8e95748b7e687f57b8
C4bc3c4eb0015c73b50ea280a4a380e3cffc5160
3:
00ea00e8e6a23a4243316f860aa07ed59203ab97
144eb9f673f14010c600766762b99cba1a64cc6e
2250af4ad29b92b07365320c5ccb7a22c17f588e
26bdfdfe71f7ceb4e0954bc5ab6c198481a280ae
283be0f77477fcd8c8bc878c602538f8a3451403
2f47330df8fb0357ef4e4d605d5c402150892a18
3ec60ab0dbdc63760429187605ede4549d7b2bad
43813b0fc44f7c41d2cdd4573145dbeb1aae1aee
4d5b52d440d3a64953a6d7ef3cbb81c8d289e392
556a5c2d759b51080e3bfe07a89b67e927749328
6fe0b6db2718625e5eeb3cbadeb58aa858ab4f1b
717e33d67ad3297a15cb432d3f70f7c12d353fa3
7587a45658aa689cc774d7253007be3feb2eec23
ad9b5fa90c8f52b3ca31dd433c2c4b408e5f2a8f
b3d7623b74dd75cc4f965d6b37dc461d2786f912
c19fc45c87de85122952d63d28a0c7d3a18b79d5
e8529e95d89d3f519a31ef7de5bd7f0d0d318e8c
f2e86371e7fe3391023adccd61856d088db773dd
fceca0050ceee8c4996a5740f7122e96c4948dd8
4:
c74d3c5cda60d8be7f38f1ec89c554a1346d57f8
5: My remotes:
https://github.com/CipherShed/CipherShed.git
https://github.com/pdinc-oss/CipherShed.git
https://github.com/discnl/CipherShed.git
https://github.com/eaglgenes101/CipherShed.git
https://github.com/erkinalp/CipherShed.git
https://github.com/GigabyteProductions/CipherShed.git
https://github.com/jeffallen/CipherShed.git
https://github.com/kaydiechii/CipherShed.git
https://github.com/srguglielmo/CipherShed.git
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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 1/7] path.c: implement xdg_config_home()
Hi Paul, maybe it would be a good idea to add a `0/7` mail that describes the overall goal of this patch series, much like a Pull Request? I found it very useful -- even for myself -- to set a description via `git branch --edit-description` and to let `git format-patch` use that via the `--cover-letter` option. below just two minor nits because the rest of the patches looks fine to me: On 2015-04-12 09:46, Paul Tan wrote: diff --git a/cache.h b/cache.h index 3d3244b..7f9bab0 100644 --- a/cache.h +++ b/cache.h @@ -836,6 +836,13 @@ char *strip_path_suffix(const char *path, const char *suffix); int daemon_avoid_alias(const char *path); extern int is_ntfs_dotgit(const char *name); +/** + * Returns the newly allocated string $XDG_CONFIG_HOME/git/%s. If + * $XDG_CONFIG_HOME is unset or empty, returns the newly allocated string + * $HOME/.config/git/%s. Returns NULL if an error occurred. + */ +extern char *xdg_config_home(const char *fn); Should this not be inserted close to home_config_paths()? Also, the name fn sounds more like function than like filename to me, especially keeping the name `config_fn_t` in mind. Maybe call the parameter filename to avoid confusion? Thanks, Dscho -- 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] reduce progress updates in background
On Tue, 14 Apr 2015, Luke Mewburn wrote: On Mon, Apr 13, 2015 at 10:11:09AM -0400, Nicolas Pitre wrote: | What if you suspend the task and push it into the background? Would be | nice to inhibit progress display in that case, and resume it if the task | returns to the foreground. That's what happens; the suppression only occurs if the process is currently background. If I start a long-running operation (such as git fsck), the progress is displayed. I then suspend background, and the progress is suppressed. If I resume the process in the foreground, the progress starts to display again at the appropriate point. I agree. I was just comenting on your suggestion about caching the in_progress_fd() result which would prevent that. In the proposed patch, the stop_progress display for a given progress (i.e. the one that ends in , done.) is displayed even if in the background so that there's some indication of progress. E.g. Checking object directories: 100% (256/256), done. Checking objects: 100% (184664/184664), done. Checking connectivity: 184667, done. This is the test 'if (is_foreground || done)'. Yes. And I think this is nice. | Also the display() function may be called quite a lot without | necessarily resulting in a display output. Therefore I'd suggest adding | in_progress_fd() to the if condition right before the printf() instead. That's an easy enough change to make (although I speculate that the testing of the foreground status is not that big a performance issue, especially compared the the existing performance overhead of printing the progress to stderr then forcing a flush :) Sure. But what I'm saying is that progress() may be called a thousand times and only one or two of those calls will result in an actual print-out. So it is best to test the foreground status only at that point. Should I submit a revised patch with (1) call in_progress_fd() just before the fprintf() as requested, and (2) suppress all display output including the done call. ? I'd suggest (1) but not (2). Nicolas -- 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 + SFC Status Update
Thanks for the report, and thanks to everyone on the committee (and the conservancy). I'm somewhat disappointed to see that violent revolutions are excluded, though ;) Seriously, keeping the scope of The Git Project (the SCF member) as limited as it is seems to be the best approach to keeping it as hasslefree and fucntional as it is. Michael -- 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/5] log: honor log.merges= option
From: Junio C Hamano gits...@pobox.com
The config. variable is honored only by log. Other log family commands
including show, shortlog and rev-list are affected only from the
equivalent command line option (i.e. --merges=). Since these commands
are somehow different representations of log command, we like to have
the same behavior from them as we do from log itself. However, to not
break the default output of them, we do not consider the the config.
var. Other log-family commands format-patch and cherry ignore the option
altogether (i.e. both on command line and on config settings).
[kk: wrote commit message]
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
builtin/log.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..c7a7aad 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -36,6 +36,7 @@ static int decoration_given;
static int use_mailmap_config;
static const char *fmt_patch_subject_prefix = PATCH;
static const char *fmt_pretty;
+static const char *log_merges;
static const char * const builtin_log_usage[] = {
N_(git log [options] [revision range] [[--] path...]),
@@ -386,6 +387,9 @@ static int git_log_config(const char *var, const char
*value, void *cb)
decoration_style = 0; /* maybe warn? */
return 0;
}
+ if (!strcmp(var, log.merges)) {
+ return git_config_string(log_merges, var, value);
+ }
if (!strcmp(var, log.showroot)) {
default_show_root = git_config_bool(var, value);
return 0;
@@ -628,6 +632,8 @@ int cmd_log(int argc, const char **argv, const char *prefix)
init_revisions(rev, prefix);
rev.always_show_header = 1;
+ if (log_merges parse_merges_opt(rev, log_merges))
+ die(unknown config value for log.merges: %s, log_merges);
memset(opt, 0, sizeof(opt));
opt.def = HEAD;
opt.revarg_opt = REVARG_COMMITTISH;
--
2.3.3.263.g095251d.dirty
--
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 commit --date format
Hi, In git 2.0, git commit --amend --date= can amend commit with current time as author time. But since git 2.0, this does not work, dying with invalid date format. I have to instead type git commit --amend --date=now. Is empty string date format no longer supported? Or will be fixed? -- 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
