* Re: merge time
From: Junio C Hamano @ 2007-07-30 8:24 UTC (permalink / raw)
To: Jeff King
Cc: Steffen Prohaska, Shawn O. Pearce, Linus Torvalds,
Matthew L Foster, git
In-Reply-To: <20070730081439.GA907@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But I think making a "fake" commit to force non-fast-forward is the
> wrong thing. You really want to make your "extra" commit be the merge
> that wouldn't have happened (which unfortunately is not as simple as
> just creating a commit by hand, since you have to actually _do_ the
> merge to get the tree).
I do agree that if you really want to create a commit instead of
allowing a fast forward, you really should create a proper merge
commit.
But it is not hard. If it is a fast forward in reality but you
are marking it as a real merge by creating a merge commit, then:
- The tree is obviously the merged branch that is a fast
forward of your old HEAD;
- The first parent of the resulting merge is your old HEAD; and
- The second parent of the resulting merge is the merged
branch.
So:
git merge --no-fast-forward other
when other is a fast forward of HEAD would do:
git commit-tree other^{tree} -p HEAD -p other
^ permalink raw reply
* Re: merge time
From: Steffen Prohaska @ 2007-07-30 8:25 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Junio C Hamano, Linus Torvalds, Matthew L Foster,
git
In-Reply-To: <20070730081439.GA907@coredump.intra.peff.net>
On Jul 30, 2007, at 10:14 AM, Jeff King wrote:
>
> How about "git commit-tree HEAD^{tree} -p HEAD"?
Thanks, I wasn't aware of this syntax.
> But I think making a "fake" commit to force non-fast-forward is the
> wrong thing. You really want to make your "extra" commit be the merge
> that wouldn't have happened (which unfortunately is not as simple as
> just creating a commit by hand, since you have to actually _do_ the
> merge to get the tree).
I agree. But I think except for being 'fake' there shouldn't be any
problems with the extra commit.
Steffen
^ permalink raw reply
* Re: merge time
From: Jeff King @ 2007-07-30 8:14 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Shawn O. Pearce, Junio C Hamano, Linus Torvalds, Matthew L Foster,
git
In-Reply-To: <577C7529-4C3C-40D4-B86A-8B3CE888C997@zib.de>
On Mon, Jul 30, 2007 at 10:09:16AM +0200, Steffen Prohaska wrote:
> I needed to slightly modify it
>
> git config --global alias.force-commit \
> '! git update-ref HEAD $(echo MARK | git commit-tree $(git cat-file
> commit HEAD | grep ^tree | cut -b 6-) -p HEAD)'
How about "git commit-tree HEAD^{tree} -p HEAD"?
But I think making a "fake" commit to force non-fast-forward is the
wrong thing. You really want to make your "extra" commit be the merge
that wouldn't have happened (which unfortunately is not as simple as
just creating a commit by hand, since you have to actually _do_ the
merge to get the tree).
-Peff
^ permalink raw reply
* Re: merge time
From: Steffen Prohaska @ 2007-07-30 8:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Linus Torvalds, Matthew L Foster, git
In-Reply-To: <20070730074937.GT20052@spearce.org>
On Jul 30, 2007, at 9:49 AM, Shawn O. Pearce wrote:
> git-force-commit:
>
> git config --global alias.force-commit \
> '! git update-ref HEAD $(echo MARK | git commit-tree HEAD -p HEAD)'
I needed to slightly modify it
git config --global alias.force-commit \
'! git update-ref HEAD $(echo MARK | git commit-tree $(git cat-
file commit HEAD | grep ^tree | cut -b 6-) -p HEAD)'
> But you didn't hear it from me. ;-)
I'll tell no-one ;)
Steffen
^ permalink raw reply
* Re: merge time
From: Shawn O. Pearce @ 2007-07-30 7:49 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, Linus Torvalds, Matthew L Foster, git
In-Reply-To: <E49A2B0B-DAA3-4A03-925D-D3D113F907F1@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> Another option could be to force a commit before the merge, even
> if there are no changes to commit, something like
>
> $ git commit --force -m 'MARK'
>
> [to my knowledge, --force or similar is not yet available]
git-force-commit:
git config --global alias.force-commit \
'! git update-ref HEAD $(echo MARK | git commit-tree HEAD -p HEAD)'
But you didn't hear it from me. ;-)
Yes, I've actually done this once in a while. But only to create
some temporary throw-away state that I need for some diff operation
or whatnot. Usually because I make it in one repository, but want
to fetch it into another and fetch likes moving refs to commits
better than refs to trees. Oh, and I'm usually passing in more
than one -p, and usually not HEAD as the tree. But whatever.
--
Shawn.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Paolo Ciarrocchi @ 2007-07-30 7:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707300221.23511.jnareb@gmail.com>
On 7/30/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Paolo Ciarrocchi wrote:
> > On 7/27/07, Jakub Narebski <jnareb@gmail.com> wrote:
>
> >> First there is a question about the form of survey. Should we use web
> >> based survey, as the survey before (http://www.survey.net.nz), sending
> >> emails with link to this survey, or perhaps do email based survey,
> >> with email Reply-To: address put for this survey alone?
> >
> > I vote for the survey.net.nz approach. I think that from a user
> > prospective that's the right thing to do, we can have "multiple choice
> > questions" and avoid some of the more common mistakes.
>
> I think it also better (especially that I started devising questions
> with multiple-choice and single-choice answers in mind...).
>
> >> Third, where to send survey to? I was thinking about git mailing list,
> >> LKML, and mailing list for git projects found on GitProjects page on
> >> GIT wiki. Do you want to add some address? Or should info about GIT
> >> User's Survey 2007 be sent also to one of on-line magazines like
> >> LinuxToday, or asked to put on some blog?
> >
> > I think that one of the mistakes I did when I sent out the first
> > survey was to not contact any magazines and blog.
>
> Any proposals? Besides LWN, NewsForge, Slashdot?
www.osnews.com and I can contact a few Italian portals.
> >> ----
> >> About you
> >>
> >> 1. What country are you in?
> >
> > I know that lot of people will disagree with me but from a pure
> > statistical prospective I'd like to add a couple of questions about
> > gender and age.
> >
> > I understand very well that these questions will not be useful for
> > making git any better but it will be interesting to have a better
> > picture abut the git customer base.
>
> I'm not sure it would add any important informatant information;
> although "age" (years, or age bracket?) could be useful.
>
> >> How you use GIT
>
> >> 8. Which porcelains do you use?
> >> (zero or more: multiple choice)
> >> - core-git, cogito, StGIT, pg, guilt, other
> IsiSetup
>
> > git-gui ?
> >
> >> 9. Which git GUI do you use
> >> (zero or more: multiple choice)
> >> - gitk, git-gui, qgit, gitview, giggle, other
> tig, instaweb, (h)gct, qct, KGit
>
> I consider git-gui an UI (like qgit or tig), not a porcelain. To be
> a porcelains tool need to add some SCM functionality not present in
> git-core.
>
> > How about adding a question about whether the user migrated from a
> > different SCM? If so, from which SCM and why?
>
> I have added, suggested [somewhat] by Andy Parkins, the following
> set of questions:
>
> ----
> Other SCMs
>
> 1. What other SCM did you use?
> 2. What other SCM do you use currently?
> 3. What other SCM do you use as a main SCM for your project
> instead of git, if any? Why?
> * example: Mercurial, better MS Windows support
> 5. What would you require from git to enable you to change,
> if you use other SCM for your project?
> 4. Do your git repository interact with other SCM? Or what SCM
> did you import from? What tool did/do you use?
> * examples: CVS, import: fromcvs, interaction: git-cvsserver;
> Subversion, git-svn
Fine with me. Thanks for you work Jakub.
Just a general comment, let's try to avoid as much as possible
multiple questions in a single question. It tends to confuse people
when they are answering to the survey.
Ciao,
--
Paolo
^ permalink raw reply
* Re: merge time
From: Steffen Prohaska @ 2007-07-30 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Matthew L Foster, git
In-Reply-To: <7vbqdumlo1.fsf@assigned-by-dhcp.cox.net>
On Jul 30, 2007, at 8:48 AM, Junio C Hamano wrote:
> I tend to agree that it would make sense to allow something like:
>
> $ git merge --no-fast-forward -m 'Merge topic XYZ' xyz
Another option could be to force a commit before the merge, even
if there are no changes to commit, something like
$ git commit --force -m 'MARK'
[to my knowledge, --force or similar is not yet available]
Steffen
^ permalink raw reply
* Re: [GUILT PATCH 1/4] get_series: Remove comments from end of series lines
From: Eric Lesh @ 2007-07-30 7:07 UTC (permalink / raw)
To: Josef Sipek; +Cc: git
In-Reply-To: <20070730052633.GI22017@filer.fsl.cs.sunysb.edu>
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> I think the script I wrote is a bit cleaner as it more easily translates to:
>
> if (!ignore_line) {
> strip comment
> print
> }
>
> to make it work, you'd need to run sed with -n to not implicitly print the
> line.
>
Told you my sed-foo sucks ;-) You're right again, of course.
Eric
^ permalink raw reply
* Re: [GUILT PATCH 4/4] Use guards information and functions
From: Eric Lesh @ 2007-07-30 7:06 UTC (permalink / raw)
To: Josef Sipek; +Cc: jsipek, git
In-Reply-To: <20070730041549.GF22017@filer.fsl.cs.sunysb.edu>
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>> -get_series | awk "{ if (NR == $n) print \$0}"
>> +get_guarded_series | awk "{ if (NR == $n) print \$0}"
>
> Seeing this almost makes me thing that get_series should give you the
> guarded series unless you poke it the right way...something like:
>
> get_series --full
>
> or
>
> get_full_series
>
>
> The guarded series is what most commands care about, right?
>
You're right. I'll do it with get_full_series.
Eric
^ permalink raw reply
* Re: Gitweb and submodules
From: Sven Verdoolaege @ 2007-07-30 7:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707300209.03531.jnareb@gmail.com>
On Mon, Jul 30, 2007 at 02:09:03AM +0200, Jakub Narebski wrote:
> On Sun,29 July 2007, Sven Verdoolaege wrote:
> > On Sat, Jul 28, 2007 at 10:39:28PM +0200, Jakub Narebski wrote:
> >> submodule.$name.path/.git (relative to toplevel of working directory)
> >
> > Having a relative path for the URL in .gitmodules in a public repo
> > doesn't seem very useful to me. I know it's only meant as a default
> > value, but if it is a relative path, then it won't work for
> > anyone cloning the superproject.
>
> Erm, it should be relative path in .git/config (as in example in the
> t/t7400-submodule-basic.sh IIRC). And this is purely local matter.
My mistake. I misread that as submodule.$name.url.
skimo
^ permalink raw reply
* Re: [GUILT PATCH 3/4] guilt-select: Select guards to apply when pushing patches
From: Eric Lesh @ 2007-07-30 7:02 UTC (permalink / raw)
To: Josef Sipek; +Cc: jsipek, git
In-Reply-To: <20070730041231.GE22017@filer.fsl.cs.sunysb.edu>
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
[...]
>> +if [ $# == 0 ]; then
>> + if [ -s "$guards_file" ]; then
>> + cat "$guards_file"
>
> Later on, for the -s option processing, you sort (presumably to have uniq do
> the right thing), should we sort here too to be consitent?
>
The $guards_file isn't really meant to be handed edited, and
guilt-select itself sorts before it stores them in the guards file. I could
sort it again on printing, but don't think it's necessary.
>> +
>> +case $1 in
>> + -n|--none)
>> + rm -f "$guards_file"
>> + touch "$guards_file"
>
> Since guilt-init doesn't create the guards file, I'm thinking that this
> should be just a rm -f ...
Should guilt-init create it? I added $guards_file to guilt(7), so not
seeing it might freak Documentation-conscious readers out?
Eric
^ permalink raw reply
* Re: merge time
From: Junio C Hamano @ 2007-07-30 6:48 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Linus Torvalds, Matthew L Foster, git
In-Reply-To: <6FE9FFD6-B5D7-4E1D-A4E8-B6D0E9517503@zib.de>
This is an old topic rehashed from time to time. The last time
was March this year if I recall correctly.
http://thread.gmane.org/gmane.comp.version-control.git/41931/focus=41983
I tend to agree that it would make sense to allow something like:
$ git merge --no-fast-forward -m 'Merge topic XYZ' xyz
but at the same time Linus is pretty clear that he would not use
that for his kernel merges, so even if we add that feature,
gitweb at k.org that shows linux-2.6 history would not see it.
^ permalink raw reply
* Re: [GUILT PATCH 2/4] guilt-guard: Assign guards to patches in series
From: Eric Lesh @ 2007-07-30 6:41 UTC (permalink / raw)
To: Josef Sipek; +Cc: jsipek, git
In-Reply-To: <20070730040610.GD22017@filer.fsl.cs.sunysb.edu>
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
[...]
>> +get_guarded_series()
>> +{
>> + get_series | while read p
>> + do
>> + [ -z `check_guards $p` ] && echo "$p"
>
> Having check_guards return 0 or 1 makes things cleaner:
>
> check_guards "$p" && echo "$p"
>
>> + done
>> +}
>> +
>> +# usage: check_guards <patch>
>> +# Returns t if the patch should be skipped
>> +check_guards()
>> +{
>> + get_guards "$1" | while read guard
>> + do
>> + pos=`echo $guard | grep -e "^+"`
>> + guard=`echo $guard | sed -e 's/[+-]//'`
>> + if [ $pos ]; then
>> + # Push +guard *only if* guard selected
>> + push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
>> + [ $push -ne 0 ] && echo t
>
> [ $push -ne 0 ] && return 1
>
This returns from the subshell created by the pipe and the while loop,
right?
So I'm using:
check_guards()
{
get_guards "$1" | while read guard
do
pos=`echo $guard | grep -e "^+"`
guard=`echo $guard | sed -e 's/^[+-]//'`
if [ $pos ]; then
# Push +guard *only if* guard selected
push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
[ $push -ne 0 ] && return 1
else
# Push -guard *unless* guard selected
push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
[ $push -eq 0 ] && return 1
fi
return 0
done
return $?
}
where 1 means push.
>> +# usage: get_guards <patch>
>> +get_guards()
>> +{
>> + grep -e "^$1[[:space:]]*#" < "$series" | sed -e "s/^$1 //" -e 's/#[^+-]*//g'
>> +}
Should this also be one sed script instead of a grep + sed?
>> +
>> +# usage: set_guards <patch> <guards>
>
> I'd try to make it clearer that multiple guards can be specified.
>
Done with <guards...> now.
>> +set_guards()
>> +{
>> + p="$1"
>> + shift
>> + for x in "$@"; do
>> + if [ -z $(echo "$x" | grep -e "^[+-]") ]; then
>
> Is that the only restriction on the guard name?
>
Yes. On patches, you put a '+guard' or '-guard'. When selecting with
guilt-select, it's just 'guard'. The + or - just means 'apply when
selected' or 'apply unless selected'. You can edit things manually to
make guards with a space in the name, but the mechanism will work even
in that case.
>> + echo "'$x' is not a valid guard name"
>> + else
>> + sed -i -e "s/^\($p[[:space:]]*.*\)$/\1 #$x/" "$series"
>> + fi
>> + done
>> +}
>> +
>> +# usage: unset_guards <patch> <guards>
>
[...]
The rest I'll do. Thanks for the review.
Eric
^ permalink raw reply
* Re: merge time
From: Steffen Prohaska @ 2007-07-30 6:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthew L Foster, git
In-Reply-To: <alpine.LFD.0.999.0707291914451.3442@woody.linux-foundation.org>
On Jul 30, 2007, at 4:29 AM, Linus Torvalds wrote:
> So there is never really any way to say that one side of a merge is
> special. The closest you can get is saying
>
> - the first parent is special.
>
> This is "see merges from the viewpoint of the merger", but as
> mentioned, the person who actually did the merge isn't
> necessarily me,
> so while this is a totally self-consistent view, it's not really
> the
> view you are looking for.
>
> You can get some of this view by using "git log --first-parent",
> which
> basically follows commits preferentially using the first parent,
> and
> thus "prefers" history as seen by whoever did the merge.
In general the first parent is not special, agreed. But could one
deliberately built a history by following certain rules that make
the first parent _always_ a special one?
I think of a quite simple example. Topic branches are always
branched off the master, and later merged back. The master, which
is the branch an official release is created from, must always be
the first parent during a merge. It doesn't matter who does the
merges or who does the releases, as long as he follows the rule
to start from the last release point and merge in all changes in
the appropriate way, such that the first parent rule is followed.
Here are two applications that I think would be interesting:
1) The kernel history. If you went from a current release back
along the first parents you'd see the changes that entered the
official kernel sorted backwards in time. I believe the history of
the kernel is already an approximation of this rule. But maybe I'm
wrong.
2) Developing using topic branches. You start topic branches and
start developing new features. Only later you fix problems on all
supported platforms, polish and review the changes. Not every
commit on the topic branch has the same quality, e.g. the early
commits may not even compile on all supported platforms. But the
tip of the topic branch passes all required tests. After a merge
of the topic branch to a stable branch it would be nice to
distinguish the stable history from the less polished commits on
the topic branch. I think this could be achieved if the first
parent always is linked to a stable commit.
I'm sure some will propose that instead of (2) I should rewrite a
topic branch such that every single commit passes all quality
requirements. But I strongly believe it is a viable choice not to
do so. It may just be too much work and often it's sufficient and
easier to polish the tip of a topic branch.
Fast-forward merges would break both of the scenarios. But would
they be possible without fast-forward merges?
Would it be possible to ensure that all commits along the
first-parent-path have 'release' quality and all release tags are
located along this path? What would be the right rules to achieve
this objective?
Steffen
^ permalink raw reply
* Re: Merging into a current branch
From: Shawn O. Pearce @ 2007-07-30 5:48 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0707292240qe92aa57s5c5152e078693a53@mail.gmail.com>
Geoff Russell <geoffrey.russell@gmail.com> wrote:
> Is there any reason why
>
> git fetch origin branchX:branchX
>
> fails if I am on branchX? All I want to do is fast forward it.
Yes.
A fetch will *only* update the branch. If the branch is your current
branch it won't update the working directory. This safety check
is to prevent the branch from updating, but the working directory
staying unchanged, and the resulting git-status output looking like
you just undid all of the recent work done on branchX of origin.
Try git-pull instead:
git pull origin branchX
--
Shawn.
^ permalink raw reply
* Merging into a current branch
From: Geoff Russell @ 2007-07-30 5:40 UTC (permalink / raw)
To: git
Dear gits,
Is there any reason why
git fetch origin branchX:branchX
fails if I am on branchX? All I want to do is fast forward it.
Cheers,
Geoff.
^ permalink raw reply
* [ANNOUNCE] git-gui 0.8.0 now available
From: Shawn O. Pearce @ 2007-07-30 5:38 UTC (permalink / raw)
To: git
I've finally released git-gui 0.8.0. Junio has already promised
to include this version in git 1.5.3 when it gets released, but
you can also acquire it directly from my repo.or.cz repository:
gitweb: http://repo.or.cz/w/git-gui.git/
fetch: git://repo.or.cz/git-gui.git
http://repo.or.cz/r/git-gui.git
Changes between 0.7.0 and 0.7.5:
Most of these changes have already been seen by a lot of users,
as they have been shipping with the maint releases of git 1.5.2
and the release candidates of 1.5.3.
* Completely rewritten blame viewer
The blame viewer was completely overhauled, with almost none of
the code from pre-0.7.0 surviving the rewrite. The end result
is a viewer that actually offers a fast overview of how code
has moved around, and makes use of tooltips to display detailed
information quickly.
* new: Keybinding of Cmd-P/Ctrl-P for push action
* new: Push action button on left side toolbar
* bugfix: Prefer HEAD's message over MERGE_MSG when amending
* bugfix: Ensure Windows git-gui "icons" always end in .bat
* bugfix: ls-tree buffering error in tree browser
* bugfix: Work around ^{tree} shell error on MSYS
* bugfix: Avoid 'nice.exe' on MSYS
Changes between 0.7.5 and 0.8.0:
Most of these new features haven't been merged into git.git yet,
but will be before 1.5.3 is released.
* Overhauled 'Starting Revision' UI for branch creation
The 'Starting Revision' part of the branch create dialog has
been rebuilt to better handle a large number of local and remote
tracking branches. A glob-style filter can be applied to narrow
the list of choices. Tooltips show the tip revision of each
branch, and also the last time the branch was last updated.
The new UI is much better suited to dealing with 200+ branches.
* Overhauled revision selection UI for checkout
The improved UI used for branch creation is also now used for
checkout, including local branches, remote tracking branches,
tags and arbitrary SHA-1 revision expressions.
* Overhauled revision selection UI for merge
Like checkout, merge uses the improved revision selection UI.
This allows users to merge arbitrary commits and not just
branches or tags. It also avoids problems with long branch
names being clipped and not fully visible.
* Branch reset (aka git-branch -f) support
Local branches can be reset through Branch->Create. This avoids
needing to delete the branch first, thereby saving the associated
reflog history.
* Automatically refetch tracking branches when needed
Before creating a new local branch or checking out a tracking
branch git-gui can first update the local tracking branch by
fetching it from the associated remote repository.
This feature helps users trying to work in a "bound branch"
workflow by making sure that they are always working with the
latest revision.
* Better detached HEAD support
git-gui now always works properly on detached HEAD and can switch
between local branches and detached HEAD. The Branch->Checkout
menu option offers support for switching to a detached HEAD.
HEAD's reflog is now also updated similar to how core Git's
command line tools would update it.
* Browse any branch/revision and not just the current branch
The browser (and thus blame viewer) can now be opened for any
commit, not just the current branch. The commit can be selected
using the improved revision selection UI already discussed above.
* Delete branches from remote repositories
If the remote repository is running git 1.5 or later you can
now delete remote branches through the Push->Delete menu.
* Prune local tracking branches via `git remote prune`
Pruning automatically deletes any tracking branches whose
corresponding remote branch has already been removed from the
remote repository. A configuration option accessible in the
options dialog can enable this feature to run after each fetch.
* Blame/browser now works in bare repositories
The `git gui blame` and `git gui browser` command line
subcommands now work properly in a bare Git repository.
This makes it easier to use git-gui's blame viewer.
* More consistent blame/browser command line interface
Revision and path argument parsing for the blame and browser
subcommands is more consistent with each other and now behave
like the core git-blame argument parsing.
* Progress meter during checkout/reset operations
git-gui now scrapes the output of `git-read-tree -v` during a
branch checkout or reset and shows the progress meter in the
main window's status bar. This lets users know how much work is
(roughly) remaining to complete the operation.
* Tracking branch merges are now formatted as pulls
When merging a tracking branch git-gui now generates the
commit message as though the branch was fetched+merged from the
remote using git-pull. This makes for a cleaner merge commit
message, but does not incur the network IO that would normally
be associated with git-pull.
* Automatic commit message backup
The Edit->Undo action appears to cause Tk to crash on some
platforms. To prevent users from losing the commit message
they were drafting git-gui now backs up the buffer to a file
every 2 seconds, if it has changed since the last backup.
* Removed 'octopus' merge support
It was decided recently on #git that octopus merge support is
not used often, and is probably not something users should be
commonly using. It has been removed from git-gui entirely.
* Language change: "to stage" instead of "to add"
This improvement came from Christian Stimming as part of the
i18n work. Although the command line uses git-add to stage
changes into the index we do tend to refer to this action as
"staging" and not "adding". Christian's changes really clarify
the UI for English users and should help i18n translators to
find better translations in their target language.
* Misc. bug fixes and UI tweaks
A number of other bugs were fixed and some minor UI nits were
corrected. For complete details please review the actual
commit history.
0.8.0 testing history:
Just to give folks a little warm-n-fuzzy feeling about merging
so much new functionality into git 1.5.3 right before release,
I offer up this little tidbit:
I have a local git-gui user's group at my day-job made up of about
20 users, ranging in skill from "novice computer user" to "expert
developer". They have been using version 0.8.0 on Cygwin for their
daily work for quite a while now and are reasonably happy with it.
Of course they also want even more features implemented.
Who doesn't. ;-)
--
Shawn.
^ permalink raw reply
* Re: [GUILT PATCH 1/4] get_series: Remove comments from end of series lines
From: Josef Sipek @ 2007-07-30 5:26 UTC (permalink / raw)
To: Eric Lesh; +Cc: git
In-Reply-To: <87r6mqcvzp.fsf@hubert.paunchy.net>
On Sun, Jul 29, 2007 at 10:15:54PM -0700, Eric Lesh wrote:
>
> [ Do you mind if these messages go to both your email addresses, or
> should I remove one or the other? ]
I really don't care if I get duplicates. It'll happen anyway when the git
mailing list is cc'd. As for which address I prefer, it really doesn't
matter to me which one stays in Cc. I'm slowly trying to move everything
over to @cs.
> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> > On Sun, Jul 29, 2007 at 12:50:15AM -0700, Eric Lesh wrote:
> > ...
> >> diff --git a/guilt b/guilt
> >> index f67bfb5..774909e 100755
> >> --- a/guilt
> >> +++ b/guilt
> >> @@ -178,7 +178,8 @@ get_series()
> >> # - whitespace only
> >> # - optional whitespace followed by '#' followed by more
> >> # optional whitespace
> >> - grep -ve '^[[:space:]]*\(#.*\)*$' "$series"
> >> + # also remove comments from end of lines
> >> + grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
> >
> > I'd be tempted to replace the whole thing with one sed script...something
> > like (not tested):
> >
> > "
> > /^[[:space:]]*#/ ! {
> > s/[[:space:]]*#.*$//
> >
> > p
> > }
> > "
> >
>
> sed -e "/^[[:space:]]*\(#.*\)*$/d
> /^[[:space:]]*\(#.*\)*$/!{
> s/[[:space:]]*#.*$//
> }
> " $series
>
> is the best I can do.
I think the script I wrote is a bit cleaner as it more easily translates to:
if (!ignore_line) {
strip comment
print
}
to make it work, you'd need to run sed with -n to not implicitly print the
line.
Jeff.
--
I'm somewhere between geek and normal.
- Linus Torvalds
^ permalink raw reply
* Re: [GUILT PATCH 1/4] get_series: Remove comments from end of series lines
From: Eric Lesh @ 2007-07-30 5:15 UTC (permalink / raw)
To: Josef Sipek; +Cc: jsipek, git
In-Reply-To: <20070730035422.GB22017@filer.fsl.cs.sunysb.edu>
[ Do you mind if these messages go to both your email addresses, or
should I remove one or the other? ]
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
> On Sun, Jul 29, 2007 at 12:50:15AM -0700, Eric Lesh wrote:
> ...
>> diff --git a/guilt b/guilt
>> index f67bfb5..774909e 100755
>> --- a/guilt
>> +++ b/guilt
>> @@ -178,7 +178,8 @@ get_series()
>> # - whitespace only
>> # - optional whitespace followed by '#' followed by more
>> # optional whitespace
>> - grep -ve '^[[:space:]]*\(#.*\)*$' "$series"
>> + # also remove comments from end of lines
>> + grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
>
> I'd be tempted to replace the whole thing with one sed script...something
> like (not tested):
>
> "
> /^[[:space:]]*#/ ! {
> s/[[:space:]]*#.*$//
>
> p
> }
> "
>
sed -e "/^[[:space:]]*\(#.*\)*$/d
/^[[:space:]]*\(#.*\)*$/!{
s/[[:space:]]*#.*$//
}
" $series
is the best I can do.
sed -e "/^[[:space:]]*\(#.*\)*$/d" -e "s/[[:space:]]*#.*$//" $series
works too, and is maybe more readable.
My sed-foo is weak, though.
Eric
^ permalink raw reply
* Re: merge time
From: david @ 2007-07-30 4:17 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Linus Torvalds, git
In-Reply-To: <994493.95349.qm@web51001.mail.re2.yahoo.com>
On Sun, 29 Jul 2007, Matthew L Foster wrote:
> --- Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> You misunderstand. It would do so both for the newly merged commits *and*
>> for the old commits. Because _you_ think the "new" commits got merged, but
>> it's logically exactly equivalent to saying that the *old* commits got
>> merged.
>>
>> So now *every* single commit would get the timestamp of the merge.
>>
>> See? It would be pointless.
>
> Ok maybe I am still confused. If a repository is in state A and a merge happens changing it to
> state B we can give the changes that got us to B the timestamp of the merge? Since the changes
> that got us from A to B were all merged locally at the same time they should be given the same
> timestamp, right? Please explain more about how changes/commits in state A would also be given the
> timestamp of the merge?
>
> When I say local time I also really mean local commit order as both should be interchangeable
> unless you widly misset/change your local clock. Git/gitweb could have an option to sort/display
> based on local commit order and maybe have check for if local time order is out of sync with local
> commit order.
one feature of git (and I think of truely distributed change management
systems)
say you have tree A and I have tree B
if you clone your tree and merge from mine, and I clone my tree and merge
from yours, the result of both merges _must_ be the same there will be
trouble when we both try and merge with tree C later on.
another thing is that a given commit cannot be changed once it's created
(if it was changed it wouldn't have the same sha1 value) so you can't just
go around changeing dates on commits that took place elsewhere.
David Lang
^ permalink raw reply
* Re: [GUILT PATCH 4/4] Use guards information and functions
From: Josef Sipek @ 2007-07-30 4:15 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <1185695418227-git-send-email-eclesh@ucla.edu>
On Sun, Jul 29, 2007 at 12:50:18AM -0700, Eric Lesh wrote:
> Make guilt-push respect guards. Also teach guilt-header, guilt-next,
> and guilt-unapplied to grok patches that are skipped because of
> guards.
>
> Signed-off-by: Eric Lesh <eclesh@ucla.edu>
> ---
> guilt-header | 7 ++++---
> guilt-next | 2 +-
> guilt-push | 8 ++++----
> guilt-unapplied | 2 +-
> 4 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/guilt-header b/guilt-header
> index d07e2be..ef7f55e 100755
> --- a/guilt-header
> +++ b/guilt-header
> @@ -15,15 +15,16 @@ patch="$1"
> if [ -z "$patch" ]; then
> # use the patch that's on the top of the stack
>
> - eidx=`wc -l < $applied`
> - if [ $eidx -eq 0 ]; then
> + patch=`get_top`
> + if [ -z "$patch" ]; then
> die "Status file is empty"
> fi
> + eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
> else
> # use the specified patch
>
> eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
> - if [ $eidx -eq 0 ]; then
> + if [ -z "$eidx" ]; then
> die "Patch $patch is not in the series"
> fi
> fi
> diff --git a/guilt-next b/guilt-next
> index f38f1cc..38f57fa 100755
> --- a/guilt-next
> +++ b/guilt-next
> @@ -13,5 +13,5 @@ fi
> n=`wc -l < $applied`
> n=$(($n + 1))
>
> -get_series | awk "{ if (NR == $n) print \$0}"
> +get_guarded_series | awk "{ if (NR == $n) print \$0}"
Seeing this almost makes me thing that get_series should give you the
guarded series unless you poke it the right way...something like:
get_series --full
or
get_full_series
The guarded series is what most commands care about, right?
> diff --git a/guilt-push b/guilt-push
> index ad3616b..ce928e3 100755
> --- a/guilt-push
> +++ b/guilt-push
> @@ -24,7 +24,7 @@ if [ "$patch" = "--all" ] || [ "$patch" = "-a" ]; then
> # we are supposed to push all patches, get the last one out of
> # series
>
> - eidx=`get_series | wc -l`
> + eidx=`get_guarded_series | wc -l`
> if [ $eidx -eq 0 ]; then
> die "There are no patches to push"
> fi
> @@ -37,9 +37,9 @@ else
> # we're supposed to push only up to a patch, make sure the patch is
> # in the series
>
> - eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
> + eidx=`get_guarded_series | grep -ne "^$patch\$" | cut -d: -f1`
> if [ -z "$eidx" ]; then
> - die "Patch $patch is not in the series"
> + die "Patch $patch is not in the series or is guarded"
> fi
> fi
>
> @@ -52,7 +52,7 @@ fi
> sidx=`wc -l < $applied`
> sidx=`expr $sidx + 1`
>
> -get_series | sed -n -e "${sidx},${eidx}p" | while read p
> +get_guarded_series | sed -n -e "${sidx},${eidx}p" | while read p
> do
> echo "Applying patch..$p"
> if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
> diff --git a/guilt-unapplied b/guilt-unapplied
> index 192a7e5..6904360 100755
> --- a/guilt-unapplied
> +++ b/guilt-unapplied
> @@ -13,4 +13,4 @@ fi
> n=`wc -l < $applied`
> n=`expr $n + 1`
>
> -get_series | sed -n -e "$n,\$p"
> +get_guarded_series | sed -n -e "$n,\$p"
> --
> 1.5.2
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 4:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707292011170.4161@woody.linux-foundation.org>
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> (Sure, gitk will show you the commit dates too, but they aren't important,
> since they have no meaning as to whether a commit got merged into
> 2.6.23-rc1 or not).
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
^ permalink raw reply
* Re: [GUILT PATCH 3/4] guilt-select: Select guards to apply when pushing patches
From: Josef Sipek @ 2007-07-30 4:12 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <11856954182318-git-send-email-eclesh@ucla.edu>
On Sun, Jul 29, 2007 at 12:50:17AM -0700, Eric Lesh wrote:
> guilt-select chooses guards that alter which patches will be applied
> with a guilt-push. The selected guards are stored in
> .git/patches/$branch/guards.
>
> Signed-off-by: Eric Lesh <eclesh@ucla.edu>
> ---
> Documentation/guilt-select.txt | 42 ++++++++++++++++++++++++++++++++++++++++
> guilt | 1 +
> guilt-select | 36 ++++++++++++++++++++++++++++++++++
> 3 files changed, 79 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/guilt-select.txt
> create mode 100755 guilt-select
>
> diff --git a/Documentation/guilt-select.txt b/Documentation/guilt-select.txt
> new file mode 100644
> index 0000000..8e18f26
> --- /dev/null
> +++ b/Documentation/guilt-select.txt
You might want to update the guilt(7) page's description of the patch
directory.
> @@ -0,0 +1,42 @@
> +guilt-select(1)
> +===============
> +
> +NAME
> +----
> +guilt-select - Select guards to apply when pushing patches
> +
> +SYNOPSIS
> +--------
> +include::usage-guilt-select.txt[]
> +
> +DESCRIPTION
> +-----------
> +Select guards to apply when pushing patches.
> +
> +Guards are selected without the + or - prefix. Patches are applied in
> +the following way:
> +
> +An unguarded patch is always applied.
> +
> +A patch with a positive guard is applied *only* if the guard is
> +selected with guilt-select.
> +
> +A patch with a negative guard is applied *unless* the guard is
> +selected with guilt-select.
> +
> +OPTIONS
> +-------
> +-n|--none::
> + Remove all selected guards
> +-s|--series::
> + List all guards listed in the series file
> +
> +Author
> +------
> +Written by Eric Lesh <eclesh@ucla.edu>
> +
> +Documentation
> +-------------
> +Documentation by Eric Lesh <eclesh@ucla.edu>
> +
> +include::footer.txt[]
> diff --git a/guilt b/guilt
> index b2767ea..3882962 100755
> --- a/guilt
> +++ b/guilt
> @@ -641,6 +641,7 @@ fi
> # very useful files
> series="$GUILT_DIR/$branch/series"
> applied="$GUILT_DIR/$branch/status"
> +guards_file="$GUILT_DIR/$branch/guards"
>
> # determine an editor to use for anything interactive (fall back to vi)
> editor="vi"
> diff --git a/guilt-select b/guilt-select
> new file mode 100755
> index 0000000..f237ef0
> --- /dev/null
> +++ b/guilt-select
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +#
> +# Copyright (c) Eric Lesh, 2007
> +#
> +
> +USAGE="[-n|--none] [-s|--series] [<guard>]"
> + . `dirname $0`/guilt
> +
> +if [ $# == 0 ]; then
> + if [ -s "$guards_file" ]; then
> + cat "$guards_file"
Later on, for the -s option processing, you sort (presumably to have uniq do
the right thing), should we sort here too to be consitent?
> + else
> + echo "No guards applied"
I think outputing this message to stderr might be better; it'll allow for
redirection more easily.
> + fi
> + exit 0
> +fi
> +
> +case $1 in
> + -n|--none)
> + rm -f "$guards_file"
> + touch "$guards_file"
Since guilt-init doesn't create the guards file, I'm thinking that this
should be just a rm -f ...
> + ;;
> + -s|--series)
> + (get_series | while read patch; do
> + get_guards "$patch"
> + done) | sed -e 's/ /\n/g' | sort | uniq
> + ;;
> + *)
> + for x in "$@"; do
> + if [ $(echo $x | grep -e "^[+-]") ]; then
> + die "'$x' is not a valid guard name"
> + fi
> + done
> + echo "$@" | sed -e 's/ /\n/g' | sort | uniq > "$guards_file"
> + ;;
> +esac
> --
> 1.5.2
--
The box said "Windows XP or better required". So I installed Linux.
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 4:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, david
In-Reply-To: <alpine.LFD.0.999.0707292007440.4161@woody.linux-foundation.org>
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> You misunderstand. It would do so both for the newly merged commits *and*
> for the old commits. Because _you_ think the "new" commits got merged, but
> it's logically exactly equivalent to saying that the *old* commits got
> merged.
>
> So now *every* single commit would get the timestamp of the merge.
>
> See? It would be pointless.
Ok maybe I am still confused. If a repository is in state A and a merge happens changing it to
state B we can give the changes that got us to B the timestamp of the merge? Since the changes
that got us from A to B were all merged locally at the same time they should be given the same
timestamp, right? Please explain more about how changes/commits in state A would also be given the
timestamp of the merge?
When I say local time I also really mean local commit order as both should be interchangeable
unless you widly misset/change your local clock. Git/gitweb could have an option to sort/display
based on local commit order and maybe have check for if local time order is out of sync with local
commit order.
-Matt
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
^ permalink raw reply
* Re: [GUILT PATCH 2/4] guilt-guard: Assign guards to patches in series
From: Josef Sipek @ 2007-07-30 4:06 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <11856954181497-git-send-email-eclesh@ucla.edu>
On Sun, Jul 29, 2007 at 12:50:16AM -0700, Eric Lesh wrote:
> guilt-guard will assign guards to a patch. They work so that:
>
> * Patches with no guards are always pushed.
>
> * Patches with positive guards (i.e. +foo) are pushed *only if* the
> guard is selected.
>
> * Patches with negative guards (i.e. -foo) are pushed *unless* the
> guard is selected.
>
> Signed-off-by: Eric Lesh <eclesh@ucla.edu>
> ---
> Documentation/guilt-guards.txt | 40 +++++++++++++++++++++++++
> guilt | 58 ++++++++++++++++++++++++++++++++++++
> guilt-guards | 63 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 161 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/guilt-guards.txt
> create mode 100755 guilt-guards
>
> diff --git a/Documentation/guilt-guards.txt b/Documentation/guilt-guards.txt
> new file mode 100644
> index 0000000..f5ac537
> --- /dev/null
> +++ b/Documentation/guilt-guards.txt
> @@ -0,0 +1,40 @@
> +guilt-guards(1)
> +===============
> +
> +NAME
> +----
> +guilt-guards - Assign guards to patches
> +
> +SYNOPSIS
> +--------
> +include::usage-guilt-guards.txt[]
> +
> +DESCRIPTION
> +-----------
> +Assign guards to the specified patch, or to the patch on top of the
> +stack if no patch is given on the command line.
> +
> +An unguarded patch is always pushed.
> +
> +A positive guard begins with a +. A patch with a positive guard is
> +pushed *only if* the guard is selected.
> +
> +A negative guard begins with a -. A patch with a negative guard is
> +always pushed, *unless* the guard is selected.
> +
> +OPTIONS
> +-------
> +-l|--list::
> + List all patches and their guards
> +-n|--none::
> + Remove all guards from a patch
> +
> +Author
> +------
> +Written by Eric Lesh <eclesh@ucla.edu>
> +
> +Documentation
> +-------------
> +Documentation by Eric Lesh <eclesh@ucla.edu>
> +
> +include::footer.txt[]
> diff --git a/guilt b/guilt
> index 774909e..b2767ea 100755
> --- a/guilt
> +++ b/guilt
> @@ -182,6 +182,64 @@ get_series()
> grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
> }
>
> +get_guarded_series()
> +{
> + get_series | while read p
> + do
> + [ -z `check_guards $p` ] && echo "$p"
Having check_guards return 0 or 1 makes things cleaner:
check_guards "$p" && echo "$p"
> + done
> +}
> +
> +# usage: check_guards <patch>
> +# Returns t if the patch should be skipped
> +check_guards()
> +{
> + get_guards "$1" | while read guard
> + do
> + pos=`echo $guard | grep -e "^+"`
> + guard=`echo $guard | sed -e 's/[+-]//'`
> + if [ $pos ]; then
> + # Push +guard *only if* guard selected
> + push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> + [ $push -ne 0 ] && echo t
[ $push -ne 0 ] && return 1
> + else
> + # Push -guard *unless* guard selected
> + push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> + [ $push -eq 0 ] && echo t
ditto
> + fi
> + done
return 0
> +}
> +
> +# usage: get_guards <patch>
> +get_guards()
> +{
> + grep -e "^$1[[:space:]]*#" < "$series" | sed -e "s/^$1 //" -e 's/#[^+-]*//g'
> +}
> +
> +# usage: set_guards <patch> <guards>
I'd try to make it clearer that multiple guards can be specified.
> +set_guards()
> +{
> + p="$1"
> + shift
> + for x in "$@"; do
> + if [ -z $(echo "$x" | grep -e "^[+-]") ]; then
Is that the only restriction on the guard name?
> + echo "'$x' is not a valid guard name"
> + else
> + sed -i -e "s/^\($p[[:space:]]*.*\)$/\1 #$x/" "$series"
> + fi
> + done
> +}
> +
> +# usage: unset_guards <patch> <guards>
ditto.
> +unset_guards()
> +{
> + p="$1"
> + shift
> + for x in "$@"; do
> + sed -i -e "/^$p[[:space:]]/s/ #$x//" "$series"
> + done
> +}
> +
> # usage: do_make_header <hash>
> do_make_header()
> {
> diff --git a/guilt-guards b/guilt-guards
> new file mode 100755
> index 0000000..71df4f8
> --- /dev/null
> +++ b/guilt-guards
> @@ -0,0 +1,63 @@
> +#!/bin/sh
> +#
> +# Copyright (c) Eric Lesh, 2007
> +#
> +
> +USAGE="[-l|--list] [-n|--none] [<patchname>] [+<guard>] [-<guard>]"
Since -l and -n are mutually exclusive, shouldn't it be something like:
[-l|--list|-n|--none|[<patchname>] [(+|-)guard...]]
> +. guilt
> +
> +print_guards()
> +{
> + guards=`get_guards "$1"`
> + echo "$1: $guards"
> +}
> +
> +if [ "$1" == "-l" ] || [ "$1" == "--list" ]; then
> + get_series | while read patch; do
> + print_guards "$patch"
> + done
> + exit 0
> +elif [ "$1" == "-n" ] || [ "$1" == "--none" ]; then
> + patch="$2"
> + if [ -z "$patch" ]; then
> + patch=`get_top`
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + exit 0
> +fi
> +
> +case $# in
> + 0)
> + if [ ! -s "$applied" ]; then
> + die "No patches applied."
> + fi
> + print_guards `get_top`
> + ;;
> + 1)
> + if [ -z $(echo $1 | grep -e '^[+-]') ]; then
> + if [ -z $(get_series | grep -e "^$1\$") ]; then
> + die "Patch $1 does not exist"
> + else
> + print_guards "$1"
> + fi
> + else
> + p=`get_top`
> + unset_guards "$p" `get_guards "$p"`
> + set_guards "$p" "$1"
> + fi
> + ;;
> + *)
> + if [ -z $(echo $1 | grep -e '^[+-]') ]; then
> + if [ -z $(get_series | grep -e "^$1\$") ]; then
> + die "Patch $1 does not exist"
> + else
> + patch="$1"
> + fi
> + shift
> + else
> + patch=`get_top`
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + set_guards "$patch" "$@"
> + ;;
> +esac
> --
> 1.5.2
--
Note 96.3% of all statistics are fiction.
^ 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