* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Karl Hasselström @ 2007-10-31 14:00 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Björn Steinbrink, Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <20071031134358.GD15182@dpotapov.dyndns.org>
On 2007-10-31 16:43:58 +0300, Dmitry Potapov wrote:
> I believe that the issue is with Junio's mail client. Indeed, the
> context encoding for the mail *body* was specified as 8859-1, but
> that should have none effect on fields in the mail header, because
> any field is the header should be either printable ASCII or encoded
> to contain only ASCII characters as specified in RFC 1522:
Yes. But it's the body that's been mangled -- specifically, the
Sign-off line.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: cpio command not found
From: David Symonds @ 2007-10-31 14:00 UTC (permalink / raw)
To: Bill Lear; +Cc: Karl Hasselström, git
In-Reply-To: <18216.35066.259686.376571@lisa.zopyra.com>
On 11/1/07, Bill Lear <rael@zopyra.com> wrote:
> On Wednesday, October 31, 2007 at 14:30:39 (+0100) Karl Hasselström writes:
> >On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> >
> >> I don't remember this dependence from earlier versions of git. I
> >> have been running git 1.4.xx on this machine for a while...
> >
> >When you clone with -l, git uses cpio to hardlink to the original
> >repository. What has changed is that -l is now used by default when
> >cloning a repository that's accessed via the file system (as opposed
> >to over some network protocol).
> >
> >To work around this, specify the repository location with file://, and
> >git won't try to hardlink (and hence won't try to use cpio).
>
> Hmm, thanks for the workaround, but I don't altogether like leaving
> things like this.
>
> If the system does not have cpio, I think the build of git should
> complain and fail, or it should activate code that treats any
> repository accessed over the file system as it would file://.
Something like this could be done at run-time instead. You might
install cpio, but shouldn't require a rebuild of git just to use it.
Dave.
^ permalink raw reply
* [PATCH] git-diff.txt: add section "output format" describing the diff formats
From: Gerrit Pape @ 2007-10-31 13:59 UTC (permalink / raw)
To: git, Junio C Hamano
git-diff.txt includes diff-options.txt which for the -p option refers
to a section "generating patches.." which is missing from the git-diff
documentation. This patch adapts diff-format.txt to additionally
mention the git-diff program, and includes diff-format.txt into
git-diff.txt.
Tino Keitel noticed this problem.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/diff-format.txt | 22 +++++++++++-----------
Documentation/git-diff.txt | 3 +++
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 0015032..a580f18 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -1,5 +1,5 @@
-The output format from "git-diff-index", "git-diff-tree" and
-"git-diff-files" are very similar.
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
These commands all compare two sets of things; what is
compared differs:
@@ -62,9 +62,9 @@ respectively.
diff format for merges
----------------------
-"git-diff-tree" and "git-diff-files" can take '-c' or '--cc' option
-to generate diff output also for merge commits. The output differs
-from the format described above in the following way:
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to generate diff output also for merge commits. The
+output differs from the format described above in the following way:
. there is a colon for each parent
. there are more "src" modes and "src" sha1
@@ -86,10 +86,10 @@ Generating patches with -p
--------------------------
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
-with a '-p' option, they do not produce the output described above;
-instead they produce a patch file. You can customize the creation
-of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
-environment variables.
+with a '-p' option, or "git diff" without the '--raw' option, they
+do not produce the output described above; instead they produce a
+patch file. You can customize the creation of such patches via the
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
What the -p option produces is slightly different from the traditional
diff format.
@@ -137,8 +137,8 @@ file made it into the new one.
combined diff format
--------------------
-git-diff-tree and git-diff-files can take '-c' or '--cc' option
-to produce 'combined diff', which looks like this:
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to produce 'combined diff', which looks like this:
------------
diff --combined describe.c
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index ce0f502..11c4216 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -82,6 +82,9 @@ include::diff-options.txt[]
the diff to the named paths (you can give directory
names and get diff for all files under them).
+Output format
+-------------
+include::diff-format.txt[]
EXAMPLES
--------
--
1.5.3.4
^ permalink raw reply related
* Re: cpio command not found
From: Bill Lear @ 2007-10-31 13:54 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20071031133039.GA29065@diana.vm.bytemark.co.uk>
On Wednesday, October 31, 2007 at 14:30:39 (+0100) Karl Hasselström writes:
>On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
>
>> I don't remember this dependence from earlier versions of git. I
>> have been running git 1.4.xx on this machine for a while...
>
>When you clone with -l, git uses cpio to hardlink to the original
>repository. What has changed is that -l is now used by default when
>cloning a repository that's accessed via the file system (as opposed
>to over some network protocol).
>
>To work around this, specify the repository location with file://, and
>git won't try to hardlink (and hence won't try to use cpio).
Hmm, thanks for the workaround, but I don't altogether like leaving
things like this.
If the system does not have cpio, I think the build of git should
complain and fail, or it should activate code that treats any
repository accessed over the file system as it would file://.
No sense in leaving this surprise to the user so late in the cycle.
Bill
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Dmitry Potapov @ 2007-10-31 13:43 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <20071031055303.GB3326@atjola.homenet>
On Wed, Oct 31, 2007 at 06:53:03AM +0100, Björn Steinbrink wrote:
> On 2007.10.30 22:05:27 -0700, Junio C Hamano wrote:
> > Your MUA seems to mark the UTF-8 message you are sending out as
> > 8859-1, which means your name in the message gets corrupt.
>
> Hm, that would be git-send-email then, anything I need to configure?
> (Actually I don't see it marking the message as anything)
I believe that the issue is with Junio's mail client. Indeed, the
context encoding for the mail *body* was specified as 8859-1, but
that should have none effect on fields in the mail header, because
any field is the header should be either printable ASCII or encoded
to contain only ASCII characters as specified in RFC 1522:
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
Here is the From field from the mail:
From: =?utf-8?q?Bj=C3=B6rn=20Steinbrink?= <B.Steinbrink@gmx.de>
So, as far as I can tell, it is encoded properly using utf-8.
Dmitry
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 13:43 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <200710311343.58414.johan@herland.net>
Hi,
On Wed, 31 Oct 2007, Johan Herland wrote:
> On Wednesday 31 October 2007, Johannes Schindelin wrote:
>
> > On Wed, 31 Oct 2007, Peter Karlsson wrote:
> >
> > > Johannes Schindelin:
> > >
> > > > Why should it? This would contradict the whole "a commit sha1
> > > > hashes the commit, and by inference the _whole_ history"
> > > > principle.
> > >
> > > Does it?
> >
> > Yes! Of course! If what you want becomes possible, I could make an
> > evil change in history long gone, and slip it by you. You could not
> > even see the history which changed.
>
> Well, technically, if the grafts file was part of the repo, you wouldn't
> be able to change the (in-tree) grafts file without affecting the SHA1
> of HEAD. In other words, given a commit SHA1 sum, you can be sure that
> someone else who checks out the same commit (and has no local
> modification to their grafts file) will see exactly the same history as
> you do.
All this does not change the fact that installing a graft and 'git gc
--prune'ing gets rid of the old history. D'oh.
Automatically installing grafts is wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: cpio command not found
From: Karl Hasselström @ 2007-10-31 13:30 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18216.31314.990545.518458@lisa.zopyra.com>
On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> I don't remember this dependence from earlier versions of git. I
> have been running git 1.4.xx on this machine for a while...
When you clone with -l, git uses cpio to hardlink to the original
repository. What has changed is that -l is now used by default when
cloning a repository that's accessed via the file system (as opposed
to over some network protocol).
To work around this, specify the repository location with file://, and
git won't try to hardlink (and hence won't try to use cpio).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Aidan Van Dyk @ 2007-10-31 12:40 UTC (permalink / raw)
To: dev; +Cc: git
In-Reply-To: <200710302244.50034.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> I use fromcvs which is *very* fast, and quite memory conservative compared
> to the others and seems reliable so far (six months). It probably breaks
> on exotic variants of branches though, but I don't have those / don't care
> about them.
I actually use fromcvs for a few repositories, and actually started using it
on repositories where cvsps (and git-cvsimport) fail.
> Drawbacks, more dependencies and access to the rcs files is required and
> tags are not converted.
Most projects have "rsyncs" or "tarballs" of their CVS repository available,
making fromcvs possible on most of them. And CVS tags, well they are about
as good as CVS $Keywords$.
^ permalink raw reply
* cpio command not found
From: Bill Lear @ 2007-10-31 12:51 UTC (permalink / raw)
To: git
I just cloned the latest git and it builds ok, but fails when I clone:
% uname -a
Linux gronk.zopyra.com 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002 i686 unknown
% git --version
git version gitgui.0.8.4.g9c514
% git clone --bare ~/my_repo
Initialized empty Git repository in /repos/git/my_repo/
/opt/git/bin/git-clone: line 297: cpio: command not found
So, should git not check this when it is building? I don't remember
this dependence from earlier versions of git. I have been running git
1.4.xx on this machine for a while...
Bill
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johan Herland @ 2007-10-31 12:43 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <Pine.LNX.4.64.0710311059020.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]
On Wednesday 31 October 2007, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 31 Oct 2007, Peter Karlsson wrote:
>
> > Johannes Schindelin:
> >
> > > Why should it? This would contradict the whole "a commit sha1 hashes
> > > the commit, and by inference the _whole_ history" principle.
> >
> > Does it?
>
> Yes! Of course! If what you want becomes possible, I could make an evil
> change in history long gone, and slip it by you. You could not even see
> the history which changed.
Well, technically, if the grafts file was part of the repo, you wouldn't be
able to change the (in-tree) grafts file without affecting the SHA1 of HEAD.
In other words, given a commit SHA1 sum, you can be sure that someone else
who checks out the same commit (and has no local modification to their grafts
file) will see exactly the same history as you do.
To a certain degree, this is actually "safer" than today's (out-of-tree)
solution, where one can change the grafts file _without_ affecting the
current HEAD (SHA1 sum), and thus will not see the same history as someone
else who checks out the same HEAD. This is of course _intended_ to a certain
degree by the current implementation, but can easily cause confusion if
people lose track of what's in their respective grafts files.
Of course, this is both a blessing and a curse: Say, for example, we have
three commits:
... --> A --> B --> C
and commit B changes the (in-tree) grafts file. Now if I have HEAD @ A, I will
see a different history than if I have HEAD @ C. Worse: If one person has
HEAD @ A, and another person has HEAD @ C, and neither is aware of the grafts
file change in B, there is _plenty_ of room for getting confused if the two
persons start discussing the repo history. Note, however, that similar
confusement can be achieved today if one of the persons forgets having
changed his out-of-tree grafts file
The grafts file concept is very powerful, but can also be extremely confusing.
Adding in-tree versioning of the grafts file will make it more powerful
(since we can now easily share and update "errata" to the repo history), but
it might also make things _orders_of_magnitude_ more confusing (as
demonstrated in the above example, although to be fair, similar confusement
can be had in today's out-of-tree solution). At some point things may become
so confusing that we'd rather drop the feature instead.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 12:32 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Lars Hjemli, Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.64.0710311305290.16298@ds9.cixit.se>
Hi,
On Wed, 31 Oct 2007, Peter Karlsson wrote:
> > Yes! Of course! If what you want becomes possible, I could make an
> > evil change in history long gone, and slip it by you. You could not
> > even see the history which changed.
>
> I would see the grafts file being changed, which would alert me (the
> problem I have with graft is that it *replaces* history information for
> an element, not just *add* to it, which threw me off at my first attempt
> at creating one).
The thing is: it is too easy to overlook a tiny change like this. And it
is very, very difficult to see what it _really_ changed.
Therefore I am _strongly_ opposed to changing the current behaviour.
> > You can do that already. But you have to ask the people at the other
> > end to actually apply the graft.
>
> Last time I tried, git would not add files that was in the ".git"
> subdirectory to version control. I might have done something
> incorrectly, though, so I'll see if it works now.
Well, I was not explicit enough. You can check in the grafts file _under
a different name_. Outside of .git/.
Hth,
Dscho
^ permalink raw reply
* Re: How to remove a specific hunk
From: Pascal Obry @ 2007-10-31 12:24 UTC (permalink / raw)
To: Florian Weimer; +Cc: Johannes Schindelin, Benoit SIGOURE, Alex Riesen, git list
In-Reply-To: <82zlxzsdkf.fsf@mid.bfk.de>
Florian Weimer a écrit :
> I think Benoit wants to remove it from the working copy (and,
> presumably, the index too). "Revert hunk" and "Move hunk to stash"
> might indeed be useful additions to citool.
That was not Benoit but me who asked this question. I want indeed the
hunk to be reverted/removed on the working copy. I had many answers to
do this but I still think a "git reset --interactive" with the
possibility to revert some hunks would be easier.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-31 12:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.64.0710301504270.4362@racer.site>
Johannes Schindelin:
> No. Use filter-branch, and publish the cleaned up history (possibly as a
> new branch/repo).
I'm considering doing this, and just replace the published repository
with the "fixed" one (and fix-up all my clonings of it). I'm having
some problems digesting the git-filter-branch manual page though--is
there an easy way of automating the process, given that I now have a
"grafts" file that expresses what I would like git-filter-branch to do
(I guess it would have to work backwards changing the merge points, to
be able to find all the revisions under the names I've used in the
grafts file)?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-31 12:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lars Hjemli, Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.64.0710311059020.4362@racer.site>
> Yes! Of course! If what you want becomes possible, I could make an
> evil change in history long gone, and slip it by you. You could not
> even see the history which changed.
I would see the grafts file being changed, which would alert me (the
problem I have with graft is that it *replaces* history information for
an element, not just *add* to it, which threw me off at my first
attempt at creating one).
> You can do that already. But you have to ask the people at the other
> end to actually apply the graft.
Last time I tried, git would not add files that was in the ".git"
subdirectory to version control. I might have done something
incorrectly, though, so I'll see if it works now.
> If you really think that, I doubt you understood the issues at hand.
I have, I'm just thinking of the issues that are created by solving the
issues it does solve.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: How to remove a specific hunk
From: Peter Baumann @ 2007-10-31 12:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Benoit SIGOURE, Alex Riesen, Shawn O. Pearce, git list
In-Reply-To: <Pine.LNX.4.64.0710311104450.4362@racer.site>
spearce Cc'ed, because this seems like a nice feature to add to git-gui
In no way should this imply that YOU have to implement this!
On Wed, Oct 31, 2007 at 11:06:18AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 31 Oct 2007, Benoit SIGOURE wrote:
>
> > On Oct 26, 2007, at 9:20 PM, Alex Riesen wrote:
> >
> > > Pascal Obry, Fri, Oct 26, 2007 17:10:38 +0200:
> > > >
> > > > Before committing sometimes I want to remove a specific hunk. Say in
> > > > file a.txt I have in the diff 3 hunks, I want to revert/delete/remove
> > > > the second one. Is there a way to do that ?
> > >
> > > Take a look at git-gui. Try right-clicking in the diff pane at the
> > > bottom.
> >
> > This only allows you to stage a given hunk, not to remove one. Right
> > now I'm in a situation where I need to remove a specific hunk to compile
> > and it's sad that git-gui doesn't provide an option so that you can
> > right-click -> revert hunk.
>
> You have seen that there are two different file lists, "staged changes"
> and "unstaged changes", right? AFAIK if you click on the file in "staged
> changes", you can find the staged hunk and then remove it from the staged
> area.
>
> "Revert hunk" would not make any sense, since the hunk disappears once you
> staged/unstaged it.
>
On the other hand, something like this would allow you to remove bogus
hunks like debug statements you want to lose, because you tested it and
all works now.
Now you first have to stage all the things you want to keep, and then
select "Commit->Revert Changes" in the menu to remove a hunk forever which
is a little clumsy if you have many hunks and just want to remove one of
them. Seems like a nice feature to add to git gui if you throw in an extra
Yes-No question for the user IFF he realy wants to remove the hunk forever.
-Peter
^ permalink raw reply
* Re: How to remove a specific hunk
From: Florian Weimer @ 2007-10-31 11:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, Alex Riesen, git list
In-Reply-To: <Pine.LNX.4.64.0710311104450.4362@racer.site>
* Johannes Schindelin:
> You have seen that there are two different file lists, "staged
> changes" and "unstaged changes", right? AFAIK if you click on the
> file in "staged changes", you can find the staged hunk and then
> remove it from the staged area.
>
> "Revert hunk" would not make any sense, since the hunk disappears
> once you staged/unstaged it.
I think Benoit wants to remove it from the working copy (and,
presumably, the index too). "Revert hunk" and "Move hunk to stash"
might indeed be useful additions to citool.
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* Re: How to remove a specific hunk
From: Johannes Schindelin @ 2007-10-31 11:06 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Alex Riesen, git list
In-Reply-To: <13D08D3F-3647-4E20-AF80-8EC6FD14E66A@lrde.epita.fr>
Hi,
On Wed, 31 Oct 2007, Benoit SIGOURE wrote:
> On Oct 26, 2007, at 9:20 PM, Alex Riesen wrote:
>
> > Pascal Obry, Fri, Oct 26, 2007 17:10:38 +0200:
> > >
> > > I'm very new to Git... but start to love it :)
> > >
> > > Before committing sometimes I want to remove a specific hunk. Say in
> > > file a.txt I have in the diff 3 hunks, I want to revert/delete/remove
> > > the second one. Is there a way to do that ?
> >
> > Take a look at git-gui. Try right-clicking in the diff pane at the
> > bottom.
>
> This only allows you to stage a given hunk, not to remove one. Right
> now I'm in a situation where I need to remove a specific hunk to compile
> and it's sad that git-gui doesn't provide an option so that you can
> right-click -> revert hunk.
You have seen that there are two different file lists, "staged changes"
and "unstaged changes", right? AFAIK if you click on the file in "staged
changes", you can find the staged hunk and then remove it from the staged
area.
"Revert hunk" would not make any sense, since the hunk disappears once you
staged/unstaged it.
Ciao,
Dscho
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 11:01 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Lars Hjemli, Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710311048450.13264@perkele.intern.softwolves.pp.se>
Hi,
On Wed, 31 Oct 2007, Peter Karlsson wrote:
> Johannes Schindelin:
>
> > Why should it? This would contradict the whole "a commit sha1 hashes
> > the commit, and by inference the _whole_ history" principle.
>
> Does it?
Yes! Of course! If what you want becomes possible, I could make an evil
change in history long gone, and slip it by you. You could not even see
the history which changed.
> Why can't the grafts file itself be committed to the repository and live
> in the history?
You can do that already. But you have to ask the people at the other end
to actually apply the graft.
> Well, yeah, the SHA1 hashing is one of Git's main strengths, but it also
> opens up some weaknesses.
If you really think that, I doubt you understood the issues at hand.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-10-31 10:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5jiseh.fsf@gitster.siamese.dyndns.org>
On Oct 31, 2007, at 9:45 AM, Junio C Hamano wrote:
>> - git push can be configuration to push only the current
>> branch, as outlined below. This would certainly work. What
>> I do not like is that you first need to do some configuration
>> before you get a safe working environment.
>
> I would not doubt it would be safer for _your_ workflow, but you
> should consider the risk of making things more cumbersome for
> workflows of others by enforcing that policy.
Together with the '--create' flag it would be safer in all
cases, because it would always do _less_ than what git push
currently does. The safest choice would be if "git push"
refused to do anything until configured appropriately.
"safer" is independent of the workflow.
But I see that it may be more cumbersome depending on the
workflow.
I'm mainly interested in using git against a shared repo,
and make it as simple and as safe as possible to use in
such a setup. I suspect that git is more optimized for the
workflow used for the Linux kernel and for developing git,
which heavily rely on sending patches to mailing lists and
pulling fro read-only repos.
> In other words, don't change anything unless you have a very
> good reason to convince everybody else that it is universally
> a good change to the default.
What I can imagine would not be universally better, but it
would be universally safer. You'd need to either explicitly
tell git push how to act (e.g. '--current' or '--matching'
flags), or you could explicitly configure git to always act in
a specific way. But it would only start to act this way _after_
being configured appropriately.
Steffen
^ permalink raw reply
* Re: Possible bug: git-svn leaves broken tree in case of error
From: Karl Hasselström @ 2007-10-31 10:23 UTC (permalink / raw)
To: Eric Wong; +Cc: Anton Korobeynikov, git
In-Reply-To: <20071031084257.GA2911@mayonaise>
On 2007-10-31 01:42:57 -0700, Eric Wong wrote:
> Warning instead of die-ing here is not a good option, because it can
> lead to inconsistent author data inside populating history. I
> believe it's better to error out immediately so the user can fix
> their authors file.
Yes, that seems to be the only sensible opition.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: How to remove a specific hunk
From: Benoit SIGOURE @ 2007-10-31 10:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git list
In-Reply-To: <20071026192034.GA3062@steel.home>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Oct 26, 2007, at 9:20 PM, Alex Riesen wrote:
> Pascal Obry, Fri, Oct 26, 2007 17:10:38 +0200:
>>
>> I'm very new to Git... but start to love it :)
>>
>> Before committing sometimes I want to remove a specific hunk. Say in
>> file a.txt I have in the diff 3 hunks, I want to revert/delete/remove
>> the second one. Is there a way to do that ?
>
> Take a look at git-gui. Try right-clicking in the diff pane at the
> bottom.
This only allows you to stage a given hunk, not to remove one. Right
now I'm in a situation where I need to remove a specific hunk to
compile and it's sad that git-gui doesn't provide an option so that
you can right-click -> revert hunk.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-31 9:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lars Hjemli, Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.64.0710310227340.4362@racer.site>
Johannes Schindelin:
> Why should it? This would contradict the whole "a commit sha1 hashes the
> commit, and by inference the _whole_ history" principle.
Does it? Why can't the grafts file itself be committed to the repository and
live in the history?
Well, yeah, the SHA1 hashing is one of Git's main strengths, but it also
opens up some weaknesses.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: remote#branch
From: Pascal Obry @ 2007-10-31 9:34 UTC (permalink / raw)
To: David Kastrup
Cc: Jeff King, Linus Torvalds, Matthieu Moy, Tom Prince, Theodore Tso,
Junio C Hamano, Jan Hudec, Johannes Schindelin, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <85pryvzt1h.fsf@lola.goethe.zz>
David Kastrup a écrit :
> You just write <URL:http://host/git repo with spaces in the path> and
> have a good chance it will work.
Well "good chance" is not an option for reliable software :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: remote#branch
From: Pascal Obry @ 2007-10-31 9:33 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, git
In-Reply-To: <20071031015708.GA24403@coredump.intra.peff.net>
Jeff King a écrit :
> 'http://foo.tld/url with a space'
>
> rather than:
>
> http://foo.tld/url+with+a+space
>
> ?
>
> I think the latter is much more common, if only because of the fact that
> copy and paste from most browsers' location bars gives the encoded
> version.
I agree 100%. It is the more common as it follows the standard encoding.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: remote#branch
From: Mike Hommey @ 2007-10-31 9:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <472844D4.8050306@op5.se>
On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
> >Or copied from gitweb.
> >
>
> Perhaps, but I've never seen that done. Partly because you can't be sure
> the HTTP url is the same as the git address (perhaps people are used to
> this from CVS and the likes), and partly because you'd, for most cases,
> want to use git:// or ssh transport instead of http.
>
> It might be nifty to have gitweb print some git-valid locator for a repo
> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
> command-line thingie. I'll look into it when I have leisure.
Hum... it already does print http and git "Mirror URL"s which are ready to
be copy/pasted to feed git clone arguments.
Mike
^ 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