From: "David Jeske" <jeske@google.com>
To: "Avery Pennarun" <apenwarr@gmail.com>
Cc: "Nicolas Pitre" <nico@cam.org>, git@vger.kernel.org
Subject: Re: why is git destructive by default? (i suggest it not be!)
Date: Tue, 24 Jun 2008 06:35:16 -0000 [thread overview]
Message-ID: <willow-jeske-01l5izRzFEDjCdyL> (raw)
In-Reply-To: <32541b130806232220r292d691cn5bf5f9976126aa29@mail.gmail.com>
Thanks for all the helpful responses...
-- Avery Pennarun wrote:
> git's philosophy is different. Branches are really just "temporary
> tags". A merge operation doesn't just copy data from one branch to
> another: it actually joins the two histories together, so you can then
> trace back through the exact history of the merged branches, commit by
> commit. "git log" will show each checkin to *either* branch
> individually, instead of just one big "merge" checkin.
If branches are "temporary tags" how do I see the actual code they had working
in their branch before they merged it?
I'm reading about rebase, and it sounds like something I would want to forever
disallow on my git repository, because it looks like it rewrites history and
makes it impossible to get to the state of the tree they actually had working
before the merge. However, something you say below both clarifies and confuses
this.
Am I understanding this wrong?
> The end result is that even if you delete the source branch after
> doing a merge, nothing is actually lost.
..and what if you never merge? That branch-pointer points to useful information
about a development attempt, but it was never merged. (imagine a different
development path was taken) They never created a tag because it's not clear
when that work was "done" (unlike a release, which is much more well
understood). What prevents someone from deleting the branch-pointer or moving
it to a different part of the tree, causing that set of changes to be a
dangling ref lost in a sea of refs. Later when someone goes back looking for
it, how would they ever find it in a sea of tens of thousands of checkins?
> Thus, there's no reason for git to try to make branches impossible
> to lose, as they are in svn.
Before I set the GC times to "100 years", there was a HUGE reason for git to
make those branch-pointers impossible to lose, because by default if you lose
them git actually garbage collects them and throws the diffs away after 90
days!
> Another way to think of it is that svn's concept of a "branch" is
> actually the "reflog" in git. (svn records which data a particular
> branch name points to over time, just like git's reflog does.) git
> branches are something else entirely; a git branch always points at
> only a single commit, and has no history of its own.
That's sort of helpful, and sort of confusing. I think of git's branches as
"branch pointers to the head of a linked-list of states of the tree".
As long as you keep those refs without deleting them, and you keep that branch
pointer to the head, you can walk back through the history of that branch. If
multiple developers are working in the branch (and not using rebase, and not
garbage collecting), can't you even go track down the working state of their
local clients while they were working before they merged?
If I'm understanding all that right, it's exactly the kind of functionality I
want -- the ability to reproduce the state of all working history, exactly as
it was when the code was actually working in someone's client a long time ago,
before they merged it to the mainline. Except the standard model seems to be to
let the system "garbage collect" all that history, and toss it away as
unimportant -- and in some cases it seems to even provide developers with ways
to more aggressively assure garbage collection makes it disappear.
Am I expecting too much out of git? It doesn't really feel like a source
control system for an organization that wants to save everything, forever, even
when those people and trees and home directories disappear. It feels like a
distributed patch manager that is much more automatic than sending around
diffs, but isn't overly concerned with providing access to old history. (which,
duh, is no surprise given that's what I expect it's doing for linux kernel)
next prev parent reply other threads:[~2008-06-24 6:57 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <willow-jeske-01l5PFjPFEDjCfzf-01l5V7wbFEDjCX7V>
[not found] ` <jeske@willow=01l5V7waFEDjChmh>
2008-06-24 1:47 ` why is git destructive by default? (i suggest it not be!) David Jeske
2008-06-24 1:47 ` David Jeske
2008-06-24 17:11 ` Boaz Harrosh
2008-06-24 17:19 ` Boaz Harrosh
2008-06-24 19:08 ` Jakub Narebski
2008-06-24 20:04 ` David Jeske
2008-06-24 21:42 ` Brandon Casey
2008-06-24 22:13 ` David Jeske
2008-06-24 22:13 ` David Jeske
2008-06-24 22:54 ` Theodore Tso
2008-06-24 23:07 ` Junio C Hamano
2008-06-25 2:26 ` Theodore Tso
2008-06-25 8:58 ` Jakub Narebski
2008-06-25 9:14 ` Junio C Hamano
2008-06-26 15:13 ` Brandon Casey
2008-06-24 22:21 ` Steven Walter
2008-06-24 22:21 ` [PATCH] cmd_reset: don't trash uncommitted changes unless told to Steven Walter
2008-06-24 22:31 ` Junio C Hamano
2008-06-25 9:12 ` Boaz Harrosh
2008-06-25 9:23 ` Junio C Hamano
2008-06-25 9:59 ` Boaz Harrosh
2008-06-25 10:16 ` Johannes Schindelin
2008-06-25 10:24 ` Matthias Kestenholz
2008-06-25 10:46 ` Anton Gladkov
2008-06-25 12:33 ` Johannes Schindelin
2008-06-25 14:49 ` [PATCH] cmd_reset: don't trash uncommitted changes unless toldto Craig L. Ching
2008-06-25 15:18 ` Anton Gladkov
2008-06-25 10:41 ` [PATCH] cmd_reset: don't trash uncommitted changes unless told to Johannes Sixt
2008-06-25 12:38 ` Johannes Schindelin
2008-06-25 13:51 ` Theodore Tso
2008-06-25 17:22 ` Junio C Hamano
2008-06-25 19:50 ` Theodore Tso
2008-06-25 20:04 ` Avery Pennarun
2008-06-25 20:11 ` Junio C Hamano
2008-06-25 20:22 ` Avery Pennarun
2008-06-25 20:48 ` Junio C Hamano
2008-06-25 20:58 ` Avery Pennarun
2008-06-25 21:24 ` Re* " Junio C Hamano
2008-06-25 21:34 ` Junio C Hamano
2008-06-26 1:26 ` Junio C Hamano
2008-06-25 20:37 ` Steven Walter
2008-06-25 20:38 ` Theodore Tso
2008-06-25 20:50 ` Junio C Hamano
2008-06-25 21:05 ` Theodore Tso
2008-06-25 21:35 ` Junio C Hamano
2008-06-26 5:16 ` Junio C Hamano
[not found] ` <20080627193325.6117@nanako3.lavabit.com>
2008-06-27 22:11 ` Junio C Hamano
2008-06-28 0:06 ` しらいしななこ
2008-06-28 22:32 ` しらいしななこ
2008-06-29 8:56 ` Junio C Hamano
2008-06-25 22:44 ` Petr Baudis
2008-06-26 1:59 ` Johannes Schindelin
2008-06-25 20:09 ` Junio C Hamano
2008-06-26 11:55 ` Björn Steinbrink
2008-06-26 12:07 ` Johannes Schindelin
2008-06-26 12:35 ` Björn Steinbrink
2008-06-26 15:55 ` Avery Pennarun
2008-06-26 17:49 ` Johannes Schindelin
2008-06-26 12:01 ` Matthieu Moy
2008-06-26 12:09 ` Johannes Schindelin
2008-06-26 12:23 ` David Kastrup
2008-06-25 13:19 ` Ian Hilt
2008-06-26 5:31 ` Andreas Ericsson
2008-06-26 16:15 ` Jon Loeliger
2008-06-25 5:29 ` Johannes Gilger
2008-06-24 20:04 ` why is git destructive by default? (i suggest it not be!) David Jeske
2008-06-25 8:57 ` Boaz Harrosh
2008-06-24 18:18 ` Brandon Casey
[not found] ` <willow-jeske-01l5PFjPFEDjCfzf-01l5V7wbFEDjCX7V@videotron.ca>
[not found] ` <willow-jeske-01l5cKsCFEDjC=91MX@videotron.ca>
2008-06-24 2:17 ` Nicolas Pitre
2008-06-24 3:18 ` David Jeske
2008-06-24 3:18 ` David Jeske
2008-06-24 8:14 ` Lea Wiemann
[not found] ` <willow-jeske-01l5PFjPFEDjCfzf-01l5ciVtFEDjCaD9@videotron.ca>
[not found] ` <willow-jeske-01l5e9cgFEDjCh3F@videotron.ca>
2008-06-24 4:03 ` Nicolas Pitre
2008-06-24 4:40 ` David Jeske
2008-06-24 5:24 ` Jan Krüger
2008-06-24 4:40 ` David Jeske
[not found] ` <1978205964779154253@unknownmsgid>
2008-06-24 5:20 ` Avery Pennarun
2008-06-24 6:35 ` David Jeske [this message]
2008-06-24 7:24 ` Jeff King
2008-06-24 7:31 ` David Jeske
2008-06-24 8:16 ` Jeff King
2008-06-24 8:30 ` David Jeske
2008-06-24 8:30 ` David Jeske
2008-06-24 9:39 ` Jakub Narebski
[not found] ` <willow-jeske-01l5PFjPFEDjCfzf-01l5kv6TFEDjCj8S@brm-avmta-1.central.sun.com>
[not found] ` <willow-jeske-01l5lTEoFEDjCVta@brm-avmta-1.central.sun.com>
2008-06-24 10:01 ` Fedor Sergeev
2008-06-24 10:24 ` David Jeske
2008-06-24 13:13 ` Theodore Tso
2008-06-24 7:31 ` David Jeske
2008-06-24 6:35 ` David Jeske
2008-06-24 7:54 ` Jakub Narebski
2008-06-24 8:08 ` David Jeske
2008-06-24 8:08 ` David Jeske
2008-06-24 11:22 ` Jakub Narebski
2008-06-24 11:29 ` David Jeske
2008-06-24 12:21 ` Jakub Narebski
2008-06-24 11:29 ` David Jeske
2008-06-24 12:19 ` Rogan Dawes
2008-06-24 12:35 ` Johannes Gilger
2008-06-24 12:46 ` Rogan Dawes
2008-06-24 12:13 ` Jakub Narebski
2008-06-24 4:59 Teemu Likonen
[not found] ` <e80d075a0806232201o3933d154he2b570986604c30a@mail.gmail.com>
2008-06-24 5:43 ` Teemu Likonen
-- strict thread matches above, loose matches on Subject: below --
2008-06-24 8:35 Björn Steinbrink
[not found] <willow-jeske-01l5PFjPFEDjCfzf-01l5oEswFEDjCZBN>
[not found] ` <willow-jeske-01l5oEsvFEDjCjRW>
2008-06-24 10:42 ` David Jeske
2008-06-24 15:29 ` Brandon Casey
2008-06-24 16:41 ` David Jeske
2008-06-24 18:55 ` Brandon Casey
2008-06-25 12:20 ` Matthieu Moy
2008-06-25 17:56 ` Jing Xue
2008-06-24 16:41 ` David Jeske
2008-06-24 10:42 ` David Jeske
2008-06-24 12:21 Olivier Galibert
2008-06-25 18:06 Dmitry Potapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willow-jeske-01l5izRzFEDjCdyL \
--to=jeske@google.com \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox