On Tue, Jan 20, 2015 at 10:38:40PM +0100, Noralf Trønnes wrote:
> Yes:
> $ echo Noralf Trønnes | xxd
> 000: 4e6f 7261 6c66 2054 72f8 6e6e 6573 0aNoralf Tr.nnes.
>
> Is there a command I can run that shows that I'm using ISO-8859-1 ?
> I need something to google with, my previous search onl
Is there a plan for upgrading to a better hash function in the future?
(E.g., should it become an urgent need.)
What are the roadblocks to adoption of a replacement hash function?
Just documenting this would go a long way towards making it possible
to upgrade some day.
Thanks,
Nico
--
--
To uns
No code == no substance might be a stretch, but definitely fair enough.
I thought the idea was clear enough, but I can flesh it out if
desired. The particular advantage I saw in it is that it would reuse
the existing object infrastructure, and extend to branches the
first-class treatment that [si
On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote:
> While signed tags and commits assert that the objects thusly signed
> came from you, who signed these objects, there is not a good way to
> assert that you wanted to have a particular object at the tip of a
> particular branch. My s
IIUC, this might help,
http://www.mail-archive.com/git@vger.kernel.org/msg56418.html
http://www.mail-archive.com/git@vger.kernel.org/msg56468.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
On Fri, Aug 08, 2014 at 10:34:43AM -0700, Mike Stump wrote:
> On Aug 6, 2014, at 10:11 PM, Nico Williams wrote:
> > Nah. Sun managed this for decades without a hitch, and for products
> > much larger than GCC. See above.
>
> Ok. Ah, ok, perfect. I see how that method
On Thu, Aug 7, 2014 at 6:38 AM, Tony Finch wrote:
> So I have a small tool which maintains a publication branch which tracks
> the head of a rebasing branch. It's reasonably satisfactory so far...
>
> https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git
>
> ... though the structure of the publication
On Thu, Aug 7, 2014 at 12:47 PM, Tony Finch wrote:
> Nico Williams wrote:
>> Either way I retain the old HEAD with some name.
>
> Hmm, yes, I can see that would work. However my previous workflow was
> rather branch-heavy and I found the accumulation of names annoying. I
On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
> Nico Williams wrote:
> > On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
> > > But [a rebasing workflow] is inconvenient for deploying the patched
> > > version to production (which is the point o
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
> I have been fiddling around in this area.
>
> What I want to be able to do is develop fixes for open source code
> that I run, and get those fixes upstream. This means I need a rebasing
> workflow, to keep the patches up-to-date and to
On Wed, Aug 06, 2014 at 05:38:43PM -0700, Mike Stump wrote:
> Oh, wait, maybe I have misunderstood the prohibition. I have:
>
>upstream <—— fsf
>|
> \
> |
> v
> Me <—> master <—> coworker.
This looks a lot like what I meant about pro
On Wed, Aug 06, 2014 at 02:44:59PM -0500, Nico Williams wrote:
> That means that you have/maintain an intermediate upstream, yes?
>
> This is a bit trickier since once in a while that intermediate upstream
> and everyone downstream of it has to catch up with the real upstream.
>
On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
> On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams wrote:
> > My proposal was to put this sort of ancillary history info in a
> > "branch object" (and that branches should be objects). This would
> > hav
On Wed, Aug 06, 2014 at 12:11:16PM -0700, Mike Stump wrote:
> On Aug 1, 2014, at 4:40 PM, Nico Williams wrote:
> > As for rebase, I still don't understand why it doesn't work for you.
>
> http://git-scm.com/docs/git-rebase says:
>
> Rebasing (or any other f
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski wrote:
> W dniu 2014-08-01 22:55, Nico Williams pisze:
>> It would help if cherry-pick history where recorded somewhere (beyond
>> the reflog)...
>>
>> Cherry-picks should record two parents, like merges.
>>
>&
Excellent. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Personally (a user of, not a maintainer of, git) I really want some
alternative backends. In particular I'm after something like Fossil's
use of SQLite3; I want a SQLite3 backend for several reasons, not the
least of which is the power of SQL for looking at history.
I'm not sure that I necessaril
On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump wrote:
> On Aug 1, 2014, at 1:12 PM, Sam Vilain wrote:
>> Git merge has a notion of discrete "merge strategies”.
>
>> There's no particular reason that you couldn't implement a merge
>> strategy which works more like SVN's approach, which essentially doe
On Fri, Aug 1, 2014 at 5:13 PM, Mike Stump wrote:
> On Aug 1, 2014, at 12:22 PM, Nico Williams wrote:
>> If you always rebase
>
> I can’t use rebase unless you make rebase work with multiple users and
> pushing pulling.
That works now, and I do it all the time. Have a singl
On Fri, Aug 1, 2014 at 4:44 PM, Junio C Hamano wrote:
> Nico Williams writes:
>
>> Cherry-picks should record two parents, like merges.
>
> No.
>
> It is OK to record where it came from, and we let you do so with the
> "-x" option.
>
> But the "w
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
>> Do you mean that "git merge" should be aware of what changes you have
>> already cherry-picked?
>>
>> It isn't, and that's deliberate
>
> That said, when today's "git merge" fails to resolve conflicts, it's
> easi
On Thursday, July 31, 2014, Mike Stump wrote:
>
> Cherry picking doesn’t work as well as it should. I was testing on git
> version 1.7.9.5.
>
> Put in a line in a file, call it:
>
> first version
>
> then cherry pick this into your branch. Then update on master and transform
> that into:
>
> se
On Friday, August 1, 2014, Dennis Kaarsemaker wrote:
>
> On di, 2014-07-29 at 17:40 -0500, Nico Williams wrote:
> > (or all of a repo's branches)
> >
> > Teamware recorded whether it had any "children" and warned about
> > rebasing published cont
On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:
> Nico Williams writes:
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I gave).
(or all of a repo's branches)
Teamware recorded whether it had any "children" and warned about
rebasing published contents. Perhaps git could do the same.
Nico
--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley wrote:
> From: "Nico Williams"
>> That workflow works just fine with git.
>
> I'm not saying that it isn't a good technique and can work well. Rather I'm
> saying we should be tolerant of the rules and te
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley wrote:
> From: "Nico Williams"
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I ga
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
> Nico Williams writes:
>> That exception aside, keeping all local commits "on top" by always
>> rebasing them onto the upstream is extremely useful: a) in simplifying
>> conflict resolution, b) making it easy
On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where th
> Still, git might like to know what ACLs to apply to files at checkout
> time. That would be a vast new feature, I think, and probably not
> worth it, particularly since that would require dealing with the
> different types of ACLs: NTFS/NFSv4/ZFS on the one hand, POSIX Draft
> on the other, plus
On Mon, Jul 14, 2014 at 6:31 AM, Erik Faye-Lund wrote:
> On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong wrote:
>> Torsten Bögershausen wrote:
>>
>
> You're saying this as if Windows is a single-user system. It's not,
> but it uses ACLs rather than POSIX permissions to manage file-system
> permission
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
>
> On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
> >
> > Now, suppose that branches were objects. Then at push time one might
> > push with a message about the set of commits being pushed, and
(thinking more about this, digesting Jonathan's response...)
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but all pus
On Fri, Jun 20, 2014 at 1:53 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> [...]
>
> Hmph, but that obviously will become very expensive to compute as
> project grows.
That's the main reason to like Fossil's approach (namely, the use of
SQL, specifically SQLite3): you can write declara
Another thing is that branches as objects could store a lot more
information, like:
- the merge-base and HEAD for a rebase (and the --onto)
- the interactive rebase plan! (and diffs to what would have been
the non-interactive plan)
- the would-be no-op non-interactive rebase plan post rebase
On Thu, Jun 19, 2014 at 6:46 PM, Jonathan Nieder wrote:
> Nico Williams wrote:
>
>> - one could see the history of branches, including
>
> Interesting. 'git log -g' is good for getting that information
> locally, but the protocol doesn't have a way to get i
[I'm a list newbie here, but a git power user.]
If branches were objects...
- one could see the history of branches, including
- how commits were grouped when pushed/pulled (push 5 commits, and
the branch object will record that its head moved by those five
commits at once)
- rebase history
37 matches
Mail list logo
