(unknown)

(unknown)

[Michael Dressel]

>Michael Dressel wrote:
>Ok nice. Another thing is that git-push will push all the tracking 
>branches in refs/remotes/origin. 

I learned that I only have to edit the .git/config file to avoid that 
git-push pushes everything. 

I modified the remotes names and added push lines explicitly.

Is that the recommended way?

In my example (git-branch -a -v):
* exp                 aa854c6 shtest 4
  master              34924b9 mastertest 1
  origin/exp          aa854c6 shtest 4
  origin/master       b68e7a9 brt master 1

I used the following .git/config:
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin1"]
        url = /home/repo/src
        fetch = +refs/heads/master:refs/remotes/origin/master
        push = +refs/heads/master:refs/heads/master
[remote "origin2"]
        url = /home/repo/src
        fetch = +refs/heads/exp:refs/remotes/origin/exp
        push = +refs/heads/exp:refs/heads/exp
[branch "master"]
        remote = origin1
        merge = refs/heads/master
[branch "exp"]
        remote = origin2
        merge = refs/heads/exp

Cheers,
Michael

Re: (no subject)

[Johannes Schindelin]

Hi,

On Sun, 11 Nov 2007, Michael Dressel wrote:

> 
> >Michael Dressel wrote:
> >Ok nice. Another thing is that git-push will push all the tracking 
> >branches in refs/remotes/origin. 
> 
> I learned that I only have to edit the .git/config file to avoid that 
> git-push pushes everything. 

It is documented that you can use "git push origin <branchname>".

> [remote "origin1"]
>         url = /home/repo/src
>         fetch = +refs/heads/master:refs/remotes/origin/master
>         push = +refs/heads/master:refs/heads/master

With "push", it is not necessary to specify the ":<target>".

Also, if "master" is unambiguous, you can write just "master" instead of 
"refs/heads/master".

Furthermore, I suggest not forcing (that's  what "+" does) the push, since 
it is quite possible that you push something old in the wrong direction.  

Hth,
Dscho

Re: cogito remote branch

[MichaelTiloDressel]

(I forgot to put the subject previously)

> Johannes Schindelin wrote:
>Hi,

>On Sun, 11 Nov 2007, Michael Dressel wrote:

>> 
>> >Michael Dressel wrote:
>> >Ok nice. Another thing is that git-push will push all the tracking 
>> >branches in refs/remotes/origin. 
>> 
>> I learned that I only have to edit the .git/config file to avoid that

>> git-push pushes everything. 

>It is documented that you can use "git push origin ".

>> [remote "origin1"]
>>         url = /home/repo/src
>>         fetch = +refs/heads/master:refs/remotes/origin/master
>>         push = +refs/heads/master:refs/heads/master

>With "push", it is not necessary to specify the ":".
So just a line like
             push = master

A push is needed somewhere in order to prevent every remote to be pushed
by default,
right?

>Also, if "master" is unambiguous, you can write just "master" instead
of 
>"refs/heads/master".

>Furthermore, I suggest not forcing (that's  what "+" does) the push,
since 
>it is quite possible that you push something old in the wrong
direction.  

O.k. I will reconsider this.

Cheers,
Michael

Re: cogito remote branch

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, MichaelTiloDressel@t-online.de wrote:

> So just a line like
>              push = master

Exactly.

> A push is needed somewhere in order to prevent every remote to be pushed 
> by default, right?

You mean a "push" config variable?  No.  I think I mentioned in my first 
reply that

	git push <remote> <branch>...

works quite wonderfully.

Hth,
Dscho

Re: cogito remote branch

[MichaelTiloDressel]

Johannes Schindelin wrote:

>> A push is needed somewhere in order to prevent every remote to be
pushed 
>> by default, right?

>You mean a "push" config variable?  No.  I think I mentioned in my
first 
>reply that

>	git push  <remote> <branch>...

>works quite wonderfully.

I mean a push = .. line in the [remote <name>] block.
And if there is such a line than git-push without arguments will push
only
the current branch. For me that is nice, because if I forgot to give 
an argument to git-push it will not push other branches.

If there is no such line all the remotes (that don't have a push line?) 
get pushed. 

Cheers,
Michael

(No Subject)

[blg666]

[-- Attachment #1.1: Type: text/plain, Size: 36 bytes --]



Dikirim dari Proton Mail Android

[-- Attachment #1.2: publickey - blg666.exp@proton.me - 0xEA5D1EAF.asc --]
[-- Type: application/pgp-keys, Size: 892 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 322 bytes --]

(No Subject)

[Emilis Kiškis]

What did you do before the bug happened? (Steps to reproduce your issue)

1. Create a new worktree with `git worktree add new-worktree`
2. Modify files in the new worktree
3. Move new worktree back to main working tree (i.e. master)

What did you expect to happen? (Expected behavior)

I expected uncommited changes from `new-worktree` to merge with changes from `master`

What happened instead? (Actual behavior)

The changes from `new-worktree` were lost

What's different between what you expected and what actually happened?

The uncommited changes were lost instead of preserved

Anything else you want to add:

I lost 4 hours of work :(((

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.39.3 (Apple Git-145)
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 arm64
compiler info: clang: 15.0.0 (clang-1500.1.0.2.5)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]
pre-push

(no subject)

[Kevin Phair]

subscribe

(no subject)

[George Shammas]

subscribe

(no subject)

[Mark Levedahl]

 From 567906ddb2fbbcf07325acc2808346ad6a472df1 Mon Sep 17 00:00:00 2001
From: Mark Levedahl <mdl123@verizon.net>
Date: Tue, 17 Jul 2007 18:35:46 -0400
Subject: [PATCH] gitk - Ignore ctrl-z as EOF on windows
To:        mlevedahl@verizon.net
-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-
Cygwin's Tcl is configured to honor any occurence of ctrl-z as an
end-of-file marker, while some commits in the git repository and possibly
elsewhere include that character in the commit comment. This causes gitk
ignore commit history following such a comment and incorrect graphs. This
change affects only Windows as Tcl on other platforms already has
eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and
the fix was suggested by Shawn Pierce.

Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
 gitk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitk b/gitk
index 39e452a..238607e 100755
--- a/gitk
+++ b/gitk
@@ -101,7 +101,7 @@ proc start_rev_list {view} {
     set commfd($view) $fd
     set leftover($view) {}
     set lookingforhead $showlocalchanges
-    fconfigure $fd -blocking 0 -translation lf
+    fconfigure $fd -blocking 0 -translation lf -eofchar {}
     if {$tclencoding != {}} {
     fconfigure $fd -encoding $tclencoding
     }
--
1.5.3.rc2.5.g66bbd

(no subject)

[dierbro]

unsubscribe git

(no subject)

[Davide Rossetti]

subscribe git