* Re: Some ideas for StGIT
From: Johannes Schindelin @ 2007-08-05 13:56 UTC (permalink / raw)
To: Josef Sipek; +Cc: Shawn O. Pearce, Jakub Narebski, git
In-Reply-To: <20070805133940.GA18835@filer.fsl.cs.sunysb.edu>
Hi,
On Sun, 5 Aug 2007, Josef Sipek wrote:
> On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:
> ...
> [rebase is complex but fun]
>
> Great, but does git have something that could replace
> $QUILT_LIKE_APP refresh?
What does "refresh"? (I never used quilt, and probably never will, since
rebase -i does what I need.)
> Sure, if you can take 2 commits and collapse them into one you could
> fake it by creating a dummy commit with the new changes, and then
> collapsing, but that's nasty - and reflog might not like that much :)
IIUC you want to edit/amend a patch in the middle of a series? Two ways
to go about it:
1) (preferred)
* start rebase -i
* mark the commit as "edit"
* wait until rebase stops to let you edit it
* edit, test, commit --amend
* rebase --continue
2) (not so preferred, but often convenient)
* fix bug
* commit with a dummy message
* rebase -i
* move commit just after the commit-to-edit
* mark second as "squash"
* when the editor comes up, just delete the second
commit's message, and possibly adjust the first's
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Johannes Schindelin @ 2007-08-05 13:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: bfields, gitster, git
In-Reply-To: <1186318785677-git-send-email-prohaska@zib.de>
Hi,
On Sun, 5 Aug 2007, Steffen Prohaska wrote:
> git gui is especially useful because it allows to select diff hunks.
You should give a _big_ _fat_ _red_ warning there.
If you selectively commit diff hunks, you _never_ tested what you
committed.
That is the reason we're not advertising git add -i more actively.
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Josef Sipek @ 2007-08-05 14:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0708051452280.14781@racer.site>
On Sun, Aug 05, 2007 at 02:56:23PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Josef Sipek wrote:
>
> > On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:
> > ...
> > [rebase is complex but fun]
> >
> > Great, but does git have something that could replace
> > $QUILT_LIKE_APP refresh?
>
> What does "refresh"? (I never used quilt, and probably never will, since
> rebase -i does what I need.)
You understood correctly...see below.
> > Sure, if you can take 2 commits and collapse them into one you could
> > fake it by creating a dummy commit with the new changes, and then
> > collapsing, but that's nasty - and reflog might not like that much :)
>
> IIUC you want to edit/amend a patch in the middle of a series? Two ways
> to go about it:
>
> 1) (preferred)
>
> * start rebase -i
> * mark the commit as "edit"
> * wait until rebase stops to let you edit it
> * edit, test, commit --amend
> * rebase --continue
Ewww...that doesn't seem to scale (read: far too much to type) :) Here's a
quilt/guilt/stgit equivalent:
$APP push <patchname>
or (depending on where you are in the patch stack)
$APP pop <patchname>
<edit>
$APP refresh # this is the commit --amend part
Josef 'Jeff' Sipek.
--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
- George Bernard Shaw
^ permalink raw reply
* Re: Some ideas for StGIT
From: Johannes Schindelin @ 2007-08-05 14:15 UTC (permalink / raw)
To: Josef Sipek; +Cc: Shawn O. Pearce, Jakub Narebski, git
In-Reply-To: <20070805140658.GA4570@filer.fsl.cs.sunysb.edu>
Hi,
On Sun, 5 Aug 2007, Josef Sipek wrote:
> On Sun, Aug 05, 2007 at 02:56:23PM +0100, Johannes Schindelin wrote:
> >
> > On Sun, 5 Aug 2007, Josef Sipek wrote:
> >
> > > Sure, if you can take 2 commits and collapse them into one you could
> > > fake it by creating a dummy commit with the new changes, and then
> > > collapsing, but that's nasty - and reflog might not like that much
> > > :)
> >
> > IIUC you want to edit/amend a patch in the middle of a series? Two ways
> > to go about it:
> >
> > 1) (preferred)
> >
> > * start rebase -i
> > * mark the commit as "edit"
> > * wait until rebase stops to let you edit it
> > * edit, test, commit --amend
> > * rebase --continue
>
> Ewww...that doesn't seem to scale (read: far too much to type) :) Here's a
> quilt/guilt/stgit equivalent:
>
> $APP push <patchname>
>
> or (depending on where you are in the patch stack)
>
> $APP pop <patchname>
>
> <edit>
>
> $APP refresh # this is the commit --amend part
Yeah. Sounds like you'd just need a "--edit-this $commit" flag to rebase
-i.
Out of curiousity, what happens if you say "push" several times,
_without_ popping the patch? And what happens if you "push" several times
with the _same_ patchname?
Ciao,
Dscho
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Julian Phillips @ 2007-08-05 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, git
In-Reply-To: <7v8x8qfnev.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Aug 2007, Junio C Hamano wrote:
> David Kastrup <dak@gnu.org> writes:
>
>> I am trying to dig through man-pages and user manual and trying to
>> match them with reality. I seem to have a hard time. My current
>> understanding (which definitely differs from the documented state) is
>> that there are two types of branches, local and remote branches, and
>> both types of branches can be remote-tracking (it may not be possible
>> to have a non-remote-tracking remote branch, though).
>
> I think we have a brief discussion on #git before you brought
> this up ;-)
>
> - local branches -- we know what they are.
>
> - remote tracking branches -- refs that appear in refs/remotes/
> in the current world order; they are updated only by copying
> the corresponding local branches at the remote site, and are
> meant to "keep track of what _they_ are doing". In olden
> days before 1.5.0 with non separate remote layout,
> 'refs/heads/origin' branch, and all the non default branches,
> were treated this way as well. You were not supposed to make
> commit on them (because of the above "keep track of" reason),
> and having them under refs/heads were too confusing, which
> was the reason the separate remote layout was invented.
>
> You can have a local branch that is created by forking off of a
> remote tracking branch, with the intention to "build on top" of
> the corresponding remote tracking brach. You can create such a
> branch and mark it as such with --track option introduced in
> v1.5.1 timeperiod. This is a relatively new concept, but many
> people find it useful. We do not have the official term to call
> this concept, and some people have misused the term "remote
> tracking branches" to describe this, which made things very
> confusing.
>
> We would need an official terminology for it.
Following was mentioned earlier in this thread ... could we use that?
tracking branch:
ref always points at a commit from the remote repo branch
following branch:
ref either points at a commit from the remote repo branch, or a
local commit with a commit from the remote repo branch in the history
perhaps?
--
Julian
---
An optimist is a man who looks forward to marriage.
A pessimist is a married optimist.
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-05 14:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bfields, gitster, git
In-Reply-To: <Pine.LNX.4.64.0708051457110.14781@racer.site>
On Aug 5, 2007, at 3:58 PM, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
>> git gui is especially useful because it allows to select diff hunks.
>
> You should give a _big_ _fat_ _red_ warning there.
>
> If you selectively commit diff hunks, you _never_ tested what you
> committed.
>
> That is the reason we're not advertising git add -i more actively.
Hmm... If you do 'git cherry-pick' or 'git rebase' you also did
not test what you committed. Should we advertise them less
actively as well?
But I see your point. Selecting diff hunks tends to be more fine
grained than cherry-picking. But this depends on the details of
what you're doing. I don't think a general warning is appropriate.
Steffen
^ permalink raw reply
* Re: [PATCH] Fix install-doc-quick target
From: Johannes Schindelin @ 2007-08-05 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Mark Levedahl, Git Mailing List
In-Reply-To: <7vmyx6fohv.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Aug 2007, Junio C Hamano wrote:
> If you say:
>
> git --work-tree=. foo
>
> without saying anything about GIT_DIR, shouldn't we run the
> usual .git/ discovery, going up the directories?
Well, it seems natural.
The problem is that if you are in a bare repository, after
setup_git_directory_gently() you will no longer be able to tell where you
started from, but you are in the same directory that HEAD was found.
I had the following patch, but it breaks all kinds of tests :-(
Will keep you posted,
Dscho
-- snipsnap --
setup.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/setup.c b/setup.c
index d87e4e1..c627623 100644
--- a/setup.c
+++ b/setup.c
@@ -291,7 +291,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env)
inside_work_tree = 0;
setenv(GIT_DIR_ENVIRONMENT, ".", 1);
- return NULL;
+ goto ret;
}
chdir("..");
do {
@@ -311,6 +311,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env)
inside_work_tree = 1;
git_work_tree_cfg = xstrndup(cwd, offset);
+ret:
if (offset == len)
return NULL;
@@ -376,14 +377,15 @@ const char *setup_git_directory(void)
/* If the work tree is not the default one, recompute prefix */
if (inside_work_tree < 0) {
static char buffer[PATH_MAX + 1];
+ const char *git_dir = get_git_dir();
char *rel;
/*
* When the git dir was determined automatically, it is
* a relative path.
*/
- if (!getenv(GIT_DIR_ENVIRONMENT))
- set_git_dir(make_absolute_path(get_git_dir()));
+ if (!is_absolute_path(git_dir))
+ set_git_dir(make_absolute_path(git_dir));
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
^ permalink raw reply related
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-08-05 14:46 UTC (permalink / raw)
To: Eran Tromer; +Cc: Junio C Hamano, git
In-Reply-To: <46B4A350.9060806@tromer.org>
On Sat, Aug 04, 2007 at 12:03:28PM -0400, Eran Tromer wrote:
> Works here: it silences the check and allows switching branches. Still,
> leaving the working tree dirty can inadvertently affect subsequent
> commits. Consider the most ordinary of sequences:
>
> $ git checkout experimental-death-ray
> $ git submodules update
> (return a week later, woozy from the vacation.)
> $ git checkout master
Here, it'll warn that your submodule isn't up-to-date.
> (hack hack hack)
> $ git commit -a -m "fixed typos"
And if you run "git status" first, it'll tell you that the submodule
(still) isn't up-to-date.
> $ git push
> (Oops. You've just accidentally committed the wrong submodule heads.)
You always have to be careful when doing "git commit -a".
> Another approach is for pull, checkout etc. to automatically update the
> submodule' head ref, but no more.
Then everything, including "git submodule update", would assume
that the submodule is up-to-date.
skimo
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Johannes Schindelin @ 2007-08-05 14:48 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: bfields, gitster, git
In-Reply-To: <17AA7EBE-B755-4F26-9C7E-AF6D762811F2@zib.de>
Hi,
On Sun, 5 Aug 2007, Steffen Prohaska wrote:
> On Aug 5, 2007, at 3:58 PM, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Sun, 5 Aug 2007, Steffen Prohaska wrote:
> >
> > > git gui is especially useful because it allows to select diff hunks.
> >
> > You should give a _big_ _fat_ _red_ warning there.
> >
> > If you selectively commit diff hunks, you _never_ tested what you
> > committed.
> >
> > That is the reason we're not advertising git add -i more actively.
>
> Hmm... If you do 'git cherry-pick' or 'git rebase' you also did
> not test what you committed. Should we advertise them less
> actively as well?
But you have that state in your working tree! Big difference there!
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Josef Sipek @ 2007-08-05 14:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0708051513310.14781@racer.site>
On Sun, Aug 05, 2007 at 03:15:29PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Josef Sipek wrote:
>
> > On Sun, Aug 05, 2007 at 02:56:23PM +0100, Johannes Schindelin wrote:
> > >
> > > On Sun, 5 Aug 2007, Josef Sipek wrote:
> > >
> > > > Sure, if you can take 2 commits and collapse them into one you could
> > > > fake it by creating a dummy commit with the new changes, and then
> > > > collapsing, but that's nasty - and reflog might not like that much
> > > > :)
> > >
> > > IIUC you want to edit/amend a patch in the middle of a series? Two ways
> > > to go about it:
> > >
> > > 1) (preferred)
> > >
> > > * start rebase -i
> > > * mark the commit as "edit"
> > > * wait until rebase stops to let you edit it
> > > * edit, test, commit --amend
> > > * rebase --continue
> >
> > Ewww...that doesn't seem to scale (read: far too much to type) :) Here's a
> > quilt/guilt/stgit equivalent:
> >
> > $APP push <patchname>
> >
> > or (depending on where you are in the patch stack)
> >
> > $APP pop <patchname>
> >
> > <edit>
> >
> > $APP refresh # this is the commit --amend part
>
> Yeah. Sounds like you'd just need a "--edit-this $commit" flag to rebase
> -i.
Still, very inconvenient (IMO) when you are working _on_ lots of patches.
> Out of curiousity, what happens if you say "push" several times,
> _without_ popping the patch? And what happens if you "push" several times
> with the _same_ patchname?
In addition to the patches, there's also ordering information for those
patches (the series file) - in the simplest case it is a stack in the
traditinal Comp Sci meaning. IOW, if you have patches {foo,bar,baz} and you
want to push "bar", the patch "foo" will also get pushed. When you push a
patch, the software makes note of the fact (status file in Guilt).
If you try to push the same patch twice, it'll tell you that the patch is
already applied. The Mercurial Book has a section about Mercurial Queues
(Mercurial's implementation of something similar to Guilt/stgit) which
describes the concepts rather well [1]. I think that figure 12.10 [2] really
explains the whole thing pretty well. Of course, there is always the quilt
doc (big PDF which has the whole history, etc., etc.).
Hrm, it just occured to me that the quilt-way of managing patches is the
basic concept of a turing machine - infinite tape which is seekable and you
can read/write to the "current" position (topmost applied patch). :)
Josef 'Jeff' Sipek.
[1] http://hgbook.red-bean.com/hgbookch12.html#x16-27200012.5
[2] http://hgbook.red-bean.com/hgbookch12.html#x16-27600310
--
Computer Science is no more about computers than astronomy is about
telescopes.
- Edsger Dijkstra
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-08-05 14:59 UTC (permalink / raw)
To: Eran Tromer; +Cc: Alex Riesen, VMiklos, git
In-Reply-To: <46B3B3D2.6030000@tromer.org>
On Fri, Aug 03, 2007 at 07:01:38PM -0400, Eran Tromer wrote:
> $ mkdir super
> $ cd super
> $ git init
> $ git submodule add ../sub-to-be sub
You probably don't want to do this as this URL
probably won't work for anyone who wants to clone
your superproject.
> BTW, is there any easy way to create a submodule directly inside the
> supermodule's working tree, instead of cloning it as in the above example?
Do you want to use the submodule porcelain or just the plumbing?
If you simply want to add a submodule locally, "git add" will do that for
you just fine. It's only when you want to make it easier for people who
clone your superproject to get updates of the submodules that you
should set up the information required by "git submodule" in .gitmodules
(see end of module_add in git-submodule.sh).
Note that the "url" can be set directly in your git config
(without specifying it in .gitmodules), but then anyone who clones
from you will have to modify his config "manually" too.
For some reason, the "path" element is required, even if it is equal
to the submodule name.
skimo
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: David Kastrup @ 2007-08-05 15:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, bfields, gitster, git
In-Reply-To: <17AA7EBE-B755-4F26-9C7E-AF6D762811F2@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Aug 5, 2007, at 3:58 PM, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>>
>>> git gui is especially useful because it allows to select diff hunks.
>>
>> You should give a _big_ _fat_ _red_ warning there.
>>
>> If you selectively commit diff hunks, you _never_ tested what you
>> committed.
>>
>> That is the reason we're not advertising git add -i more actively.
>
> Hmm... If you do 'git cherry-pick' or 'git rebase' you also did
> not test what you committed. Should we advertise them less
> actively as well?
Selectively committing diff hunks also means that a subsequent rebase
-i or git-cherry will have to reconsider the same commit as it has
only been incompletely applied.
So it can mean more work later. Also one would in general have to
edit the commit message (if it describes everything that has been
done).
There are simply consequences for the workflow if you do things
right. Whether they are worth a "big fat red warning" is one
question, but mentioning them is probably not amiss.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 15:09 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708051519400.7631@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Sun, 5 Aug 2007, Junio C Hamano wrote:
>>
>> I think we have a brief discussion on #git before you brought
>> this up ;-)
>>
>> - local branches -- we know what they are.
>>
>> - remote tracking branches -- refs that appear in refs/remotes/
>> in the current world order; they are updated only by copying
>> the corresponding local branches at the remote site, and are
>> meant to "keep track of what _they_ are doing". In olden
>> days before 1.5.0 with non separate remote layout,
>> 'refs/heads/origin' branch, and all the non default branches,
>> were treated this way as well. You were not supposed to make
>> commit on them (because of the above "keep track of" reason),
>> and having them under refs/heads were too confusing, which
>> was the reason the separate remote layout was invented.
>>
>> You can have a local branch that is created by forking off of a
>> remote tracking branch, with the intention to "build on top" of
>> the corresponding remote tracking brach. You can create such a
>> branch and mark it as such with --track option introduced in
>> v1.5.1 timeperiod. This is a relatively new concept, but many
>> people find it useful. We do not have the official term to call
>> this concept, and some people have misused the term "remote
>> tracking branches" to describe this, which made things very
>> confusing.
>>
>> We would need an official terminology for it.
>
> Following was mentioned earlier in this thread ... could we use that?
>
> tracking branch:
> ref always points at a commit from the remote repo branch
>
> following branch:
> ref either points at a commit from the remote repo branch, or a
> local commit with a commit from the remote repo branch in the history
>
> perhaps?
An auto-merging branch? The term is somewhat more technical so that
people are less likely to think it just a colloquial alternative
expression for "tracking".
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Julian Phillips @ 2007-08-05 15:24 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85ps226mrc.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> On Sun, 5 Aug 2007, Junio C Hamano wrote:
>>> We would need an official terminology for it.
>>
>> Following was mentioned earlier in this thread ... could we use that?
>>
>> tracking branch:
>> ref always points at a commit from the remote repo branch
>>
>> following branch:
>> ref either points at a commit from the remote repo branch, or a
>> local commit with a commit from the remote repo branch in the history
>>
>> perhaps?
>
> An auto-merging branch? The term is somewhat more technical so that
> people are less likely to think it just a colloquial alternative
> expression for "tracking".
Personally I don't like auto-merging as it doesn't have any connotations
of _what_ is auto-merged ... and it's not really an automatic merge
anyway, you have to ask for it (by running pull).
--
Julian
---
Don't look back, the lemmings are gaining on you.
^ permalink raw reply
* Re: gitbox status (for those who want to hack on it)
From: Johannes Schindelin @ 2007-08-05 15:37 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Mike Pape, Paul Hampson
In-Reply-To: <fcaeb9bf0708041040w6d2b3f2cu1680e1e7dc542ffb@mail.gmail.com>
Hi,
On Sat, 4 Aug 2007, Nguyen Thai Ngoc Duy wrote:
> I would say it's in pretty good state now because it can run through
> test cases. Running tests on Windows can take about an hour so I'll
> put test results here so you don't have to rerun the whole thing if
> you want to know what part needs work.
I think your project is awesome. Unfortunately, I did not have time to
check it out yet -- work-tree regressions and msysgit keep me occupied,
along with daytime job...
It should be relatively easy to get this as an option into the msysGit net
installer, once /git is a submodule there.
Ciao,
Dscho
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Theodore Tso @ 2007-08-05 15:48 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, git
In-Reply-To: <85fy2y89kb.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 02:12:04PM +0200, David Kastrup wrote:
> Well, that is pretty much exactly what I find fascinating: that the
> behavior is arbitrary and undocumented enough that one can't deduce it
> either by logic or by recollection or by documentation, but just by
> reading the code.
The behavior of how references work and how the config file parameters
under remote.* and branch.* are pretty well understood, and the
conceptual model is pretty simple; see Jeff's message. And most of it
*is* documented if you look at the git-fetch, git-pull, git-config man
pages --- just not systematically in one place.
What's not so well understood I suspect by most people is how the "git
branch" tool edits the config file. It was added later, and many of
the git hackers who already know the conceptual model and who are used
to editing .git/config directly to get what they want, don't use git
branch much themselves; that's really for more novice users and more
simpler config files.
To use a GNU emacs example, consider M-x customize, which is this
huge, very fancy, *very* complex hierarchical mechanism with a
pointy-clicky interface for setting options. Most emacs experts
wouldn't use it, preferring to open code raw emacs-lisp settings in
their .emacs.el. If you ask an old-time emacs user how to set up some
specific feature setting via M-x customize, they might look at you
blankly, because it's not an interface they use much, if at all.
A similar thing can be said of "git branch"; once you are familiar
with how git works at a conceptual level, it can often be
faster/easier to just hack the .git/config file directly, instead of
using "git branch" to set up things the way you want. And I'm pretty
sure there are ways to set up the config file when you edit it by hand
that you can't set up via "git branch".
- Ted
^ permalink raw reply
* Problem with bisect
From: Larry Finger @ 2007-08-05 16:02 UTC (permalink / raw)
To: git
I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and
v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's
wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we
obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before
bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this
code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom
is all the way to v2.6.16, which I think is the origin of the git process.
Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by
arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has
been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the
bug doesn't show on my machine.
Thanks,
Larry
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Theodore Tso @ 2007-08-05 16:11 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Shawn O. Pearce, Miles Bader
In-Reply-To: <200708051411.25238.johan@herland.net>
On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
> $ hg addremove --help
> hg addremove [OPTION]... [FILE]...
>
> add all new files, delete all missing files
>
> Add all new files and remove all missing files from the repository.
>
> New files are ignored if they match any of the patterns in .hgignore. As
> with add, these changes take effect at the next commit.
>
> Adding a git-addremove command should not be much work, and it would be a
> lot friendlier to people whose workflow is more aligned with #2 than #1.
Not much work at alll:
# git config --system --add alias.addremove "git add . ; git add -u"
:-)
(And the performance problem with git add . is fixed in 1.5.3-rc4,
right?)
- Ted
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Randal L. Schwartz @ 2007-08-05 16:27 UTC (permalink / raw)
To: Theodore Tso; +Cc: David Kastrup, Jeff King, git
In-Reply-To: <20070805154801.GD28263@thunk.org>
>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:
Theodore> To use a GNU emacs example, consider M-x customize, which is this
Theodore> huge, very fancy, *very* complex hierarchical mechanism with a
Theodore> pointy-clicky interface for setting options. Most emacs experts
Theodore> wouldn't use it, preferring to open code raw emacs-lisp settings in
Theodore> their .emacs.el. If you ask an old-time emacs user how to set up
Theodore> some specific feature setting via M-x customize, they might look at
Theodore> you blankly, because it's not an interface they use much, if at all.
I beg to differ. I *am* an old-time Emacs user, and I resisted customize when
it first appeared, because *most* of the things still didn't use it. However,
as of a year ago, I assessed that customize had gotten to "critical mass", and
that 75% of my .emacs could be replaced by it. So I have, and it's made
things simpler for me.
So, it just has to be complete enough and flexible enough.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 16:23 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jeff King, git
In-Reply-To: <20070805154801.GD28263@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> To use a GNU emacs example, consider M-x customize, which is this
> huge, very fancy, *very* complex hierarchical mechanism with a
> pointy-clicky interface for setting options. Most emacs experts
> wouldn't use it, preferring to open code raw emacs-lisp settings in
> their .emacs.el. If you ask an old-time emacs user how to set up
> some specific feature setting via M-x customize, they might look at
> you blankly, because it's not an interface they use much, if at all.
Well, let me throw you back one of your questions: do you have any
statistics backing this up?
As to anecdotal evidence: I am an old-time Emacs user, and I pretty
much use customize _exclusively_ since it generally leaves me with a
_working_ configuration even when the DOC string might be sub-optimal
or misleading or hard to understand, and it makes sure that, say,
everything to make a global minor mode _active_ (like loading some
file, or calling some initialization functions) is done at the right
point of time.
If "old-time Emacs users" would not use customize, why would pretty
much _every_ package come with _working_ defcustoms? Who writes and
_tests_ those defcustoms if not the "old-time Emacs users"?
> A similar thing can be said of "git branch"; once you are familiar
> with how git works at a conceptual level, it can often be
> faster/easier to just hack the .git/config file directly, instead of
> using "git branch" to set up things the way you want. And I'm
> pretty sure there are ways to set up the config file when you edit
> it by hand that you can't set up via "git branch".
Sure. But we don't want to _require_ this sort of special knowledge
before one can even hope to do some basic task.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Sean @ 2007-08-05 16:40 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, git
In-Reply-To: <85fy2y89kb.fsf@lola.goethe.zz>
On Sun, 05 Aug 2007 14:12:04 +0200
David Kastrup <dak@gnu.org> wrote:
> Well, that is pretty much exactly what I find fascinating: that the
> behavior is arbitrary and undocumented enough that one can't deduce it
> either by logic or by recollection or by documentation, but just by
> reading the code.
>
> Usually code is supposed to implement a design, but here it seems
> rather like the design, if there is any, is to be abstracted from the
> code.
To me it's yet another example of bad UI design in Git. Git already
had remote-tracking branches, which conceptually were relatively easy
to explain. Instead of leveraging this foundation, and adding the
ability for local branches to pick a default remote-tracking branch
to use for merging, Git instead implemented direct remote tracking
from local branches. After having read the thread Jeff mentioned
earlier i'm still at a loss as to how this decision was justified.
To make it even worse, it turns out that this command:
$ git branch --track mybranch remote/branch
Does _NOT_ tell git to setup mybranch to track remote/branch. Read that
command line again and then scratch your head as to how anyone without
deep Git knowledge is supposed to infer its real meaning without being
told to read previous email threads etc. This also means the feature
can't be used to say:
$ git branch --track mybranch otherlocalbranch
Being a fan of Git, it's frustrating to see that more weight is not
paid to such UI concerns. Especially when the concern _was_ raised
when the feature was first added.
Sean
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 16:45 UTC (permalink / raw)
To: Sean; +Cc: David Kastrup, git
In-Reply-To: <20070805124050.c1345ec9.seanlkml@sympatico.ca>
On Sun, Aug 05, 2007 at 12:40:50PM -0400, Sean wrote:
> To me it's yet another example of bad UI design in Git. Git already
> had remote-tracking branches, which conceptually were relatively easy
> to explain. Instead of leveraging this foundation, and adding the
> ability for local branches to pick a default remote-tracking branch
> to use for merging, Git instead implemented direct remote tracking
> from local branches. After having read the thread Jeff mentioned
> earlier i'm still at a loss as to how this decision was justified.
To be fair, the default remote-tracking branch stuff predates the thread
I pointed you to. But I do agree it makes the system that much more
confusing to have it this way.
There is a clash between users with different workflows here, I think.
For example, I almost _never_ run git-pull, but instead always fetch,
inspect, and then merge from a tracking branch. So I think of tracking
branches as a first-class item. But I suspect Linus doesn't use tracking
branches at all, since he pulls directly from a variety of different
repositories.
-Peff
^ permalink raw reply
* Re: possible bug in git apply?
From: Linus Torvalds @ 2007-08-05 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: david, git, rob
In-Reply-To: <7vvebuh8g8.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Aug 2007, Junio C Hamano wrote:
> >
> > Does this fix it? Totally untested, but it _looks_ obvious enough..
>
> That would regress the fix made in aea19457, I am afraid.
The fix in aea19457 is broken anyway.
Why?
That whole "do it in two phases" thing breaks it.
What can happen is that you have a directory with 100 files, and:
- a patch modifies 99 of them
- and removes one
What happens is that during phase 0, we'll remove all the files (and *not*
write new ones), and then beause the last patch entry is a removal, we'll
also remove the directory (which succeeds, because all the files that got
modified are all long gone).
Then, in phase 1, we'll re-create the files that we modified, and create a
whole new directory.
IOW, as far as I can see we _already_ delete and then recreate the
directory structure under some circumstances.
I just extended it to also do it for "rename" and not just delete, since a
rename may be renaming it to another directory.
So I'd say that my patch is a clear improvement on the current situation.
That said, if we really wanted to get it right, we should do this as a
three-phase thing: (1) remove old files (2) create new files (3) for all
removals and renames, try to remove source directories that might have
become empty.
That would fix it properly and for all cases.
Linus
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Linus Torvalds @ 2007-08-05 17:04 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <87hcnejuxp.fsf@catnip.gol.com>
On Sun, 5 Aug 2007, Miles Bader wrote:
>
> I notice that "git ls-files -o" doesn't do normal ignore-processing, so
> for instance all my .o and editor backup files show up in the output...
Yeah, I'm a moron.
> Is that expected or is it a bug
It's expected (I just didn't try the command line I gave you).
"git ls-files" is low-level plumbing, and those things generally do only
what you ask from them and never anything user-friendly. In particular,
they tend to avoid policy decisions. An example of this is "git diff" that
colorizes the output by default as you have specified, but "git diff-tree"
that does not.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-05 17:08 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85bqdmctcl.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
>
> So please get a grip and focus on what we were actually talking
> about. Not Emacs, but rather documentation formats.
You're the one who started talking about me expecting people to use *my*
editor. I had never done that. I had talked about the _reverse_: the
idiocy of emacs users expecting people to use that bloated piece of
crap-ware.
> > Man-pages with man.
>
> Actually, Emacs "woman" does a pretty good job with those, offers
> convenient man page name completion and works on Windows and similar
> platforms without needing
See? Can you not see that normal users don't want to have some random
emacs crap? In fact, even GNU emacs users (apart from the ones that have
used it for more than a decade) don't do it.
So stop this *insane* insistence of emacs. You should learn to just assume
that people don't even have it installed!
Anything that works with some random emacs mode is a total non-usable
piece of crap as far as most users are concerned.
> Focus. How do you propose to manage documention of a hundred pages an
> more conveniently, finding information easily by text, index,
> hyperlinks? A single large HTML page? A documentation directory full
> of *.txt files which you can grep through (not that Emacs would not be
> useful for that, too)?
Oh, a single large html page is certainly better than emacs and info,
absolutely. Ask *any* normal person.
The fact that you cannot see that fact is a sign of your personal (and
rather odd) preferences.
Linus
^ 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