* [PATCHv6 0/5] gitweb: PATH_INFO enhancement
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Sixth attempt for my gitweb PATH_INFO patchset, whose purpose is to
reduce the use of CGI parameters by embedding as many parameters as
possible in the URL path itself, provided the pathinfo feature is
enabled.
The new typical gitweb URL is therefore in the form
$project/$action/$parent:$file..$hash:$file
(with useless parts stripped). Backwards compatibility for old-style
$project/$hash[:$file] URLs is kept, as long as $hash is not a refname
whose name happens to match a git action.
The main implementation is provided by paired patches (#1#2, #4#5)
that implement parsing and generation of the new style URLs.
Patch #3 is a minor improvement to the URL syntax that allows web
sites to be properly browsable in raw mode.
The patchset depends on my previous input parameter handling patch
currently waiting in 'next'. This resend fixes a couple of problems
I found in v5.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 124 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 114 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-16 20:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matt Draisey, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0810161619330.26244@xanadu.home>
On Thu, Oct 16, 2008 at 04:20:32PM -0400, Nicolas Pitre wrote:
> > so almost all my git repositories are still using a symlink HEAD.
> > I have some old scripts That I use occasionally and still depend on it.
> > Using detached checkout is the only problem I've had.
>
> A symlink HEAD and detached checkouts are simply incompatible.
Agreed, but I think the complaint is not that it doesn't work, but that
it silently clobbers the current branch when you try it.
-Peff
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Nicolas Pitre @ 2008-10-16 20:20 UTC (permalink / raw)
To: Matt Draisey; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <1224187863.2796.15.camel@localhost>
On Thu, 16 Oct 2008, Matt Draisey wrote:
> On Thu, 2008-10-16 at 15:17 -0400, Jeff King wrote:
>
> > Hmm. I don't think we have shipped with a symlink HEAD for quite a long
> > time. Using one obviously doesn't work with detached HEAD, but also
> > would fail with packed refs. I don't know if we ever deprecated it.
>
> I am using the following system defaults:
>
> core.prefersymlinkrefs=true
> gc.packrefs=false
>
> so almost all my git repositories are still using a symlink HEAD.
> I have some old scripts That I use occasionally and still depend on it.
> Using detached checkout is the only problem I've had.
A symlink HEAD and detached checkouts are simply incompatible.
Nicolas
^ permalink raw reply
* Re: Git and tagging hook
From: Jan Hudec @ 2008-10-16 20:15 UTC (permalink / raw)
To: Kristis Makris; +Cc: Andreas Ericsson, Jakub Narebski, git, scmbug-users
In-Reply-To: <1224007401.4073.40.camel@localhost>
On Tue, Oct 14, 2008 at 11:03:21 -0700, Kristis Makris wrote:
> I have two use cases:
>
> (1) A developer maintains besides his local copy a local bug-tracking
> system in which he tracks his changes. We would like to apply various
> verification policies when he commits or tags. For example, for tagging
> we wants to ensure that he tags giving consistent labels to his
> intermediate builds. e.g. as in:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
That already requires using additional interface to git alone. Using an alias
for creating tags that are synchronized with that local bug-tracker is not
that much more complex than IMHO. Besides you will sometimes want to use git
tags, branches, commits and other things *without* synchronizing them to the
local bug-tracker even if you usually synchronize -- they are often very
useful for manipulating changes.
> Or he may want to have Git force him to also supply a log message along
> with a tag, so that he can remember later more accurately why a tag was
> created and what it really captures. Even if Git (or other SCM systems)
> don't natively support log messages on tags. Scmbug plans to implement
> this.
>
> http://bugzilla.mkgnu.net/show_bug.cgi?id=219
Git does support log messages on tags. It has unannotated tags (which are
just refs) and annotated tags which have a special tag object with the log
message (and optionally PGP signature).
> (2) I would like to apply various verification policies when work from a
> local repository is finally merged with the central repository. I assume
> there can/will be a central repository, and there is one "software
> product" that is being released somewhere among the many copies.
>
> When its time to merge local changes to a central repository, the
> verification policies may deem that changes are not acceptable to be
> merged with the mainline. e.g. because log messages are too short,
> commits during the merge are issued against bugs in "a central"
> bugtracker that are either closed, assigned to someone else, or just
> plain wrong bug-numbers that belong to other products:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
>
> (I'm not very clear whether this is how Git works)
>
> Does someone get to write-up a brand new log comment during the merge
> and the merge totally disregards older log comments? My understanding
> is that log comments on the local copy are preserved (and will need to
> be mapped to bug-numbers in the central bug-tracker.
Indeed, the locally made commits are transfered to the upstream repository as
they are. In fact, because the commit id is a SHA1 checksum of all it's
content, including the message and the parent ids (and therefore complete
history), when the commit message is changed, it is no longer the same
commit.
However, git provides many tools (commit --amend, rebase -i, filter-branch)
and has additional extensions (stgit, topgit), that make it easy to create
a new commit based on another one with some change. This is extremely useful
and many people use it really often.
Such new commit will not replace the previous one -- it has different
checksum -- so it's not good thing to do when other people already based
further changes on your commit. But it's very useful for handling work in
progress, quickly diverting to different tasks, making experiments and such.
Therefore it's the push that casts things in stone, but before that you can
easily take back and redo both commits and tags. Additionally it's very
useful to sometimes do commits and tags that you intend to replace later just
to temporarily record some interesting state eg. to divert to other bug that
suddenly got higher priority or to try out different approach.
Thus you only want to run the checks as warnings locally and probably want to
have an option to avoid them in a particular case for performance reasons
(all this stuff is so useful because it's fast). And since the tags that are
ment for publication you will usually pull shortly after making them and
because creating a tag is rather simple, I would say that running the check
on push is sufficient there and the alias helps if you'd really want to run
the check earlier. For commits you can of course use the pre-commit and
post-commit hooks.
> [...]
> The local tag is useful to the local user and his local bug-tracker. He
> can have tag operations intercepted so that the tag names show up as
> versions in his bug-tracker. In this way he can keep track of which bugs
> still exist or have recently been introduced/discovered to his local
> copy, before he decides to publish his polished, final version:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS
>
> And his "local bug-tracker" may be reachable on the web and useful by
> others that take a peek at the users progress (even fetching it with
> Git).
I would rather recommend having per-developer branches (you can actually have
branch hierarchies, so it's rather per-developer branch directories) on the
central repo, where the users would push their work they consider final
enough to show to anybody. Than you can have a "pending" (or "for review" or
both or whatever) state in the central bug-tracker for issues with fixes on
such developer branches. That saves the hassle of installing per-developer
trackers and gives developer more freedom to create temporary stuff locally.
That is not to say that your use case makes no sense. I am just trying to
suggest a workflow, that might fit better with the existing practices used
with git and maybe requiring less work to implement.
As for people replacing their local commits, this is common especially in
Linux (and Git) development model. For Linux patches need to be sent split
into logical steps to make it easier to review them, which is quite important
for a critical piece of code like kernel. But everybody will inevitably make
mistakes when implementing the changes; these mistakes must not appear in the
final submission though, because they would interfere with review. When
developing in Git, each commit will produce one patch in the submission, so
people go and redo their commits multiple times to make them as much readable
as possible and fix bugs they made earlier.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Matt Draisey @ 2008-10-16 20:11 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081016191751.GB14707@coredump.intra.peff.net>
On Thu, 2008-10-16 at 15:17 -0400, Jeff King wrote:
> Hmm. I don't think we have shipped with a symlink HEAD for quite a long
> time. Using one obviously doesn't work with detached HEAD, but also
> would fail with packed refs. I don't know if we ever deprecated it.
I am using the following system defaults:
core.prefersymlinkrefs=true
gc.packrefs=false
so almost all my git repositories are still using a symlink HEAD.
I have some old scripts That I use occasionally and still depend on it.
Using detached checkout is the only problem I've had.
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-16 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzbdjcb8.fsf@gitster.siamese.dyndns.org>
On Thu, Oct 16, 2008 at 8:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Thu, Oct 16, 2008 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>
>>>> On Wed, Oct 15, 2008 at 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>>>
>> Would you prefer to leave -v out?
>
> Not at all.
>
> Perhaps there is a deeper misunderstanding.
Perhaps there was one :-)
> It makes perfect sense _at the end user interface level_ to have -v and -q
> as two separate options, perhaps with "later one wins" semantics. Another
> possible semantics is "-q and -v are mutually incompatible", but I think
> "later one wins" makes it much more usable from the end user's point of view.
>
> The only thing I was objecting to was your repeated (verbose || !quiet)
> expression in the _implementation_, which would have been much easier to
> read and maintain, if it were expressed as a single variable "verbosity"
> that can have one of three values.
This leaves no space for speculation and is as clear as it gets :D
> IOW,
>
> static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
> ...
>
> if (!strcmp("--quiet", arg))
> verbosity = QUIET;
> else if (!strcmp("--verbose", arg))
> verbosity = VERBOSE;
> else ...
>
> ...
> if (verbosity > QUIET)
> print informational message;
> if (verbosity > NORMAL)
> print verbose message;
>
> See?
Yeah, no problem with that.
How do you propose we should integrate this with the
existing usage of parse_options() and OPT_ macros?
I want to keep using it and not redo argv handling
from scratch in builtin-fetch/builtin-merge.
^ permalink raw reply
* [JGIT PATCH] Fix the build script to make jgit.jar, jgit.src non-executable
From: Shawn O. Pearce @ 2008-10-16 19:57 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Silly copy and paste error included these unncessary chmods.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
make_jgit.sh | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/make_jgit.sh b/make_jgit.sh
index a15f73f..2969e6e 100755
--- a/make_jgit.sh
+++ b/make_jgit.sh
@@ -95,7 +95,6 @@ java org.spearce.jgit.pgm.build.JarLinkUtil \
-include org.spearce.jgit/bin2 \
-file META-INF/MANIFEST.MF=$T_MF \
>$O_JAR+ &&
-chmod 555 $O_JAR+ &&
mv $O_JAR+ $O_JAR &&
echo "Created $O_JAR." &&
@@ -103,7 +102,6 @@ java org.spearce.jgit.pgm.build.JarLinkUtil \
-include org.spearce.jgit/src \
-file META-INF/MANIFEST.MF=$T_MF \
>$O_SRC+ &&
-chmod 555 $O_SRC+ &&
mv $O_SRC+ $O_SRC &&
echo "Created $O_SRC." &&
--
1.6.0.2.711.gf1ba4
^ permalink raw reply related
* Re: Working with remotes; cloning remote references
From: Peter Harris @ 2008-10-16 19:20 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <48F7852F.109@xiplink.com>
On Thu, Oct 16, 2008 at 2:17 PM, Marc Branchaud wrote:
> From this point of view (and please correct me if I'm wrong), it would be
> good if "git clone" had an option to include a repo's remote references in
> the clone. The clone's origin reference would point to the original repo as
> usual, but all the other remotes would be in the clone.
"git clone" doesn't have this option, but you can turn it on
immediately after with something similar to:
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
(which I use for fanning-out my git-svn repos)
See "git help fetch" for further documentation.
Peter Harris
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-16 19:17 UTC (permalink / raw)
To: Matt Draisey; +Cc: Junio C Hamano, git
In-Reply-To: <1224095087.5366.19.camel@localhost>
On Wed, Oct 15, 2008 at 02:24:47PM -0400, Matt Draisey wrote:
> If HEAD is a symlink rather than a "ref:" style link this is really
> bad.
Hmm. I don't think we have shipped with a symlink HEAD for quite a long
time. Using one obviously doesn't work with detached HEAD, but also
would fail with packed refs. I don't know if we ever deprecated it.
Still, this is a pretty nasty effect, in that it kills whatever was in
the existing ref. There is a fix below which refuses to lock any ref if
it is a symlink and we have requested not to dereference (actually, it
is overly cautious -- the symlink flag is triggered when we see a
symlink anywhere in the chain, though we need only prevent the situation
when the _first_ symref is a symlink. I don't know if it is worth
differentiating, since they are both "should never happen anymore"
situations, I think).
---
diff --git a/refs.c b/refs.c
index b680750..43568e7 100644
--- a/refs.c
+++ b/refs.c
@@ -447,7 +447,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
strcpy(ref_buffer, buffer);
ref = ref_buffer;
if (flag)
- *flag |= REF_ISSYMREF;
+ *flag |= REF_ISSYMREF | REF_ISSYMLINK;
continue;
}
}
@@ -817,6 +817,10 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
}
ref = resolve_ref(orig_ref, lock->old_sha1, mustexist, &type);
}
+ if (type & REF_ISSYMLINK && flags & REF_NODEREF) {
+ error("unable to directly lock symbolic link '%s'", orig_ref);
+ goto error_return;
+ }
if (type_p)
*type_p = type;
if (!ref) {
diff --git a/refs.h b/refs.h
index 06ad260..6356a6a 100644
--- a/refs.h
+++ b/refs.h
@@ -12,6 +12,7 @@ struct ref_lock {
#define REF_ISSYMREF 01
#define REF_ISPACKED 02
+#define REF_ISSYMLINK 04
/*
* Calls the specified function for each ref file until it returns nonzero,
^ permalink raw reply related
* Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-16 18:17 UTC (permalink / raw)
To: git
Hi all,
We're a Subversion shop moving to git, and our git-fu is still pretty
weak. So I'd appreciate feedback on the setup I'm going to describe, in
addition to the specific issue I'm going to raise.
Our products involve extensive customization of various
externally-maintained code bases (mainly in FreeBSD, but also in a few
other projects too). We'd like to track the various external
repositories, to be able to bring their updates into our code base. We
don't normally push our own customizations back upstream (yes, not The
Way Things Should Be, please turn down the flamethrowers).
So we want our main code tree to be composed of our own code and an
assortment of modified external code:
main/
external1/
external2/
ourstuffA/
ourstuffB/
Our general approach for supporting this (remember, git novices here) is
to keep a local git mirror of each external code repository (say, with
git-svn for the FreeBSD tree). Then we incorporate the local mirrors
into our main repo, each under its own directory.
I've looked at two ways to do this: submodules and subtree merges, and
the latter looks better to me. The main complication with submodules is
branching and tagging. We need to branch or tag the entire main code
tree, including all the external code bases. With submodules that seems
like it would involve several steps to touch all the external mirror
repos as well as the main repo. Another complication is that we do a
lot of our work (50% or more) in the external code trees, and having to
update the main repo's submodule references as that code changes seems
rather fragile.
OTOH, a subtree merge nicely puts the external code into a specific spot
in our main tree, lets that spot get updated with a single command (git
pull -s subtree External2 master), and still let us branch and tag with
single commands in the main repo. Also, the changes we make to
externally-based code are plain old git pushes to the main repo. Clean
and simple. (BTW, what does braid add beyond just doing subtree merges
directly?)
So, first the general question: Anything braindead about the above? Any
better ways to do this?
Now for the specific issue, which has to do with managing the remotes
defined in the main repository. The subtree-merge approach calls for
the mirrored external repos to be "git remote add"-ed to the main repo.
But clones of that repo don't include the remote references (using git
1.5.4.3 for my testing here).
I think that makes sense in most cases: Usually a developer will only
want to clone the main repo and work with what's in there, ad not want
to bother with the external references. But when it comes time to pull
in updates from the external mirror repos the only place where that can
be done is on the main repo where the original "git remote add" commands
were issued.
That means merge work has to be done on the main repository's shared
host (not good) and that testing merged code has to involve committing
changes on the main shared repo (also not good, even in a branch) and
testing them on a different host (still no goodness here).
From this point of view (and please correct me if I'm wrong), it would
be good if "git clone" had an option to include a repo's remote
references in the clone. The clone's origin reference would point to
the original repo as usual, but all the other remotes would be in the clone.
Pushing and pulling would then also update (non-origin) the remote
references.
Does this make sense? Am I missing something here? (And thanks for
reading this far!)
Marc
^ permalink raw reply
* Re: [Q] "status" of files in (a part of) the working tree
From: Jeff King @ 2008-10-16 18:44 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <200810150953.42279.brian.foster@innova-card.com>
On Wed, Oct 15, 2008 at 09:53:42AM +0200, Brian Foster wrote:
> For every file in a directory of my working tree,
> I want to obtain a quick "status" summary (ideally,
> recursively, i.e. descending into each sub-directory):
> E.g., not-tracked, latest modification is not in
> the index, latest modification is in the index,
> not-modified, and so on. As a hypothetical example
> (`# comments' added to explain what the line means):
>
> $ git some-cmd
> ? foo # not-tracked
> - bar # tracked, not-modified
> M xyzzy # tracked, last modification not-in-index
> I plover # tracked, last modification in-the-index
> ...
> $
Check out this thread:
http://thread.gmane.org/gmane.comp.version-control.git/97830/focus=98041
Hopefully Shawn will unveil his tool soon, and I expect there may be
some discussion about the preferred format.
-Peff
^ permalink raw reply
* Re: git-svnimport.perl bug when copy source path has a revision
From: Karl Chen @ 2008-10-16 18:36 UTC (permalink / raw)
To: Pete Harlan; +Cc: Git mailing list
In-Reply-To: <48F6E29F.1050807@pcharlan.com>
>>>>> On 2008-10-15 23:43 PDT, Pete Harlan writes:
Pete> git svn init -T trunk -t tags $R git svn fetch git log
Pete> tags/mytag
Thanks for the pointer. I do know about git-svn and used it
to convert most of my repositories, but one particular repository
isn't converting with git-svn - it runs for hours before I cancel
it, whereas git-svnimport completes in minutes.
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: David Tweed @ 2008-10-16 16:33 UTC (permalink / raw)
To: Ian Brown; +Cc: Michael J Gruber, git
In-Reply-To: <d0383f90810160923m60ec95d8v8550a611f91176b6@mail.gmail.com>
On Thu, Oct 16, 2008 at 5:23 PM, Ian Brown <ianbrn@gmail.com> wrote:
> Hello,
> Thanks for you quick answer.
>
> ls shows the files.
I'm assuming this is on both the vfat and ext3 disks? All the
filenames' cases are correct?
> git status shows:
> fatal: Not a git repository
> Regards,
> IB
The error message unfortunately really means "git couldn't find
_everything_ needed to be a repository" without saying what precisely
it had problems finding. Educated guess: Have a look in the .git
directory on each disk. Is there a file called 'HEAD' or has its case
been changed?
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: Ian Brown @ 2008-10-16 16:23 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48F76936.3010801@drmicha.warpmail.net>
Hello,
Thanks for you quick answer.
ls shows the files.
git status shows:
fatal: Not a git repository
Regards,
IB
On Thu, Oct 16, 2008 at 6:17 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ian Brown venit, vidit, dixit 16.10.2008 18:03:
>> Hello, ]
>>
>> I have a diskOnKey which has a vfat filesystem.
>> I ran there:
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>> the I copied all the wireless-2.6 folder to an ext3 partition.
>
> How did you copy it?
>
>> There I ran git diff.
>>
>> I get many messages like these (probably on all files of the repository):
>>
>> diff --git a/COPYING b/COPYING
>> deleted file mode 100644
>> index ca442d3..0000000
>> --- a/COPYING
>> +++ /dev/null
>> @@ -1,356 +0,0 @@
>> -
>>
>> and then all the lines of the file with "-" in the beginning, as if
>> they are empty.
>>
>> Why is it so ?
>> Is there any way to overcome it ?
>> Must I run "git clone" on an ext3 DiskOnKey only ?
>
> git diff gives you the difference between the index and the work tree.
> The index is the one you copied from vfat; git doesn't see the files on
> the ext3 work tree. Do you see them with ls?
>
> One by one I would try
>
> git status
> git reset
> git reset --hard
>
> in order to reconcile your index with your checkout. You probably need
> the last one.
>
> Michael
>
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: David Tweed @ 2008-10-16 16:22 UTC (permalink / raw)
To: Ian Brown; +Cc: git
In-Reply-To: <d0383f90810160903p6f8ffe77o86fdad5387f82481@mail.gmail.com>
On Thu, Oct 16, 2008 at 5:03 PM, Ian Brown <ianbrn@gmail.com> wrote:
> Hello, ]
>
> I have a diskOnKey which has a vfat filesystem.
> I ran there:
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> the I copied all the wireless-2.6 folder to an ext3 partition.
> There I ran git diff.
>
> I get many messages like these (probably on all files of the repository):
>
> diff --git a/COPYING b/COPYING
> deleted file mode 100644
> index ca442d3..0000000
> --- a/COPYING
> +++ /dev/null
> @@ -1,356 +0,0 @@
> -
>
> and then all the lines of the file with "-" in the beginning, as if
> they are empty.
The first question is what do the directories on the vfat and ext3
disks look like? Are the files like COPYING present in both directory
trees (so git is wrong at that point of the diff) or has something
gone wrong earlier?
> Why is it so ?
> Is there any way to overcome it ?
> Must I run "git clone" on an ext3 DiskOnKey only ?
I have certainly cloned onto a vfat partition with no problems,
although I've always done it with a --bare clone because a lot of my
repos have had case sensitive filenames and I've had some problems
with the "git dirent reading code reads back different case file names
than it wrote out and gets confused". If you're only transporting the
repo on the stick, I'd definitely do it via "git clone --bare" just to
reduce the potential for problems.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
^ permalink raw reply
* Re: git and filesystem problems (ext3 and vfat)
From: Michael J Gruber @ 2008-10-16 16:17 UTC (permalink / raw)
To: Ian Brown; +Cc: git
In-Reply-To: <d0383f90810160903p6f8ffe77o86fdad5387f82481@mail.gmail.com>
Ian Brown venit, vidit, dixit 16.10.2008 18:03:
> Hello, ]
>
> I have a diskOnKey which has a vfat filesystem.
> I ran there:
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> the I copied all the wireless-2.6 folder to an ext3 partition.
How did you copy it?
> There I ran git diff.
>
> I get many messages like these (probably on all files of the repository):
>
> diff --git a/COPYING b/COPYING
> deleted file mode 100644
> index ca442d3..0000000
> --- a/COPYING
> +++ /dev/null
> @@ -1,356 +0,0 @@
> -
>
> and then all the lines of the file with "-" in the beginning, as if
> they are empty.
>
> Why is it so ?
> Is there any way to overcome it ?
> Must I run "git clone" on an ext3 DiskOnKey only ?
git diff gives you the difference between the index and the work tree.
The index is the one you copied from vfat; git doesn't see the files on
the ext3 work tree. Do you see them with ls?
One by one I would try
git status
git reset
git reset --hard
in order to reconcile your index with your checkout. You probably need
the last one.
Michael
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Pieter de Bie @ 2008-10-16 15:37 UTC (permalink / raw)
To: Brandon Casey
Cc: Jeff King, Junio C Hamano, git, Arjen Laarhoven, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <0my5lujnbpdG6sxrffMExwukINu2tasxBSH0E0xYQoe6y5yyFL0LNA@cipher.nrlssc.navy.mil>
On 16 okt 2008, at 17:21, Brandon Casey wrote:
> Darwin, anyone?
'maint' passes for me on Darwin (OS X Leopard) after removing the
regex stuff in Makefile
- Pieter
^ permalink raw reply
* git and filesystem problems (ext3 and vfat)
From: Ian Brown @ 2008-10-16 16:03 UTC (permalink / raw)
To: git
Hello, ]
I have a diskOnKey which has a vfat filesystem.
I ran there:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
the I copied all the wireless-2.6 folder to an ext3 partition.
There I ran git diff.
I get many messages like these (probably on all files of the repository):
diff --git a/COPYING b/COPYING
deleted file mode 100644
index ca442d3..0000000
--- a/COPYING
+++ /dev/null
@@ -1,356 +0,0 @@
-
and then all the lines of the file with "-" in the beginning, as if
they are empty.
Why is it so ?
Is there any way to overcome it ?
Must I run "git clone" on an ext3 DiskOnKey only ?
Regards,
Ian
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Thomas Rast @ 2008-10-16 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
You wrote:
> * tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
> + Documentation: Refer to git-rebase(1) to warn against rewriting
> + Documentation: new upstream rebase recovery section in git-rebase
>
> Shawn says that an update came in recently, but they are not here yet.
> I'd need to dig it up, but I haven't had time.
The one you commented on was the last iteration. I hope to find the
time to reroll the next (perhaps final) iteration this weekend.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Usability of git stash
From: Brandon Casey @ 2008-10-16 15:22 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86vdvsg4up.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Anders Melchiorsen wrote:
>>
>>> When trying to recover from that scenario, I do "git stash apply" as
>>> recommended by the "git stash" output. Now I still lost my index
>>> state, all changes are unstaged.
>> See the documentation, apply has a '--index' option.
>
> Still, the shoot-yourself-in-the-foot potential is quite larger than
> appropriate for what is mostly workflow porcelaine. It is even larger
> than appropriate for plumbing IMHO.
I think it is excessive to call the action taken by 'git stash', when it
is unwanted, "shoot[ing]-yourself-in-the-foot". More like stub-your-toe.
In exchange for allowing new users to stub their toe on new commands, the
work flow of more experienced users is made a little easier.
> I mean, even misspellings like
> git stash lisp
>
> cause action that is not easily reversible, and the given help output is
> misleading with regard to index state.
$ git stash lisp
Usage: git stash list [<options>]
or: git stash (show | drop | pop ) [<stash>]
or: git stash apply [--index] [<stash>]
or: git stash branch <branchname> [<stash>]
or: git stash [save [--keep-index] [<message>]]
or: git stash clear
Maybe you are referring to the long since changed behavior where
'git stash' == 'git stash save' and so "lisp" in your example
would have been taken as a stash description. This behavior existed
for less than 6 months, and has been changed now for over 10 months.
-brandon
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Brandon Casey @ 2008-10-16 15:21 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Arjen Laarhoven, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <20081016100805.GA20762@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 15, 2008 at 10:35:30AM -0500, Brandon Casey wrote:
>
>> 2) Do we want to stick with compat/regex on
>>
>> Darwin: Arjen
>> FreeBSD: Jeff
>> AIX: Mike
>>
>> now that the builtin funcname patterns have been converted to Extended
>> Regular Expressions?
>
> t4018 passes without compat/regex on FreeBSD. Is that a sufficient test?
I think so. t4018 makes sure all the patterns compile, and includes Arjen's test
for appropriate handling of the alternation operator.
Darwin, anyone?
-brandon
^ permalink raw reply
* Re: [PATCH] refactor handling of "other" files in ls-files and status
From: Jeff King @ 2008-10-16 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailinglist
In-Reply-To: <20081016145916.GA31859@sigill.intra.peff.net>
On Thu, Oct 16, 2008 at 10:59:16AM -0400, Jeff King wrote:
> This patch pulls the ls-files code into a new function,
> cache_name_is_other, and uses it in both places. This should
> leave the ls-files functionality the same and fix the bug
> in status.
BTW, this is probably maint-worthy, but I prepared it on 'master'.
Unfortunately, there is a purely textual conflict when applying to
maint. For your convenience, here's a rebase to maint:
-- >8 --
refactor handling of "other" files in ls-files and status
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-ls-files.c | 33 ++-------------------------------
cache.h | 2 ++
read-cache.c | 28 ++++++++++++++++++++++++++++
t/t7502-status.sh | 6 ++++++
wt-status.c | 15 ++-------------
5 files changed, 40 insertions(+), 44 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 068f424..b48327d 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -91,39 +91,10 @@ static void show_other_files(struct dir_struct *dir)
{
int i;
-
- /*
- * Skip matching and unmerged entries for the paths,
- * since we want just "others".
- *
- * (Matching entries are normally pruned during
- * the directory tree walk, but will show up for
- * gitlinks because we don't necessarily have
- * dir->show_other_directories set to suppress
- * them).
- */
for (i = 0; i < dir->nr; i++) {
struct dir_entry *ent = dir->entries[i];
- int len, pos;
- struct cache_entry *ce;
-
- /*
- * Remove the '/' at the end that directory
- * walking adds for directory entries.
- */
- len = ent->len;
- if (len && ent->name[len-1] == '/')
- len--;
- pos = cache_name_pos(ent->name, len);
- if (0 <= pos)
- continue; /* exact match */
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == len &&
- !memcmp(ce->name, ent->name, len))
- continue; /* Yup, this one exists unmerged */
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
show_dir_entry(tag_other, ent);
}
}
diff --git a/cache.h b/cache.h
index 884fae8..76730ce 100644
--- a/cache.h
+++ b/cache.h
@@ -270,6 +270,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define ce_match_stat(ce, st, options) ie_match_stat(&the_index, (ce), (st), (options))
#define ce_modified(ce, st, options) ie_modified(&the_index, (ce), (st), (options))
#define cache_name_exists(name, namelen, igncase) index_name_exists(&the_index, (name), (namelen), (igncase))
+#define cache_name_is_other(name, namelen) index_name_is_other(&the_index, (name), (namelen))
#endif
enum object_type {
@@ -382,6 +383,7 @@ extern int add_to_index(struct index_state *, const char *path, struct stat *, i
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
+extern int index_name_is_other(const struct index_state *, const char *, int);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index 8f96fd1..4e067e4 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1480,3 +1480,31 @@ int read_index_unmerged(struct index_state *istate)
istate->cache_nr = dst - istate->cache;
return !!last;
}
+
+/*
+ * Returns 1 if the path is an "other" path with respect to
+ * the index; that is, the path is not mentioned in the index at all,
+ * either as a file, a directory with some files in the index,
+ * or as an unmerged entry.
+ *
+ * We helpfully remove a trailing "/" from directories so that
+ * the output of read_directory can be used as-is.
+ */
+int index_name_is_other(const struct index_state *istate, const char *name,
+ int namelen)
+{
+ int pos;
+ if (namelen && name[namelen - 1] == '/')
+ namelen--;
+ pos = index_name_pos(istate, name, namelen);
+ if (0 <= pos)
+ return 0; /* exact match */
+ pos = -pos - 1;
+ if (pos < istate->cache_nr) {
+ struct cache_entry *ce = istate->cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, name, namelen))
+ return 0; /* Yup, this one exists unmerged */
+ }
+ return 1;
+}
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
index c8e4c2e..187a13e 100755
--- a/t/t7502-status.sh
+++ b/t/t7502-status.sh
@@ -285,6 +285,12 @@ test_expect_success 'status submodule summary is disabled by default' '
test_cmp expect output
'
+# we expect the same as the previous test
+test_expect_success 'status --untracked-files=all does not show submodule' '
+ git status --untracked-files=all >output &&
+ test_cmp expect output
+'
+
head=$(cd sm && git rev-parse --short=7 --verify HEAD)
cat >expect <<EOF
diff --git a/wt-status.c b/wt-status.c
index 889e50f..64cedfc 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -275,20 +275,9 @@ static void wt_status_print_untracked(struct wt_status *s)
read_directory(&dir, ".", "", 0, NULL);
for(i = 0; i < dir.nr; i++) {
- /* check for matching entry, which is unmerged; lifted from
- * builtin-ls-files:show_other_files */
struct dir_entry *ent = dir.entries[i];
- int pos = cache_name_pos(ent->name, ent->len);
- struct cache_entry *ce;
- if (0 <= pos)
- die("bug in wt_status_print_untracked");
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == ent->len &&
- !memcmp(ce->name, ent->name, ent->len))
- continue;
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
if (!shown_header) {
s->workdir_untracked = 1;
wt_status_print_header(s, "Untracked files",
--
1.6.0.2.710.gc3f34.dirty
^ permalink raw reply related
* Re: Rebasing Multiple branches at once...
From: Robin Burchell @ 2008-10-16 15:02 UTC (permalink / raw)
To: Rick Moynihan; +Cc: David Kastrup, git
In-Reply-To: <48F75657.6010308@calicojack.co.uk>
On Thu, Oct 16, 2008 at 3:57 PM, Rick Moynihan <rick@calicojack.co.uk> wrote:
>
> This appears to be true of the current implementation, but shouldn't it be
> possible to do this as a single operation?
>
> e.g. when the situation is this with dev being the current branch.
>
> o---o---o---o---o master
> \
> o---o---o---o---o dev (*)
> \
> o---o---o topic
>
> Running the hypothetical command:
>
> git rebase master --all
>
> Would produce this:
>
> o---o---o---o---o master
> \
> o---o---o---o---o dev (*)
> \
> o---o---o topic
>
> I think this can be performed right now with a rebase followed by a rebase
> --onto
>
> I can see how if there were conflicts in the rebase from dev, then you would
> need to resolve them all the way up your topic branches also. Is there
> anything else that makes this a bad idea?
>
> R.
Rebase is indeed useful IMHO in situations like this with multiple
related topic branches when needing to pull a single fix or two from
somewhere without messy merges (especially when that will end up with
rather a lot of merge commits in history - one or so for each branch,
which is not exactly desirable).
(resent after I learned how to use 'reply to all', sorry Rick)
^ permalink raw reply
* [PATCH] refactor handling of "other" files in ls-files and status
From: Jeff King @ 2008-10-16 14:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hoss, Johannes Sixt, Pedro Melo, Pieter de Bie,
Git Mailinglist
In-Reply-To: <20081016141812.GA30026@sigill.intra.peff.net>
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
---
On Thu, Oct 16, 2008 at 10:18:13AM -0400, Jeff King wrote:
> But the right solution is to refactor this so the code isn't duplicated.
> And I'll post a patch for that in a second.
Here it is.
> I do have to wonder, though, whether an even better solution would be to
> more explicitly tell read_directory "I'm interested only in 'other'
> files" rather than relying on guessing based on
> dir.show_other_directories. Then we could just avoid ever passing these
> gitlinks back to ls-files and status in the first place.
I was thinking such a change would get rid of the need for my patch,
since all files returned _would_ be "others". However, we would still
need to deal with the "unmerged entries" problem, so I think this
refactoring is worth it regardless.
builtin-ls-files.c | 33 ++-------------------------------
cache.h | 2 ++
read-cache.c | 27 +++++++++++++++++++++++++++
t/t7502-status.sh | 6 ++++++
wt-status.c | 15 ++-------------
5 files changed, 39 insertions(+), 44 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 068f424..b48327d 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -91,39 +91,10 @@ static void show_other_files(struct dir_struct *dir)
{
int i;
-
- /*
- * Skip matching and unmerged entries for the paths,
- * since we want just "others".
- *
- * (Matching entries are normally pruned during
- * the directory tree walk, but will show up for
- * gitlinks because we don't necessarily have
- * dir->show_other_directories set to suppress
- * them).
- */
for (i = 0; i < dir->nr; i++) {
struct dir_entry *ent = dir->entries[i];
- int len, pos;
- struct cache_entry *ce;
-
- /*
- * Remove the '/' at the end that directory
- * walking adds for directory entries.
- */
- len = ent->len;
- if (len && ent->name[len-1] == '/')
- len--;
- pos = cache_name_pos(ent->name, len);
- if (0 <= pos)
- continue; /* exact match */
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == len &&
- !memcmp(ce->name, ent->name, len))
- continue; /* Yup, this one exists unmerged */
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
show_dir_entry(tag_other, ent);
}
}
diff --git a/cache.h b/cache.h
index 991544c..ae6647e 100644
--- a/cache.h
+++ b/cache.h
@@ -277,6 +277,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define ce_match_stat(ce, st, options) ie_match_stat(&the_index, (ce), (st), (options))
#define ce_modified(ce, st, options) ie_modified(&the_index, (ce), (st), (options))
#define cache_name_exists(name, namelen, igncase) index_name_exists(&the_index, (name), (namelen), (igncase))
+#define cache_name_is_other(name, namelen) index_name_is_other(&the_index, (name), (namelen))
#endif
enum object_type {
@@ -393,6 +394,7 @@ extern int add_to_index(struct index_state *, const char *path, struct stat *, i
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
+extern int index_name_is_other(const struct index_state *, const char *, int);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index c229fd4..780f2c7 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1565,3 +1565,30 @@ int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
return !!data.add_errors;
}
+/*
+ * Returns 1 if the path is an "other" path with respect to
+ * the index; that is, the path is not mentioned in the index at all,
+ * either as a file, a directory with some files in the index,
+ * or as an unmerged entry.
+ *
+ * We helpfully remove a trailing "/" from directories so that
+ * the output of read_directory can be used as-is.
+ */
+int index_name_is_other(const struct index_state *istate, const char *name,
+ int namelen)
+{
+ int pos;
+ if (namelen && name[namelen - 1] == '/')
+ namelen--;
+ pos = index_name_pos(istate, name, namelen);
+ if (0 <= pos)
+ return 0; /* exact match */
+ pos = -pos - 1;
+ if (pos < istate->cache_nr) {
+ struct cache_entry *ce = istate->cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, name, namelen))
+ return 0; /* Yup, this one exists unmerged */
+ }
+ return 1;
+}
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
index 1905fb3..93f875f 100755
--- a/t/t7502-status.sh
+++ b/t/t7502-status.sh
@@ -292,6 +292,12 @@ test_expect_success 'status submodule summary is disabled by default' '
test_cmp expect output
'
+# we expect the same as the previous test
+test_expect_success 'status --untracked-files=all does not show submodule' '
+ git status --untracked-files=all >output &&
+ test_cmp expect output
+'
+
head=$(cd sm && git rev-parse --short=7 --verify HEAD)
cat >expect <<EOF
diff --git a/wt-status.c b/wt-status.c
index d2eac36..c3a9cab 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -277,20 +277,9 @@ static void wt_status_print_untracked(struct wt_status *s)
read_directory(&dir, ".", "", 0, NULL);
for(i = 0; i < dir.nr; i++) {
- /* check for matching entry, which is unmerged; lifted from
- * builtin-ls-files:show_other_files */
struct dir_entry *ent = dir.entries[i];
- int pos = cache_name_pos(ent->name, ent->len);
- struct cache_entry *ce;
- if (0 <= pos)
- die("bug in wt_status_print_untracked");
- pos = -pos - 1;
- if (pos < active_nr) {
- ce = active_cache[pos];
- if (ce_namelen(ce) == ent->len &&
- !memcmp(ce->name, ent->name, ent->len))
- continue;
- }
+ if (!cache_name_is_other(ent->name, ent->len))
+ continue;
if (!shown_header) {
s->workdir_untracked = 1;
wt_status_print_untracked_header(s);
--
1.6.0.2.710.gc3f34.dirty
^ permalink raw reply related
* Re: Rebasing Multiple branches at once...
From: Rick Moynihan @ 2008-10-16 14:57 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <8663nsfxoq.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Rick Moynihan <rick@calicojack.co.uk> writes:
>
>> Hi,
>>
>> I have a master branch, a dev branch and a number of feature branches
>> from dev. And I was wondering if there was an easy way to rebase dev
>> and all of it's sub-branches onto master.
>>
>> I know I can run this as a series of commands, and use --onto to do
>> this, but was wondering if there was an easier way. As running:
>>
>> git rebase master
>>
>> when on the dev branch only rebases dev and not it's dependent branches.
>
> Rebasing has no relation to dependent branches. It creates a new branch
> from the branch point. After it finishes, it just reseats HEAD of the
> branch to the new one. There is no operation that would work implicitly
> on originally dependent branches.
This appears to be true of the current implementation, but shouldn't it
be possible to do this as a single operation?
e.g. when the situation is this with dev being the current branch.
o---o---o---o---o master
\
o---o---o---o---o dev (*)
\
o---o---o topic
Running the hypothetical command:
git rebase master --all
Would produce this:
o---o---o---o---o master
\
o---o---o---o---o dev (*)
\
o---o---o topic
I think this can be performed right now with a rebase followed by a
rebase --onto
I can see how if there were conflicts in the rebase from dev, then you
would need to resolve them all the way up your topic branches also. Is
there anything else that makes this a bad idea?
R.
^ 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