* [PATCH 2/2] Documentation: Refer to git-rebase(1) to warn against rewriting
From: Thomas Rast @ 2008-09-11 15:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1221147525-5589-2-git-send-email-trast@student.ethz.ch>
This points readers at the "Recovering from upstream rebase" warning
in git-rebase(1) when we talk about rewriting published history in the
'reset', 'commit --amend', and 'filter-branch' documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-commit.txt | 4 ++++
Documentation/git-filter-branch.txt | 4 +++-
Documentation/git-reset.txt | 4 +++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index eb05b0f..eeba58d 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -144,6 +144,10 @@ It is a rough equivalent for:
------
but can be used to amend a merge commit.
--
++
+You should understand the implications of rewriting history if you
+amend a commit that has already been published. (See the "RECOVERING
+FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
-i::
--include::
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index b0e710d..fed6de6 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -36,7 +36,9 @@ the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
full implications, and avoid using it anyway, if a simple single commit
-would suffice to fix your problem.
+would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM
+REBASE" section in linkgit:git-rebase[1] for further information about
+rewriting published history.)
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 6abaeac..52aab5e 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -82,7 +82,9 @@ $ git reset --hard HEAD~3 <1>
+
<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
and you do not want to ever see them again. Do *not* do this if
-you have already given these commits to somebody else.
+you have already given these commits to somebody else. (See the
+"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
+the implications of doing so.)
Undo a commit, making it a topic branch::
+
--
1.6.0.1.470.g200b
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-11 15:39 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, git
In-Reply-To: <20080911062242.GA23070@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>
> >delete of the origin branch will basically make them unreachable.
>
> False.
Stephen, here's a f*cking clue:
- I know how git works.
> If you fetch just branches A, B and C, but not D, the origin link from A
> to D is dangling. Once you have fetched D as well [..]
So I just said we deleted beanch 'D', so there's no way to ever fetch it
again.
Get it?
The fact is, a big part of git is temporary branches. It's one of the
*best* features of git. Throw-away stuff. Those throw-away branches are
often done for initial development, and then the final result is often a
cleaned-up version. Often using rebase or cherry-picking or any number of
things.
And this is why "git cherry-pick" DOES NOT PUT THE ORIGINAL SHA1 IN THE
COMMENT FIELD BY DEFAULT.
(Although you can use "-x" to make it do so for when you actually _want_
to say "cherry-picked from xyzzy")
Can you not understand that? The "origin" field is _garbage_. It's garbage
for all normal cases. The original commit will not ever even EXIST in the
result, because it has long since been thrown away and will never exist
anywhere else.
Garbage should be _avoided_, not added.
Linus
^ permalink raw reply
* [RFC PATCH] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-09-11 15:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1221147525-5589-3-git-send-email-trast@student.ethz.ch>
This attempts to make a manpage about workflows that is both handy to
point people at it and as a beginner's introduction.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/Makefile | 2 +-
Documentation/gitworkflows.txt | 326 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 327 insertions(+), 1 deletions(-)
create mode 100644 Documentation/gitworkflows.txt
diff --git a/Documentation/Makefile b/Documentation/Makefile
index ded0e40..e33ddcb 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
gitrepository-layout.txt
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt
+ gitdiffcore.txt gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
new file mode 100644
index 0000000..3462000
--- /dev/null
+++ b/Documentation/gitworkflows.txt
@@ -0,0 +1,326 @@
+gitworkflows(7)
+===============
+
+NAME
+----
+gitworkflows - An overview of recommended workflows with git
+
+SYNOPSIS
+--------
+git *
+
+
+DESCRIPTION
+-----------
+
+This tutorial gives a brief overview of workflows recommended to
+use, and collaborate with, Git.
+
+While the prose tries to motivate each of them, we formulate a set of
+'rules' for quick reference. Do not always take them literally; you
+should value good reasons higher than following a random manpage to
+the letter.
+
+
+SEPARATE CHANGES
+----------------
+
+As a general rule, you should try to split your changes into small
+logical steps, and commit each of them. They should be consistent,
+working independently of any later commits, pass the test suite, etc.
+
+To achieve this, try to commit your new work at least every couple
+hours. You can always go back and edit the commits with `git rebase
+--interactive` to further improve the history before you publish it.
+
+
+MANAGING BRANCHES
+-----------------
+
+In the following, we will assume there are 'developers', 'testers' and
+'users'. Even if the "Testers" are actually an automated test suite
+and all "Users" are developers themselves, try to think in these terms
+as you follow a software change through its life cycle.
+
+Usually a change evolves in a few steps:
+
+* The developers implement a few iterations until it "seems to work".
+
+* The testers play with it, report bugs, test the fixes, eventually
+ clearing the change for stable releases.
+
+* As the users work with the new feature, they report bugs which will
+ have to be fixed.
+
+In the following sections we discuss some problems that arise from
+such a "change flow", and how to solve them with Git.
+
+We consider a fictional project with (supported) stable branch
+'maint', main testing/development branch 'master' and "bleeding edge"
+branch 'next'. We collectively call these three branches 'main
+branches'.
+
+
+Merging upwards
+~~~~~~~~~~~~~~~
+
+Since Git is quite good at merges, one should try to use them to
+propagate changes. For example, if a bug is fixed, you would want to
+apply the corresponding fix to all main branches.
+
+A quick moment of thought reveals that you cannot do this by merging
+"downwards" to older releases, since that would merge 'all' changes.
+Hence the following:
+
+.Merge upwards
+[caption="Rule: "]
+=====================================
+Always commit your fixes to the oldest supported branch that require
+them. Then (periodically) merge the main branches upwards into each
+other.
+=====================================
+
+This gives a very controlled flow of fixes. If you notice that you
+have applied a fix to e.g. 'master' that is also required in 'maint',
+you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
+downwards. This will happen a few times and is nothing to worry about
+unless you do it all the time.
+
+
+Topic branches
+~~~~~~~~~~~~~~
+
+Any nontrivial feature will require several patches to implement, and
+may get extra bugfixes or improvements during its lifetime. If all
+such commits were in one long linear history chain (e.g. if they were
+all committed directly to, 'master'), it becomes very hard to see how
+they belong together.
+
+The key concept here is "topic branches". The name is pretty self
+explanatory, with a minor caveat that comes from the "merge upwards"
+rule above:
+
+.Topic branches
+[caption="Rule: "]
+=====================================
+Make a side branch for every topic. Fork it off at the oldest main
+branch that you will eventually want to merge it into.
+=====================================
+
+Many things can then be done very naturally:
+
+* To get the feature/bugfix into a main branch, simply merge it. If
+ the topic has evolved further in the meantime, merge again.
+
+* If you find you need new features from an 'other' branch to continue
+ working on your topic, merge 'other' to 'topic'. (However, do not
+ do this "just habitually", see below.)
+
+* If you find you forked off the wrong branch and want to move it
+ "back in time", use linkgit:git-rebase[1].
+
+Note that the last two points clash: a topic that has been merged
+elsewhere should not be rebased. See the section on RECOVERING FROM
+UPSTREAM REBASE in linkgit:git-rebase[1].
+
+We should point out that "habitually" (regularly for no real reason)
+merging a main branch into your topics--and by extension, merging
+anything upstream into anything downstream on a regular basis--is
+frowned upon:
+
+.Merge to downstream only at well-defined points
+[caption="Rule: "]
+=====================================
+Do not merge to downstream except:
+
+* with a good reason (such as upstream API changes that affect you), or
+
+* at well-defined points such as when an upstream release has been tagged.
+=====================================
+
+Otherwise, the many resulting small merges will greatly clutter up
+history. Anyone who later investigates the history of a file will
+have to find out whether that merge affected the topic in
+development. Linus hates it. An upstream might even inadvertently be
+merged into a "more stable" branch. And so on.
+
+
+Integration branches
+~~~~~~~~~~~~~~~~~~~~
+
+If you followed the last paragraph, you will now have many small topic
+branches, and occasionally wonder how they interact. Perhaps the
+result of merging them does not even work? But on the other hand, we
+want to avoid merging them anywhere "stable" because such merges
+cannot easily be undone.
+
+The solution, of course, is to make a merge that we can undo: merge
+into a throw-away branch.
+
+.Integration branches
+[caption="Rule: "]
+=====================================
+To test the interaction of several topics, merge them into a
+throw-away branch.
+=====================================
+
+If you make it (very) clear that this branch is going to be deleted
+right after the testing, you can even publish this branch, for example
+to give the testers a chance to work with it, or other developers a
+chance to see if their in-progress work will be compatible.
+
+
+SHARING WORK
+------------
+
+After the last section, you should know how to manage topics. In
+general, you will not be the only person working on the project, so
+you will have to share your work.
+
+Roughly speaking, there are two important workflows. Their
+distinguishing mark is whether they can be used to propagate merges.
+Medium to large projects will typically employ some mixture of the
+two:
+
+* "Upstream" in the most general sense 'pushes' changes to the
+ repositor(ies) holding the main history. Everyone can 'pull' from
+ there to stay up to date.
+
+* Frequent contributors, subsystem maintainers, etc. may use push/pull
+ to send their changes upstream.
+
+* The rest -- typically anyone more than one or two levels away from the
+ main maintainer -- send patches by mail.
+
+None of these boundaries are sharp, so find out what works best for
+you.
+
+
+Push/pull
+~~~~~~~~~
+
+There are three main tools that can be used for this:
+
+* linkgit:git-push[1] copies your branches to a remote repository,
+ usually to one that can be read by all involved parties;
+
+* linkgit:git-fetch[1] that copies remote branches to your repository;
+ and
+
+* linkgit:git-pull[1] that is fetch and merge in one go.
+
+Note the last point. Do 'not' use 'git-pull' unless you actually want
+to merge the remote branch.
+
+Getting changes out is easy:
+
+.Push/pull: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+`git push <remote> <branch>` and tell everyone where they can fetch
+from.
+=====================================
+
+You will still have to tell people by other means, such as mail. (Git
+provides the linkgit:request-pull[1] to send preformatted pull
+requests to upstream maintainers to simplify this task.)
+
+If you just want to get the newest copies of the main branches,
+staying up to date is easy too:
+
+.Push/pull: Staying up to date
+[caption="Recipe: "]
+=====================================
+Use `git fetch <remote>` or `git remote update` to stay up to date.
+=====================================
+
+Then simply fork your topic branches from the stable remotes as
+explained earlier.
+
+If you are a maintainer and would like to merge other people's topic
+branches to the main branches, they will typically send a request to
+do so by mail. Such a request might say
+
+-------------------------------------
+Please pull from
+ git://some.server.somewhere/random/repo.git mytopic
+-------------------------------------
+
+In that case, 'git-pull' can do the fetch and merge in one go, as
+follows.
+
+.Push/pull: Merging remote topics
+[caption="Recipe: "]
+=====================================
+`git pull <url> <branch>`
+=====================================
+
+Occasionally, the maintainer may get merge conflicts when he tries to
+pull changes from downstream. In this case, he can ask downstream to
+do the merge and resolve the conflicts themselves (perhaps they will
+know better how to react). It is one of the rare cases where
+downstream 'should' merge from upstream.
+
+
+format-patch/am
+~~~~~~~~~~~~~~~
+
+If you are a contributor that sends changes upstream in the form of
+emails, you should use topic branches as usual (see above). Then use
+linkgit:git-format-patch[1] to generate the corresponding emails
+(highly recommended over manually formatting them because it makes the
+maintainer's life easier).
+
+.format-patch/am: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+`git format-patch -M upstream..topic` and send out the resulting files.
+=====================================
+
+See the linkgit:git-format-patch[1] manpage for further usage notes.
+Also you should be aware that the maintainer may impose further
+restrictions, such as "Signed-off-by" requirements.
+
+If the maintainer tells you that your patch no longer applies to the
+current upstream, you will have to rebase your topic (you cannot use a
+merge because you cannot format-patch merges):
+
+.format-patch/am: Keeping topics up to date
+[caption="Recipe: "]
+=====================================
+`git rebase upstream`
+=====================================
+
+You can then fix the conflicts during the rebase. Presumably you have
+not published your topic other than by mail, so rebasing it is not a
+problem.
+
+If you receive such a patch (as maintainer, or perhaps reader of the
+mailing list it was sent to), save the mail to a file and use
+'git-am':
+
+.format-patch/am: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+`git am < patch`
+=====================================
+
+One feature worth pointing out is the three-way merge, which can help
+if you get conflicts because of renames: `git am -3` will use index
+information contained in patches to reconstruct a merge base. See
+linkgit:git-am[1] for other options.
+
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:git-push[1],
+linkgit:git-pull[1],
+linkgit:git-merge[1],
+linkgit:git-rebase[1],
+linkgit:git-format-patch[1],
+linkgit:git-am[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
--
1.6.0.1.470.g200b
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 16:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0809111047380.23787@xanadu.home>
Nicolas Pitre wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> Anything I missed?
>Technically speaking, implementation d is obviously the most efficient.
>but, as mentioned above, the actual need for this feature has not been
>convincing so far. Until then, it is not wise to add random stuff to
>the very structure of a commit object, while c can be done even
>externally from git which is a good way to demonstrate and convince
>people about the usefulness of such feature.
The actual need for the feature seems to be dependent on one's workflow
habits. This is also the problem I sense throughout the thread: some
people know exactly what I'm talking about, and would come up with the
almost identical design specs for the feature independent of myself, and
others need to be explained every tiny detail of the spec because they
are not familiar with the concept and can't imagine why/how it would be
used.
Let me try and describe once more the typical environment this origin field
is vital in:
Imagine a repository with:
- 33774 commits total
- 13 years of history
- 1 development branch
- 9 stable branches (forked off of the development branch at regular
intervals during the past 13 years).
- The stable branches are never merged with each other or with the
development branch.
- 2787 individual back/forward ports between the development and stable
branches.
In order to have meaningful output for git-blame, it needs to follow the
chain across cherry-picks reliably.
Once you alter a piece of code, in order to figure out what more to alter,
you need to verify if this piece of code was or wasn't forward/backported.
Reliable and fast reporting of this, and actual comparison of the
different forward/backports between the 9 branches is essential. It
basically means that you need to view the diffs of the patches across 9
branches on a regular basis.
Without the origin links, this workflow will cost a lot more time to
pursue (I know it, because I'm living it at the moment, and no, I'm not
the only developer, it's a development team).
This development model is not unique to my situation, it occurs at more
places.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-11 16:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809110835070.3384@nehalem.linux-foundation.org>
>> If you fetch just branches A, B and C, but not D, the origin link from A
>> to D is dangling. Once you have fetched D as well [..]
>
> So I just said we deleted beanch 'D', so there's no way to ever fetch it
> again.
>
> Get it?
Yes, but you should not have used Stephen's proposed new option to git
cherry-pick, just like you shouldn't have used the existing -x option.
"-x" would not have created a dangling reference, but it would have
created a puzzling commit message.
> The fact is, a big part of git is temporary branches. It's one of the
> *best* features of git. Throw-away stuff. Those throw-away branches are
> often done for initial development, and then the final result is often a
> cleaned-up version. Often using rebase or cherry-picking or any number of
> things.
These days I doubt people would use cherry-pick, they would probably use
interactive rebase. But anyway, exactly for the same reason...
> "git cherry-pick" DOES NOT PUT THE ORIGINAL SHA1 IN THE
> COMMENT FIELD BY DEFAULT.
... neither should cherry-picking create the origin link by default.
Only if requested by the user, using a new option that is basically "-x"
done in a different way. Just like "-x", it should not be used when
cherry-picking from private branches.
But say someone does it, then what happens? If people clone the branch,
the reference will be basically unusable. But since "git gc" does not
delete the referenced commit, at least the origin commit is still
available in the repository where the cherry-pick was made. It is
debatable whether it is better or worse than "-x".
Can we discuss instead a generic way to have porcelain-level metadata,
immutable or at least versioned, for the commit objects? (This is the
same kind of metadata as the author or committer, which clearly have
nothing to do with the git plumbing.) Do you have any proposal of saner
semantics, not for the origin link but for commit references within this
kind of metadata in general?
Paolo
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-11 16:23 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <48C940C8.6040407@gnu.org>
On Thu, 11 Sep 2008, Paolo Bonzini wrote:
>
> Yes, but you should not have used Stephen's proposed new option to git
> cherry-pick, just like you shouldn't have used the existing -x option.
> "-x" would not have created a dangling reference, but it would have
> created a puzzling commit message.
But my point is, _none_ of what Stephen proposes has _any_ advantage over
the already existing functionality.
IOW, absolutely *everything* is actually done better with existing data
structures, and then just adding tools to perhaps follow those SHA1's in
the commit message.
The whole "origin" field doesn't have any semantics that make sense for
core git. It's basically ignored by all normal git operations, and the
_only_ things that people seem to point out as being features are things
that can - and obviously in my opinion should - be done by much higher
levels.
For example, the claim was that it's hard to follow the chain of
cherry-picks. That's not _true_. Use gitweb and gitk, and you can already
see them. Sure, you need to use "-x", BUT YOU'D HAVE TO USE THAT WITH
Steven's MODEL TOO!
Exactly because it would be a frigging _disaster_ if that "origin" field
was done by default.
And the only thing that "origin" does is:
- hide the information
- make it easier to make mistakes (either enable the feature by default,
or not notice that you didn't enable it when you wanted to)
- add a requirement for a backwards-incompatible field that is just
guaranteed to confuse any old git binaries.
- make it _harder_ to do things like send revert/cherry-pick information
by email.
See? There are only downsides.
Look at the kernel -stable trees. They explicitly add that cherry-pick
information, and can add *more*. For example, they go look at
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=commit;h=cb09de4542ad75cc3b66d0cf1a86217bf5633416
and then go to its parent commit (just click on the parent SHA). And
notice how the stable kernel tree commits talk about where they were
back-ported from, or _why_ they aren't back-ports at all!
IOW, there are really two main cases:
- the common case for cherry-picking: you do not want any origin
information, because it's irrelevant, pointless, and *wrong*.
- you _do_ want origin information, but you actually want to _explain_
explicitly why it's not irrelevant, pointless, or wrong.
And yes, the latter case is about a lot more than "this was
cherry-picked". It's about "this fixes that other commit we did", or it's
about "this was anti-cherry-picked - ie reverted". They are all "origins"
for the commit in the sense that they are relevant to the commit, but they
all need some explanation of what _kind_ of origins they are.
Linus
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Elijah Newren @ 2008-09-11 16:32 UTC (permalink / raw)
To: Changsheng Jiang; +Cc: Eric Raible, Git Mailing List
In-Reply-To: <eafc0afe0809102305u6de85ef3ib2c08004dea8d6f9@mail.gmail.com>
On Thu, Sep 11, 2008 at 12:05 AM, Changsheng Jiang
<jiangzuoyan@gmail.com> wrote:
> I don't know what version of you git, my git with version 1.5.4.5
> doesn't delete the file file42 after git-reset.
He stated the same with his version. The point wasn't the behavior of
git reset, but of git reset --hard.
> BTW, if you added the file42 to .gitignore, why git-status still
> reported "new file" file42"?
>From the gitignore(5) manpage:
"Note that all the gitignore files really concern only files that are
not already tracked by git; in order to ignore uncommitted changes in
already tracked files, please refer to..."
Once you run git add, the file is tracked (unless you do something to
explicitly stop tracking it).
Hope that helps,
Elijah
^ permalink raw reply
* Re: [RFC PATCH] Documentation: add manpage about workflows
From: Jakub Narebski @ 2008-09-11 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <1221147585-5695-1-git-send-email-trast@student.ethz.ch>
Thomas Rast wrote:
> This attempts to make a manpage about workflows that is both handy to
> point people at it and as a beginner's introduction.
[...]
Very nice.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-11 16:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, git
In-Reply-To: <alpine.LFD.1.10.0809110835070.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
> On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>
>> If you fetch just branches A, B and C, but not D, the origin link from A
>> to D is dangling. Once you have fetched D as well [..]
>
> So I just said we deleted beanch 'D', so there's no way to ever fetch it
> again.
>
> Get it?
>
> The fact is, a big part of git is temporary branches. It's one of the
> *best* features of git. Throw-away stuff. Those throw-away branches are
> often done for initial development, and then the final result is often a
> cleaned-up version. Often using rebase or cherry-picking or any number of
> things.
>
> And this is why "git cherry-pick" DOES NOT PUT THE ORIGINAL SHA1 IN THE
> COMMENT FIELD BY DEFAULT.
>
> (Although you can use "-x" to make it do so for when you actually _want_
> to say "cherry-picked from xyzzy")
And that is why the proposal was to use "-o" option to git-cherry-pick
to add 'origin'/'changeset' header, exactly because git-cherry-pick is
_abused_ to clean up branches and reorder commits; although I think that
"git rebase --interactive" (and patch management interfaces) do replace
using git-cherry-pick for that purpose.
git-revert would add 'origin'/'changeset' header unconditionally,
just like by default it seeds commit message with SHA-1 id of reverted
commit.
> Can you not understand that? The "origin" field is _garbage_. It's garbage
> for all normal cases. The original commit will not ever even EXIST in the
> result, because it has long since been thrown away and will never exist
> anywhere else.
>
> Garbage should be _avoided_, not added.
Hmmm... the difference between having 'origin' in a commit object header,
and having it in commit mesage is like difference between 'Signed-off-by:'
convention and 'author' header. First is the matter of workflow, second
is inherent, required and non-avoidable part of revision information.
On the other hand git-cherry and git-blame would then have rely on
parsing correctly free-form part of a commit object, to take advantage
of 'origin' information: something what 'origin' info is for.
P.S. 'generation' header was not added... just saying... :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 17:02 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911160040.GE2056@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> Let me try and describe once more the typical environment this origin field
> is vital in:
>
> Imagine a repository with:
> - 33774 commits total
> - 13 years of history
> - 1 development branch
> - 9 stable branches (forked off of the development branch at regular
> intervals during the past 13 years).
> - The stable branches are never merged with each other or with the
> development branch.
> - 2787 individual back/forward ports between the development and stable
> branches.
>
> In order to have meaningful output for git-blame, it needs to follow the
> chain across cherry-picks reliably.
> Once you alter a piece of code, in order to figure out what more to alter,
> you need to verify if this piece of code was or wasn't forward/backported.
> Reliable and fast reporting of this, and actual comparison of the
> different forward/backports between the 9 branches is essential. It
> basically means that you need to view the diffs of the patches across 9
> branches on a regular basis.
>
> Without the origin links, this workflow will cost a lot more time to
> pursue (I know it, because I'm living it at the moment, and no, I'm not
> the only developer, it's a development team).
>
> This development model is not unique to my situation, it occurs at more
> places.
OK. I think I might be able to believe you.
Where I feel uncomfortable is with the real semantics of your "origin"
link proposal.
First, its name. The word "origin" probably has a too narrow meaning
that creates confusion. I'd suggest something like a
"may-be-related-to" field that would be like a weak link.
The format of a may-be-related-to field would be the same as the parent
field, except that the object pointed to by the sha1 could have its type
relaxed, i.e. it could be anything like a blob or a tag.
The semantics of a "may-be-related-to" link would be defined for object
reachability only:
- If the may-be-related-to link is dangling then it is ignored.
- If it is not dangling then usual reachability rules apply.
That's all the core git might care about, and the only real argument for
not having this information in the free form commit message.
Still, in your case, you probably won't get rid of your stable branches,
hence the reachability argument is rather weak for your usage scenario,
meaning that you could as well have that info in the free form text
(like cherry-pick -x), and even generate a special graft file from that
locally for visualization/blame purposes. Sure the indirection will add
some overhead, but I doubt it'll be measurable.
People fetching your main branch won't have to carry the whole
repository because those weak links would otherwise be followed if
they're formally part of the commit header. And if they want
to benefit from the information those weak links carry then they just
have to also fetch the branch(es) where those links are pointing. At
that point it is trivial to regenerate the special graft file locally
which would also have the benefit of only containing links to actually
reachable commits, hence you'd never have dangling "origin" links.
Conclusion: the only fundamental reason for having this weak link
information in the commit header is for reachability convenience for
when the actual branch that contained the referenced commits is gone,
which IMHO is a bad justification. Having lines of developments hanging
off of a weak link alone is just plain stupid if you can't reach it via
proper branches or tags.
So I think that your usage scenario is a valid one, but I think that you
should implement it some other ways, like this special graft file I
mentioned above, which can be generated and updated from custom
information found in the free form comment text of a commit object, and
that proper reachability issues should continue to be handled through
proper branches and tags as it is done today.
Nicolas
^ permalink raw reply
* StGit question
From: Clark Williams @ 2008-09-11 17:04 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Are there any guidelines or best-practices for sharing StGit trees?
I'm working with the Linux -rt patchset and I need to be able to share my tree with
other people. What I'd *like* to do is push git tree's up to a git server, let other
people fetch them and have them be able to 'stg uncommit' to get back to my stack
state. The problem is that when someone uncommits, you lose the patch names. If
you're trying to create an RPM out of a stack, this causes problems :).
Is there something I can do or something that we can do to StGit to make it possible
for an 'uncommit' to restore the original patch name? It looks like I could modify
the commit message, so that the first line is the patch name, but that's not very
nice for people scanning commits.
Or am I missing something completely trivial that will make my life easier?
Thanks,
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkjJT4UACgkQqA4JVb61b9d1tgCfeVNG1BkaZ9czZpeHrFumU+xW
3/kAnj307N0Wx5nLSmtIPr5d+UetAxEG
=uol3
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Commit templates are not readable after 'make install'
From: Anatol Pomozov @ 2008-09-11 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.sixt
In-Reply-To: <7vprnd5b07.fsf@gitster.siamese.dyndns.org>
Hi, Junio.
Thanks for the provided patch. It works fine for me and I agree that
it is better do not hardcode that only hooks are executable. So your
solution looks better for me. +1 for include this patch.
Now permissions for are
anatol:repo $ ls -l /usr/share/git-core/templates/ -R
/usr/share/git-core/templates/:
total 16
drwxr-xr-x 2 root root 4096 2008-09-11 10:13 branches
-rw-r--r-- 1 root root 58 2008-09-11 10:13 description
drwxr-xr-x 2 root root 4096 2008-09-11 10:13 hooks
drwxr-xr-x 2 root root 4096 2008-09-11 10:13 info
/usr/share/git-core/templates/branches:
total 0
/usr/share/git-core/templates/hooks:
total 44
-rwxr-xr-x 1 root root 452 2008-09-11 10:13 applypatch-msg.sample
-rwxr-xr-x 1 root root 894 2008-09-11 10:13 commit-msg.sample
-rwxr-xr-x 1 root root 160 2008-09-11 10:13 post-commit.sample
-rwxr-xr-x 1 root root 553 2008-09-11 10:13 post-receive.sample
-rwxr-xr-x 1 root root 189 2008-09-11 10:13 post-update.sample
-rwxr-xr-x 1 root root 398 2008-09-11 10:13 pre-applypatch.sample
-rwxr-xr-x 1 root root 519 2008-09-11 10:13 pre-commit.sample
-rwxr-xr-x 1 root root 1219 2008-09-11 10:13 prepare-commit-msg.sample
-rwxr-xr-x 1 root root 4942 2008-09-11 10:13 pre-rebase.sample
-rwxr-xr-x 1 root root 2892 2008-09-11 10:13 update.sample
/usr/share/git-core/templates/info:
total 4
-rw-r--r-- 1 root root 240 2008-09-11 10:13 exclude
On Tue, Sep 9, 2008 at 1:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Didn't 9907721 (templates/Makefile: don't depend on local umask setting,
>> 2008-02-28) take care of that?
>>
>> ... goes and looks ...
>>
>> Ah, that is only to propagate the wish of the person who _built_ it.
>>
>> You probably have a tight umask and have sources checked out unreadable to
>> others, which is propagated to the installation (check the permission of
>> files in your templates/blt directory to verify this conjecture). And the
>> build procedure is honoring your wish to make things unreadable to others.
>
> I should have said "too tight a umask", but anyway, try this patch and see
> it helps.
>
> -- >8 --
> Fix permission bits on sources checked out with an overtight umask
>
> Two patches 9907721 (templates/Makefile: don't depend on local umask
> setting, 2008-02-28) and 96cda0b (templates/Makefile: install is
> unnecessary, just use mkdir -p, 2008-08-21) tried to prevent an overtight
> umask the builder/installer might have from screwing over the installation
> procedure, but we forgot there was another source of trouble. If the
> person who checked out the source tree had an overtight umask, it will
> leak out to the built products, which is propagated to the installation
> destination.
>
> templates/Makefile | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git c/templates/Makefile w/templates/Makefile
> index 0722a92..a12c6e2 100644
> --- c/templates/Makefile
> +++ w/templates/Makefile
> @@ -31,9 +31,11 @@ boilerplates.made : $(bpsrc)
> dir=`expr "$$dst" : '\(.*\)/'` && \
> mkdir -p blt/$$dir && \
> case "$$boilerplate" in \
> - *--) ;; \
> - *) cp -p $$boilerplate blt/$$dst ;; \
> - esac || exit; \
> + *--) continue;; \
> + esac && \
> + cp $$boilerplate blt/$$dst && \
> + if test -x "blt/$$dst"; then rx=rx; else rx=r; fi && \
> + chmod a+$$rx "blt/$$dst" || exit; \
> done && \
> date >$@
>
>
--
anatol
^ permalink raw reply
* Git on server
From: delux @ 2008-09-11 17:57 UTC (permalink / raw)
To: git
I work in a studio and we have many projects that we work on. We want to
start using git, but we seem to be having some problems. I need to be able
to pull the files from the server on to the local machines or have user
repositories where the employees can pull the files to their repositories
work on them then push the back to the main repository. I have tried to
create a main repository and user repositories to try and push and pull
between them and had no luck, git is installed on a Linux server and we have
Mac and Windows machines. Any help is greatly appreciated and if more info
is needed please let me know. Thanks in advance!
--
View this message in context: http://www.nabble.com/Git-on-server-tp19440690p19440690.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-11 18:00 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911153202.GD2056@cuci.nl>
On Thu, Sep 11, 2008 at 05:32:02PM +0200, Stephen R. van den Berg wrote:
> gc will preserve the commits the origin links point to once they are
> reachable. I.e. if the developer doesn't care about the commits the
> origin links point to (i.e. if the branches are not reachable) then gc
> just skips them, if the developer *does* care, the origin links are used
> to keep those objects alive (and, of course, all their parenthood).
This seems wrong. OK, suppose you have branches A, B, C, and D, while
you are on branch C, you cherry pick commit 'p' from branch B, so that
there is a new commit q on branch C which has an origin link
containing the commit ID's p^ and 'p.
Now suppose branch B gets deleted, and you do a "git gc". All of the
commits that were part of branch B will vanish except for p^ and p,
which in your model will stick around because they are origin links
commit q on branch C. But what good is are these two commits? They
represent two snapshots in time, with no context now that branch B has
been deleted. 99% of the time, the diff between p^ and p will result
in the equivalent of the diff between q^ and q. But even if they
aren't, what use are these isolated, disconnected commits? So having
"git gc" retain them commits that are pointed to be this proposed
origin link doesn't seem to make any sense, and doesn't seem to be
well thought through.
Oh, BTW, suppose you then further do a "git cherry-pick -o" of commit
q while you are on branch D. Presumably this will create a new
commit, r. But will the origin-link of commit r be p^ and p, or q^
and q? And will this change depending on whether or not -o is
specified?
> >I'll also note that having a ***local*** database to cache the origin
> >link is a great way of short-circuiting the performance difficulties.
> >If it works, then it will be a lot easier to convince people that
> >perhaps it should be done git-core, and by modifying core git functions.
>
> Creating local databases for these kinds of structures feels kludgy
> somehow, since the git hash objects essentially *are* a working
> database. I have not checked yet if git already has some kind of
> ready-to-use local database lib inside which I could reuse for that.
Gitk already keeps a cache (.git/gitk.cache) to speed up some of its
operations. And in some ways the index file is a cache, although it
does far more than that.
- Ted
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 18:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0809111222170.23787@xanadu.home>
Nicolas Pitre wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> Let me try and describe once more the typical environment this origin field
>> is vital in:
>> Without the origin links, this workflow will cost a lot more time to
>> pursue (I know it, because I'm living it at the moment, and no, I'm not
>First, its name. The word "origin" probably has a too narrow meaning
>that creates confusion. I'd suggest something like a
>"may-be-related-to" field that would be like a weak link.
Well, the important properties of the name/field would be:
- It should be as specific as possible, in order to minimise the
potential for abuse in the future. I distill the desirability of this
requirement out of the various earlier discussions about commitheaders
in the past on this mailinglist held by others.
- It should convey a sense of direction (it's a directed graph).
Any generic may-be-related-to field is therefore probably a non-starter.
>The semantics of a "may-be-related-to" link would be defined for object
>reachability only:
>- If the may-be-related-to link is dangling then it is ignored.
>- If it is not dangling then usual reachability rules apply.
>That's all the core git might care about, and the only real argument for
>not having this information in the free form commit message.
The origin field as currently proposed tightens the requirements that
it either is dangling and ignored or points to a commit.
rev-list --topo-order should use the origin links to order the output.
gc/prune won't delete commits referenced *by* an origin link.
The only two other arguments one might give to actually keep the field
in the header of the commit as opposed to the trailer is that the
physical field can be kept machine readable, and the actual display can be
beautified like: Origin: 2abcdef..1234567
The output of the field could be suppressed (if so desired) if the
target commit isn't reachable.
All this is of course possible for a trailer field in the free-form
area as well, but it seems a bit silly to have two places for "headers".
>Still, in your case, you probably won't get rid of your stable branches,
True.
>hence the reachability argument is rather weak for your usage scenario,
Then again, I don't want to be bothered by stupid free-form origin links
made to local branches by a developer. If the developer creates them
using cherry-pick -o which creates an origin link, I'll never have to
see his silly commit hashes where he is referring to commits in his
local branch (and never waste time wondering where those commits are).
>meaning that you could as well have that info in the free form text
>(like cherry-pick -x), and even generate a special graft file from that
>locally for visualization/blame purposes. Sure the indirection will add
>some overhead, but I doubt it'll be measurable.
The free-form equivalent looks like:
Origin: df85f7855da44c730f942b330ada181209d09d7a ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123
You need a pair of hashes, which is, a bit bulky, for my taste.
What special graft file would I need to visualise? Isn't having the
origin link information enough?
>People fetching your main branch won't have to carry the whole
>repository because those weak links would otherwise be followed if
>they're formally part of the commit header. And if they want
>to benefit from the information those weak links carry then they just
>have to also fetch the branch(es) where those links are pointing. At
>that point it is trivial to regenerate the special graft file locally
>which would also have the benefit of only containing links to actually
>reachable commits, hence you'd never have dangling "origin" links.
You lost me here somewhere. Could you give a concrete example with one
commit, one origin link (your style) and a special graftfile entry?
>Conclusion: the only fundamental reason for having this weak link
>information in the commit header is for reachability convenience for
>when the actual branch that contained the referenced commits is gone,
Erm. Quite the opposite, actually.
The practical use for the origin link in case the target is unreachable
is zero to none, so it can gleefully be ignored in that case.
But maybe the semantics of your "related" link and my origin link are
sufficiently distinct.
For the arguments why it should be in the header of a commit, see above.
>which IMHO is a bad justification. Having lines of developments hanging
>off of a weak link alone is just plain stupid if you can't reach it via
>proper branches or tags.
Agreed. But this is in reference to your "related" link proposal.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 19:03 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911180037.GH5082@mit.edu>
Theodore Tso wrote:
>On Thu, Sep 11, 2008 at 05:32:02PM +0200, Stephen R. van den Berg wrote:
>> gc will preserve the commits the origin links point to once they are
>> reachable. I.e. if the developer doesn't care about the commits the
>> origin links point to (i.e. if the branches are not reachable) then gc
>> just skips them, if the developer *does* care, the origin links are used
>> to keep those objects alive (and, of course, all their parenthood).
>This seems wrong. OK, suppose you have branches A, B, C, and D, while
>you are on branch C, you cherry pick commit 'p' from branch B, so that
>there is a new commit q on branch C which has an origin link
>containing the commit ID's p^ and 'p.
Ok.
>Now suppose branch B gets deleted, and you do a "git gc". All of the
>commits that were part of branch B will vanish except for p^ and p,
Not quite. Obviously all parents of p and p^ will continue to exist.
I.e. deleting branch B will cause all commits from p till the tip of B
(except p itself) to vanish. Keeping p implies that the whole chain of
parents below p will continue to exist and be reachable. That's the way
a git repository works.
>which in your model will stick around because they are origin links
>commit q on branch C. But what good is are these two commits? They
>represent two snapshots in time, with no context now that branch B has
The context are all their ancestors, which continue to exist, and that
is all you need.
>been deleted. 99% of the time, the diff between p^ and p will result
>in the equivalent of the diff between q^ and q. But even if they
>aren't, what use are these isolated, disconnected commits? So having
>"git gc" retain them commits that are pointed to be this proposed
>origin link doesn't seem to make any sense, and doesn't seem to be
>well thought through.
I beg to differ, but I presume you agree with me now?
>Oh, BTW, suppose you then further do a "git cherry-pick -o" of commit
>q while you are on branch D. Presumably this will create a new
>commit, r. But will the origin-link of commit r be p^ and p, or q^
>and q?
It will be q^..q, and specifically not p^..p, using ^p..p would be
lying. We aim to document the evolvement of the patch in time.
Cherry-pick itself will always ignore the origin links present on the
old commit, it simply creates new ones as if the old ones didn't exist.
> And will this change depending on whether or not -o is
>specified?
No. Actually, cherry-pick will never generate origin links unless -o is
specified.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 19:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809110835070.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> >delete of the origin branch will basically make them unreachable.
>> False.
>Stephen, here's a f*cking clue:
> - I know how git works.
I'd presume you do, but that doesn't mean you always accurately express
yourself.
>> If you fetch just branches A, B and C, but not D, the origin link from A
>> to D is dangling. Once you have fetched D as well [..]
>So I just said we deleted beanch 'D', so there's no way to ever fetch it
>again.
You did not state you deleted branch 'D' on the repository being fetched
*FROM*. I assumed you meant you deleted branch 'D' on the repository
doing the fetching (after having fetched 'D' in the past).
>Get it?
"You stupid git".
>The fact is, a big part of git is temporary branches. It's one of the
>*best* features of git. Throw-away stuff. Those throw-away branches are
>often done for initial development, and then the final result is often a
>cleaned-up version. Often using rebase or cherry-picking or any number of
>things.
Indeed, features I value in git very much, and use every day, thanks.
[...portions of man git-cherry-pick stripped...]
>Can you not understand that? The "origin" field is _garbage_. It's garbage
>for all normal cases. The original commit will not ever even EXIST in the
>result, because it has long since been thrown away and will never exist
>anywhere else.
The origin field will *not* be created on regular cherry-picks, this
*would* create garbage. The origin field is not meant to be generated
when doing things with temporary branches. The origin field is meant to
be filled *ONLY* when cherry-picking from one permanent branch to
another permanent branch. This is a *rare* operation.
>Garbage should be _avoided_, not added.
Quite.
I do understand that "normal cases" in your case mean cherry-picks among
temporary branches.
Well, you are completely right that *your* normal cases should not (and
will not) generate an origin field.
The origin field is intended for the *abnormal* cases, which means
cherry-picking between permanent branches (which, apparently, you rarely
do, if ever), this is something that (depending on your workflow) can be
a more frequent event. For *those* cases, the origin field will not
contain garbage.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 19:33 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911190335.GB1451@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> Theodore Tso wrote:
> >On Thu, Sep 11, 2008 at 05:32:02PM +0200, Stephen R. van den Berg wrote:
> >> gc will preserve the commits the origin links point to once they are
> >> reachable. I.e. if the developer doesn't care about the commits the
> >> origin links point to (i.e. if the branches are not reachable) then gc
> >> just skips them, if the developer *does* care, the origin links are used
> >> to keep those objects alive (and, of course, all their parenthood).
>
> >This seems wrong. OK, suppose you have branches A, B, C, and D, while
> >you are on branch C, you cherry pick commit 'p' from branch B, so that
> >there is a new commit q on branch C which has an origin link
> >containing the commit ID's p^ and 'p.
>
> Ok.
>
> >Now suppose branch B gets deleted, and you do a "git gc". All of the
> >commits that were part of branch B will vanish except for p^ and p,
>
> Not quite. Obviously all parents of p and p^ will continue to exist.
> I.e. deleting branch B will cause all commits from p till the tip of B
> (except p itself) to vanish. Keeping p implies that the whole chain of
> parents below p will continue to exist and be reachable. That's the way
> a git repository works.
And that's what I called stupid in my earlier reply to you. Either you
have proper branches or tags keeping P around, or deleting B brings
everything not reachable through other branches or tags (or reflog)
away too. Otherwise there is no point making a dangling origin link
valid.
Nicolas
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 19:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0809111527030.23787@xanadu.home>
Nicolas Pitre wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> Not quite. Obviously all parents of p and p^ will continue to exist.
>> I.e. deleting branch B will cause all commits from p till the tip of B
>> (except p itself) to vanish. Keeping p implies that the whole chain of
>> parents below p will continue to exist and be reachable. That's the way
>> a git repository works.
>And that's what I called stupid in my earlier reply to you. Either you
>have proper branches or tags keeping P around, or deleting B brings
>everything not reachable through other branches or tags (or reflog)
>away too. Otherwise there is no point making a dangling origin link
>valid.
Well, the principle of least surprise dictates that they should be kept
by gc as described above, however...
I can envision an option to gc say "--drop-weak-links" which does
exactly what you describe.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 19:45 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <20080911192356.GC1451@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> The origin field will *not* be created on regular cherry-picks, this
> *would* create garbage. The origin field is not meant to be generated
> when doing things with temporary branches. The origin field is meant to
> be filled *ONLY* when cherry-picking from one permanent branch to
> another permanent branch. This is a *rare* operation.
... and therefore you might as well just have a separate file (which
might or might not be tracked by git like the .gitignore files are)
to keep that information? Since this is a rare operation, modifying the
core database structure for this doesn't appear that appealing to most
so far.
And, while recording this origin link is optional, you are likely to
make mistakes like forgotting to record it, or you might even wish to
fix it with better links after the facts. Having it versionned also
means that older git versions will be able to carry that information
even if they won't make any use of it, and that also solves the
cryptographic issue since that data is part of the top commit SHA1.
Nicolas
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 19:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809111534300.23787@xanadu.home>
Nicolas Pitre wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> when doing things with temporary branches. The origin field is meant to
>> be filled *ONLY* when cherry-picking from one permanent branch to
>> another permanent branch. This is a *rare* operation.
>... and therefore you might as well just have a separate file (which
>might or might not be tracked by git like the .gitignore files are)
>to keep that information? Since this is a rare operation, modifying the
>core database structure for this doesn't appear that appealing to most
>so far.
For various reasons, the best alternate place would be at the trailing
end of the free-form field. Using a separate structure causes
(performance) problems (mostly).
>And, while recording this origin link is optional, you are likely to
>make mistakes like forgotting to record it,
That is just as likely filling in the wrong commit message.
> or you might even wish to
>fix it with better links after the facts.
That is not possible for commit messages, and should not be possible for
origin links either (same reasons).
> Having it versionned also
>means that older git versions will be able to carry that information
>even if they won't make any use of it, and that also solves the
>cryptographic issue since that data is part of the top commit SHA1.
It would allow the data to be faked, that is undesirable for "git blame".
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 20:00 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911184405.GA1451@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> Nicolas Pitre wrote:
> >First, its name. The word "origin" probably has a too narrow meaning
> >that creates confusion. I'd suggest something like a
> >"may-be-related-to" field that would be like a weak link.
>
> Well, the important properties of the name/field would be:
> - It should be as specific as possible, in order to minimise the
> potential for abuse in the future. I distill the desirability of this
> requirement out of the various earlier discussions about commitheaders
> in the past on this mailinglist held by others.
Well, sure. But being too specific sometimes limits its usefulness.
There could be other usages for such a link which IMHO should be defined
in terms of graph connectivity semantics rather than high level purpose.
> - It should convey a sense of direction (it's a directed graph).
Well, isn't that already obvious?
> Any generic may-be-related-to field is therefore probably a non-starter.
Well, my whole argument is that if it has no generic purpose then it
probably doesn't belong in the commit header.
> The origin field as currently proposed tightens the requirements that
> it either is dangling and ignored or points to a commit.
> rev-list --topo-order should use the origin links to order the output.
> gc/prune won't delete commits referenced *by* an origin link.
And I disagree on the gc/prune point, as mentioned previously.
As to rev-list --topo-order, it doesn't need for this link to actually
be part of the commit object to accomplish the desired effect.
> The only two other arguments one might give to actually keep the field
> in the header of the commit as opposed to the trailer is that the
> physical field can be kept machine readable, and the actual display can be
> beautified like: Origin: 2abcdef..1234567
> The output of the field could be suppressed (if so desired) if the
> target commit isn't reachable.
> All this is of course possible for a trailer field in the free-form
> area as well, but it seems a bit silly to have two places for "headers".
And I think you should simply create a file within the repository with
that info instead of either thecommit header or the free form text. It
gives all the usability advantages you wish for and more.
Nicolas
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 20:03 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911194447.GD1451@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> Nicolas Pitre wrote:
> >On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> >> Not quite. Obviously all parents of p and p^ will continue to exist.
> >> I.e. deleting branch B will cause all commits from p till the tip of B
> >> (except p itself) to vanish. Keeping p implies that the whole chain of
> >> parents below p will continue to exist and be reachable. That's the way
> >> a git repository works.
>
> >And that's what I called stupid in my earlier reply to you. Either you
> >have proper branches or tags keeping P around, or deleting B brings
> >everything not reachable through other branches or tags (or reflog)
> >away too. Otherwise there is no point making a dangling origin link
> >valid.
>
> Well, the principle of least surprise dictates that they should be kept
> by gc as described above, however...
> I can envision an option to gc say "--drop-weak-links" which does
> exactly what you describe.
Don't you think this starts to look silly at that point?
Nicolas
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-11 20:04 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911190335.GB1451@cuci.nl>
On Thu, Sep 11, 2008 at 09:03:35PM +0200, Stephen R. van den Berg wrote:
> >This seems wrong. OK, suppose you have branches A, B, C, and D, while
> >you are on branch C, you cherry pick commit 'p' from branch B, so that
> >there is a new commit q on branch C which has an origin link
> >containing the commit ID's p^ and 'p.
>
> >Now suppose branch B gets deleted, and you do a "git gc". All of the
> >commits that were part of branch B will vanish except for p^ and p,
>
> Not quite. Obviously all parents of p and p^ will continue to exist.
> I.e. deleting branch B will cause all commits from p till the tip of B
> (except p itself) to vanish. Keeping p implies that the whole chain of
> parents below p will continue to exist and be reachable. That's the way
> a git repository works.
That's still not very useful, since you still don't have a label for
this anonymous series of commit chain that just dead ends at commit p.
How would anyone find this useful?
> >which in your model will stick around because they are origin links
> >commit q on branch C. But what good is are these two commits? They
> >represent two snapshots in time, with no context now that branch B has
>
> The context are all their ancestors, which continue to exist, and that
> is all you need.
Need for what? What useful information would you devine from it?
> >Oh, BTW, suppose you then further do a "git cherry-pick -o" of commit
> >q while you are on branch D. Presumably this will create a new
> >commit, r. But will the origin-link of commit r be p^ and p, or q^
> >and q?
>
> It will be q^..q, and specifically not p^..p, using ^p..p would be
> lying. We aim to document the evolvement of the patch in time.
> Cherry-pick itself will always ignore the origin links present on the
> old commit, it simply creates new ones as if the old ones didn't exist.
So if you never pull branch C (where commit q resides), there is no
way for you to know that commits p and r are related. How.... not
useful.
If the scenario was being able to tell which stable branches had a
particular bug fixes, I think my proposal of attaching a bug
identifier is a far superior solution.
Again, what's the use case of "trying to document the development of
the patch in time?" Aside from drawing pretty dotted lines
everywhere, what *good* does this actually achieve? How would it
affect other git commands' behavior, and how would this change in
behavior actually be considered a net improvement over what we have
now?
- Ted
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-11 20:05 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Nicolas Pitre, Theodore Tso, Linus Torvalds, git
In-Reply-To: <20080911194447.GD1451@cuci.nl>
Stephen R. van den Berg wrote:
> Nicolas Pitre wrote:
>>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>>> Not quite. Obviously all parents of p and p^ will continue to exist.
>>> I.e. deleting branch B will cause all commits from p till the tip of B
>>> (except p itself) to vanish. Keeping p implies that the whole chain of
>>> parents below p will continue to exist and be reachable. That's the way
>>> a git repository works.
>
>>And that's what I called stupid in my earlier reply to you. Either you
>>have proper branches or tags keeping P around, or deleting B brings
>>everything not reachable through other branches or tags (or reflog)
>>away too. Otherwise there is no point making a dangling origin link
>>valid.
>
> Well, the principle of least surprise dictates that they should be kept
> by gc as described above, however...
> I can envision an option to gc say "--drop-weak-links" which does
> exactly what you describe.
Well, IIRC the need for this was one of the causes of "death" of 'prior'
header link proposal...
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox