Re: Why "You cannot combine --squash with --no-ff" in git merge?
Hi All, I made a mistake in the previous message. I'm really sorry, I need to go have some sleep right now. Anatoly Borodin <anatoly.boro...@gmail.com> wrote: > `git merge --squash --ff` will happily move the A ref to the B commit. > > But what I want, and expect, is: > > A---B' > > where B' has the same tree as B. `git merge --squash --ff` WILL create A---B'. But it's still unclear to me why `git merge --squash --no-ff` should fail instead of doing the same as `git merge --squash --ff` does. The error message and the documentation do not give any good reasons for it. PS In my case, I set `merge.ff=false` and run just `git merge --squash`. -- Mit freundlichen Grüßen, Anatoly Borodin
Why "You cannot combine --squash with --no-ff" in git merge?
Hi All,
the message "You cannot combine --squash with --no-ff" appeared in 2008,
in the commit 1c7b76be7d620bbaf2e6b8417f04012326bbb9df ("Build in
merge"). I don't understand the logic of this restriction.
Imagine, I have the following branches, where A is a master and B is a
feature branch:
A---B1---B2---B3---B4---B
`git checkout A && git merge --squash --no-ff B` says:
fatal: You cannot combine --squash with --no-ff.
`git merge --squash --ff` will happily move the A ref to the B commit.
But what I want, and expect, is:
A---B'
where B' has the same tree as B.
This can of course be done with `git rebase --interactive` and marking
all commits for squash or fixup. But `git merge --squash` works with
not-fastforwarding feature branch, why should it refuse to work in a
fastforwarding case?
--
Mit freundlichen Grüßen,
Anatoly Borodin
gitk bug: file select in the tree mode
Hi All! There is a bug in gitk (e.g. 2.11.0): 1) Choose a repository with files in a subdir (git's repo for example). 2) `cd` to a subdir (e.g. `xdiff`). 3) Run `gitk`. 4) Select 'Tree' in the 'Patch / Tree' panel. 5) Select any file with 'Highlight this too' or 'Highlight this only' (e.g `xmerge.c`). 6) See the short file name (`xmerge.c`) instead of the full path (`xdiff/xmerge.c`) in the 'Find commit touching path:' edit field. No commits touching the file can be found. -- Mit freundlichen Grüßen, Anatoly Borodin
git-archive and submodules
Hi All, are there plans to add submodules support to git-archive? -- Mit freundlichen Grüßen, Anatoly Borodin
Re: git branches & merge
Hi, the IP will not be overwritten, you'll still have the new IP in master. Nothing to worry about :) -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Feature Request: user defined suffix for temp files created by git-mergetool
Hi Josef, On Mon, Oct 3, 2016 at 8:36 AM, Josef Ridky <jri...@redhat.com> wrote: > In several projects, we are using git mergetool for comparing files from > different folders. > Unfortunately, when we have opened three files for comparing using meld tool > (e.q. Old_version -- Result -- New_version), > we can see only name of temporary files created by mergetool in the labels > (e.g. foo_REMOTE -- foo_BASE -- foo_LOCAL) > and users (and sometime even we) are confused, which of the files should they > edit and save. `git mergetool` just creates temporary files (with some temporary names) and calls `meld` (or `vimdiff`, etc) with the file names as parameters. So why wouldn't you call `meld` with the file names you want? -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Setting pager.add=true breaks add --patch
Hi Ravi, I've reported this one bug recently: https://public-inbox.org/git/nrmbrl$hsk$1...@blaine.gmane.org/ The developers know about it, but it will require some deeper refactoring. -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Two bugs in --pretty with %C(auto)
Hi René, On Thu, Sep 29, 2016 at 8:13 PM, René Scharfe <l@web.de> wrote: > Reverts the change to t6006, so we'd need another test for this. > Anatoly? :) I've checked my example commands and couldn't find any regressions. -- Mit freundlichen Grüßen, Anatoly Borodin
git-pack-objects(1): --honor-pack-keep
Hi All, the option `--honor-pack-keep` is not mentioned in the `SYNOPSIS` of `git-pack-objects(1)` (`Documentation/git-pack-objects.txt`), only below in the `OPTIONS`. The same story with `--include-tag`, `--window-memory`, `--max-pack-size`, `--no-reuse-object`, `--compression`, `--thin`, `--threads`, and `--index-version`. Is it a mistake, or different options should be treated differently, like, often used vs. seldom used? But as far as I can see, `--honor-pack-keep` is used pretty often by `git gc`. PS The `--non-empty` block is indented with whitespaces, should it be corrected? -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Limitiations of git rebase --preserve-merges --interactive
Hi Kevin, Kevin Daudt <m...@ikke.info> wrote: > Changing the order, or dropping commits might then give unexpected > results. The question that Stefan has is rather "what is *supposed* to work / give *expected* results?". Some stuff can be found in the tests (t/t*rebase*preserve*), but maybe there is more? -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Limitiations of git rebase --preserve-merges --interactive
Hi Stefan, I've also done some archaeology and found that the original version of the merge preserving code was written by Johannes Schindelin <johannes.schinde...@gmx.de>, see e.g. f09c9b8c5ff9d8a15499b09ccd6c3e7b3c76af77 There were also some big discussion threads in 2007-2008 regarding a better mechanism to "mark" or "tag" the heads of rebased branches, but I haven't seen consensus and development in that direction after that. PS There are also some pieces of "what should work" in these tests: t/t3409-rebase-preserve-merges.sh* t/t3410-rebase-preserve-dropped-merges.sh* t/t3411-rebase-preserve-around-merges.sh* t/t3414-rebase-preserve-onto.sh* -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Limitiations of git rebase --preserve-merges --interactive
Hi Stefan, this section was added to the manual in the commit cddb42d2c58a9de9b2b5ef68817778e7afaace3e by "Jonathan Nieder" <jrnie...@gmail.com> 6 years ago. Maybe he remembers better? -- Mit freundlichen Grüßen, Anatoly Borodin
Bug? Short command line options
Hi All, is there a good reason why git fetch -vpnf works like git fetch -v -p -n -f and git commit -avem msg works like git commit -a -v -e -m msg etc etc, but git log -wWp says fatal: unrecognized argument: -wWp ? -- Mit freundlichen Grüßen, Anatoly Borodin
Re: .git directory tree as tar-file
Hi Martin, if multiple small loose files are the problem, this could be interesting for you: https://git-scm.com/docs/git-gc This command is run automatically from time to time, and you can configure it or run manually. PS To see how bad the situation is, you can use https://git-scm.com/docs/git-count-objects -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Bug: pager. doesn't work well with editors
> I think, the pagination should be turned off when the editor is being > called. ... even if the `[-p|--paginate]` option is used explicitly. Is there a case when pagination shouldn't be ignored with an editor? `git -p -c core.editor=gvim config -e` works, but the pagination is not effective. `git -p -c core.editor=vim config -e` doesn't work and wants to be killed. I've tested it on FreeBSD and Linux, have no idea, how it works on Mac or Windows. -- Mit freundlichen Grüßen, Anatoly Borodin
Bug: pager. doesn't work well with editors
Hi All! It can be useful to enable `pager.branch`, `pager.tag`, `pager.config`, etc for some projects (`git` itself can be a good example, with all its feature branches and tags). But it makes commands like `git branch --edit-description`, `git tag -a`, `git config -e` extremely unhappy. For example, `vim` says Vim: Warning: Output is not to a terminal and then becomes unusable (just as `vim | less` would be). I think, the pagination should be turned off when the editor is being called. -- Mit freundlichen Grüßen, Anatoly Borodin
Re: Two bugs in --pretty with %C(auto)
Hi René! On Sat, Sep 17, 2016 at 8:25 PM, René Scharfe <l@web.de> wrote: > I'm not sure how just how automatic %C(auto) is supposed to be, but you > expected it do emit the reset for you, right? Sounds reasonable to me. I don't see a good reason not to do so. Spare some bytes?.. > The following patch implements that behavior. Thanks, the patch works great! -- Mit freundlichen Grüßen, Anatoly Borodin
Re: [wishlist] disable boring messages
Hi! Alexander Inyukhin <shur...@sectorb.msk.ru> wrote: > I have a lot of repos and a batch script to update them all, > and I want to get rid of 'Fetching origin' and 'Already up-to-date.' > messages leaving only new refs and tags. There is an option `-q`, but it's too silent :) As far as I can see, `git fetch` prints 'Fetching origin' etc to stdout, and new refs/tags to stderr (don't ask me why). So git fetch blabla > /dev/null should probably do the job. Now, if you collect and save those logs, you may need some shell-fu to redirect that stderr to stdout, but not to /dev/null. Something like (git fetch blabla > /dev/null) 2>&1 (run `git fetch` in a subshell)... -- Mit freundlichen Grüßen, Anatoly Borodin
Two bugs in --pretty with %C(auto)
Hi All!
First bug:
git log -3 --pretty='%C(cyan)%C(auto)%h%C(auto)%d %s'
prints %h with the default color (normal yellow), but
git log -3 --pretty='%C(bold cyan)%C(auto)%h%C(auto)%d %s'
shows %h with bold yellow, as if only the color was reset, but not
the attributes (blink, ul, reverse also work this way). %d and %s are
printed with the right color both times.
Second bug, maybe related to the first one:
git log -3 --pretty='%C(bold cyan)%h%C(auto)%d %s %an %h %h %s'
The first line looks as expected. Well, almost: the '(' of %d is bold
yellow.
The second line looks like this:
* %h, %s, %an with bold cyan;
* %h with bold yellow;
* %h with normal yellow and %s with normal white (default colors).
PS git version 2.9.2
--
Mit freundlichen Grüßen,
Anatoly Borodin
Re: Potentially misleading color.* defaults explanation in git-config(1)
Hi! Matthieu Moy <matthieu@grenoble-inp.fr> wrote: > My bad, I forgot to update these parts of the docs when changing the > default for color.ui (a while back already). Patch follows. Thanks for the patch! > git -c color.branch=false git branch Oh, that's a nice one! I don't get a chance to use those between-git-and-command options often. Merci! -- Mit freundlichen Grüßen, Anatoly Borodin
Potentially misleading color.* defaults explanation in git-config(1)
Hi All! git-config(1) says: color.branch A boolean to enable/disable color in the output of git-branch(1). May be set to always, false (or never) or auto (or true), in which case colors are used only when the output is to a terminal. Defaults to false. If the value false is the default, and neither color.branch nor color.ui is set in any config file, one can expect that (1) git branch and (2) git config color.branch false ; git branch produce the same result. But only (2) produces colorless output, (1) uses colors (that probably depend on the default value of color.ui). The same story with color.diff and git-show, color.grep, etc. Is it me being a non-native English speaker, or does this part really need to be rewritten? PS git version 2.9.3 -- Mit freundlichen Grüßen, Anatoly Borodin
Re: git show -m with a parent number
Hi! Jeff King <p...@peff.net> wrote: > For the first one, showing all diffs is what I want. For the second, it > only makes sense to for the first parent case, as following other > parents would zig-zag through history. Lucky you! :) You probably don't need to inspect 9 month old ex-svn branches with sync (i.e. 'trunk'->'feature') merges *-...-*-...-*-...-*-...-*---trunk \ \ \ \ / *-...-*-...-*-...-*-...-*---feature (Not to forget some funny legacy inter-feature merges.) It's not like `git diff X^2 X` is a big problem, but too much of a copypaste. The other thing that bugs me is that you can easily `git cherry-pick -m 2 X`, but to see the diff that you are going to apply is not that trivial. > But perhaps you have some other use case in mind. In cases like these, I > think it is a good idea to implement the feature, and run with it for a > while, seeing how it can be used. And then if it proves useful, post the > patch to the list describing your experiences. I'll try. BTW, should it be like '-m[=parent]' for consistency, or '-m [parent]' is ok? PS Another idea: '-m parent' makes sence in a normal, 2-branch merge. But what to do in a case of an octopus merge? In a normal case I can treat '-m 2' as 'the diff regarding the second parent', but also as 'the changes contributed by the first parent (plus "evil")'. But with 3 and more branches '-m 3' means 'the changes from 1 and 2'. Would it be possible to get only the contribution from the second or third parent in this case? Yeah, I know, there is `git diff parent1...parent3` etc, but not all the changes from parent3 will always get to the merge commit. -- Mit freundlichen Grüßen, Anatoly Borodin -- 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 show -m with a parent number
Hi All, is there a good reason for `git show -m` to not accept the number of a parent of a merge commit? I can run `git show --first-parent COMMIT`, but need to write `git diff COMMIT^2 COMMIT` every time I want to diff with the second parent! `git cherry-pick -m 2 COMMIT` works, so why can't `git log` work like that? -- Mit freundlichen Grüßen, Anatoly Borodin -- 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
A different bug in git-filter-branch (v2.7.0)
Hi Jeff,
unfortunately, `--tree-filter true` doesn't solve the problem with the
repo at my work: not all old blobs are replaced with the new ones. I've
made a test repository to demonstrate it; it's a huge one (115M), but I
couldn't make it much smaller, because the bug fails to reproduce if the
repo is not big enough:
https://github.com/anatolyborodin/git-filter-branch-bug
There are some description and instructions in `README.md`. I hope you
will be able to reproduce it on your machine, if not - just add more
files :)
I've debugged the test case and found the place where `git diff-index`
behaves differently regarding `aa/bb.dat`:
read-cache.c +351 ie_match_stat():
...
if (!changed && is_racy_timestamp(istate, ce)) {
if (assume_racy_is_modified)
changed |= DATA_CHANGED;
else
changed |= ce_modified_check_fs(ce, st);
}
...
After `git-checkout-index` the blob hash for `aa/bb.dat` in the index is
88a0f09b9b2e4ccf2faec89ab37d416fba4ee79d (the huge binary), but the file
on disk is a text file "This file was to big, and it has been removed."
with the hash 16e0939430610600301680d5bf8a24a22ff8b6c4.
In the case of a "good behaving" commit, the timestamps of the index and
the cache entry are the same, is_racy_timestamp() returns 1, and
ce_modified_check_fs() finds that the content of the file has changed.
`git diff-index` lists the file `aa/bb.dat`.
In the case of a "bad behaving" commit, the timestamps of the index and
the cache entry are different (the index is 1 second newer),
is_racy_timestamp() returns 0, and the file is assumed unchanged; `git
diff-index` prints nothing.
I don't know if it should be considered to be a bug in in the logic of
`git checkout-index`, or `git diff-index` / `git update-index`.
--
Mit freundlichen Grüßen,
Anatoly Borodin
--
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: Bugs in git filter-branch (git replace related)
Hi Jeff, I've created a gist with the script https://gist.github.com/anatolyborodin/6505a364a68584f13846 I've added some changes and a second test (will be discussed in the comments). Jeff King <p...@peff.net> wrote: > I'm not sure if this is a bug or not. The "empty commit" check works by > checking the tree sha1s, without doing a full diff respecting replace > refs. > > You're expecting git to notice a tree change, even though it never even > examined the tree in the first place (because you didn't give it a tree > or index filter). When git-filter-branch(1) says "If you have any grafts or replacement refs defined, running this command will make them permanent.", and it doesn't work like that because of some optimization, it *is* a bug. > Try: > > git filter-branch --prune-empty --tree-filter true master > > which will force git to go through the motions of checking out the > replaced content and re-examining it. Thank you, I've added this command to the script, and it works! I think it should be added to git-filter-branch(1), if there is no other way to rewrite the optimization. >> Bug 2: the replace refs are not ignored (they can epresent blobs, trees etc, >> but even if they represent commits - should they be rewritten?). > > You told it "--all", which is passed to rev-list, where it means "all > refs". I agree that running filter-branch on refs/replace is probably > not going to yield useful results, but I'm not sure if it is > filter-branch's responsibility to second-guess the rev-list options. Look how `git log --all` works (see the second test in the script): it ignores (without any messages) the blobs, and writes only the commits. For example, the same commit log message is printed twice in the second testcase. Maybe it makes sence, I don't know. I would suggest that all refs/replace/* heads should be ignored by `git log`. `git rev-list --no-replace` maybe? > Probably the documentation for filter-branch should recommend > "--branches --tags" instead of "--all", though. Or redefine `--all` as "all refs excepting refs/replace/*". Who would really want to run `--all` the way it works now? The blobs replaces should be ignored, as in `git log --all`. Is there any reason to rewrite refs/rebase/hash if it's a replace commit? -- Mit freundlichen Grüßen, Anatoly Borodin -- 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: Gitignore file exceptions are not applied to untarcked files
Hi Junio, I've tested it with many older versions of git, as well as with the recent v2.7.0 - it seems like this feature has been never working properly. The script https://gist.github.com/anatolyborodin/9c581b50c584534fff28 #!/bin/sh set -e # a # b # c # D/a # D/b # D/c # E/F/a # E/F/b # E/F/c mkdir -p D E/F touch a b c D/a D/b D/c E/F/a E/F/b E/F/c echo && echo '.gitignore' && echo '--' echo '*\n!b\n!D/b\n!/D/b\n!/E/*/b' > .gitignore cat .gitignore echo && echo 'With `--ignored`' && echo '--' git status --ignored echo && echo 'Without `--ignored`' && echo '--' git status The output: .gitignore -- * !b /D/b !/D/b !/E/*/b With `--ignored` -- On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) b Ignored files: (use "git add -f ..." to include in what will be committed) .gitignore D/ E/ a c nothing added to commit but untracked files present (use "git add" to track) Without `--ignored` -- On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) b nothing added to commit but untracked files present (use "git add" to track) All files in the subdirectories are ignored, no matter what. -- Mit freundlichen Grüßen, Anatoly Borodin -- 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
Bugs in git filter-branch (git replace related)
Hi All! There are two bugs in `git filter-branch`, present in the most recent versions (d10e2cb9d0299a26f43d57dd5bdcf2b3f86a30b3), as well as in the old ones (I couldn't find a version where it works properly). The script: #!/bin/sh set -e GIT_EXEC_PATH=/tmp/git export GIT_EXEC_PATH GIT=$GIT_EXEC_PATH/git rm -rf a mkdir a cd a $GIT init echo aaa > a.txt && $GIT add a.txt && $GIT commit -a -m a echo bbb > a.txt && $GIT add a.txt && $GIT commit -a -m b echo ccc > a.txt && $GIT add a.txt && $GIT commit -a -m c $GIT replace f761ec192d9f0dca3329044b96ebdb12839dbff6 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 echo && echo One && $GIT filter-branch --prune-empty -- master echo && echo Two && $GIT filter-branch --prune-empty -- --all The output is: ... One Rewrite 98af0305b778bf56e25a0d4f85acdf82f435f9b3 (3/3) (0 seconds passed, remaining 0 predicted) WARNING: Ref 'refs/heads/master' is unchanged Two Rewrite 98af0305b778bf56e25a0d4f85acdf82f435f9b3 (3/3) (0 seconds passed, remaining 0 predicted) WARNING: Ref 'refs/heads/master' is unchanged error: object 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 is a blob, not a commit error: object 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 is a blob, not a commit fatal: ambiguous argument 'refs/replace/f761ec192d9f0dca3329044b96ebdb12839dbff6^0': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' WARNING: Ref 'refs/replace/f761ec192d9f0dca3329044b96ebdb12839dbff6' is unchanged The `git replace` makes the second commit empty (use the file content from the first commit). It should disappear after `git filter-branch`, but it doesn't happen. Bug 1: the empty commit stays. Bug 2: the replace refs are not ignored (they can epresent blobs, trees etc, but even if they represent commits - should they be rewritten?). Any ideas? PS I've found http://article.gmane.org/gmane.comp.version-control.git/220931 , seems like the bug 1. But it's old! -- 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
