git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [RFC doc] Tracking git.git
@ 2021-05-13 13:05 Bagas Sanjaya
  2021-05-13 14:49 ` dwh
  0 siblings, 1 reply; 4+ messages in thread
From: Bagas Sanjaya @ 2021-05-13 13:05 UTC (permalink / raw)
  To: Git Users

Hi,

Some people (most notably Git developers here and me) like to run Git
compiled from git.git repository, as opposed to normal users that run
either Git from distribution or compiled from official source tarball.

In git.git repo, besides master, there is also next, seen, and maint
branches. The purposes of these branches are described on
Documentation/howto/maintain-git.txt.

When we have git.git repo clone and track it, tracking master, next,
and maint are easy peasy: git pull will do the job. But tracking seen
is more like tracking linux-next. We do NOT use git pull because
often doing so will try to merge origin (upstream) with our local
version, which are divergent and most likely will end with conflict.
Instead, we do git fetch first followed by resetting to upstream by
git reset --hard origin/seen.

Should the fact above be documented? And on what file the fact should
be placed? In INSTALL?

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC doc] Tracking git.git
  2021-05-13 13:05 [RFC doc] Tracking git.git Bagas Sanjaya
@ 2021-05-13 14:49 ` dwh
  2021-05-13 20:12   ` Junio C Hamano
  2021-05-13 22:47   ` Felipe Contreras
  0 siblings, 2 replies; 4+ messages in thread
From: dwh @ 2021-05-13 14:49 UTC (permalink / raw)
  To: Bagas Sanjaya; +Cc: Git Users

On 13.05.2021 20:05, Bagas Sanjaya wrote:
>But tracking seen is more like tracking linux-next. We do NOT use git
>pull because often doing so will try to merge origin (upstream) with
>our local version, which are divergent and most likely will end with
>conflict.  Instead, we do git fetch first followed by resetting to
>upstream by git reset --hard origin/seen.
>
>Should the fact above be documented? And on what file the fact should
>be placed? In INSTALL?

I vote yes. I was trying out tracking the different branches and got
bitten by this very situation (tons of conflicts) when pulling seen.

Cheers!
Dave

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC doc] Tracking git.git
  2021-05-13 14:49 ` dwh
@ 2021-05-13 20:12   ` Junio C Hamano
  2021-05-13 22:47   ` Felipe Contreras
  1 sibling, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2021-05-13 20:12 UTC (permalink / raw)
  To: dwh; +Cc: Bagas Sanjaya, Git Users

dwh@linuxprogrammer.org writes:

> On 13.05.2021 20:05, Bagas Sanjaya wrote:
>>But tracking seen is more like tracking linux-next. We do NOT use git
>>pull because often doing so will try to merge origin (upstream) with
>>our local version, which are divergent and most likely will end with
>>conflict.  Instead, we do git fetch first followed by resetting to
>>upstream by git reset --hard origin/seen.
>>
>>Should the fact above be documented? And on what file the fact should
>>be placed? In INSTALL?
>
> I vote yes. I was trying out tracking the different branches and got
> bitten by this very situation (tons of conflicts) when pulling seen.

I vote checking for existing docs before doing this, though.  I
would be surprised if we do not say "do not build on (fork from)
'seen' (formerly known as 'pu')".

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC doc] Tracking git.git
  2021-05-13 14:49 ` dwh
  2021-05-13 20:12   ` Junio C Hamano
@ 2021-05-13 22:47   ` Felipe Contreras
  1 sibling, 0 replies; 4+ messages in thread
From: Felipe Contreras @ 2021-05-13 22:47 UTC (permalink / raw)
  To: dwh, Bagas Sanjaya; +Cc: Git Users

dwh@ wrote:
> On 13.05.2021 20:05, Bagas Sanjaya wrote:
> >But tracking seen is more like tracking linux-next. We do NOT use git
> >pull because often doing so will try to merge origin (upstream) with
> >our local version, which are divergent and most likely will end with
> >conflict.  Instead, we do git fetch first followed by resetting to
> >upstream by git reset --hard origin/seen.
> >
> >Should the fact above be documented? And on what file the fact should
> >be placed? In INSTALL?
> 
> I vote yes. I was trying out tracking the different branches and got
> bitten by this very situation (tons of conflicts) when pulling seen.

git pull is evil.

For more than a decade we've had unending debates about how to fix it,
and nothing comes out of them (last one being [1]).

Just don't use it, and tell your friends to not use it.

Always do `git fetch` plus either one of these:

 1. git merge --ff-only
 2. git rebase
 3. git merge --no-ff
 4. git reset --hard @{upstream}

Cheers.

[1] https://lore.kernel.org/git/20201208002648.1370414-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-05-13 22:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-13 13:05 [RFC doc] Tracking git.git Bagas Sanjaya
2021-05-13 14:49 ` dwh
2021-05-13 20:12   ` Junio C Hamano
2021-05-13 22:47   ` Felipe Contreras

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git