Re: [BUG] git-rebase: reword squashes commits in case of merge-conflicts

2018-06-15 Thread ch

On 12.06.2018 12:08, Jeff King wrote:

> Thanks for a thorough report. I couldn't reproduce it on v2.17.1 on
> Linux, which makes me wonder if the issue is related to git-for-windows
> somehow. To the best of my knowledge (and a quick scan of "git diff"
> results) the code should be the same, though.

I gave native Git version 2.17.1 on Ubuntu 18.04 (no WSL this time) a try
and was able to reproduce the issue outlined in my first email.

In case there is a misunderstanding, when I wrote

On 11.06.2018 18:06, ch wrote:

> After the rebase the 'stuff' branch only has a single commit even though I'd
> expect there to be two according to the instructions that were passed to
> git-rebase.

I actually meant that there's only a single commit exclusively reachable
from 'stuff' after the rebase, i.e.

  $ git log stuff ^master

only lists a single commit while there actually should be two unless I'm
missing something.

Sorry for being a bit sloppy in my initial report.

- ch


[BUG] git-rebase: reword squashes commits in case of merge-conflicts

2018-06-11 Thread ch

Hi all!

During a recent rebase operation on one of my repositories a number of commits
unexpectedly ended up getting squashed into other commits. After some
experiments it turned out that the 'reword' instruction seems to squash the
referenced commit into the preceding commit if there's a merge-conflict.

Here's a small reproduction recipe to illustrate the behavior:

  1. Create a small test repository using the following Bash script:


function add_file()
{
echo "$1" > "$2"
git add "$2"
git commit -m "$3"
}

git init .

add_file "test" "file-1" "master"

git checkout -b stuff

add_file "aaa" "file-2" "feature_a"
add_file "bbb" "file-2" "fixup! feature_a"
add_file "ccc" "file-2" "fixup! feature_a"

add_file "ddd" "file-2" "feature_b"
add_file "eee" "file-2" "fixup! feature_b"
add_file "fff" "file-2" "fixup! feature_b"


  2. Run

   $ git rebase --autosquash --interactive --onto master master stuff

 to interactively rebase 'stuff' onto 'master'. This should generate the
 following todo-stream:


pick ... feature_a
fixup ... fixup! feature_a
fixup  fixup! feature_a
pick  feature_b
fixup ... fixup! feature_b
fixup ... fixup! feature_b


  3. Remove the fixup line right before the second pick (i.e. 'fixup ')
 in order to enforce a merge-conflict later when applying commit .

  4. Replace the second pick instruction (i.e. 'pick ') with a reword.

  5. Launch the rebase operation. It should fail at the 'reword '
 instruction due to a merge-conflict.

  6. Resolve the conflict by taking the remote-side (i.e. 'ddd'), add the
 change to the index with git-add and run

   $ git rebase --continue

 This should spawn the commit message editor and after saving and quitting
 the rebase should finish cleanly.

After the rebase the 'stuff' branch only has a single commit even though I'd
expect there to be two according to the instructions that were passed to
git-rebase. It works as expected if there's either no merge-conflict at the
reword or if the conflicting commit is applied as 'pick'.

I'm running git version 2.17.1.windows.2. I also tried native git version 2.7.4
via WSL (running Ubuntu 16.04.4 LTS) and this version does not exhibit this
behavior.

- ch


INFO

2017-11-13 Thread GORD CH
I have important transaction for you as next of kin to claim US$8.37m  email me 
at changgordo...@yahoo.com.hk so I can send you more 

details


Re: Add --ignore-missing to git-pack-objects?

2017-08-20 Thread ch

Hi Jeff.

Thanks a lot for your response.

Jeff King wrote:


So if I understand correctly, you are only using these for the negative
side of the traversal?


Yes.

Jeff King wrote:


rev-list should ignore missing objects in such a
case even without --ignore-missing, and I think it may simply be a bug
if pack-objects is not.

Do you have a simple reproduction recipe?


Here's a small bash script to illustrate the core issue:


add_file()
{
echo "$1" > "$1"
git add "$1"
git commit -m "$1"
}

git init .
git config core.logAllRefUpdates false

add_file "test-1"
add_file "test-2"

git checkout -b feature

add_file "test-3"
add_file "test-4"

git checkout master

add_file "test-5"
add_file "test-6"

feature_tip=$(git rev-list -1 feature)

echo -e "\nDeleting branch 'feature' ($feature_tip)..."
git branch -D feature
git gc --prune=now

echo -e "\nCalling git-pack-objects with (now deleted) ^$feature_tip..."
git pack-objects --all --revs --stdout --thin --delta-base-offset --all-progress-implied 
<<< ^$feature_tip > pack

echo -e "\nCalling git-rev-list with (now deleted) ^$feature_tip..."
git rev-list --all ^$feature_tip

echo -e "\nCalling git-rev-list --ignore-missing with (now deleted) 
^$feature_tip..."
git rev-list --all --ignore-missing ^$feature_tip


Both, git-pack-objects and git-rev-list (without --ignore-missing) fail with

fatal: bad object 

on git version 2.14.1.windows.1.


Add --ignore-missing to git-pack-objects?

2017-08-14 Thread ch

Hi.

Is it possible to add an option akin to git-rev-list's '--ignore-missing' to
git-pack-objects?

I use git bundles to (incrementally) backup my repositories. My script inspects
all bundles in the backup and passes their contained refs as excludes to
git-pack-objects to build the pack for the new bundle. This works fine as long
as none of these refs have been garbage-collected in the source repository.
Something like '--ignore-missing' would be really handy here to ask
git-pack-objects to simply ignore any of the passed revs that are not present
(anymore).

Thanks in advance.


Passing revs to git-bundle-create via stdin

2017-05-22 Thread ch

Hi,

I'm using git bundles to create (incremental) backups of my local repositories.
This works quite well but for certain repositories I'm getting unexpectedly big
incremental bundles. I did some testing and from what I can tell it seems
git-bundle-create has issues processing revs passed via stdin. To illustrate
the problem I have included a small bash script below.

I'm using Git for Windows 2.13.0.windows.1 (64-bit). Unfortunately I don't have
access to a non-Windows box to check whether it's a problem specific to the
Windows port.


add_file()
{
echo "$1" > "$1"
git add "$1"
git commit -m "$1"
}

git init .

add_file "test-1"
add_file "test-2"
add_file "test-3"

git checkout -b feature
add_file "test-4"
add_file "test-5"
add_file "test-6"

git checkout master
add_file "test-7"
add_file "test-8"
add_file "test-9"

echo -e "\nCreating test.git..."
git bundle create test.git --all ^feature ^master^

echo -e "\nCreating test-stdin.git..."
echo -e "^feature\n^master^\n" | git bundle create test-stdin.git --all --stdin

echo -e "\nCreating test-2.git..."
git bundle create test-2.git --all ^feature^ ^master^

echo -e "\nCreating test-2-stdin.git..."
echo -e "^feature^\n^master^\n" | git bundle create test-2-stdin.git --all 
--stdin

echo -e "\nCreating test-3-stdin.git..."
echo -e "feature\nmaster\n" | git bundle create test-3-stdin.git --stdin

echo
git branch -D feature
git tag -am "Annotated tag" annotated-tag master~2

echo -e "\nCreating annotated.git..."
git bundle create annotated.git --all ^annotated-tag

echo -e "\nCreating annotated-stdin.git..."
echo -e "^annotated-tag\n" | git bundle create annotated-stdin.git --all --stdin

echo
git tag -d annotated-tag
git tag lightweight-tag master~2
echo -e "\nCreating lightweight-stdin.git..."
echo -e "^lightweight-tag\n" | git bundle create lightweight-stdin.git --all 
--stdin


I'd expect test.git and test-stdin.git to be identical. In fact the contained-
and required-refs lists of both bundles are equal but the pack in
test-stdin.git is notably larger compared to the one in test.git. Interestingly
test-2.git and test-2-stdin.git are identical.

git-bundle-create does not appear to handle includes properly either. In this
specific case it won't create test-3-stdin.git and dies with
'error: Refusing to create empty bundle.'.

Last but not least git-bundle-create includes annotated-tag in
annotated-stdin.git even though the tag is excluded via stdin. It works alright
if the tag is excluded via commandline like in case of annotated.git. The issue
also seems to be specific to annotated tags as lightweight-tag is properly
excluded from lightweight-stdin.git.

Any help would be appreciated.

Thanks in advance.


my private

2014-12-09 Thread Blauw-Hospers CH, Cornill




My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust 
you with a business worth $8.3M USD? Please reply ONLY to my private email: 
mga...@rogers.commailto:mga...@rogers.com for more information
--
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