* Re: Different svn-id URLs in history
From: Michael J Gruber @ 2008-10-09 14:20 UTC (permalink / raw)
To: Knut Eldhuset; +Cc: git@vger.kernel.org >> Git Mailing List
In-Reply-To: <48EC7B52.4000100@3d-radar.com>
Knut Eldhuset venit, vidit, dixit 08.10.2008 11:20:
> Michael J Gruber wrote:
>> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
>>> Michael J Gruber wrote:
>>>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>>>> Hi,
>>>>>
>>>>> After cloning my svn repository, I notice that the svn-id URL is
>>>>> different when going back in history:
>>>>>
>>>>> git-svn-id: https://server/trunk@300
>>>>>
>>>>> vs
>>>>>
>>>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>>>
>>>> I take this is as an invitation for guesswork (given the amount of
>>>> details)...
>>> Sorry about that... I'm confused.
>>>> You probably have commits which don't follow your usual svn repo layout
>>>> (trunk/some_folder/project/src) but commit to trunk/ directly. The output of
>>>>
>>>> svn log -v -r300 https://server/trunk@300
>>>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>>>
>>>> should give some clues.
>>>>
>>> Svn log shows that the same path has been modified in both cases. I see
>> Does "same path" mean:
>> - same relative to the above paths or
>> - same absolute path?
>
> Both say "/trunk/some_folder/project/src/some_file".
>
>>> something strange in git, though. Our svn repository has about 6500
>>> commits, but git shows over 10.000. Further investigation shows that a
>>> lot of svn commits have two entries in git. Some branches off of trunk
>>> do not start at r1, but off of a duplicate rNNNN. Could this be due to
>>> our unhealthy practice of creating branches off of subtrees in svn? By
>>> this I mean create a branch off of
>>> https://server/trunk/some_folder/project/src instead of
>>> https://server/trunk. If so, what can be done to fix this?
>>>
>>> As a sidenote, during git svn clone, I noticed that each time a new
>>> branch or tag was discovered, the "scanning" started back at r1. Is this
>>> normal? I would think the history before the branch was already
>>> imported. Of course, this could maybe be due to the bad branching
>>> practice described above.
>> svn is typically "abused" in the sense that one svn repo is used for
>> separate projects (your subtrees). git-svn can deal with non-standard
>> repo layouts.
>>
>> I assume you can't share the svn repo publically, can you?
>
> Sorry, no.
>
>> So, in order to help you, we would need to know
>>
>> - the layout of your svn repo: where are trunk, branches and tags, how
>> did you create branches and tags in svn, are "projects" entirely separate
>
> https://server/trunk
> https://server/branches
> https://server/tags
>
> We really only have one "project" source tree at
> https://server/trunk/some_folder/project/src
>
> However, once the sources were at
> https://server/trunk/some_folder/project/old_source
That may be the source of the trouble. In fact, the log below indicates
that it is more like the following two paths:
https://server/trunk/project/old_source
https://server/trunk/project/src/client
> Therefore we have the following:
>
> $ svn log -v -r4871 https://server/
> ------------------------------------------------------------------------
> r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
> D /trunk/project/old_source/some_file
> A /trunk/project/src/client/some_file (from
> /trunk/project/old_source/some_file:4795)
>
> commit-message
> ------------------------------------------------------------------------
>
> $ svn log -v -r4869 https://server/
> ------------------------------------------------------------------------
> r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
> A /trunk/project/src
> A /trunk/project/src/client
>
> commit-message
>
> ------------------------------------------------------------------------
>
> $ svn log -v -r4868 https://server/
> ------------------------------------------------------------------------
> r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
>
> commit-message
>
That one is funny. A modified directory but no paths modified
underneath. Was this a propset?
> ------------------------------------------------------------------------
>
> $ svn log -v -r4867 https://server/
> ------------------------------------------------------------------------
> r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
> A /trunk/project/some_file
>
> commit-message
> ------------------------------------------------------------------------
Maybe you're trying too hard to disguise things. Are you really adding
some_file right under project here and under project/src/client in r4871?
>
> r4868 appears twice in git. One commit is on master/trunk and has parent
> and child, while the other is on a branch and has no parent.
>
>> - your incarnation of git-svn
>>
>
> # git --version
> git version 1.6.0.2
I actually meant incantation, I guess I should brush up on my little
latin, uhm ;)
So, did you use something like
git svn init -s https://server/
or
git svn init -T trunk/project/src/client -t 'tags/*/project/src/client'
-b 'branches/*/project/src/client' https://server/
My suggestion would to use two svn sections (option "-R") with different
configs for different repo structures, and to fetch the first one with
"-r1:4866" and the second one with "-r4871:HEAD". Reorganising the svn
repo layout can confuse git-svn quite a bit (and understandably so).
Using different configs for different "epochs" helps. grafts are your
friend when it comes to connecting the two.
Michael
^ permalink raw reply
* Re: [PATCH maint] builtin-merge.c: fix memory under-allocation
From: Brandon Casey @ 2008-10-09 14:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Shawn O. Pearce, Git Mailing List
In-Reply-To: <7vmyheowcr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>> I didn't mean to imply that the memory under-allocation
>> was caused by a change in variable type in this case. Re-reading my commit
>> message, maybe it sounds like that.
>
> Yeah, it does. I was scratching my head and had to read the patch three
> times until I got it (yes, I am especially slower than usual today, as the
> reason I am reading mails right now is because I am jetlagged and cannot
> sleep).
If it's not too late, maybe this would make a better commit message:
--->8---
builtin-merge.c: allocate correct amount of memory
Fix two memory allocation errors which allocate space for a pointer rather
than enough space for the structure itself.
This:
struct commit_list *parent = xmalloc(sizeof(struct commit_list *));
should have been this:
struct commit_list *parent = xmalloc(sizeof(struct commit_list));
But while we're at it, change the allocation to reference the variable it is
allocating memory for to try to prevent a similar mistake, for example if the
type is changed, in the future.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
^ permalink raw reply
* [PATCH] builtin-apply: fix typo leading to stack corruption
From: Imre Deak @ 2008-10-08 21:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This typo led to stack corruption for lines > 1024 if whitespace fixing
is in effect.
Signed-off-by: Imre Deak <imre.deak@gmail.com>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 20bef1f..720dc7f 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1696,7 +1696,7 @@ static int match_fragment(struct image *img,
fixlen = ws_fix_copy(buf, orig, oldlen, ws_rule, NULL);
/* Try fixing the line in the target */
- if (sizeof(tgtfixbuf) < tgtlen)
+ if (sizeof(tgtfixbuf) > tgtlen)
tgtfix = tgtfixbuf;
else
tgtfix = xmalloc(tgtlen);
--
1.6.0.2.308.g754c
^ permalink raw reply related
* [RFD] Sparse checkout, unmerged entries and "reset --hard"
From: Nguyen Thai Ngoc Duy @ 2008-10-09 13:45 UTC (permalink / raw)
To: Git Mailing List
Hi,
There is a problem with those things and I don't know how to handle
it. In brief, in "git reset --hard" (or "git read-tree --reset"),
unmerged entries will be removed from in-memory index, so merge
process does not see them and re-add them like new entries. But with
sparse checkout, "new entries" and "merged entries" are handled
differently. This may lead to stale/orphaned entries.
The detail:
1. unmerged entries are filtered out from cmd_read_tree() if --reset
is provided.
2. inside unpack_trees(), [1-3]way_merge() pass src[0] (which is NULL
in unmerged cases) to merged_entry()
3. merged_entry() sees it as "no old entry so this must be new
entry", it makes sure there is no real file in working directory, but
then the check is ignored in --reset mode.
4. entries get added as new ones.
With sparse checkout, in the last two steps, it would check if new
entry matches default sparse pattern (which determines if the entry
should be added to working directory). In case it decides the entry
should not be added to working directory, it would remove CE_UPDATE
flag from the entry. This is fine for _true_ new entries. But in
unmerged case, it would leave a stale/orphaned entry in working
directory while it is marked no-checkout in index.
I would expect sparse checkout work correctly even in unmerged case.
That is the entry is removed from working directory (if outside sparse
pattern), staged entries are removed in index, stage 0 entry is added
with no-checkout flag.
Comments? Maybe doing a two-phase merge (unmerged entries first, the
rest later)?
--
Duy
^ permalink raw reply
* Re: [PATCH] builtin-apply: fix typo leading to stack corruption
From: Junio C Hamano @ 2008-10-09 12:51 UTC (permalink / raw)
To: Imre Deak; +Cc: git
In-Reply-To: <48ed30f5.0707d00a.2994.6f1e@mx.google.com>
Looks good and would look better with a sign-off.
^ permalink raw reply
* Re: [RFC PATCH v2] Documentation: add manpage about workflows
From: Junio C Hamano @ 2008-10-09 12:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, santi, Dmitry Potapov, Junio C Hamano
In-Reply-To: <1223552537-6918-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
> new file mode 100644
> index 0000000..037ace5
> --- /dev/null
> +++ b/Documentation/gitworkflows.txt
> @@ -0,0 +1,362 @@
> +gitworkflows(7)
> +===============
> ...
> +DESCRIPTION
> +-----------
> +
> +This document attempts to write down and motivate some of the workflow
> +elements used for `git.git` itself. Many ideas apply in general,
> +though the full workflow is rarely required for smaller projects with
> +fewer people involved.
Hmm. Even though I have to wonder if the workflow used in git.git should
be treated as a representative BCP. For one thing, git.git is on the
smaller end of the spectrum (from the point of view of the size of the
codebase, but not from the size of the contributor base), it is something
we know well enough and probably is a good place to take examples from.
> +Graduation
> +~~~~~~~~~~
> +
> +As a given feature goes from experimental to stable, it also
> +"graduates" between the corresponding branches of the software.
> +`git.git` uses the following 'main branches':
> +
> +* 'maint' tracks the commits that should go into the next "maintenance
> + release", i.e., update of the last released stable version;
> +
> +* 'master' tracks the commits that should go into the next release;
> +
> +* 'next' is intended as a testing branch for topics not stable enough
> + for master yet.
s/not stable enough/being tested for stability/;s/ yet//;
The point being that commits on next are deemed stable enough from code
inspection but are kept out of master for a while because your maintainer
wants to be extra careful.
> +Topic branches
> +~~~~~~~~~~~~~~
> +
> +Any nontrivial feature will require several patches to implement, and
> +may get extra bugfixes or improvements during its lifetime.
> +
> +Committing everything directly on the main branches leads to many
> +problems: Bad commits cannot be undone, so they must be reverted one
> +by one, which creates confusing histories and further error potential
> +when you forget to revert part of a group of changes. Working in
> +parallel mixes up the changes, creating further confusion.
> +
> +The key concept here is "topic branches". The name is pretty self
> +explanatory, with a caveat that comes from the "merge upwards" rule
> +above:
I'd reword the first sentence --- Use of "Topic branches" solves these
problems.
> +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: upstream API changes affect your branch; your
> + branch no longer merges to upstream cleanly; etc.
> +
> +* 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.
This description misses the most important reason why merging into topic
branches is not a good idea. Once you merge a general purpose integration
branch such as master into a topic branch, the branch ceases to be about
the single topic. It becomes "the topic and other unrelated changes mixed
together".
> +Integration branches
> +~~~~~~~~~~~~~~~~~~~~
Nomenclature. I think we use the word "integration branches" to mean the
stable branches such as maint/master/next, not the ones you use for
throw-away test merges.
Always merging upward is a good rule, and this is when used with topic
branches, there is one twist you did not mention but is worth knowing
about. A topic that is meant to eventually merge into older integration
branch (e.g. maint) does not necessarily have to be merged to its final
destination branch first. I often do this:
git checkout tr/maint-fix-bla maint
git am -s fix-mail-from-thomas.txt
git checkout next
git merge tr/maint-fix-bla
... cook further, perhaps adding more commits to
... tr/maint-fix-bla topic and merging the result to next;
... and then when the topic appears to be stable do:
git checkout master
git merge tr/maint-fix-bla
... and later
git checkout maint
git merge tr/maint-fix-bla
git branch -d tr/maint-fix-bla
This keeps older integration branches stale, until the topic really gets
proven to be regression-free in the field. This workflow is safer and
more suitable for a final integration branch to which a known breakage is
better than an unintended regression. An alternative would be what the
reader would assume from your description of merging upwards, which would
look like this:
git checkout tr/maint-fix-bla maint
git am -s fix-mail-from-thomas.txt
git checkout maint
git merge tr/maint-fix-bla
git checkout master
git merge maint
git checkout next
git merge master
This can regress maint unintentionally and then the regression is
propagated upwards to contaminate all integration branches.
^ permalink raw reply
* [RFC PATCH v2] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-10-09 11:42 UTC (permalink / raw)
To: git; +Cc: santi, Dmitry Potapov, Junio C Hamano
In-Reply-To: <adf1fd3d0810010254k5961b182ked9acda55e2aa57c@mail.gmail.com>
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>
---
[Apologies if some of the Cc's were sent twice; I got a bounce because
of non-ASCII headers and was unable to tell if any were delivered.]
Let's try another iteration.
I decided the "MANAGING BRANCHES" introduction paragraph was a good
place to (finally) mention the points about merge vs. cherry-pick
raised by Dmitry earlier.
I think I've addressed the other concerns, except for the "SHARING
WORK" section, now renamed to "DISTRIBUTED WORKFLOWS":
Santi Béjar wrote:
> Sorry, but I don't see the point explaining how to publish the
> branches, or keep them up to date.
I feel it needs to be explained _somewhere_, since pull is designed to
make the merge workflow as easy as possible, and then push/fetch are
needed to complete the picture (especially so since I'm trying to make
a point of highlighting when not to use pull). Maybe you can/want to
convince me otherwise.
And note that push is not explained in gittutorial.txt, only linked.
It is explained in gitcore-tutorial.txt, but that says
However, an understanding of these low-level tools can be helpful if
you want to understand git's internals.
in the introduction. I don't really expect any user to read any
further after hearing that everything in there is "low-level". Maybe
some tutorial cleanup would be in order.
Other than that, I'll wait for some more comments, then polish up the
commit message and submit "for real".
Interdiff will follow, as before.
- Thomas
Documentation/Makefile | 2 +-
Documentation/gitworkflows.txt | 362 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 363 insertions(+), 1 deletions(-)
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..037ace5
--- /dev/null
+++ b/Documentation/gitworkflows.txt
@@ -0,0 +1,362 @@
+gitworkflows(7)
+===============
+
+NAME
+----
+gitworkflows - An overview of recommended workflows with git
+
+SYNOPSIS
+--------
+git *
+
+
+DESCRIPTION
+-----------
+
+This document attempts to write down and motivate some of the workflow
+elements used for `git.git` itself. Many ideas apply in general,
+though the full workflow is rarely required for smaller projects with
+fewer people involved.
+
+We formulate a set of 'rules' for quick reference, while the prose
+tries to motivate each of them. Do not always take them literally;
+you should value good reasons for your actions higher than manpages
+such as this one.
+
+
+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.
+This makes the review process much easier, and the history much more
+useful for later inspection and analysis, for example with
+linkgit:git-blame[1] and linkgit:git-bisect[1].
+
+To achieve this, try to split your work into small steps from the very
+beginning. It is always easier to squash a few commits together than
+to split one big commit into several. Don't be afraid of making too
+small or imperfect steps along the way. You can always go back later
+and edit the commits with `git rebase \--interactive` before you
+publish them. You can use `git stash save \--keep-index` to run the
+test suite independent of other uncommitted changes; see the EXAMPLES
+section of linkgit:git-stash[1].
+
+
+MANAGING BRANCHES
+-----------------
+
+There are two main tools that can be used to include changes from one
+branch on another: linkgit:git-merge[1] and
+linkgit:git-cherry-pick[1].
+
+Merges have many advantages, so we try to solve as many problems as
+possible with merges alone. Cherry-picking is still occasionally
+useful; see "Merging upwards" below for an example.
+
+Most importantly, merging works at the branch level, while
+cherry-picking works at the commit level. This means that a merge can
+carry over the changes from 1, 10, or 1000 commits with equal ease,
+which in turn means the workflow scales much better to a large number
+of contributors (and contributions). Merges are also easier to
+understand because a merge commit is a "promise" that all changes from
+all its parents are now included.
+
+There is a tradeoff of course: merges require a more careful branch
+management. The following subsections discuss the important points.
+
+
+Graduation
+~~~~~~~~~~
+
+As a given feature goes from experimental to stable, it also
+"graduates" between the corresponding branches of the software.
+`git.git` uses the following 'main branches':
+
+* 'maint' tracks the commits that should go into the next "maintenance
+ release", i.e., update of the last released stable version;
+
+* 'master' tracks the commits that should go into the next release;
+
+* 'next' is intended as a testing branch for topics not stable enough
+ for master yet.
+
+There is a fourth official branch that is used slightly differently:
+
+* 'pu' (proposed updates) is an integration branch for things that are
+ not quite ready for inclusion yet (see "Integration Branches"
+ below).
+
+Each of the four branches is usually a direct descendant of the one
+above it.
+
+Conceptually, the feature enters at an unstable branch (usually 'next'
+or 'pu'), and "graduates" to 'master' for the next release once it is
+considered stable enough.
+
+
+Merging upwards
+~~~~~~~~~~~~~~~
+
+The "downwards graduation" discussed above cannot be done by actually
+merging downwards, however, since that would merge 'all' changes on
+the unstable branch into the stable one. 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 very frequently.
+
+
+Topic branches
+~~~~~~~~~~~~~~
+
+Any nontrivial feature will require several patches to implement, and
+may get extra bugfixes or improvements during its lifetime.
+
+Committing everything directly on the main branches leads to many
+problems: Bad commits cannot be undone, so they must be reverted one
+by one, which creates confusing histories and further error potential
+when you forget to revert part of a group of changes. Working in
+parallel mixes up the changes, creating further confusion.
+
+The key concept here is "topic branches". The name is pretty self
+explanatory, with a caveat that comes from the "merge upwards" rule
+above:
+
+.Topic branches
+[caption="Rule: "]
+=====================================
+Make a side branch for every topic (feature, bugfix, ...). 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 the branch 'other' 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: upstream API changes affect your branch; your
+ branch no longer merges to upstream cleanly; etc.
+
+* 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.
+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. You must never base any work on such a 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. `git.git`
+has such an official integration branch called 'pu'.
+
+
+DISTRIBUTED WORKFLOWS
+---------------------
+
+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: merge and patch.
+The important difference is that the merge workflow can propagate full
+history, including merges, while patches cannot. Both workflows can
+be used in parallel: in `git.git`, only subsystem maintainers use
+the merge workflow, while everyone else sends patches.
+
+Note that the maintainer(s) may impose restrictions, such as
+"Signed-off-by" requirements, that all commits/patches submitted for
+inclusion must adhere to. Consult your project's documentation for
+more information.
+
+
+Merge workflow
+~~~~~~~~~~~~~~
+
+The merge workflow works by copying branches between upstream and
+downstream. Upstream can merge contributions into the official
+history; downstream base their work on the official history.
+
+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 does 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 looks like
+
+-------------------------------------
+Please pull from
+ <url> <branch>
+-------------------------------------
+
+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 resolve them). It is one of the rare cases where
+downstream 'should' merge from upstream.
+
+
+Patch workflow
+~~~~~~~~~~~~~~
+
+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` to turn them into preformatted
+ patch files
+* `git send-email --to=<recipient> <patches>`
+=====================================
+
+See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
+manpages for further usage notes.
+
+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 pull --rebase <url> <branch>`
+=====================================
+
+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 series (as maintainer, or perhaps as a
+reader of the mailing list it was sent to), save the mails to files,
+create a new topic branch and use 'git-am' to import the commits:
+
+.format-patch/am: Importing patches
+[caption="Recipe: "]
+=====================================
+`git am < patch`
+=====================================
+
+One feature worth pointing out is the three-way merge, which can help
+if you get conflicts: `git am -3` will use index information contained
+in patches to figure out the 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-send-email[1],
+linkgit:git-am[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
--
tg: (2de69d4..) t/doc-workflows (depends on: origin/master t/doc-rebase-warn t/doc-rebase-refer)
^ permalink raw reply related
* [Interdiff] [RFC PATCH v2] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-10-09 11:42 UTC (permalink / raw)
To: git; +Cc: santi, Dmitry Potapov, Junio C Hamano
In-Reply-To: <1223552537-6918-1-git-send-email-trast@student.ethz.ch>
---
I wrote:
> Interdiff will follow, as before.
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 87c2270..037ace5 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -39,24 +39,32 @@ beginning. It is always easier to squash a few commits together than
to split one big commit into several. Don't be afraid of making too
small or imperfect steps along the way. You can always go back later
and edit the commits with `git rebase \--interactive` before you
-publish them.
+publish them. You can use `git stash save \--keep-index` to run the
+test suite independent of other uncommitted changes; see the EXAMPLES
+section of linkgit:git-stash[1].
MANAGING BRANCHES
-----------------
-Usually a feature (or other change) evolves in stages: it "graduates"
-from patch to the testing branches and on to stable releases. During
-this process, it may require fixes or improvements. XXX terrible
-paragraph XXX
+There are two main tools that can be used to include changes from one
+branch on another: linkgit:git-merge[1] and
+linkgit:git-cherry-pick[1].
-Merges (as opposed to cherry-picks, see below) greatly simplify
-handling large numbers of commits, so a scalable workflow needs to use
-merges. Fortunately Git is very good at merging.
+Merges have many advantages, so we try to solve as many problems as
+possible with merges alone. Cherry-picking is still occasionally
+useful; see "Merging upwards" below for an example.
-XXX non sequitur XXX
-In the following sections we discuss some problems that arise from
-such a "change flow", and how to solve them with Git.
+Most importantly, merging works at the branch level, while
+cherry-picking works at the commit level. This means that a merge can
+carry over the changes from 1, 10, or 1000 commits with equal ease,
+which in turn means the workflow scales much better to a large number
+of contributors (and contributions). Merges are also easier to
+understand because a merge commit is a "promise" that all changes from
+all its parents are now included.
+
+There is a tradeoff of course: merges require a more careful branch
+management. The following subsections discuss the important points.
Graduation
@@ -66,13 +74,13 @@ As a given feature goes from experimental to stable, it also
"graduates" between the corresponding branches of the software.
`git.git` uses the following 'main branches':
-* 'master' tracks the commits that should go into the next release;
-
* 'maint' tracks the commits that should go into the next "maintenance
- release", i.e., update of the last released stable version; and
+ release", i.e., update of the last released stable version;
-* 'next' is intended as a testing branch for people who like to use
- more experimental stuff.
+* 'master' tracks the commits that should go into the next release;
+
+* 'next' is intended as a testing branch for topics not stable enough
+ for master yet.
There is a fourth official branch that is used slightly differently:
@@ -80,6 +88,9 @@ There is a fourth official branch that is used slightly differently:
not quite ready for inclusion yet (see "Integration Branches"
below).
+Each of the four branches is usually a direct descendant of the one
+above it.
+
Conceptually, the feature enters at an unstable branch (usually 'next'
or 'pu'), and "graduates" to 'master' for the next release once it is
considered stable enough.
@@ -88,10 +99,9 @@ considered stable enough.
Merging upwards
~~~~~~~~~~~~~~~
-As explained above, features conceptually "graduate downwards" to
-older releases. This cannot be done by actually merging downwards,
-however, since that would merge 'all' changes on the unstable branch
-into the stable one. Hence the following:
+The "downwards graduation" discussed above cannot be done by actually
+merging downwards, however, since that would merge 'all' changes on
+the unstable branch into the stable one. Hence the following:
.Merge upwards
[caption="Rule: "]
@@ -187,45 +197,41 @@ into a throw-away branch.
[caption="Rule: "]
=====================================
To test the interaction of several topics, merge them into a
-throw-away branch.
+throw-away branch. You must never base any work on such a 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. `git.git`
-has such an official integration branch called 'pu'. You must never
-base any work on such a throw-away branch!
+has such an official integration branch called 'pu'.
-SHARING WORK
-------------
+DISTRIBUTED WORKFLOWS
+---------------------
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: push/pull and
-format-patch/am. The important difference is that push/pull can
-propagate merges, while format-patch cannot. Medium to large projects
-will typically employ some mixture of the two:
+Roughly speaking, there are two important workflows: merge and patch.
+The important difference is that the merge workflow can propagate full
+history, including merges, while patches cannot. Both workflows can
+be used in parallel: in `git.git`, only subsystem maintainers use
+the merge workflow, while everyone else sends patches.
-* "Upstream" in the most general sense 'pushes' changes to the
- repositor(ies) holding the official history of the project.
- Everyone can 'fetch' from there to stay up to date.
+Note that the maintainer(s) may impose restrictions, such as
+"Signed-off-by" requirements, that all commits/patches submitted for
+inclusion must adhere to. Consult your project's documentation for
+more information.
-* Frequent contributors, subsystem maintainers, etc. may push to a
- public repository to make their changes available to 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.
+Merge workflow
+~~~~~~~~~~~~~~
-Push/pull
-~~~~~~~~~
+The merge workflow works by copying branches between upstream and
+downstream. Upstream can merge contributions into the official
+history; downstream base their work on the official history.
There are three main tools that can be used for this:
@@ -267,11 +273,11 @@ 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
+do so by mail. Such a request looks like
-------------------------------------
Please pull from
- git://some.server.somewhere/random/repo.git mytopic
+ <url> <branch>
-------------------------------------
In that case, 'git-pull' can do the fetch and merge in one go, as
@@ -290,8 +296,8 @@ know better how to resolve them). It is one of the rare cases where
downstream 'should' merge from upstream.
-format-patch/am
-~~~~~~~~~~~~~~~
+Patch workflow
+~~~~~~~~~~~~~~
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
@@ -308,9 +314,7 @@ maintainer's life easier).
=====================================
See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
-manpages for further usage notes. Also you should be aware that the
-maintainer may impose further restrictions, such as "Signed-off-by"
-requirements.
+manpages for further usage notes.
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
@@ -326,11 +330,11 @@ 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 as a reader of
-the mailing list it was sent to), save the mail to a file and use
-'git-am':
+If you receive such a patch series (as maintainer, or perhaps as a
+reader of the mailing list it was sent to), save the mails to files,
+create a new topic branch and use 'git-am' to import the commits:
-.format-patch/am: Publishing branches/topics
+.format-patch/am: Importing patches
[caption="Recipe: "]
=====================================
`git am < patch`
^ permalink raw reply related
* Re: [PATCH/RFC] Add post-init hook
From: Alex Riesen @ 2008-10-09 11:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jonathan del Strother, git
In-Reply-To: <7viqs2ovte.fsf@gitster.siamese.dyndns.org>
2008/10/9 Junio C Hamano <gitster@pobox.com>:
> Jeff King <peff@peff.net> writes:
>> On Wed, Oct 08, 2008 at 09:16:56AM +0100, Jonathan del Strother wrote:
>> ...
>>> I want symlinks so I only have to edit my hooks in one place whenever
>>> I change them)
>>
>> This makes a lot of sense to me as a best-practice. I wonder if we
>> wouldn't do better to add a core.symlink-templates option?
>
> AFAIR, "git init" copies symlinks in templates as symlinks, so I do not
> see why you would even want to have such an option.
>
> Wouldn't it be better if users and installations with such a special
> set of templates specified by core.template or --template prepare a
> template directory with files and symbolic links of their liking? If
> they want some hooks to point at the latest copy of installation specific
> standard hook script, templates/hooks/$that_hook can be a symlink to the
> real location, no?
It will be replaced with a file next time you update your git installation.
Seems like we need ~/.gitconfig/*...
^ permalink raw reply
* Re: [PATCH/RFC] Add post-init hook
From: Jeff King @ 2008-10-09 11:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan del Strother, git
In-Reply-To: <7viqs2ovte.fsf@gitster.siamese.dyndns.org>
On Thu, Oct 09, 2008 at 04:24:29AM -0700, Junio C Hamano wrote:
> > This makes a lot of sense to me as a best-practice. I wonder if we
> > wouldn't do better to add a core.symlink-templates option?
>
> AFAIR, "git init" copies symlinks in templates as symlinks, so I do not
> see why you would even want to have such an option.
Ah, I didn't realize that. In that case, yes, setting up a template
directory of symlinks makes the most sense. I think a core.template
option is still worthwhile, though.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] Add post-init hook
From: Junio C Hamano @ 2008-10-09 11:24 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan del Strother, git
In-Reply-To: <20081009014146.GA14204@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 08, 2008 at 09:16:56AM +0100, Jonathan del Strother wrote:
> ...
>> I want symlinks so I only have to edit my hooks in one place whenever
>> I change them)
>
> This makes a lot of sense to me as a best-practice. I wonder if we
> wouldn't do better to add a core.symlink-templates option?
AFAIR, "git init" copies symlinks in templates as symlinks, so I do not
see why you would even want to have such an option.
Wouldn't it be better if users and installations with such a special
set of templates specified by core.template or --template prepare a
template directory with files and symbolic links of their liking? If
they want some hooks to point at the latest copy of installation specific
standard hook script, templates/hooks/$that_hook can be a symlink to the
real location, no?
^ permalink raw reply
* Re: [PATCH maint] builtin-merge.c: fix memory under-allocation
From: Junio C Hamano @ 2008-10-09 11:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: Miklos Vajna, Shawn O. Pearce, Git Mailing List
In-Reply-To: <0LPLRUZaEHuEZTri_v38ySJHqYAhrfOpOkyUviUH9eOrx8IXBEAzYA@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Miklos Vajna wrote:
>> On Wed, Oct 08, 2008 at 07:07:54PM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>> While we're at it, change the allocation to reference the variable it is
>>> allocating memory for to try to prevent a similar mistake if the type is
>>> changed in the future.
>>
>> If this is really a problem, then I think it would be good to mention
>> this in Documentation/CodingGuidelines.
>
> That's fine. Though I didn't mean to imply that the memory under-allocation
> was caused by a change in variable type in this case. Re-reading my commit
> message, maybe it sounds like that.
Yeah, it does. I was scratching my head and had to read the patch three
times until I got it (yes, I am especially slower than usual today, as the
reason I am reading mails right now is because I am jetlagged and cannot
sleep).
^ permalink raw reply
* Re: [PATCH] Implement git clone -v
From: Junio C Hamano @ 2008-10-09 11:06 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Shawn O. Pearce, Alex Riesen, Constantine Plotnikov, git
In-Reply-To: <1223509232-3520-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> The new -v option forces the progressbar, even in case the output is not
> a terminal.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
The patch made me wonder why this new feature had to be implemented in the
first place and had me look up the message the patch was an follow-up to.
For somebody who would not recall the original request-for-feature (that
includes you 6 months from now), it would have been easier to understand
the context if the commit message said what the intended purpose of this
(i.e. "have it read by an IDE").
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Paul Mackerras @ 2008-10-09 11:02 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <bb6f213e0810090112l60d7b4c3v42e42d9d769c6057@mail.gmail.com>
Alexander Gavrilov writes:
> On Thu, Oct 9, 2008 at 4:27 AM, Paul Mackerras <paulus@samba.org> wrote:
> >> + catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
> >
> > What is this key, or why is this line needed?
>
> It is a workaround for an apparent bug in interaction between Tk and
> XKB on some systems.
> XKB configuration files bind those symbols to Ctrl-Alt-F*
> combinations, but Tk's keyboard
> handiling code sees them when Shift-F* is pressed. I'll be glad to
> find a better fix, but that's
> all I could do for now.
OK, that information should go in the patch description.
> > You need to change the error returns in domktag to say "return 0",
> > otherwise this will give a "can't use empty string as operand of "!""
> > Tcl error.
>
> I did not know this. I'm not that familiar with Tcl...
Then I am amazed at how much you have been able to accomplish...
There's a lot of information available in the Tcl/Tk man pages. On
Debian or Ubuntu, you need the tcl8.5-doc and tk8.5-doc packages
installed. Then you can do e.g. "man 3tcl Tcl" to get a summary of
the Tcl language syntax, etc.
BTW, I haven't forgotten about your encoding support patches. The
last month has been occupied with travelling for Kernel Summit and the
Linux Plumbers Conference, followed by a vacation, and then catching
up with work that has piled up, so I haven't had much time to spare
for gitk hacking.
Paul.
^ permalink raw reply
* Re: [PATCH 5/7] gitk: Make cherry-pick call git-citool on conflicts.
From: Paul Mackerras @ 2008-10-09 10:57 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <bb6f213e0810090124i62a51e92n45836ee02577331a@mail.gmail.com>
Alexander Gavrilov writes:
> If I understand correctly, using a shell would require composing the
> command as a string, which itself requires quoting the author name & email,
> and other argument strings. I did not feel confident enough to do that, so
> chose a dumb but safe solution.
You're right. I think we should do it basically the way you suggest,
but the saving/restoring of the environment can be done a bit more
concisely like this:
proc exec_citool {args {baseid {}}} {
global commitinfo env
set save_env [array get env GIT_AUTHOR_*]
if {$baseid ne {}} {
# as before ...
}
eval exec git citool $args &
catch {array unset env GIT_AUTHOR_*}
array set env $save_env
}
> I'm more used to languages where lists and strings are very different types...
> Even in perl you have to use [] for an empty list ref, and '' for an
> empty string.
In Tcl, everything is a string. :)
Paul.
^ permalink raw reply
* [StGit PATCH 2/2] Always resolve "git describe" to something
From: Samuel Tardieu @ 2008-10-09 9:02 UTC (permalink / raw)
To: git
In-Reply-To: <20081009090157.12637.45887.stgit@arrakis.enst.fr>
Sometimes, "git describe" cannot describe the current version. Use
"--always" so that we have a fallback.
---
stgit/version.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/version.py b/stgit/version.py
index d57053d..05fa8e9 100644
--- a/stgit/version.py
+++ b/stgit/version.py
@@ -8,7 +8,7 @@ class VersionUnavailable(StgException):
def git_describe_version():
path = sys.path[0]
try:
- v = run.Run('git', 'describe', '--tags', '--abbrev=4'
+ v = run.Run('git', 'describe', '--tags', '--abbrev=4', '--always'
).cwd(path).output_one_line()
except run.RunException, e:
raise VersionUnavailable(str(e))
^ permalink raw reply related
* [StGit PATCH 1/2] Handle "git diff-tree --stdin" error
From: Samuel Tardieu @ 2008-10-09 9:01 UTC (permalink / raw)
To: git
If, for any reason, one of the SHA1 is not a commit object,
"git diff-tree --stdin" will signal an error on its standard
error and will only issue the requested "end" pattern.
"stg diff" could wait forver for the right references to
happen. With this patch, we now get:
% stg diff
stg diff: error: Object 6daaab2215a3d277a315d6938bdda86b2f75f6af not a commit
---
stgit/lib/git.py | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index 4f210f8..45c0b32 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -579,10 +579,10 @@ class DiffTreeProcesses(object):
p.stdin.write(query + end)
p.stdin.flush()
s = ''
- while not (s.endswith('\n' + end) or s.endswith('\0' + end)):
+ while not s.endswith(end):
s += os.read(p.stdout.fileno(), 4096)
- assert s.startswith(query)
- assert s.endswith(end)
+ if not s.startswith(query):
+ raise RepositoryException(os.read(p.stderr.fileno(), 4096))
return s[len(query):-len(end)]
class Repository(RunWithEnv):
^ permalink raw reply related
* Re: Fwd: git status options feature suggestion
From: Johannes Schindelin @ 2008-10-09 9:03 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0810082327q71b9d6apf2787eb8519031bb@mail.gmail.com>
Hi,
On Thu, 9 Oct 2008, Caleb Cushing wrote:
> > How about "git ls-files -o"?
>
> doh... hadn't even heard of that command.
Which is good! As ls-files is listed as plumbing. Users should not need
to call ls-files, so I like your idea about adding --new, --untracked etc.
to "git status" (I do not agree with others that "git status" has to stay
that non-existant "git commit --dry-run").
Could you list exactly which options you want implemented?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/7] gitk: Make cherry-pick call git-citool on conflicts.
From: Alexander Gavrilov @ 2008-10-09 8:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18669.46569.45285.170033@cargo.ozlabs.ibm.com>
On Thu, Oct 9, 2008 at 11:42 AM, Paul Mackerras <paulus@samba.org> wrote:
>> +proc exec_citool {args {baseid {}}} {
>
> I'm a little nervous about you having a parameter called "args", since
> that specific name has a special meaning in Tcl; it's how Tcl handles
> variable-length argument lists.
Yes, I'd better change that. Probably it works only because that name is
special only as the last parameter.
> If we can assume the existence of a shell (which we do elsewhere), we
> can perhaps do this more simply by putting the environment variable
> settings in the command before the command name. It's a pity that git
> citool won't take the author name/email/date as command-line arguments
> or from a file, since it ends up being pretty verbose doing it the way
> you have.
If I understand correctly, using a shell would require composing the
command as a string, which itself requires quoting the author name & email,
and other argument strings. I did not feel confident enough to do that, so
chose a dumb but safe solution.
>> @@ -7861,7 +7908,17 @@ proc cherrypick {} {
>> # no error occurs, and exec takes that as an indication of error...
>> if {[catch {exec sh -c "git cherry-pick -r $rowmenuid 2>&1"} err]} {
>> notbusy cherrypick
>> - error_popup $err
>> + if {[regexp -line \
>> + {Entry '(.*)' would be overwritten by merge} $err msg fname]} {
>> + error_popup [mc "Cherry-pick failed: file '%s' had local modifications.
>> +Your working directory is in an inconsistent state." $fname]
>
> That message seems a bit too scary. It's not inconsistent, it's just
> got local modifications. If I remember correctly, in this situation
> git cherry-pick will back out all the changes it did and leave the
> working directory as it was before.
Yes, I'll have to reword it.
> [list] as an idiom for the empty list is a little unusual (here and
> elsewhere in your patches); {} would be more usual.
I'm more used to languages where lists and strings are very different types...
Even in perl you have to use [] for an empty list ref, and '' for an
empty string.
Alexander
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Alexander Gavrilov @ 2008-10-09 8:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18669.20487.88439.584567@cargo.ozlabs.ibm.com>
On Thu, Oct 9, 2008 at 4:27 AM, Paul Mackerras <paulus@samba.org> wrote:
>> + catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
>
> What is this key, or why is this line needed?
It is a workaround for an apparent bug in interaction between Tk and
XKB on some systems.
XKB configuration files bind those symbols to Ctrl-Alt-F*
combinations, but Tk's keyboard
handiling code sees them when Shift-F* is pressed. I'll be glad to
find a better fix, but that's
all I could do for now.
The catch wrapper is there to avoid erroring out if that keysym does not exist.
>> @@ -2484,10 +2501,10 @@ proc keys {} {
>>
>> -[mc "<%s-Q> Quit" $M1T]
>> [mc "<Home> Move to first commit"]
>> [mc "<End> Move to last commit"]
>> [mc "<Up>, p, i Move up one commit"]
>> @@ -2521,11 +2538,11 @@ proc keys {} {
>> [mc "<%s-plus> Increase font size" $M1T]
>> [mc "<%s-KP-> Decrease font size" $M1T]
>> [mc "<%s-minus> Decrease font size" $M1T]
>> -[mc "<F5> Update"]
>
> I think it is useful to have the accelerator keys listed in the key
> binding help.
I don't insist on this part of the patch, it just seemed to be redundant now.
>> @@ -7501,6 +7534,7 @@ proc domktag {} {
>> addedtag $id
>> dispneartags 0
>> run refill_reflist
>> + return 1
>> }
>>
>> proc redrawtags {id} {
>> @@ -7539,7 +7573,7 @@ proc mktagcan {} {
>> }
>>
>> proc mktaggo {} {
>> - domktag
>> + if {![domktag]} return
>
> You need to change the error returns in domktag to say "return 0",
> otherwise this will give a "can't use empty string as operand of "!""
> Tcl error.
I did not know this. I'm not that familiar with Tcl...
Alexander
^ permalink raw reply
* Re: [PATCH 5/7] gitk: Make cherry-pick call git-citool on conflicts.
From: Paul Mackerras @ 2008-10-09 7:42 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-6-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Now that git-gui has facilities to help users resolve
> conflicts, it makes sense to launch it from other gui
> tools when they happen.
Nice idea...
> +proc exec_citool {args {baseid {}}} {
I'm a little nervous about you having a parameter called "args", since
that specific name has a special meaning in Tcl; it's how Tcl handles
variable-length argument lists.
> + global commitinfo env
> +
> + if {[info exists env(GIT_AUTHOR_NAME)]} {
> + set old_name $env(GIT_AUTHOR_NAME)
> + }
> + if {[info exists env(GIT_AUTHOR_EMAIL)]} {
> + set old_email $env(GIT_AUTHOR_EMAIL)
> + }
> + if {[info exists env(GIT_AUTHOR_DATE)]} {
> + set old_date $env(GIT_AUTHOR_DATE)
> + }
> +
> + if {$baseid ne {}} {
> + if {![info exists commitinfo($baseid)]} {
> + getcommit $baseid
> + }
> + set author [lindex $commitinfo($baseid) 1]
> + set date [lindex $commitinfo($baseid) 2]
> + if {[regexp {^\s*(\S.*\S|\S)\s*<(.*)>\s*$} \
> + $author author name email]
> + && $date ne {}} {
> + set env(GIT_AUTHOR_NAME) $name
> + set env(GIT_AUTHOR_EMAIL) $email
> + set env(GIT_AUTHOR_DATE) $date
> + }
> + }
> +
> + eval exec git citool $args &
If we can assume the existence of a shell (which we do elsewhere), we
can perhaps do this more simply by putting the environment variable
settings in the command before the command name. It's a pity that git
citool won't take the author name/email/date as command-line arguments
or from a file, since it ends up being pretty verbose doing it the way
you have.
> @@ -7861,7 +7908,17 @@ proc cherrypick {} {
> # no error occurs, and exec takes that as an indication of error...
> if {[catch {exec sh -c "git cherry-pick -r $rowmenuid 2>&1"} err]} {
> notbusy cherrypick
> - error_popup $err
> + if {[regexp -line \
> + {Entry '(.*)' would be overwritten by merge} $err msg fname]} {
> + error_popup [mc "Cherry-pick failed: file '%s' had local modifications.
> +Your working directory is in an inconsistent state." $fname]
That message seems a bit too scary. It's not inconsistent, it's just
got local modifications. If I remember correctly, in this situation
git cherry-pick will back out all the changes it did and leave the
working directory as it was before.
> + } elseif {[regexp -line {^CONFLICT \(.*\):} $err msg]} {
> + # Force citool to read MERGE_MSG
> + file delete [file join [gitdir] "GITGUI_MSG"]
> + exec_citool [list] $rowmenuid
[list] as an idiom for the empty list is a little unusual (here and
elsewhere in your patches); {} would be more usual.
Paul.
^ permalink raw reply
* Re: [PATCH] Implement git clone -v
From: Alex Riesen @ 2008-10-08 6:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, Constantine Plotnikov, git
In-Reply-To: <20081008060257.GA15240@spearce.org>
Shawn O. Pearce, Wed, Oct 08, 2008 08:02:57 +0200:
> Miklos Vajna <vmiklos@frugalware.org> wrote:
> > On Tue, Oct 07, 2008 at 08:21:28AM +0200, Alex Riesen <raa.lkml@gmail.com> wrote:
> > > Yes. Does it work? :)
> >
> > Yes, it does. I'm not sure how to test it from the testsuite, maybe
> > redirect the output to a file and grep in it? It's ugly, that's why I
> > did not do so, but if you think a testcase is a musthave for this
> > feature then that's the way to go, I guess.
>
> Actually its not a bad way to test the feature. Normally we disable
> progress if stdout is not a tty. If you redirect to a file then
> -v should be needed to get anything at all on stderr.
>
> You may be able to just test the size of the file:
>
> git fetch -v ... >out 2>err &&
git clone
> test -s err
Right, but I don't think you need tests for progress bar. As a typical
eye candy, it tends to change often enough to be too annoying to test.
^ permalink raw reply
* Fwd: git status options feature suggestion
From: Caleb Cushing @ 2008-10-09 6:27 UTC (permalink / raw)
To: git
In-Reply-To: <81bfc67a0810082327p421ca4e9v84f4b33023bc6fe6@mail.gmail.com>
> How about "git ls-files -o"?
doh... hadn't even heard of that command.
--
Caleb Cushing
^ permalink raw reply
* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-09 6:16 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
In-Reply-To: <48EC7022.7030707@drmicha.warpmail.net>
Michael J Gruber wrote:
> svn is typically "abused" in the sense that one svn repo is used for
> separate projects (your subtrees). git-svn can deal with non-standard
> repo layouts.
>
I've decided to give up on cloning the whole svn repo. Cloning just our
src folder is sufficient for now, and it does follow a sensible repo layout.
Maybe I'll get back to this if I manage to find a way of reproducing the
previously described behavior.
Regards,
Knut
^ permalink raw reply
* Re: git status options feature suggestion
From: Jeff King @ 2008-10-09 6:11 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0810082234p55e2fb9jb2a10f837eea7de0@mail.gmail.com>
On Thu, Oct 09, 2008 at 01:34:41AM -0400, Caleb Cushing wrote:
> I was just doing a git status for a large add and all I really wanted
> to see was the untracked files maybe git status could have options
> like --new --untracked --modified to only show those.
How about "git ls-files -o"?
-Peff
^ 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